after rebooting a server vmtouch (v1.3.1) now suddenly (probably forgot to reboot after updating) fails to lock more than 1G. Even with ulimits increased an arbitrary high -m parameters to it.
It stops at exactly 500259 pages (1G) each time. I have (currently) still 4G memory completely free and ulimits (after poking it) are:
# ulimit -a
real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 23578
max locked memory (kbytes, -l) 10485760
max memory size (kbytes, -m) unlimited
open files (-n) 999999
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8388608
cpu time (seconds, -t) unlimited
max user processes (-u) 23578
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux trixie/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=trixie
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Example commands I used to poke at this issue (all ran as root):
vmtouch -L -p 0-50k -f /opt/mycachefiles/ => vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping and LOCKED 500259 pages (1G)
vmtouch -m 1000000000 -L -p 0-50k -f /opt/mycachefiles/ => vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping and LOCKED 500259 pages (1G)
vmtouch -m 128 -L -p 0-50k -f /opt/mycachefiles/ => vmtouch: WARNING: file X too large, skipping and LOCKED 98 pages (392K)
What limit is this hitting? Maybe a regression of #35 sounds most likely atm. Am I missing something?
Edit: after further testing:
vmtouch -L -p 0-100k -f /opt/mycachefiles/ => vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping and LOCKED 669225 pages (2G)
So is this some kind of file descriptor limit (other than ulimit -n?)
Edit 2: Probably not. The issue appears to be specific to the combination of -l/L and -p:
vmtouch -L -f /opt/mycachefiles/ => vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping and LOCKED 1170529 pages (4G), this one at least could also have been an out of memory issue from running vmtouch over and over again. The system only has 6G total. However it still doesn't explain why using -p in addition would cause it to fail so much sooner...
vmtouch -f /opt/mycachefiles/ => "Just works", therefore it's not an issue with the amount of file descriptors. However it sparks more questions than it answers... Total stats btw:
Hi,
after rebooting a server vmtouch (v1.3.1) now suddenly (probably forgot to reboot after updating) fails to lock more than 1G. Even with ulimits increased an arbitrary high
-m
parameters to it.It stops at exactly 500259 pages (1G) each time. I have (currently) still 4G memory completely free and ulimits (after poking it) are:
Example commands I used to poke at this issue (all ran as root):
vmtouch -L -p 0-50k -f /opt/mycachefiles/
=>vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping
andLOCKED 500259 pages (1G)
vmtouch -m 1000000000 -L -p 0-50k -f /opt/mycachefiles/
=>vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping
andLOCKED 500259 pages (1G)
vmtouch -m 128 -L -p 0-50k -f /opt/mycachefiles/
=>vmtouch: WARNING: file X too large, skipping
andLOCKED 98 pages (392K)
What limit is this hitting? Maybe a regression of #35 sounds most likely atm. Am I missing something?
Edit: after further testing:
vmtouch -L -p 0-100k -f /opt/mycachefiles/
=>vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping
andLOCKED 669225 pages (2G)
So is this some kind of file descriptor limit (other thanulimit -n
?)Edit 2: Probably not. The issue appears to be specific to the combination of
-l/L
and-p
:vmtouch -L -f /opt/mycachefiles/
=>vmtouch: WARNING: unable to mmap file X (Cannot allocate memory), skipping
andLOCKED 1170529 pages (4G)
, this one at least could also have been an out of memory issue from running vmtouch over and over again. The system only has 6G total. However it still doesn't explain why using-p
in addition would cause it to fail so much sooner...vmtouch -f /opt/mycachefiles/
=> "Just works", therefore it's not an issue with the amount of file descriptors. However it sparks more questions than it answers... Total stats btw: