[SOLVED] [slackware 13.1] xpdf very slow and cpu goes to 100%
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
[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 ?
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.
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
[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]
Last edited by cacao74; 11-15-2010 at 02:11 AM.
Reason: added some notes
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
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).
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.
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.
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.
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.
Now I'm in current, but I can give some answer about the 13.1 (full fresh install):
Quote:
Originally Posted by business_kid
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
