| 1 |
On Mon, Sep 17, 2012 at 10:52 AM, Jarry <mr.jarry@×××××.com> wrote: |
| 2 |
> On 16-Sep-12 20:06, Michael Hampicke wrote: |
| 3 |
>>> |
| 4 |
>>> * Each Apache process is consuming 80-100MB of RAM. |
| 5 |
>>> * Squid is consuming 666MB of RAM |
| 6 |
>>> * memcached is consuming 822MB of RAM |
| 7 |
>>> * mysqld is consuming 886MB of RAM |
| 8 |
>>> * The kernel is using 110MB of RAM for buffers |
| 9 |
>>> * The kernel is using 851MB of RAM for file cache (which benefits squid). |
| 10 |
>>> |
| 11 |
>> |
| 12 |
>> As Jerry did not specify which content his apache is serving, I used |
| 13 |
>> 12MB of RAM per apache process (as a general rule of thumb). But if it's |
| 14 |
>> dynamic content generated by a scripting language like php it could be a |
| 15 |
>> lot more. But I think 80-100MB of RAM with php in the back should be a |
| 16 |
>> good guess. |
| 17 |
>> |
| 18 |
>> Important thing is: |
| 19 |
>> |
| 20 |
>> MaxClients x memory footprint per apache process < available memory :-) |
| 21 |
>> |
| 22 |
>> If you have lots of concurrent requests you may be better suited with |
| 23 |
>> something lighter.... like lighttpd. Or start caching of some sort, like |
| 24 |
>> Michael does. |
| 25 |
> |
| 26 |
> |
| 27 |
> Thank you for all tips&tweaks. My apache is serving mostly dynamic |
| 28 |
> content (drupal cms), and single apache process has ~35-40MB RES |
| 29 |
> It is on VPS, with 1GB/2GB soft/hard RAM limits, only apache & mysql |
| 30 |
> running. Mysqld needs ~100-200MB, and caching is covered by apc. |
| 31 |
> I reduced maxclients down to 40, it should never run out of memory. |
| 32 |
|
| 33 |
APC is for PHP opcode caching. Memcached is like a database cache |
| 34 |
(depends on how clients choose to use it). squid is finished-object |
| 35 |
caching. |
| 36 |
|
| 37 |
Each cache reduces resource requirements for a different piece of the |
| 38 |
overall application. APC allows mod_php to avoid some reparsing and |
| 39 |
recompilation. Memcached allows an application to say "I can |
| 40 |
regenerate this data if I _must_, but it's kinda expensive, and I'd |
| 41 |
rather not." Squid captures HTTP requests, looks to see if it has a |
| 42 |
copy of the object being requested. If it does, it looks to see if the |
| 43 |
object has expired. If it has, it passes the request on to the backend |
| 44 |
httpd. If it hasn't, it returns the object it already has. (There are |
| 45 |
at least three mechanisms that protect clients from stale copies of |
| 46 |
dynamically-generated data, and I would be very, very surprised if |
| 47 |
drupal didn't leverage all of them, so it should be safe and |
| 48 |
beneficial for you to add a squid proxy.) |
| 49 |
|
| 50 |
TL;DR, caching is _never_ fully handled by one component. Now go back |
| 51 |
and read what I wrote, if you didn't. :) |
| 52 |
|
| 53 |
> |
| 54 |
> BTW, how's that someone has apache process 10-20MB, and me 40MB? |
| 55 |
> I'd like to reduce its size, but do not know how... |
| 56 |
|
| 57 |
APC is going to be part of it. You might also look up some other ways |
| 58 |
of performance-tuning mod_php. |
| 59 |
|
| 60 |
Really, though, I'd recommend sticking an HTTP proxy in front of |
| 61 |
apache first, so you can reduce the number of processes you need. The |
| 62 |
setup I described is what runs rosettacode.org, which gets a fair |
| 63 |
amount of traffic (averaging 50k-60k pageviews per week, 500 pageviews |
| 64 |
per hour with spikes up to 1100, and a virgin pageview will (IIRC) |
| 65 |
involve up to around 12 objects requested from the server.). |
| 66 |
|
| 67 |
This setup is stable enough that it only requires enough attention |
| 68 |
from me for security updates and an occasional log issue. (There's a |
| 69 |
file not being handled by logrotate that I haven't had time to fix.) |
| 70 |
|
| 71 |
-- |
| 72 |
:wq |
Archives