Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a web server running Plesk. I've created a test subdomain in apache and placed a copy of the site there to use for testing. Since doing that, memory usage on the server has gone up quite a bit. The files are the same, the tasks are the same... but if I restart Apache, and tool around on the live site for a while, the usage sits around 0.5gb / 2.0gb total. Visiting one page on the test site puts the usage up to 1.0gb straight away, and the usage then hovers around the 1gb mark.

My first question is, does it sound reasonable that a second virtual host would consume that much extra memory? I don't know much about these things but I can imagine that a bunch of resources are cached and/or reserved once the second virtual host starts getting used, and that the amount of resources required by two copies of that application would be twice that required by one copy.

My second question is, if that's the case, is there any way to tell the system that this test server is really low priority, and that I'm perfectly happy to wait longer for requests to it to go through, for it to free memory after it's done stuff, etc?

share|improve this question

1 Answer 1

up vote 3 down vote accepted

(I don't know plesk, so this answer may be off the mark if these assumptions are wrong.)

With regard to the memory usage, this depends on what your application backend is using, because mod_XXX php or whatever your scripting language you are using may spawn a new script processing instance to handle the 2nd virtual host. So it is plausible that it would create a 2nd duplicate cache and buffer for itself. You would have to provide the app server details etc.

With regard to creating a higher priority for one site over the other the following applies; Assuming that your test subdomain is running as a NameVirtualHost then both your main site and your test subdomain site are running on the same IP address on the same instance of apache httpd.

Then the problem is that apache must read the HTTP "Host:" header from the request to determine which virtual host should handled the request, so its already most of the way through before it can decide to apply limits. (most of the httpd limits apply per server, not per virtualhost, see http://httpd.apache.org/docs/2.2/mod/core.html#rlimitmem for details)

So its hard to apply CPU or memory limits that way. However your options might be to start another instance of httpd, which has smaller RLimitMEM, RLimitNPROC set on that server, and for that you would need another IP address. (however that is a PITA, unless its easy to do with plesk, or you are happy to mess with init.d files, and you may well end up using even more RAM for the 2nd httpd/children than before)

share|improve this answer
    
Awesome info, thanks. The app is a bloated Joomla install, running as cgi rather than mod_php. At the moment I'm thinking, it doesn't seem to be a memory leak because at least without the test server, the memory usage holds steady at 1gb. Though I haven't ruled out the test server doing something weird, like maybe rebuilding a massive image cache which is complete on the live server, or something of that kind. –  Jeremy Warne Feb 19 '12 at 22:03
    
On linux the "headline" numbers for memory usage are deceiving because both httpd and the kernel will dynamically adjust (depending on the tuning). Really a more practical way to go is to record some useful baseline number, such as page response time and track that. You can use pingdom.com or some free service which will poll your pages and combine that with some system metrics tool like munin. Obviously performance monitoring and tracking is a subject which you can spend a whole career doing ... ;-) –  Tom H Feb 20 '12 at 3:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.