What is process xz?

My old (32bit) computer gets more and more sluggish - it may be hardware… The harddrive LED is nearly constantly alight and I have to wait minutes even for bringing another window in the foreground. I tried the top command and I received the following:


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND               
** 3289 root      39  19   98448  97296   1972 R 97.02 4.881   4:06.53 xz                   ** 
 4369 root      20   0   13068   9724   4928 D 1.325 0.488   0:00.93 rpm                   
 2239 uli       20   0  313696  98056  74352 S 0.662 4.919   0:02.83 krunner               
** 4390 uli       20   0    8384   3908   3356 R 0.662 0.196   0:00.19 top                  ** 
  393 root      20   0    8180   5240   1548 S 0.331 0.263   0:02.53 haveged               
 1973 root      20   0  111060  56940  27268 S 0.331 2.856   0:10.51 X                     
 2673 uli       20   0  168456  56676  47788 S 0.331 2.843   0:02.61 konsole               
 4132 root      20   0       0      0      0 I 0.331 0.000   0:00.07 kworker/0:1           
 4372 uli       20   0  168820  57888  48996 S 0.331 2.904   0:00.81 konsole               
    1 root      20   0   39336   7244   5472 S 0.000 0.363   0:03.62 systemd                  

What is this xz which uses up 97% cpu? the command

~> ps -ef | grep xz
root      3289  1830 72 14:52 ?        00:04:32 /usr/bin/**xz**

the only window open was another console where zypper dup was running (already at the install process).
cheers
uli

Information for package xz: Summary : A Program for Compressing Files with the Lempel–Ziv–Markov algorithm

I expect that’s the compress/decompress software. It is probably being called by something else (maybe you are running updates – the “.rpm” files are compressed).

Yes, I wrote that I did a zypper dup - only 2 console windows open and it took a long time, even switching from one window to the other. But why is it blocking everything else on the computer to the point where it is nearly unusable. The computer was never so sluggish as today!

Probably decompressing a large .rpm file (package). Yes, xz can use a lot of cpu cycles. I used to notice that updating was slow when I had a 32-bit system, though that would have been with openSUSE 32.1 or earlier. I don’t think I ever tried Tumbleweed on that box.

If your machine is really sluggish,
Maybe your machine is really low on resources.
A thrashing hard drive can be an indication of memory starvation and excessive swapping.

Run top or htop to view how much of your memory is being used.
top or htop will also display CPU usage as well what other processes are eating up resources.

You can also use the Free tool to analyze your overall memory usage, and how much might be locked up in buffers.
Also, if you are transitioning from a heavy workload which caused large amounts of memory to be allocated to buffers, I provide a command that clears your memory buffers… short of rebooting your machine, this can immediately free up your memory for a new major workload.

https://en.opensuse.org/User:Tsu2/free_tool

HTH,
TSU

https://youtu.be/j1QOYAfdZ_M?t=41s

The robot is your computer;
you are the guy throwing things onto the treadmill.

  1. multi-user.target
  2. zypper dup
  3. go do something that doesn’t involve your computer

Thank you, tsu, you are right, my old computer is a bit low on resources:

~> free
              total        used        free      shared  buff/cache   available
Mem:        1993464      949668      332404      176040      711392      643660
Swap:       2103292      830464     1272828

I run Tumbleweed since this is the only supported software from openSUSE on 32bit machines and it might be a bit too much. However it was not (yet) as bad as today. I have planned in a replacement for this laptop for this year but I wondered if there is something that can be done to improve the performance. Next time I will boot into LXDE (now it is KDE) to see how much better this will be.

Simple, straight forward, based on feelings only: swapping.