iocage + rtorrent, limited to single CPU

[Jeren]

I'm running 11.1-U5 and configured a working rtorrent jail using the following guide: https://danthesalmon.com/create-seedbox-jail-freenas/

Unfortunately, I'm running into an error where upon checking data of existing downloaded files, the rtorrent process is seemingly limited to a single core. The small CPU monitor in the bottom left of the ruTorrent GUI plateaus at 100% and the FreeNAS cpu reporting shows a steady 15~ish %. I'm running a hyperthreaded quad-core Xeon, so 15% is about 1 CPU.

The iocage version is Version 1.0 ALPHA, and upon checking the documentation, defaults to cpuset=off. I've verified this by running the following commands:

Code:

root@freenas:~ # iocage set cpuset=on test
Property: cpuset has been updated to on
root@freenas:~ # iocage set cpuset=off test
Property: cpuset has been updated to off

Also per the documentation, cpu limitation functionality is supposed to be for legacy only and not for the current version. Not sure what's going on here, but I'm happy to hear anyone's suggestions.

[EDIT] added output of iocage get all

Code:

% iocage get all test
CONFIG_VERSION:11
allow_chflags:0
allow_mount:0
allow_mount_devfs:0
allow_mount_nullfs:0
allow_mount_procfs:0
allow_mount_tmpfs:0
allow_mount_zfs:0
allow_quotas:0
allow_raw_sockets:0
allow_set_hostname:1
allow_socket_af:0
allow_sysvipc:0
available:readonly
basejail:no
boot:off
bpf:no
children_max:0
cloned_release:11.1-RELEASE
comment:none
compression:lz4
compressratio:readonly
coredumpsize:off
count:1
cpuset:off
cputime:off
datasize:off
dedup:off
defaultrouter:10.0.0.1
defaultrouter6:none
depends:none
devfs_ruleset:4
dhcp:off
enforce_statfs:2
exec_clean:1
exec_fib:0
exec_jail_user:root
exec_poststart:/usr/bin/true
exec_poststop:/usr/bin/true
exec_prestart:/usr/bin/true
exec_prestop:/usr/bin/true
exec_start:/bin/sh /etc/rc
exec_stop:/bin/sh /etc/rc.shutdown
exec_system_jail_user:0
exec_system_user:root
exec_timeout:60
host_domainname:none
host_hostname:test
host_hostuuid:test
host_time:yes
hostid:e2446868-8ce7-11e7-a8b2-002590d35be2
hostid_strict_check:off
interfaces:vnet0:bridge0
ip4:new
ip4_addr:10.0.0.154
ip4_saddrsel:1
ip6:new
ip6_addr:none
ip6_saddrsel:0
jail_zfs:off
jail_zfs_dataset:iocage/jails/test/data
jail_zfs_mountpoint:none
last_started:2018-08-16 03:00:09
login_flags:-f root
mac_prefix:02ff60
maxproc:off
memorylocked:off
memoryuse:off
mount_devfs:1
mount_fdescfs:1
mount_linprocfs:0
mount_procfs:0
mountpoint:readonly
msgqqueued:off
msgqsize:off
nmsgq:off
notes:none
nsemop:off
nshm:off
nthr:off
openfiles:off
origin:readonly
owner:root
pcpu:off
priority:99
pseudoterminals:off
quota:none
release:11.1-RELEASE-p13
reservation:none
resolver:/etc/resolv.conf
rlimits:off
securelevel:2
shmsize:off
stacksize:off
state:up
stop_timeout:30
swapuse:off
sync_state:none
sync_target:none
sync_tgt_zpool:none
sysvmsg:new
sysvsem:new
sysvshm:new
template:no
type:jail
used:readonly
vmemoryuse:off
vnet:on
vnet0_mac:02ff60ae1b75,02ff60ae1b76
vnet1_mac:none
vnet2_mac:none
vnet3_mac:none
vnet_interfaces:none
wallclock:off

 

[Jailer]

If I'm not mistaken this is by design. It was implemented a while back to prevent a run away process in a jail from taking over all the resources of the host. Of course that was with Warden, I' don't know if it still applies to iocage.

 

[Fish]

I'm glad you found my article useful, OP!

Were you able to solve this issue? I'm wondering now if my rTorrent jail is able to use both cores on my system...