0

I guess there is some memory leakage and memory is not being freed. Is there some good ways to find out which process and why is leaking memory?

The only temporary solution is to restart server. But after few days memory usage grows and grows and then server slows down a lot and I have to do yet another restart.

For example checking free -m:

             total       used       free     shared    buffers     cached
Mem:          2005       1989         15          0          2        126
-/+ buffers/cache:       1861        144
Swap:         2004       1494        510

The thing is this usage does not change much. And such memory usage keeps either freezed like this or grows bigger, but not less.

Does anyone know any good practices to pin point the cause of memory leakages?

top ordered by used memory shows this:

top - 16:58:40 up  6:00,  1 user,  load average: 0.10, 0.08, 0.07
Tasks: 136 total,   1 running, 135 sleeping,   0 stopped,   0 zombie
Cpu(s): 26.2%us,  1.0%sy,  0.0%ni, 72.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2053476k total,  2036380k used,    17096k free,    39272k buffers
Swap:  2053112k total,    13348k used,  2039764k free,   924372k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 1529 oerp      20   0  919m 419m 8100 S 19.9 20.9  17:44.49 python             
 1768 postgres  20   0  342m 161m 137m S  0.0  8.1   0:27.28 postgres           
 1775 postgres  20   0  334m 155m 137m S  0.0  7.8   0:14.05 postgres           
 1751 postgres  20   0  333m 152m 138m S  0.0  7.6   0:26.56 postgres           
 1779 postgres  20   0  330m 150m 136m S  0.0  7.5   0:13.73 postgres           
 1758 postgres  20   0  329m 149m 137m S  0.0  7.5   0:19.89 postgres           
 1742 postgres  20   0  330m 149m 137m S  0.0  7.5   0:10.19 postgres           
 1769 postgres  20   0  329m 149m 138m S  0.0  7.4   0:55.47 postgres           
 1760 postgres  20   0  329m 149m 137m S  0.0  7.4   0:16.52 postgres           
 1772 postgres  20   0  328m 148m 136m S  0.0  7.4   0:18.93 postgres           
 1764 postgres  20   0  328m 148m 137m S  0.0  7.4   0:17.72 postgres           
 1759 postgres  20   0  329m 148m 136m S  0.0  7.4   0:21.15 postgres           
 1757 postgres  20   0  330m 148m 136m S  5.6  7.4   0:17.73 postgres           
 1766 postgres  20   0  327m 148m 138m S  0.3  7.4   0:25.07 postgres           
 1762 postgres  20   0  328m 148m 136m S  0.0  7.4   0:17.91 postgres           
 1776 postgres  20   0  329m 147m 137m S  0.0  7.4   0:21.30 postgres           
 1770 postgres  20   0  328m 147m 136m S  0.0  7.4   0:16.01 postgres

Its clear that Python and PostgreSQL eat all the memory, but how can I pin point the cause of not releasing any memory (the are lots of different operation that Python and PostgreSQl does)?

using ps aux:

This process uses most memory:

oerp 1529 4.9 20.9 916984 429332 ? Sl 10:58 17:55 /opt/odoo/venv/bin/python /opt/odoo/odoo/openerp-server --config=/etc/odoo-server.conf --no-database-list

But if you combine all processes like this (there are many of those)

postgres  1742  0.0  7.4 338268 153140 ?       Ss   10:59   0:10 postgres: oerp nodbaltic [local] idle 

Then it takes the biggest part of the memory.

Is it normal for postgresql to have many idle processes that take such huge amount of memory?

cat /proc/meminfo:

MemTotal:        2053476 kB
MemFree:           20312 kB
Buffers:           38944 kB
Cached:           926480 kB
SwapCached:         1196 kB
Active:          1431788 kB
Inactive:         490424 kB
Active(anon):     824712 kB
Inactive(anon):   276456 kB
Active(file):     607076 kB
Inactive(file):   213968 kB
Unevictable:        3884 kB
Mlocked:            3884 kB
SwapTotal:       2053112 kB
SwapFree:        2039340 kB
Dirty:              4144 kB
Writeback:             0 kB
AnonPages:        959108 kB
Mapped:           164144 kB
Shmem:            142332 kB
Slab:              58796 kB
SReclaimable:      38440 kB
SUnreclaim:        20356 kB
KernelStack:        1728 kB
PageTables:        28340 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3079848 kB
Committed_AS:    2131992 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      281432 kB
VmallocChunk:   34359446164 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       10240 kB
DirectMap2M:     2086912 kB

P.S. Oh and server is running on virtual machine if that makes any difference.

  • 2
    Did you try to use top or look into /proc/$pid/mem to find the offending process? – Dmitry Grigoryev Mar 25 '15 at 9:15
1

The top command will show the processes currently running along with their memory usage. The RES column reports the memory actually used by a process. Press Shift + M to sort by that column. Press the Q button to get out of the screen again.

0

There are several ways to find out what processes are running and using memory memory.

Top has already been mentioned but i prefer to use atop or htop. You can install those from your repository(yum install atop or apt-get install atop) it gives a much better and complete overview of everything that's happening on your server. You can even configure atop to log everything every x minutes which could help in debugging your issue.

It's also possible to just check what is currently running and using resources by typing

ps faux

the PS command gives you a snapshot of all currently running processes. There's a column for CPU and MEM usage.

Also, just using free -m to debug memory issues can be misleading. It would be a better idea to check:

cat /proc/meminfo

Or use the tools i mentioned like atop or htop as they give a better insight into what the memory usage is actually like (memory reserved by cache and buffers)

Also, posting the results from ps faux or top/atop/htop would help us better assist your issue.

0

Move all data in memory to disk, clearing out the physical memory:

sudo /bin/syncfree pagecache, dentries and inodes 
sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"

Ensure there is enough physical memory to store the entire swap space, and then move the swapped data back into available RAM by running the following two commands:

$ free -m
total       used       free     shared    buffers     cached
Mem:          2048        884       1163          0          0         42
-/+ buffers/cache:        842       1205
Swap:          996        996          0


sudo /sbin/swapoff -a && sudo /sbin/swapon -a 

this moves swapped items to physical memory, disables & re-enables swap.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.