1

i am a noob with servers. I have a centos5.5 vps with 512mb ram. My goal is to have it host just one magento store. I've installed Magento on the server without any control panel, by just installing lamp myself and whatever php extensions were necessary to get Magento to install.

As soon as i visit my magento store, suddenly the ram on the vps is almost completely used, with only about 100mb left. Please see this screenshot of htop taken after just myself visited the website.

http://img714.imageshack.us/img714/1944/screenouv.png

As you can see there's only around 100mb left. Is that normal? I'm wondering if i might have done something stupid with the server that makes it very resource hungry. I installed apache from the centos base repo, php version 5.3 from the ius repository and mysql 5.1 also from ius repo. I haven't changed any of the default config files for any of these except to make memory_minimum 256 in php.ini. Is there anything i can do to make more ram free?

I'm clueless but i see each Apache daemon is using 8% of available ram, and AFAIK each visitor needs one Apache daemon. So i would run out of ram with just a handful of visitors. Thanks for your advice.

user66779
  • 153
  • 1
  • 1
  • 7
  • If you use *regular* old-fashioned `top` instead of fancy "htop", you'll be shown the amounts for cache and buffers, which is a lot more useful, as pretty as the text-gui bar there might be. – mattdm Jan 13 '11 at 19:58
  • What happens when you run something like ApacheBench (ab) against it? Depending on how it's setup, Apache will keep a couple of spare processes ready to serve more incoming requests. – Niall Donegan Jan 13 '11 at 20:13

4 Answers4

5

My guess is that you are fine: The memory is used by the disk caching of the Linux kernel (see http://www.linuxatemyram.com/ for more details).

About Apache: While every user needs an instance of Apache if you use a non-threaded version of Apache (as is the default), he uses this for only a short amount of time, while a single page is transmitted to the user. After this, the apache process will handle the next request, likely by a different user. This way, you can handle many connections with only relatively few apache processes.

Edit: An example for free's output:

             total       used       free     shared    buffers     cached
Mem:           498        434         64          0        194         77
-/+ buffers/cache:        162        336
Swap:         4102          0       4102

The 64MB that are listed as free is the amount of memory that is not used in any way. But (nearly) all of the buffers/cache memory can be used by the OS immediately if it needs it, so the potential available memory is in fact nearly 350MB instead of 64MB.

Sven
  • 98,649
  • 14
  • 180
  • 226
1

Centos will use any spare RAM as disk cache and buffers to speed things up. As you access files they will be cached in memory. The cache is still part of free memory and will be given up if if required elsewhere by the system. Take a look here for more information.

user9517
  • 115,471
  • 20
  • 215
  • 297
0

By visiting the Magneto store, mysql retrieves data from disk and then keeps in in cache (RAM) for quicker retrieval. This is normal.

0

512MB is not very much. PHP in combination with the Apache prefork MPM means you'll consume that very quickly.

In fact, you need to divide your total RAM (512MB) by the memory_limit in /etc/php.ini to get a reasonable number for Apache's MaxClients setting. The Magneto wiki says 64MB is recommended but may not be enough. Assuming you go with 64MB, that gives you 8 clients. Really, somewhat fewer, as you're also running mysql and some other stuff on the same system. You can get away with a larger number than that, but at some point, your system will die.

Remember that each request needs to be answered by one prefork server, not each visitor. If each request is served quickly enough, you may not need as many servers as you think.

Holdddd onnnn a second here. The system requirements documentation for the current version say that memory_limit should be at least 256MB, and they in fact ask for 512MB. That gives you 2 or 1 Apache workers, which is not really tenable.

So. You'll need to re-think. You can either throw more RAM at the problem (highly recommended), or use a different Apache MPM (may be problematic with your PHP app; I dunno), or use lighttpd + fastcgi.

In fact, you're probably going to have to get more RAM in any case — or else use an entirely different application.

(BTW: Turn off yum-updatesd, and replace it with yum-cron. You should have automatic updates, but you don't need the daemon sitting there in RAM all day long.)

mattdm
  • 6,600
  • 1
  • 26
  • 48
  • so your saying i need to change the maxclients setting from the default 256 value to like 8 or even less? Is this for value you are referring to the prefork MPM or worker MPM one. – user66779 Jan 13 '11 at 21:30
  • Question one: I'm really saying that you need to get more RAM. – mattdm Jan 13 '11 at 21:38
  • Question two: That's for prefork. For worker, the limit is (basically) ServerLimit, but honestly I'm not sure how exactly the memory usage of a PHP app is going to interact. (Or if your application is even thread-safe.) – mattdm Jan 13 '11 at 21:41
  • Is this a good or bad result: Concurrency Level: 20 Time taken for tests: 1.190956 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Non-2xx responses: 5000 Total transferred: 1915000 bytes HTML transferred: 1025000 bytes Requests per second: 4198.31 [#/sec] (mean) Time per request: 4.764 [ms] (mean) Time per request: 0.238 [ms] (mean, across all concurrent requests) Transfer rate: 1570.17 [Kbytes/sec] received – user66779 Jan 13 '11 at 22:03
  • Assuming that's ApacheBench results. You probably wanted to post that as an edit to your question, not as a comment to my answer. But the short answer is: the numbers look good, but it's an incomplete result that doesn't tell us much, because it probably doesn't represent real usage very well. ("How do I benchmark my PHP app?" would be a whole separate question.) – mattdm Jan 13 '11 at 22:10