2

My centos 5.7 is running Magento. 4GB RAM and 4 Cores. Nginx + spwan-fcgi + memcached (Best performance if you ask me).

Now i'm a little bit concerned about the Memory usage.

[root@adikastyle shipment]# free -m
             total       used       free     shared    buffers     cached
Mem:          3948       3712        236          0        224       **2377**
-/+ buffers/cache:       1109       2839
Swap:        10975          0      10975

I've seen in few forum's this command:

# sync; echo 3 > /proc/sys/vm/drop_caches

the website is fast and handle many cur-connections.

but the cache is really strange..

  1. Is this command is safe for production?

  2. Does the 2377MB of cache is good ?

  3. Do i have to change something?

Thanks.

Jeff Ferland
  • 20,239
  • 2
  • 61
  • 85

4 Answers4

4

The cached line you are observing is a very good thing to have.

All the data mentioned there would have to be read from the disk without the cache. With cache, the results will be returned from the RAM.

Linux is very smart with caching and buffering nowadays; do not try to outsmart it with some random copy-and-paste 'tips' you see around in the Internet.

Do not change anything, be happy you have nearly 2.5 GB stuff cached. It helps your performance enormously; dropping the caches with your echo line actually hurts performance quite a lot! The cached stuff will be released immediately if any application actually needs it, this does not cause a performance hit.

Janne Pikkarainen
  • 31,454
  • 4
  • 56
  • 78
2

If it's working well in your configuration, it's performing well, and your statistics are satisfactory for your application(s), don't play with it.

Linux is pretty good about maintaining cache on its own.

Wait until you have actual problems to fix instead of creating new problems.

Bart Silverstrim
  • 31,092
  • 9
  • 65
  • 87
  • 1
    @livneberebi: Nothing wrong with asking that. Everyone had to start somewhere. Good rule of thumb is that as long as your metrics are satisfactory, spend your time reading up on good practices and start roadmapping how you follow them and if you could improve things with your setup. – Bart Silverstrim Mar 14 '12 at 14:09
  • For example, do you have a good backup plan in place? Can you recover if your system were hacked? How soon can you get your server back up if XYZ fails? Did you document your setup? Do you have monitoring in place? Spend time poking around these types of questions instead of poking around tuning the system when it's working okay already for you. – Bart Silverstrim Mar 14 '12 at 14:11
2

It is a common misconception that you should have RAM free. You want as much RAM being used as possible - it is the fastest memory subsystem on your server.

So the Linux OS is pretty smart and begins to store frequently accessed files/data/information in RAM, in the buffers/cache.

When an application needs RAM (eg. more PHP threads), then the memory allocated to disk/buffers is reduced in favour of userspace apps.

So at the moment, your memory usage looks very healthy. But it is also worth bearing in mind how much memory you are actually committing (if your traffic increases and PHP threads increase, MySQL connections increase etc.). You can check this by running

cat /proc/meminfo | grep committed

You should hope to see something like this

commitLimit 3145728 
committed_AS 6291456

It is usually 'fairly safe' for a Magento server to have a committed memory around double available memory (due to having to increase PHP memory limits for long-running admin processes).

Ben Lessani
  • 5,174
  • 16
  • 37
1

The canonical references around here for memory usage that is dominated by cache:

Cached data in memory is free (both in you may treat it as unused and it comes at no cost to performance -- only benefit!), and there are few things in life that are free. When your programs need it, they will get it. When they don't, recently read data from the disks will be kept in memory and used to answer reads that would otherwise need to come from the drive.

Jeff Ferland
  • 20,239
  • 2
  • 61
  • 85