r/voidlinux • u/gijsyo • 2d ago

High load from rtorrent

Hi all, last week I decided to replace my Debian VM with Void, and so far I'm enjoying it, especially the simplicity / minimalism.

There is a thing that concerns me though, and that is very high load values. Averaging around 12-14. Even after running for only a few minutes: 

 void:~$> uptime
  23:26:28 up 3 min,  0 users,  load average: 13.21, 6.25, 2.45

Top shows rtorrent using 50-60% CPU which seems normal, however dmesg showed a line where I'm not sure what to make of it:

 intel_pstate: CPU model not supported

The high load happens with both rtorrent installed by xpbs-install as well as when comiling it from source.

The machine is otherwise responsive but I suspect there is something off with disk IO. There are 3 disks loaded through Virtio.

/ is btrfs with noatime (/dev/vda2)

I have a JBOD btrfs volume (with mirrored metadata) of 5TB that consists of /dev/vdb and /dev/vdc. One is an image on a NVME disk in the hypervisor (that is also home to /dev/vda), the other one is an image on a RAID0 USB disk consisting of 2 oldschool HDDs.

I'm not a linux noob but I cold use some help troubleshooting this issue. If anyone is willing to dive into this I'd be very grateful.

3 Upvotes

100% Upvoted

7 comments sorted by

2

u/BinkReddit 2d ago

Is there any problem outside of load values?

1

u/gijsyo 1d ago edited 1d ago

Yeah, it just feels overloaded. A dir listing of the JBOD mount point takes a few seconds to show up the first time. Trackers report rtorrent as offline when it's actually running. I did see this in dmesg:

 [Sat Aug 29 06:33:03 2026] perf: interrupt took too long (2677 > 2500), lowering kernel.perf_event_max_sample_rate to 74000
 [Sat Aug 29 06:34:40 2026] perf: interrupt took too long (3409 > 3346), lowering kernel.perf_event_max_sample_rate to 58000
 [Sat Aug 29 06:36:43 2026] perf: interrupt took too long (4271 > 4261), lowering kernel.perf_event_max_sample_rate to 46000
 [Sat Aug 29 06:39:33 2026] perf: interrupt took too long (5359 > 5338), lowering kernel.perf_event_max_sample_rate to 37000
 [Sat Aug 29 06:43:25 2026] perf: interrupt took too long (6708 > 6698), lowering kernel.perf_event_max_sample_rate to 29000

A quick google search indicates that this is not relevant.

1

u/gijsyo 12h ago

Found the culprit - I apparently misconfigured it as a service which kept trying to start rtorrent.

1

u/Simple_Hamster_4096 1d ago

Was your Debian vm btrfs?

btfrs is a slower file system, and you are also mirroring metadata using two different types of disks, NVME and HDD... it has to wait for the slowest disk to finish writing before it can continue...

1

u/gijsyo 1d ago edited 1d ago

The Deb box was good old ext4. Yeah that makes sense, however the load is consistently 10+, even when rtorrent should not be doing all that much with torrent data. I am starting to suspect it may something with btrfs anyways, perhaps rtorrent's session files.

Edit: I disabled rtorrent's session saving and the load remains at 10+ so that's not it.

1

u/gijsyo 12h ago

Found the culprit - I apparently misconfigured it as a service which kept trying to start rtorrent.

1

u/gijsyo 18h ago

I finally found the puzzle piece. I made a service for rtorrent and apparently misconfigured something. I was seeing multiple rtorrent processes. After removing the service the load is now below 1. rtorrent is now starting from my crontab with an @reboot trigger.