In <0ffc01bf6cc8$015240d0$0743d1c3@ssu.samara.ru> BeerBong (alexei@samara.net)
wrote:
>> Ну конечно. Вместо того, чтобы все сегменты кода лежали зашаренными
>> в памяти, наплодим разных апачей, чтобы каждый свою копию кода
>> держал, и тогда получится сказочная экономия памяти, да?.. :)
>>
>> Уже 10 раз обсуждали, наверное... :( И еще раз: в юниксах шарится
>> даже байткод компилированных mod_perl'ом скриптов, если он до
>> расфоркивания создан. То есть часть содержимого сегмента данных.
B> Хмм... Опять же не спорю, я вообще всего полгода назад активно начал
B> перетаскивать все свои работы и сайты с Windows NT IIS 4.0 которые
B> накопились за 5 лет работы на Apache on Linux.
Обычно полезно сначала добиться того, чтобы все работало, а уж затем
оптимизитровать...
B> Все идеи изложенные мною выше конечно не я придумал, а прочитал на
B> perl.apache.org/guide - где собсно и рассказывается про разные Апачи. Про
B> расшаренный код mod_perl скриптов это понятно, это можно на back-end сервере
B> грузить их лоадером. Не хочу разводить флейм про это, раз уж это обсуждалось
B> 10 раз. Где можно почитать про сравнение этих моделей ? Или как вообще
B> настроить Apache для большого кол-ва пользователей и чтобы mod_perl
B> использовался ?
Поставить побольше памяти :-) Вообще при современных ценах на пямять все эти
штучками с двумя Apache'ами и т.п. стоит занимать тогда, когда понятно -- что
это даст.
B> Ты про DSO говоришь что все будет расшаренно ? У меня и тот и другой Apache
B> скомпилены как DSO, но top показывает что каждый процесс mod_perl Apache
B> занимает по 15 метров и памяти у меня собсно не остается...
???? Ну это, знаете ли, та еще информация. Вон у меня top (с сортировкой по
занимаемой памяти) показывает вот это:
-- cut --
8:08pm up 6 days, 3:59, 5 users, load average: 0.86, 0.29, 0.10
73 processes: 71 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 0.5% user, 7.3% system, 0.0% nice, 92.7% idle
Mem: 128032K av, 126744K used, 1288K free, 35272K shrd, 22960K buff
Swap: 265032K av, 11024K used, 254008K free 54252K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
1007 apache 0 0 43072 7928 1980 S 0.0 6.1 0:39 apache
740 apache 0 0 43064 7908 1852 S 0.0 6.1 0:43 apache
742 apache 0 0 43004 7868 1884 S 0.0 6.1 0:42 apache
738 apache 0 0 37724 2652 1912 S 0.0 2.0 0:42 apache
2297 apache 0 0 37700 2652 1892 S 0.0 2.0 0:47 apache
739 apache 0 0 37716 2604 1868 S 0.0 2.0 0:41 apache
741 apache 0 0 37676 2556 1872 S 0.0 1.9 0:42 apache
1031 apache 0 0 37624 2488 1852 S 0.0 1.9 0:37 apache
874 apache 0 0 37608 2472 1860 S 0.0 1.9 0:43 apache
1030 apache 0 0 37560 2420 1844 S 0.0 1.8 0:40 apache
734 mysql 5 5 2468 2016 1460 S N 0.0 1.5 0:00 mysqld
748 mysql 5 5 2468 2016 1460 S N 0.0 1.5 0:06 mysqld
751 mysql 5 5 2468 2016 1460 S N 0.0 1.5 0:00 mysqld
-- cut --
Ну и что с того ? Суммарный объем всех Apache'й первышает объем все виртуалки,
а система почти что в swap не ходит... В Linux'е, по крайней мере, НАЛИЧИЕ
существенных объемов free memory заставляет задуматься о том, что "что-то здесь
не так". А когда free memory - 1-2MiB, то это значит, что все в порядке...
Ибо непорядок это - когда память просто свободна :-) Вот когда LA зашкаливает
за 10-15 или процессы начинают пачками в "D" state застревать (обычно это
обозначает, что они ждут, пока система странички из swap'а вытащит) - это
требует разбирательств.
B> Извините за может быть идиотские вопросы...
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at http://www.lexa.ru/apache-talk =