ПРОЕКТЫ 


  АРХИВ 


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.