ПРОЕКТЫ 


  АРХИВ 


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] mod_ssl + mod_proxy



> Обычно полезно сначала добиться того, чтобы все работало, а уж затем
> оптимизитровать...

Да все работает прекрасно, потребность в 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                 =



 




Copyright © Lexa Software, 1996-2009.