> Апачевские модули лучше линковать статически.
>
ЗАЧЕМ???
> Запускаем ./configure --enable-module=most --enable-shared=max && make.
> Получаем 32 модуля в виде .so.
> Запускаем size src/modules/*/*.so и убеждаемся, что ни у одного модуля,
> кроме libproxy, сегмент данных не превышает 1К. Это значит, мы потеряли
> по 3К в каждом модуле на сегменте данных. Допустим, мы подгружаем в Апач
> 20 модулей из 32. Это 20*3K=60К на Апач. Допустим, у нас работают 100
> апачей. Это 6 потерянных мегобайт. Если стандартный Апач имеет около
> 500К-1М private memory, это 6-12 потерянных Апачей.
>
Если вы уже зашли в такие нагрузки, что эти 10% вам делают погоду, то вам
нужно СРОЧНО задуматься о перестройке системы. И да - если это ДЕЙСТВИТЕЛЬНО
так, то очень может быть, что вам стоит подумать о Tux (который в ядре
живет и данные из SCSI-контроллера прямо в Etnernet передает "без захода
в память" - при наличии соотвествующего железа, разумеется) и т.п.
наворотах. Содание своей "особой версии" Apache (с "правильным
набором" вкомпилированных статически модулей) - в их числе. Настройка
"экстремальной" системы и настройка "обычного сервера" (где проблема
потери 10-20Mb легко решается заменой 256Mb DIMM'ом на 512Mb'е) - две
ОЧЕНЬ разные вещи. Для "экстремальных случаев" Apache ВООБЩЕ не
проектировался и то, что его в таких ситуациях все-таки удается
использовать - показатель живучести современных *nix'ов и ничего более...
> Что касается
> > $ ls -al ls -al /usr/lib/php/extensions
> > total 418
> то число 418 меня просто пугает. Даже если в них сегменты данных
> большие (в чем я не уверен), все равно в среднем теряется 2К на модуль.
> Если используется 10 модулей, то на 100 Апачей мы теряем 2M.
>
> Умножайте на свои цифры и считайте потери.
>
А ЗАЧЕМ ? Вспомните старую заповедь (она актуальна и сегодня):
"преждевременная оптимизация - корень всех бед" (Д.Кнут). Так вот подобные
подсчеты - та самая "преждевременная оптимизация". Если дело зашло в тупик,
то ПРЕЖДЕ всего следует подумать о смене алгоритма (читай - используемого
web-server'а/web-server'ов: установка дополнительного "сверхлегкого"
сервера для отдачи картинок или кеширующего frontend'а способна куда
сильнее снизить нагрузку, чем "лишние" 10 Apache'й), потом - о смене
железа (нарастить памать вдве-втрое: благо сейчас это дешево и навесить
на машину 2-4-8Gb RAM - не бог весть какие затраты) и уж потом (когда все
остальные пути испробованы) начинать считать байты и миллисекунды.
Почему ? Вот тут мы насчитатли "ужасные потери" в 10Mb на 100 Apache'й.
Пусть мы ошиблись в 2-3 раза. То есть мы потеряли памяти на 15-20$
(дорогой памяти, RIMM'овой под Pentium 4!). А приобрели взамен особую
конфигцурацию, с которой мы имеем потенциальный дополнительный геморой,
так как она может вести себя по другому, нежели предкомпилированные
модули. ОНО ВАМ НАДО ? ЧТОБЫ ВЫИГРАТЬ НЕСЧАСТНЫЕ 20$ ???? Да даже если
этих серверов у вас десяток - и тогда овчинка выделки, скорее всего, не
стоит!
P.S. "Rule of thumb": если планируемая акция позволит вам выиграть
ПРОЦЕНТЫ (5-10-15%), а не РАЗЫ (хотя бы в 1.5-2 раза), и при этом вам
придется делать особую конфигурацию чего-либо для сервера (по сравнению
с конфигурацией в базовой OS), то об этом НЕ СЛЕДУЕТ ДАЖЕ И ДУМАТЬ (и
неважно - о чем идет речь: об Apache, Kernel'е, Perl'е или PHP). Конечно
это - не закон: если у вас уже стоит в машине 32Gb RAM и 8 Pentium 4 на
1700MHz, то тут простым походом в магазин с парой сотен баксов делу не
поможешь; или если у вас кластер их 1000 серверов, так что добавть в
каждый 128Mb стоит не 20-30$, а 20'000$-30'000$, так что тут можно
получить экономии на железе больше, чем проигрыша из-за затрат времени
сисадмина и недовольства клиентов.
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
