LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   [slackware 13.1] xpdf very slow and cpu goes to 100% (http://www.linuxquestions.org/questions/slackware-14/%5Bslackware-13-1%5D-xpdf-very-slow-and-cpu-goes-to-100-a-844238/)

cacao74 11-14-2010 03:53 PM

[slackware 13.1] xpdf very slow and cpu goes to 100%
 
A brief preamble:

I'm gonna tell you about slackware installation on my notebook, an acer travelmate 800lci.

On this notebook, I successfully installed (and work with) slackware from version 10.0 till the recent 13.0. Upgrading to a new version till using a new internal hard disk (from 40 GB to 160 GB). After upgrade I fully reinstall slackware 12.2 and then upgrade to 13.0.

Now, I had to use the notebook for testing, so I made a new full installation of slackware 13.0 and after some time a new full installation of slackware 13.1.
On this disk (160 GB P-ATA) I have to pass the following parameter to the kernel:
libata.ignore_hpa=1
during installation and boot.
This operation solve the issue that can "see" the full size of the disk (160 GB) and not the 137 GB limit.

--

Only using slackware 13.1, occur a big (for me) problem.
I can fully reproduce it opening any pdf document with xpdf: moving into document with arrow keys make the cpu goes to 100% and page "fault/s" goes from 30 to 8000 and some times 15000 "fault/s". So, xpdf becomes unusable. This problem reflects in similar manner to other software, like firefox.

Here is my question: what type of analisys could I try to solve/analyze this issue? Maybe the kernel, xorg, wtf ?

On slackware 13.0 all works perfectly.

darkstarbyte 11-14-2010 04:00 PM

I heard of similar issues with this and the issue was something to do with the upgrade package.

catkin 11-14-2010 08:11 PM

One solution might be to use eVince instead of Xpdf. Although it is not so lightweight it is very nice to work with.

Richard Cranium 11-15-2010 12:52 AM

Quote:

Originally Posted by cacao74 (Post 4158741)

Only using slackware 13.1, occur a big (for me) problem.
I can fully reproduce it opening any pdf document with xpdf: moving into document with arrow keys make the cpu goes to 100% and page "fault/s" goes from 30 to 8000 and some times 15000 "fault/s". So, xpdf becomes unusable. This problem reflects in similar manner to other software, like firefox.

Here is my question: what type of analisys could I try to solve/analyze this issue? Maybe the kernel, xorg, wtf ?

On slackware 13.0 all works perfectly.

I don't have any issues with xpdf under Slackware64 13.1, much less the one that you describe.

I do see it with xpdf under Slackware 13.1 (the 32bit version) on my other machine.

You could run top (or qps or system monitor) to see what exactly is spiking the CPU. It might be the X server.

cacao74 11-15-2010 01:33 AM

Quote:

Originally Posted by catkin (Post 4158908)
One solution might be to use eVince instead of Xpdf. Although it is not so lightweight it is very nice to work with.

You're right. I could use eVince (not installed), or okular (installed).
Okular works pretty well, but I am a xpdf lover.
;^)

cacao74 11-15-2010 02:04 AM

Quote:

Originally Posted by Richard Cranium (Post 4159075)
I don't have any issues with xpdf under Slackware64 13.1, much less the one that you describe.

I do see it with xpdf under Slackware 13.1 (the 32bit version) on my other machine.

You could run top (or qps or system monitor) to see what exactly is spiking the CPU. It might be the X server.

On slackware64, everything works very well. It's another pc, but the 64bit version is fantastic! No issues for me, now.

On 32 bit version, the problems exists only with the 13.1 of slackware.
I've initially run top when xpdf becomes slowly: top shows 100% of cpu usage related to xpdf process. After that I tried to find some indexes using iostat, vmstat, sar, ... and I founded something with "sar -B". That's why I've written in the initial post about high page fault per second.

To give an idea of the issue, here is some snippet from the shell when I use xpdf.
The file used for test is this:
Code:

[cacao74@tweety ~]$ man -t yes | ps2pdf - cacao.pdf
Open the file with xpdf
[code]
[cacao74@tweety ~]$ xpdf -z width -g 640x400 cacao.pdf &
[1] 3392
On other 2 xterm window, I trace top and sar output (filtered) that show some indexes of using xpdf. The highest value of cpu% usage (top) and fault/s (sar), are related to pressing arrow down key to scroll down the pdf document till the end of the page.

output of top:
Code:

[cacao74@tweety ~]$ top -p 3392 -b -n 20 -d 1 | grep "PID\|xpdf"
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13264 9044 3852 S  0.0  0.7  0:00.15 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13264 9044 3852 S  0.0  0.7  0:00.15 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13264 9044 3852 S  1.0  0.7  0:00.16 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13264 9044 3852 S  0.0  0.7  0:00.16 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13368 9048 3852 S  8.0  0.7  0:00.24 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13368 8912 3852 R 57.8  0.7  0:00.82 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13368 9048 3852 R 84.8  0.7  0:01.67 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13368 7244 3852 R 89.8  0.6  0:02.57 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13368 9048 3852 R 87.8  0.7  0:03.45 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13368 9048 3852 S 79.8  0.7  0:04.25 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13368 9048 3852 S  0.0  0.7  0:04.25 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13368 9048 3852 S  0.0  0.7  0:04.25 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13368 9048 3852 S  0.0  0.7  0:04.25 xpdf             
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 3392 cacao74  20  0 13368 9048 3852 S  0.0  0.7  0:04.25 xpdf

output of sar:
Code:

