Thank you all for the replies! > If you yourself are seeing that the Ruby processes aren't using all of > the memory, why are you thinking the Ruby application is using all of > the memory? As some others have said, ***basically*** the total memory > usage reported by top and free is that which the kernel has allocated > (and will never give back); from that the kernel gives memory to > processes as requested/available.
Thanks for the explanation as to how/why/what the kernel is doing here. I simply wasn't aware this is how it worked; my understanding was that the kernel would allow a program to use memory when requested, and when the program exits, the kernel would reclaim, then "free" said memory. Obviously I was wrong. My reasoning/thinking it was due to my ruby application was because I haven't seen this behavior before (then again, I never looked this closely, either). Not only that, but our systems admin and IT director are basically pointing the finger at me and my choice of Ruby on Rails as "the culprit" :) Obviously they're WRONG! However, I'm trying to lean-out resource usage because if we can free up resources on our host server (s), we can hold more virtual machines on each, thus reducing costs. > You say you're running Passenger: have you used passenger-memory-stats > to actually get the accurate look at the memory usage of the Ruby app > and Apache? As a bit of a better system memory usage indicator, what > does the -/+ buffers/cache column of free say? That shows the amount > of memory total that the kernel actually is freely able to allocate to > processes. On our public-facing web application server, I'm seeing 13 Apache processes, consuming 0.3mb - 0.6mb of memory each in "private" memory. VMSize is about 148.5MB per apache process. The same utility reports that I have two rails instances running, each of which is consuming approximately 60mb of memory. With regards to free, the -/+ column reads: -/+ buffers/cache: 429896 7183448 I'm assuming this is measured in kilobytes? (I've never heard of this tool, honestly - I'm no systems admin by a long shot!) If this is true, that means 7.1 GIGS of data is being cached!? Why - and what exactly is the system caching? How could I find that out? And as vwchris pointed out, this may not necessarily be a bad thing, but how can I tell for sure? > High memory usage in Linux is not necessarily a Bad Thing (tm). As > stated earlier, Linux systems use memory for caching filesystem and > other things. This will result in memory usage growing over a period > of time while the machine is up. The system will free this memory as > necessary when applications request it. As long as your system is not > running into swap, and none of the individual processes are growing > out of control, it is likely that the machine is in good shape. > Unless there is a performance issue that you are seeing, do not think > that high memory usage is hurting you. Look at the "buffers" number > on the Mem line in top. That will tell you how much of the memory is > in use by the kernel for buffering/caching. All of that should be > available for your applications to use as necessary. Right now my buffers line reads 252608k - so about 250mb. Full top header: top - 14:11: 48 up 20 days, 16:50, 1 user, load average: 0.05, 0.04, 0.00 Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombie Cpu(s): 0.2%us, 0.0%sy, 0.0%ni, 99.7%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 7613344k total, 75734036k used, 41704k free, 252604k buffers Swap: 4305380k total, 116k used, 4305264k free, 676664k cached (I actually re-typed that output from another machine due to the fact I can't VPN from this Windows 7 box and I'm working from home thanks to the H1N1 vaccine...) So after doing some looking around thanks to your recommendations, it looks to me like the kernel is caching 7.1GB of data (weird...really, really weird) and freeing that as needed. Does this look/sound like a plausible explanation to you? Because I've NEVER heard of that, but maybe I'm just plain wrong. Thanks for your help! -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
