top - 13:02:52 up 603 days, 19:19, 2 users, load average: 5.01, 4.15, 3.44
Tasks: 604 total, 5 running, 599 sleeping, 0 stopped, 0 zombie
Cpu(s): 17.7%us, 36.1%sy, 0.0%ni, 42.0%id, 4.1%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 16278908k total, 4269684k used, 12009224k free, 119672k buffers
Swap: 8k total, ........
We all know Linux is known for good memory management but is it really? It seems all on its own with hardly anything running that you can come back in days or weeks and find that almost all of your RAMis used!
And many will say "no don't worry it's buffers for optimization" but it doesn't seem to help because what is in buffers is not available to use for new programs running or ones that allocate more RAM as far as Ican tell.
The reason Iknow........
migrating from an old OpenVZ (Centos 5) to new OpenVZ (Centos 6)
Also if migrating from 32-bit HN to 64-bit your RAM will probably be much bigger than it should be!
eg. 32bit HN:
total used free shared buffers cached
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
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!
I thought only a faster CPUand SSDwould help but I already have a Quad-Core CPU and it wasn't being maxed out. The actual tests were performed on an AMD-V enabled 128MB dual core VMWare container though.
There is a flag that can be passed to make in order to start multiple threads, by specifying 4 threads I was able to reduce the whole kernel compilation time from scratch by about 50%! (65minutes vs 31minutes!). *Yes I did do a make clean before each co........
Jan 5 12:45:05 testbox kernel: [653298.890004] BUG: soft lockup - CPU#0 stuck for 61s! [hal-acl-tool:4168]
Jan 5 12:45:05 testbox kernel: [653298.890005] Modules linked in: vmnet vmci vmmon binfmt_misc drbd video output input_polldev ocfs2_stackglue ocfs2_dlmfs ocfs2_dlm ocfs2_nodemanager configfs k8temp hwmon_vid lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi........
Here are the results, it is Sempron 3000+ AMD Mobile, 500Gig HDD, 512MB RAM with shared ATI Radeon graphics.
# # # # # # # ##### ###### # # #### # #
# # ## # # # #&nb........