search

nakijun / peazip

Automatically exported from code.google.com/p/peazip
2 stars 0 forks source link

[Linux] PeaZip brings Xorg CPU usage on Ubuntu at 90-95 % #87

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Ubuntu 11.04, PeaZip 3.6.1, AMD E-350.

I had Xorg CPU usage constantly at about 90-95 % for at least a hour, so I 
followed https://wiki.ubuntu.com/X/Troubleshooting/HighCPU , I killed all the 
suspect applications but nothing happened.
Without anything else happening, the CPU usage suddenly became normal again 
after a long running 7z compression by PeaZip ended. The process had been 
running for about 7 hours. 
What does PeaZip do with Xorg? 
https://wiki.ubuntu.com/X/Troubleshooting/HighCPU#Client_Applications

Original issue reported on code.google.com by nemow...@gmail.com on 13 Jul 2011 at 6:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Xorg is the X server allowing graphic display, during compression/extraction 
PeaZip simply updates the progress bar and a couple of strings (time, processed 
size), which should not represent a demanding task for the graphic system 
(tested even on old Celeron machines).

Your report seem rather pointing out the problem was due to the high CPU usage 
by a 7z process was running and using most of the CPU.
PeaZip launches 7z backend when user starts a compression, extraction, test or 
other operation on a format handled through that backend - in example when 
browsing an archive a list operation is launched by PeaZip to display archive's 
content.

What you report seems abnormal in terms of duration (7 hours) but normal in 
terms of procedure: a long 7z process was launched and was using most of the 
CPU, then it ended normally correctly releasing its resources.

Without knowing more on the specific issue (what operation were done by the 
user, on what files, is it replicable and under what conditions, did multiple 
processes overlapped exhausting system's resources, what was the primary 
bottleneck in delaying a process so much?) it is not possible to give an answer 
on the specific problem encountered.

I would recommend anyway to update PeaZip as you are using 3.6.1 and 3.8 
release is available: it is compiled with new release of Lazarus IDE (so the 
GUI related part under the hood was deeply updated) and uses updated 7z backed 
for Linux.

Original comment by giorgio.tani.software@gmail.com on 13 Jul 2011 at 9:04

GoogleCodeExporter commented 9 years ago 
I know that PeaZip doesn't use much graphical resources, but Xorg documentation 
shows that even in that case you can drive Xorg crazy.

I'm not reporting a generic CPU overload, I used top to verify that Xorg was 
using 90-95% CPU (one core).

I said you what I did. I don't think it's useful to know what's the file but 
you can find it except that it was some GiB but anyway it's here: 
https://docs.google.com/leaf?id=0By9Ct0yopDdVYWU3OWIxZDEtYjJiOS00OGZmLThiYTUtNjY
xMjFkZTBkNTUz&sort=name&layout=list&pid=0By9Ct0yopDdVNzExNzIxMWQtN2Q5Ny00NzQzLTg
yOWQtMTdkZjcwNDNhY2E0&cindex=1 
The bottleneck was Xorg, as said. I can try to reproduce it with another file...

Original comment by nemow...@gmail.com on 13 Jul 2011 at 9:36

GoogleCodeExporter commented 9 years ago 
I confirm that it's PeaZip, see screenshots. Apparently it happens whatever the 
job, after some time (in this case less than 5000 s).
I found a workaround, though: you just have to abandon "status" tab and because 
the others don't have any graphics moving Xorg is left alone.

Original comment by nemow...@gmail.com on 14 Jul 2011 at 7:34

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for tracking the issue further.
The GUI related code for updating status window is quite light as it was 
designed to run even on very limited hardware (virtual machines, and phisical 
machine with CPUs as old as Celeron); as you can see there is nothing more than 
a cycling 16px icon, a progress bar and a few strings to be updated.
I suspect there is a bug in the underlying code that may not work well with 
some versions of Xorg, and shows up after some time as you reported.

In any case I would like to recommend to update to current release 3.8, not 
only because of my updates but, probably more relevant to fix this specific 
issue, the compiler was changed so the underlying code dealing with Xorg was 
deeply updated.

Original comment by giorgio.tani.software@gmail.com on 14 Jul 2011 at 9:17

GoogleCodeExporter commented 9 years ago 
I confirm it also for PeaZip 3.8 (version details: 
http://p.defau.lt/?iAd9IYsAXDVZeOZOlvI3gg ).
To reproduce it I launched 7z compression of about 3x3 GiB and waited for about 
30-45 min (the length counter is broken as well).
I've changed tab on each PeaZip window and Xorg CPU usage has immediately 
dropped.

Original comment by nemow...@gmail.com on 14 Jul 2011 at 10:32

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for tracking the problem, I'll try to reproduce the issue in order to 
identify what versions of Xorg are affected, and a possible solution.
Possible workarounds are
- as you suggested, shitch to another tab not displaying progress animation
- Options > Settings, chose Console in "Backend binaries user interface" in 
order to see the job running in a console rather than wrap it in the graphic 
component.

Original comment by giorgio.tani.software@gmail.com on 15 Jul 2011 at 7:21

GoogleCodeExporter commented 9 years ago 
Does the same issue happens with newer 3.9 release?

Original comment by giorgio.tani.software@gmail.com on 1 Aug 2011 at 10:30

GoogleCodeExporter commented 9 years ago 
I've compressed a 9.2 GiB directory, the job lasted something like 8 hours and 
Xorg didn't have any problem.

Original comment by nemow...@gmail.com on 21 Aug 2011 at 8:16

GoogleCodeExporter commented 9 years ago 
Thank you very much for re-testing the issue, I'll now close this item.

Original comment by giorgio.tani.software@gmail.com on 21 Aug 2011 at 8:34