[cacao74@tweety ~]$ sar -B 1 20
Linux 2.6.33.4-smp (tweety)    15/11/2010      _i686_  (1 CPU)

08:54:38    pgpgin/s pgpgout/s  fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
08:54:39        0,00      0,00    35,00      0,00    131,00      0,00      0,00      0,00      0,00
08:54:40        0,00      0,00    38,00      0,00    73,00      0,00      0,00      0,00      0,00
08:54:41        0,00      0,00    959,60      0,00  1510,10      0,00      0,00      0,00      0,00
08:54:42        0,00      0,00  4796,04      0,00  7770,30      0,00      0,00      0,00      0,00
08:54:43        0,00    44,00  10894,00      0,00  15914,00      0,00      0,00      0,00      0,00
08:54:44        0,00      0,00  9656,00      0,00  14695,00      0,00      0,00      0,00      0,00
08:54:45        0,00      0,00  9199,00      0,00  15472,00      0,00      0,00      0,00      0,00
08:54:46        0,00      0,00  9312,00      0,00  14670,00      0,00      0,00      0,00      0,00
08:54:47        0,00      0,00    32,00      0,00    319,00      0,00      0,00      0,00      0,00
08:54:48        0,00      0,00  2063,37      0,00    521,78      0,00      0,00      0,00      0,00
08:54:49        0,00      0,00    36,00      0,00    67,00      0,00      0,00      0,00      0,00
08:54:50        0,00      0,00    32,32      0,00    83,84      0,00      0,00      0,00      0,00
08:54:51        0,00      0,00    54,00      0,00    218,00      0,00      0,00      0,00      0,00
^C

I will continue to investigate. :^)

[edit]
just one note:
the heavy cpu usage is much more noticeable when viewing a "real" pdf file, such as a tecnical document, which freeze my xpdf experience and make the notebook fan start her noisy music...
[/edit]

Ilgar 11-15-2010 02:10 AM

Did you check the following thread about xpdf?

http://www.linuxquestions.org/questi...slowly-840078/

cacao74 11-15-2010 02:50 AM

Quote:

Originally Posted by Ilgar (Post 4159126)
Did you check the following thread about xpdf?
http://www.linuxquestions.org/questi...slowly-840078/

yes, but it doesn't help me or so I think.

cacao74 11-20-2010 02:53 PM

Cannot find a simply or quick solution... I've tried to upgrade from 13.1 to current version. It's noticeable a general improve of performance within a X session (I use fluxbox). For example, thunderbird and firefox works better with a lower cpu% value. Another example is that Xv viewer return to works, like in the 13.0 (in 13.1 display a solid color instead of the image).

Xpdf problems still remains, sigh... but I continue to search for an answer to this issue.

Quote:

Originally Posted by catkin (Post 4158908)
One solution might be to use eVince instead of Xpdf. Although it is not so lightweight it is very nice to work with.

I've installed apvlv using the slackbuild from "slackbuilds.org" (Approved by: rworkman). A very light pdf viewer with vim key-bindings. A must have for me that I love vi(m).

:^)

Ian John Locke II 11-20-2010 03:31 PM

cacao you may run into problems with apvlv. When I installed it, it was quite unstable. Despite it's memory footprint (which can be reduced through settings) I would recommend okular. Even using it with dwm works really well for me.

T3slider 11-20-2010 03:46 PM

Quote:

Originally Posted by Ian John Locke II (Post 4165613)
cacao you may run into problems with apvlv. When I installed it, it was quite unstable. Despite it's memory footprint (which can be reduced through settings) I would recommend okular. Even using it with dwm works really well for me.

I've been using apvlv for quite some time now and it has never crashed on me once...I haven't encountered any bugs at all (or at least none that I can recall). The only thing that I've missed compared to xpdf is colour inversion.

cacao74 11-20-2010 03:57 PM

Quote:

Originally Posted by Ian John Locke II (Post 4165613)
cacao you may run into problems with apvlv. When I installed it, it was quite unstable. Despite it's memory footprint (which can be reduced through settings) I would recommend okular. Even using it with dwm works really well for me.

thanks for the info, but now I can only say that apvlv works well.
I will report if something goes bad.

Ian John Locke II 11-21-2010 12:34 PM

To be honest, I used it so long ago that the problems I ran into (which I can't remember exactly what they were) may have been fixed.

business_kid 11-21-2010 02:21 PM

Let me have a quick go at the xpdf issue

1. Try 'ldd /usr/bin/xpdf |grep found'
desired output is no output. Install anything that appears.

2. Ditto for /usr/bin/gs

3. Try in an xterm 'gs /path/to/some.pdf'. Make sure to use a text pdf, as gs (and therefore xpdf) really sweats over picture based pdfs. I could open a government report on Clerical Child Abuse quicker much faster than a local Pizza Hut menu. The drawing speed of the latter was painfully slow. It could just be the pdfs you have chosen to open.

4. Compare your results in gs with your results in xpdf for the same file. Xpdf may have a higher 'nice' value.

cacao74 11-21-2010 02:32 PM

Now I'm in current, but I can give some answer about the 13.1 (full fresh install):
Quote:

Originally Posted by business_kid (Post 4166344)
Let me have a quick go at the xpdf issue

1. Try 'ldd /usr/bin/xpdf |grep found'

All dependencies satisfied (no "not found").
Quote:

2. Ditto for /usr/bin/gs
same as xpdf
Quote:

3. Try in an xterm 'gs /path/to/some.pdf'.
4. Compare your results in gs with your results in xpdf for the same file. Xpdf may have a higher 'nice' value.
I can't try these now...

:^)


All times are GMT -5. The time now is 11:57 PM.