Bad performance issue in LXC, using Swap

[duschkopf]

Hi,

I use sabnzbd on a LXC in proxmox. I noticed that the download drops to almosst zero, then to zero when an unpack starts. Unpack is done via unrar from debian non-free packages. I thought maybe it was too much for the HDD so I put the incomplete temp folder to an mount on the LVM (SSD), but it is the same behavior. When the unpack finishes, the download resumes with normal speed and sabnzbd becomes responsive again. There is NO high CPU usage for the container, so there must something going wrong, badly..

At one pont the system started using 100% swap, even there wa only 20% RAM usage. I reboot fixed it, but it uses like 1-5% still. my other LXCs dont use any swap. I also increased the RAM for the LXC to 2GB, without any change. There is plenty of RAm left. Dont know if the Swap Problem is linked together.

Does anyone have an idea?

I stress tested the system + the LXC with "stress" from stress-ng package. It works as expected with high load. So I guess it must be a prolme with sabnzbd/unrar integrations.

best greetings

 

[psilan]

Did you ever resolve this?
I'm trying to make the 'perfect' sabnzbd container - but I feel like I have just been throwing more cores at the problem.

This morning it was constantly rebooting during unrar / verification procedures. Anything with high cpu. The below helped, but it doesn't run as well as my old server (20c xeon).

Gave it 6 cores, 2GB.
Download direct to mounted zfs.
Pause download for processing.
Move to completed folder via cifs to NAS (2.5G).
Disabled direct unpack.



Originally I had 2c 512MB, download direct to NAS. CPU maxed out and constant reboots. Changed just the download location to local, and still had problems until I tossed cores at it.

 

[psilan]

Unrar was crashing the lxc over and over, causing multiple duplicated folders in /complete. It then also couldn't handle the deletions after the crashes.
I disabled recursive unpacking and de-obfuscate filenames. Not sure which helped. Probably unpacking.

I've dropped the specs back down to 2c/2g and will see how it goes.
Edit: Dropping spec brought the issue back. Duplicates everywhere.

 

[psilan]

It appears the container just can't handle unrar to remote smb share.
I have gone back to incomplete and complete directories on the NAS and it's fine.

Alternatively I could have put incomplete and complete on zfs, but then have another layer of configuration to get radarr/sonarr/etc accessing the completed folder on sabnzbd. Rather keep it simple.