Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi,
I'm trying to determine how many memory I've in order to run Apache websites, so I'm using "free" command.
Should I consider the free one (first row) or the second (in the +/- buffer/cached row)?
I'd say the second one. You have 3 Gb of memory readily made available to applications when requested. The free memory is somehow wasted, in the sense it would be better to use it, since reading data from disk is far slower than reading from memory. This is the reason why data are cached in memory: if they are used again, the cache will speed up the process.
Some useful information in the (unmaintained) Linux System Administrator's Guide and in this old (but still valid) article from Linux Journal.
The second line is almost always the one the represents the true situation in the sense that you care about used vs. free memory.
In the case quoted by the first post, I would be extra confident that the second line is the meaningful line.
When a Linux system is under major memory pressure, it will soft fault a lot in addition to paging to/from disk. When there is a high rate of soft faults, the cache memory is effectively part of the resident memory of the active tasks, but not reported as such. Under that unusual case the second line of free output is misleading and the first line more informative. That does not imply I think any such thing is happening for the OP. It just means the claim that the second line is more meaningful than the first is not universally correct.
Perhaps I did not understand: the buffer/cache row is only speaking about "memory data" stored on hard disk?
So, If I've a lot of "%wa" (wait, in top command), should I think that things will runs very slow?
Thankyou again.
Perhaps I did not understand: the buffer/cache row is only speaking about "memory data" stored on hard disk?
buffer/cache is ram used to store copies of data that is also on hard disk and that is not needed in ram at the moment.
If more ram is needed for some other purpose, it can be taken from buffer/cache. If instead, the data stored in buffer/cache happens to be needed it can be used immediately instead of reading it from disk.
Quote:
So, If I've a lot of "%wa" (wait, in top command), should I think that things will runs very slow?
Do you have a lot of "%wa" in top? I think that would mean the programs you are running are reading a lot of files from disk that have not been read before recently and thus are not in cache.
so, memory listed in the buffer/cache relates to data that are currently in the physical ram (in my case: 4 GB) and can be quickly "replaced" according to application usage?
memory listed in the buffer/cache relates to data that are currently in the physical ram (in my case: 4 GB) and can be quickly "replaced" according to application usage?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.