ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] php-cgi кеширован ие в памяти




Eugene Grosbein wrote:

Может зависеть от операционной системы. Операционки семейства BSD,
к примеру, вообще не "читают" бинарники с диска, они мапят файл бинарника
непосредственно в адресное пространство и запускают его оттуда.
Необходимые страницы кода (и только они) подкачиваются в физическую память
при первом обращении к ним системным пейджером и при достаточном количестве
памяти остаются в ней. При следующем (или даже одновременном) обращении
к коду эти страницы просто используются повторно, никакого повторного чтения
с носителя не будет. Всё это происходит для апача совершенно прозрачно,
он выполняет системый вызов execve(), всё остальное оптимизирует ядро.

ОС FreeBSD, но думаю, что и для линукса механизмы в общем похожи.

Исходя из определения модели CGI - one process per request надо пологать что основная нагрузка получается из за форканья(дублирования) кода пхп-бинаря в памяти? (причем если пришло несколько одновременных запросов, то система сделает столько же копий пхп в памяти? а потом это все добро переместит в inactive(если позволяют ресурсы))

Есть ли разница для системы, из-под какого пользователя был считан бианрь пхп в память?(т.е. для двух разных юзеров система считает пхп-бинарь в память) Насколько я могу судить, то бинарь считывается с соотвествующими правами и для другого юзера системе опять понадобиться считать бинарь пхп в память.

Напоследок, если все происходит в памяти, то все это ложиться на процессор, однако на практике имем большую нагрузку на винт от считывания этих бинарей. Чем это можно обьяснить?

Спасибо за Ваше время!



 




Copyright © Lexa Software, 1996-2009.