> Обычно полезно сначала добиться того, чтобы все работало, а уж затем
> оптимизитровать...
Да все работает прекрасно, потребность в ssl появилась после. Ну и возникло
желание что-нить пооптимизировать :)
>
> B> Все идеи изложенные мною выше конечно не я придумал, а прочитал на
> B> perl.apache.org/guide - где собсно и рассказывается про разные Апачи.
Про
> B> расшаренный код mod_perl скриптов это понятно, это можно на back-end
сервере
> B> грузить их лоадером. Не хочу разводить флейм про это, раз уж это
обсуждалось
> B> 10 раз. Где можно почитать про сравнение этих моделей ? Или как вообще
> B> настроить Apache для большого кол-ва пользователей и чтобы mod_perl
> B> использовался ?
>
> Поставить побольше памяти :-) Вообще при современных ценах на пямять все
эти
> штучками с двумя Apache'ами и т.п. стоит занимать тогда, когда понятно --
что
> это даст.
Да и понятно, легкие Апачи потихоньку отдают тормозным клиентам данные,
кол-во mod_perl Apache не большое, коннектов к Oracle соответственно тоже не
много (2-5 штук, а коннект к Ораклу занимает немалое время, так как не на
локальной машине, и памяти - хотя память наверное опять же половина
расшаренная :)) и мне совсем не хочется их плодить для каждого пользователя
даже с использованием Apache::DBI.
>
> 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'а вытащит) - это
> требует разбирательств.
Понятно, поставил Apache::VMonitor - клево, что-то понятно стало...
Спасибо за комментарии...
Учиться, учиться
и еще раз учиться :)
----------------------------------------------
Sergey Polyakov (BeerBong)
Chief of Web Lab (http://www.mustdie.ru/~beerbong)
=============================================================================
= 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 =