SabNZBD: Heavy load (> 100%) when unraring files

after I upgraded to an Odroid N2 the unraring of files takes much longer than before (Udroid XU4).
That means that the Server is not usable while unraring.
Any ideas?
(Made an update, no changes)

I think it takes a ton of resources on SabNZBD to decompress files, even on my full UnRaid server running an Intel i5 w/ 16 gigs of RAM and it will even peg that out…

Have you checked swap usage during the decompress? Do you have ZRAM setup?

Hi WarHawk,
i never had those issues with my odroid xu4 so i think there is something wrong with my configuration for the N2.
I had a look to htop and you are right.
There seems to be no swap at all.
Did i miss that during install?

I do not know what zram is, so i think i have an default installation of dietpi without zram.


EDIT: Tried to activate swapfile in dietpi-config but it does not work

what did you have done to activate the swap? By default swap is deactivated on systems with more than 2 GB phys ram. Anyway you would need watch htop during unrar to see what is going on. There you should see how much phys ram is used. And if CPU is on 100%, for sure you are stuck on your system. Where do you store your data? on an external drive?

Yes, i set swap from 0 to 1 in the “drive manager”, but as i said, it did not wqork.
Btw the N2 has 4GB RAM, so maybe this should not be the propblem?

I have 6 cores (0 to 5) but only one seems to unrar with around 85% of that core.
Average is around 15%.

Used memory is 600MB from 3630 MB.
Swap is 0kB / okB.

And yes, data is stored on external drive.

Does this helps?

ok CPU / memory doesn’t seems to be an issue. It’s using a single CPU only and still enough memory free.

Probably it’s the I/O from/to disk. What file system format you are using?

It is an external 1TB USB-hdd that i used with dietpi and the odroid xu4 before.

for testing purposes, are you able to use internal storage? Just to see how it is behaving from performance point of view.

It appears it might need it…even Archlinux needs it

ZRAM/ZSWAP setup with a gig or two would probably be the best bet…keep the swapping from even going to a drive and have it handle it in high speed RAM

I know they are talking about setting ZRAM stuff in new releases…but there should be a howto to enable it on an older build, it’s actually surprisingly easy

The Odroid N2 only uses less than 15% from the RAM.
Do you really think it depends on swap or zram?

Isnt’t it more strange that there is only one core working?

Oh, that’s not very simple to me.
There are around 13GB free on /.
(/dev/mmcblk1p2 15G 1,5G 13G 11% /)

So i would rar a file, copy it to / and try to unrar it from there, right?

yes that would be the idea to use some space on your RootFS for testing.

Regarding the swap, yes you still have enough phys me free. But you could simple give it a try. Just do one og the following 2 options:

  1. to create a normal 1GB swap file
/boot/dietpi/func/dietpi-set_swapfile 1024
  1. to create a 512MB compressed swap file
/boot/dietpi/func/dietpi-set_swapfile 512 zram

To revert changes and to remove swap

/boot/dietpi/func/dietpi-set_swapfile 0

Regarding the single core usage. That’s quite normal as you have just a single process running.

Ok, here we go.

I successfully activated swap. Unrar uses unbelievable 4,5 MB of the whole swap-space and there is no difference at all.

I just unrared a 1379 MB file on the sdcard (internal).
It took 14:30 min…

Then i did the same on the external usb-hdd:
There it took 12:30 min

So, this seems to be no issue with the external hdd-drive.

slowly I’m running out of ideas :frowning:

What does

cat /proc/swaps



free -m
dietpi@DietPi:~$ cat /proc/swaps
Filename                                Type            Size    Used    Priority
/mnt/externe_HDD_1TB/.swapfile          file            1048572 12928   -1

dietpi@DietPi:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3713         510          22          15        3180        3148
Swap:          1023          12        1011

How does it looks like if SabNZBD is running an unrar?

while downloading

dietpi@DietPi:~$ cat /proc/swaps
Filename                                Type            Size    Used    Priority
/mnt/externe_HDD_1TB/.swapfile          file            1048572 12968   -1
dietpi@DietPi:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3713         560          43          15        3109        3097
Swap:          1023          12        1011

while unraring

dietpi@DietPi:~$ cat /proc/swaps
Filename                                Type            Size    Used    Priority
/mnt/externe_HDD_1TB/.swapfile          file            1048572 13380   -1
dietpi@DietPi:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3713         551          19          15        3141        3106
Swap:          1023          13        1010

Is it possible, that the installation of dietpi went wrong?
NFS not working is another issue.

Is it possible to check if the installation of dietpi was “clean”?

DietPi logs from first run are stored at /var/tmp/dietpi/logs. But if there are issues in initial setup, you would have been noticed before.

Let’s try a hdparm

Howto here

hdparm: Test HDD, SSD, USB Flash Drive’s Performance
hdparm is a Linux command line utility that allows to set and view hardware parameters of hard disk drives.
And it can also be used as a simple benchmarking tool that allows to quickly find out the READ speed of a disk.

hdparm is available from standard repositories on the most Linux distributions.

Install hdparm depending on your Linux distribution.

On Linux Mint, Ubuntu, Debian:

$ sudo apt-get install hdparm

Run hdparm as follows, to measure the READ speed of a storage drive device /dev/sda:

$ sudo hdparm -Tt /dev/sda
 Timing cached reads:   16924 MB in  2.00 seconds = 8469.95 MB/sec
 Timing buffered disk reads: 1386 MB in  3.00 seconds = 461.50 MB/sec

Whichever your external USB drive is mounted as…