take my memory rtorrent! take it!

[KyleSanderson]

No matter what I try I can't seem to get rtorrent to use my ram...

I've tried both:
max_memory_usage = 14000M
pieces.memory.max.set = 128000M

But it won't do a damn thing... Is there some bizarre hard limit of 2624M or something?

EDIT: I have 32G of RAM...

[KyleSanderson]

Confirming: pieces.memory.max.set = 42949672950 does absolutely nothing...

[rakshasa]

Might be an issue with ulimit being set, or you have 32bit kernel without physical address extension enabled.

[KyleSanderson]

data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 128251
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 9000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 128251
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

/usr/bin/rtorrent: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped

Gentoo amd64. I really can't figure it out beyond it being a casting issue or an issue with the command type itself (the type is void?).

[rakshasa]

Try calling ulimit from from within rtorrent, should be something like print=(execute.capture,ulimit,-a).

[KyleSanderson]

2173240K - mmap
3328804K - total pmap...

ulimit -a in the instance is returning the same... looks like it's capped at the old 32bit limit but the executable is 64bit...

[KyleSanderson]

OK - so even though rtorrent holds onto file descriptors it doesn't actually use them accroding to the memory mapping... There's 5768 open descriptors (the limit) but only 77 files are mmap'd...

This is a libtorrent bug - can you transfer the issue @rakshasa ?

[chros73]

Probably it's related to this one.

[rakshasa]

Those file descriptors also get used as socket connections, so 5000 is not unusual.

You did not post the results of the 'ulimit -a' call, and if it as you say it is capped at 32 bits then you need to solve that, it's not an issue with the client.

[kannibalox]

OK - so even though rtorrent holds onto file descriptors it doesn't actually use them accroding to the memory mapping... There's 5768 open descriptors (the limit) but only 77 files are mmap'd...

This is a libtorrent bug - can you transfer the issue @rakshasa ?

Have you tried lowering the number of allowed descriptors?

[rakshasa]

Closing this as it seems an issue with the setup, not the client.