Linux box13. 2.6.32-042stab076.5 #1 SMP Mon Mar 18 20:41:34 MSK 2013 x86_64 x86_64 x86_64 GNU/Linux
even setting privvmpages to a specific setting DOES not affect "free -m" in containers.
This is probably a kernel issue
23:36:29 up 159 days, 7:12, 4 users, load average: 0.42, 0.44, 0.33
[root@box13 ~]# free -m
total&n........
This example involves an Aterisk message log of about 26GB, but with any server it usually does not get deleted until the server is stopped/restarted:
asterisk 13729 root 6w REG 0,41 27277943090 59097971 (deleted) /var/log/asterisk/messages
So if you've deleted a bunch of large logs, make sure you restart the server for them to regain your space.
........
I had a system running a 128MB live CD image with 2.8 gigs of available RAM and the OOM kernel killer went crazy when using dd for more than 8 minutes and kept killing everything. I've read that this is due to a low-memory issue and paging in the kernel and 32-bit systems with lots of RAM.
I even enabled swapspace on my LiveCD and the issue happened 25 minutes into dd rather than 8 minutes, so what gives?
Also no swap space was ever used!
cat /proc/s........
VBoxManage modifyvdi /path/to/your.vdi compact
I believe this should be done only when your VM is powered off, but I decided to try it with the system powered on. i wouldn't recommend it because it's dangerous even if it does work but this is a test system. For anything important/production I would always take a backup first and make sure the system is powered off.
VBoxManage modifyvdi XP-clone.vdi compact
0%...10%...20%...30%...40%...5........
Out of memory: kill process 7559 (rsync) score 635 or a child
Killed process 7559 (rsync)
I was surprised to see this in my dmesg whenmy rsync backup suddenly stalled/stopped.
This system has 3 gigs of RAM and lots of free memory so I don't understand what is happening.
rsync invoked oom-killer: gfp_mask=0x200d2, order=0, oomkilladj=0
Pid: 7600, comm: rsync Not tainted 2.6.24.2 #83
[] oom_kill_pr........