VSZ это сколько процесс запросил памяти у операционной системы.
RSS это сколько из этой памяти он использует, разделяя её часть с другими
апачами или нет - уже не суть. Разница VSZ-RSS это сколько памяти было
запрошено, но в соответствующую область не было ни одного факта записи.
Спасибо за обьяснение. Уже понял что VSZ-RSS ниочем не говорящие данные.
Насколько я понял, в основном все чаилды используют shared mem родителя
(на 90%). Остальное - передаваемые данные, скомпилированный код и
прочее, что не шаред. Возможно, сюда попадает еще чтото, но я не знаю точно.
Таким образом, сначала, стартуя, apache загребает на себя в принципе
не много (~20-30м) в зависимости от конфигурации. Далее в процессе
работы чаилды разрастаются за счет компиляции кода пхп, данных и прочего.
Для интереса написал небольшой скрипт для сравнения количества памяти и
процессов.
Diff mem from last measure - показывает насколько изменилось состояние
памяти от последнего отсчета
Diff process from last measure - показывает на сколько изменилось
количество процессов апаче от последнего отсчета
Memory per process - собственно (изменение памяти)/(изменение процессов)
Date: 17.09.07-14:37
Active Mem: 483 M
Process httpd: 35
Average VSZ: 37124 Kb
Average RSS: 30677 Kb
Diff mem from last measure: 42
Diff process from last measure: 10
Memory per process: 4.2 Mb
Date: 17.09.07-14:38
Active Mem: 551 M
Process httpd: 48
Average VSZ: 37212 Kb
Average RSS: 30778 Kb
Diff mem from last measure: 68
Diff process from last measure: 13
Memory per process: 5.2 Mb
Логика, конечно, немного грубовата, но тем не менее...
Прирост памяти в зависимости от процессов апаче налицо. И в среднем это
4-5м.
Хотелось бы услышать от гуру чем еще может обуславливаться этот размер
процессов(4-5м), который вызывает чистый расход памяти(RSS).
И это исключительная особенность апаче? как бы себя повел апаче в
связке с php-fastcgi.
Также если использовать Nginx в качестве фронтенда, какая будет картина
с апаче ?
Еще весьма интересно....на официальной странице по тюнингу апаче:
определение числа MaxClients. The procedure for doing this is simple:
determine the size of your average Apache process, by looking at your
process list via a tool such as top, and divide this into your total
available memory, leaving some room for other processes.
( Hardware and
Operating System Issues).
Если я таким образом буду оперелять число MaxClients...хм... 2G/30м ~ 67
процессов (без учета всего остального...) . А в реале
Active Mem: 1020 M, Process httpd: 125. - обычная нагрузка.
Никак не пойму почему на официальной доке советуют способ без учета
шаред мемори.
На
()
дается существенно более обьективная информация по этому поводу.
It's important to understand how much real memory a child occupies. Your
children can share memory between them when the OS supports that. You
must take action to allow the sharing to happen - See Preload Perl
modules at server startup. If you do this, the chances are that your
MaxClients can be even higher. But it seems that it's not so simple to
calculate the absolute number. If you come up with a solution please let
us know! If the shared memory was of the same size throughout the
child's life, we could derive a much better formula:
Total_RAM - Shared_RAM_per_Child
MaxClients = ---------------------------------------
Max_Process_Size - Shared_RAM_per_Child
что гораздо ближе к истине.
PS. меня вообщето не MaxClients интересует...просто хочу понять как
происходит распределение памяти между чаилдами.
