D. Krmpotic wrote: > free -m > total used free shared buffers > cached > Mem: 510 470 40 0 11 > 45 > -/+ buffers/cache: 413 97 > Swap: 0 0 0 > > This is quite a problem for me and I hope someone can suggest a > solution! Thanx!
Linux aggressively caches files using available free memory (and even sometimes swapping out lesser used programs for more cache), consequently "free" memory is not just the reported unused memory, but unused + buffers + cache. So, when you looked at top, it said 52M free, but the effective free memory is 97M as reported by that second line from free. Your VM does appear to have swap disabled, which can be a good idea if you have a very well tuned and controlled memory profile, but quite a problem if not. Yes it's best never to swap, but it might be preferable to go slow instead of fail completely when you run out. > Can you please help me understand how can 90% of memory be used if first > 5 lines in TOP total to 63% (the rest is negligible). So 3 thins, nginx, > mysql and postgres should not consume 90% of 512MB and the percentages > in the table confirm this. But still I only have 52MB left (!?). Well, as we just discussed, you actually have about 80% used, not 90%, when you reclaim the OSes cache slush, Don't discount all those little processes -- you likely have several dozen to a hundred 1-5M processes below your top five -- it adds up. Looking back at your earlier top output, I also notice you have Pg running with about 90M shared buffers (inferred from the virtual memory size), but it normally uses only 2-4M RSS: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2472 postgres 16 0 99.6m 4836 2168 S 0 0.9 0:00.85 postgres 13653 postgres 16 0 99.1m 4064 1876 S 0 0.8 0:00.03 postgres 2476 postgres 16 0 99.9m 3356 812 S 0 0.6 0:00.39 postgres It's possible that the sphinx indexing operation, which queries postgres directly, causes Pg to temporarily allocate substantially more memory then the normal working set to serve the re-index requests, and that could be another source of your memory over-commit. If your principle database is postgres, I gotta wonder why you have a 32M mysqld running too? 2102 mysql 15 0 162m 32m 1524 S 0 6.4 0:07.48 mysqld -Devin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en -~----------~----~----~----~------~----~------~--~---
