Настройка Apache

Apache – часть программного обеспечения, легко поддающаяся настройке. Он имеет множество функций, но каждая является ценной. Настройка Apache отчасти состоит в надлежащем распределении ресурсов и подразумевает отключение ненужных настроек.

Конфигурирование мультипроцессорных модулей

Приложение Apache является модульным, в том смысле, что вы легко можете добавлять и удалять его элементы. Эту модульную функциональность в ядре Apache — управление сетевыми соединениями и отправку запросов — обеспечивают мультипроцессорные модули (Multi-Processing Modules, MPM). Модули позволяют вам использовать thread’ы или даже перемещать Apache в другую операционную систему.

Одновременно может быть активен только один мультипроцессорный модуль и он должен быть скомпилирован статически при помощи --with-mpm=(worker|prefork|event) .

Традиционная модель «один процесс на запрос» назвается prefork. Более новая, модель с thread’ами, называемая worker, использует несколько процессов, каждый с несколькими thread’ами, для получения более высокой производительности при более низких накладных расходах. Наконец, event — экспериментальный модуль, который содержит особые группы thread’ов для различных задач. Чтобы определить, какой мультипроцессорный модуль вы сейчас используете, выполните httpd -l.

Выбор мультипроцессорного модуля зависит от многих факторов. Отключение модуля event до тех пор, пока он имеет экспериментальный статус, — это выбор между thread’ами и их отсутствием. Внешне кажется, что использовать thread лучше, чем использовать fork, если все основные модули являются безопасными thread’ами, включая все используемые PHP библиотеки. Prefork — более безопасный выбор; если вы выбрали worker, вы должны провести тщательное тестирование. Рост производительности также зависит от входящих в дистрибутив библиотек и вашего оборудования.

Независимо от того, какой мультипроцессорный модуль вы выбрали, вы должны соответствующим образом сконфигурировать его. Вообще, конфигурирование модуля подразумевает определение, как Apache контролирует количество запущенных worker’ов, являются ли они thread’ами или процессами. В Листинге 1 показаны важные опции конфигурирования модуля prefork.

Листинг 1. Конфигурирование мультипроцессорного модуля prefork
StartServers 50
MinSpareServers 15
MaxSpareServers 30
MaxClients 225
MaxRequestsPerChild 4000

В модуле prefork новый процесс создан при помощи запроса. Резервные процессы простаивают, чтобы общаться с поступающими запросами, что уменьшает время ожидания запуска. Предыдущая конфигурация запускает 50 процессов, как только стартует Web-сервер, и старается поддерживать в наличии от 10 до 20 простаивающих запущенных серверов. Жесткий лимит процессов определяется при помощи MaxClients. Даже если процесс может общаться с множеством последовательных запросов, Apache убивает процессы после 4,000 соединений, что уменьшает риск утечки памяти.

Конфигурирование мультипроцессорных модулей с поддержкой thread’ов производится подобным образом, за исключением того, что вы должны определить, сколько thread’ов и процессов должно использоваться. Документация Apache дает разъяснения по всем параметрам и необходимым расчетам.

Выбор используемых значений подразумевает некий метод проб и ошибок. Наиболее важное значение — MaxClients. Цель состоит в том, чтобы разрешить достаточное количество процессов worker или thread’ов, чтобы сервер не занимался исключительно свопингом. Если поступает больше запросов, чем может быть обработано, то по крайней мере те, которые поступили, обрабатываются; другие блокируются.

Если MaxClients слишком высок, все клиенты получают недостаточно высокий уровень сервиса, поскольку Web-сервер пробует выгрузить один процесс, чтобы позволить выполняться другому. Установка слишком низкого значения приводит к тому, что вы можете необоснованно отказать в обслуживании. Проверка количества процессов, запущенных в момент повышенной нагрузки, и анализ объема памяти, используемой всеми процессами Apache, дает вам хорошую идею относительно установки этого значения. Если вы устанавливаете значение MaxClients выше 256, вы должны установить то же значение для ServerLimit; внимательно прочтите документацию по мультипроцессорным модулям, чтобы узнать о соответствующих предостережениях.

Настройка числа запускаемых серверов и наличие запасных зависит от роли сервера. Если на сервере выполняется только Apache, вы можете использовать невысокое значение, как показано в Листинге 1, поскольку вы можете использовать машину в полной мере. Если система используется еще и базой данных или другим сервером, вы должны ограничить число запасных запущенных серверов.

Эффективное применение опций и переопределений

Каждый запрос, который обрабатывает Apache, проходит через сложный набор правил, которые диктуют любые ограничения или специальные инструкции, которым должен следовать Web-сервер. Доступ к папке может быть ограничен IP-адресом для определенной папки, или могут быть сконфигурированы имя пользователя и пароль. Эти опции также включают обработку определенных файлов, например, если предоставляется листинг каталога, они определяют, как будут обрабатываться определенные типы файлов, или должен ли быть сжат вывод.

Эти конфигурации имеют вид контейнеров в httpd.conf, например, <Directory> определяет, что конфигурация обращается к местоположению на диске, или <Location> задает отсылку на путь, указанный в URL. В Листинге 2 показан контейнер Directory в действии.

Листинг 2. Контейнер Directory, применяемый к каталогу root

AllowOverride None
Options FollowSymLinks


В Листинге 2 конфигурация, ограниченная тегами Directory и /Directory, применяется к данному каталогу и его содержимому — в этом случае к каталогу root. Здесь тег AllowOverride определяет, что пользователям не разрешается отменять любые опции (более подробно об этом позже). Опция FollowSymLinks разрешена, что позволяет Apache видеть прошлые символьные линки для обслуживания запроса, даже если файл не входит в каталог, содержащий Web-файлы. Это означает, что если файл в вашем Web-каталоге является символьным линком на /etc/passwd, Web-сервер успешно обслужит файл, если поступит запрос. Использование -FollowSymLinks отключит эту возможность, и тот же самый запрос будет причиной возврата ошибки клиенту.

Последний сценарий — повод для беспокойства на двух фронтах. Первый — вопрос производительности. Если FollowSymLinks отключен, Apache должен проверять каждый компонент имени файла (каталоги и собственно файл), чтобы убедиться, что они не являются символьными линками. Это влечет дополнительные накладные расходы в форме нагрузки на диск. Сопутствующая опция FollowSymLinksIfOwnerMatch следует за символьным линком, если владелец файла тот же, что и владелец линка. Это оказывает такое же воздействие на производительность, как и отключение следования символьным линкам. Для наилучшей производительности используйте опции из Листинга 2.

Читатели, которых волнуют вопросы безопасности, уже должны быть обеспокоены. Безопасность — всегда компромисс между функциональностью и риском. В этом случае функциональность — это скорость, и риск предполагает неавторизованный доступ к файлам системы. Смягчающим фактором является то, что серверы приложений LAMP обычно предназначены для определенной функции, и пользователи не могут создавать потенциально опасные символьные линки. Если жизненно необходимо разрешить проверку символьной ссылки, вы можете разрешить это только в определенной области файловой системы, как показано в Листинге 3.

Листинг 3. Ограничение FollowSymLinks для каталога пользователя

<Directory />
Options FollowSymLinks
</Directory>
<Directory /home/*/public_html>
Options -FollowSymLinks
</Directory>

В Листинге 3 любой каталог public_html в домашнем каталоге пользователя имеет опцию FollowSymLinks, отключенную для этого и всех вложенных каталогов.

Как вы видели, опции могут конфигурироваться на покаталожной основе через конфигурацию главного сервера. Пользователи могут самостоятельно отменить конфигурацию сервера (если администратором разрешено AllowOverrides), исключив из каталога файл .htaccess. Этот файл содержит дополнительные директивы сервера, которые загружаются и применяются к каждому запросу каталога, в котором содержится файл .htaccess. Несмотря на прежние рассуждения об отсутствии в системе пользователей, многие приложения LAMP используют эту функциональность для осуществления контроля доступа и для перезаписи URL, так что это целесообразно для понимания того, как это работает.

Несмотря на то, что утверждение AllowOverrides препятствует пользователям в совершении тех действий, которые вы хотите им запретить, Apache по-прежнему должен искать файл .htaccess, чтобы выяснить, нужно ли что-нибудь сделать. Родительский каталог может определить директивы, которые должны быть обработаны запросом дочернего каталога, что означает, что Apache должен также исследовать каждый компонент дерева каталогов, ведущий к запрашиваемому файлу. По понятным причинам это является причиной высокой дисковой активности по каждому запросу.

Самое простое решение — не позволять любые переопределения, которые отменяют необходимость проверки Apache файла .htaccess. Любые специальные конфигурации затем помещаются непосредственно в httpd.conf. В Листинге 4 показано, что нужно добавить в httpd.conf, чтобы позволить проверку пароля для пользовательского каталога project, вместо того чтобы помещать информацию в файл .htaccess и надеяться на AllowOverrides.

Листинг 4. Перемещение конфигурации .htaccess в httpd.conf
<Directory /home/user/public_html/project/>
AuthUserFile /home/user/.htpasswd
AuthName "uber secret project"
AuthType basic
Require valid-user
</Directory>

Если конфигурация помещена в httpd.conf и AllowOverrides отключен, интенсивность использования диска может уменьшиться. Каталог пользователя project может не привлечь большого количества обращений, но учитывайте мощь этого метода применительно к сайту, работающему с большой нагрузкой.

Иногда невозможно исключить использование файлов .htaccess. Например, в Листинге 5, где выбор ограничен определенной частью файловой системы, возможность отмены также может быть ограничена.
Листинг 5. Ограничение проверки .htaccess
<Directory />
AllowOverrides None
</Directory>
<Directory /home/*/public_html>
AllowOverrides AuthConfig
</Directory>

После того как вы выполните операции из Листинга 5, Apache все же ищет файлы .htaccess в родительском каталоге, но прекращает поиск в каталоге public_html, поскольку становится невозможным функционирование остальной части файловой системы. Например, если запрашивается файл /home/user/public_html/project/notes.html, то его успешное отображение произойдет только в том случае, если каталоги public_html и project будут найдены.

Уместно сделать одно последнее замечание относительно относящихся к отдельным каталогам конфигураций. Любой документ о настройке Apache дает указание запретить DNS lookup через директиву HostnameLookups off, поскольку попытки обратно разрешить соединения всех IP-адресов с вашим сервером — излишняя трата ресурсов. Однако любые ограничения, базирующиеся на имени хоста, вынуждают Web-север выполнять обратный lookup на IP-адресе клиента и прямой lookup на основании результата проверки подлинности имени. Поэтому благоразумно избегать использования средств контроля доступа, базирующихся на имени хоста, и, когда они необходимы, проверять их, как описано.

Постоянные соединения

Когда клиент соединяется с Web-сервером, разрешается порождение множественных запросов по одному и тому же TCP-соединению, что уменьшает время ожидания, связанное с многократными соединениями. Это полезно, когда Web-страница содержит несколько изображений: клиент может запросить страницу и затем все изображения в течение одного соединения. Обратная сторона состоит в том, что процесс worker на сервере должен ожидать закрытия сеанса клиентом, прежде чем он сможет перейти к следующему запросу.

Apache позволяет вам определять, как будут обработаны постоянные соединения, называемые keepalives. KeepAlive 5 на глобальном уровне httpd.conf позволяет серверу обработать 5 запросов на соединение, прежде чем соединение будет насильственно прервано. Установка этого числа в 0 запретит использование постоянных соединений. KeepAliveTimeout, тоже на глобальном уровне, определяет, как долго Apache будет ожидать другого запроса, прежде чем сессия закроется.

Обработка постоянных соединений не является конфигурацией типа «один-размер-годится всем». Некоторые Web-сайты функционируют лучше, если keepalives запрещены (KeepAlive 0), и в некоторых случаях их включение может принести огромную пользу. Единственное решение — попробовать оба варианта и выяснить все самостоятельно. Тем не менее разумно использовать низкий таймаут, например, 2 секунды, при помощи KeepAliveTimeout 2, если вы разрешили keepalives. Это даст гарантии, что любой клиент, желающий сделать другой запрос, будет иметь достаточное количество времени, и что процессы worker не останутся без работы, пока будут ждать другого запроса, который может никогда не поступить.

Сжатие

Web-сервер может сжимать вывод, прежде чем он возвратить его клиенту. В результате уменьшается объем страницы, посылаемой по Интернету, за счет циклов CPU на Web-сервере. Для тех серверов, которые могут позволить себе высокую нагрузку на CPU, это отличный способ создания быстро загружаемых страниц — размер страницы может после сжатия уменьшиться втрое.

Изображения обычно уже сжаты, поэтому необходимо сжимать только текстовый вывод. Apache предусматривает сжатие при помощи mod_deflate. Несмотря на то, что mod_deflate может быть просто отключен, он содержит множество сложных моментов, которые руководство стремится объяснить. Эта статья не касается темы конфигурирования сжатия, за исключением предоставления ссылки на соответствующую документацию (см. раздел Ресурсы).

Настройка PHP

PHP — движок, который запускает код приложений. Вы должны установить только модули, которые планируете использовать, и сконфигурировать ваш Web-сервер для использования PHP только для файлов скриптов (обычно те файлы, названия которых заканчиваются на .php) а не всех статических файлов.

Кеширование кода операции

Когда запрашивается скрипт PHP, PHP читает скрипт и собирает его в то, что называется код операции Zend, бинарное представление кода, который будет выполнен. Этот код операции затем выполняется движком PHP и теряется. Кэш кода операции сохраняет его и в следующий раз при запросе страницы вновь использует. Это экономит немало времени. Некоторые кэши кода операции доступны; я успешно использовал eAccelerator.

Инсталляция eAccelerator требует наличия в компьютере библиотек разработки PHP. Поскольку разные дистрибутивы Linux помещают файлы в разные места, получите инструкции по инсталляции непосредственно с Web-сайта eAccelerator’а (см. ссылку в разделе Ресурсы). Также возможно, что ваш дистрибутив уже упаковал кэш кода операции, и вы должны просто установить соответствующий пакет.

Независимо от того, каким образом вы установили на своей системе eAccelerator, есть несколько вариантов конфигурации. Конфигурационным файлом обычно бывает /etc/php.d/eaccelerator.ini. eaccelerator.shm_size определяет размер кэша совместно используемой памяти, где хранятся скомпилированные скрипты. Значение измеряется в мегабайтах. Определение подходящего размера зависит от приложения. eAccelerator предоставляет скрипт для показа статуса кэша, который включает использование памяти; 64 мегабайта — хорошее значение для начала (eaccelerator.shm_size="64"). Вы также можете настроить максимальный размер для shared memory, если выбранное вами значение не было принято. Добавьте kernel.shmmax=67108864 в /etc/sysctl.conf и запустите sysctl -p, чтобы настройки вступили в силу. Значение kernel.shmmax измеряется в байтах.

Если превышен объем выделяемой shared memory, eAccelerator должен удалить из памяти старые скрипты. По умолчанию это отключено; eaccelerator.shm_ttl = "60" устанавливает, что когда eAccelerator исчерпывает размер shared memory, любой скрипт, доступ к которому не был получен в течение 60 секунд, должен быть удален.

Другая популярная альтернатива eAccelerator — Alternative PHP Cache (APC). Создатели Zend также имеют коммерческий кэш кода операции, включающий оптимизатор для дальнейшего повышения эффективности.

php.ini

Вы конфигурируете PHP в php.ini. Четыре важных параметра настройки определяют, какое количество системных ресурсов может потреблять PHP, как показано в Таблице 1.
Таблица 1. Параметры настройки php.ini, связанные с ресурсами

Размер этих значений обычно зависит от приложения. Если вы принимаете от пользователей большие файлы, max_input_time может быть увеличен или в php.ini, или путем его переопределения в коде. Подобным образом, для программ, потребляющих большое количество CPU или памяти могут потребоваться более высокие значения. Цель состоит в том, чтобы уменьшить воздействие «прожорливой» программы, поэтому глобальная отмена этих настроек не рекомендуется. Другое замечание относительно max_execution_time: это относится ко времени, затраченному CPU на процесс, а не к абсолютному времени. Таким образом, программа, совершающая большое количество вводов/выводов и небольшое количество вычислений, может выполняться намного дольше, чем max_execution_time. max_input_time также может быть больше, чем max_execution_time.

Количество записей, которые может сделать PHP, может настраиваться. В промышленной эксплуатации экономят место на диске, отменяя все журналы, кроме самых критических. Если журналы необходимы для диагностики проблем, вы можете вернуть то журналирование, которое необходимо. error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR включает журналирование, достаточное для выявления проблем, но удаляет из скриптов лишнюю информацию.

Заключение

Эта статья сфокусирована на настройке Web-сервера, как Apache, так и PHP. С Apache главная идея состоит в том, чтобы исключить лишние проверки, которые должен делать Web-сервер, например, обработку файла .htaccess. Вы также должны настроить мультипроцесорный модуль (MPM), который позволит сбалансировать используемые системные ресурсы и простаивающие worker’ы для входящих запросов. Лучшее, что вы можете сделать для PHP, — установить кэш кода операции. Наблюдение за несколькими параметрами настройки ресурсов также гарантирует, что скрипты не завладеют ресурсами и не замедлят работу системы.

Ресурсы

Научиться

• Tuning LAMP systems, Part 2: Optimizing Apache and PHP — оригинал этой статьи на developerWorks.
• «Оценка изменений производительности при помощи трассировки приложения (Quantify performance changes using application tracing)» (developerWorks, июль 2006) показывает, как использовать трассировку приложения для демонстрации результата изменений конфигурирования Apache.
• «Использование нового memory manager (Using the new memory manager)» (developerWorks, март 2007) охватывает самые последние изменения управления памятью в PHP 5.2. Использование PHP системных ресурсов постоянно совершенствуется.
• mod_deflate — модуль Apache, динамически компрессирующий вывод. Это можно также сделать в PHP при помощи сжатия вывода.
• Предварительное кэширование сжатых статических файлов, таких как код JavaScript. CSS — другой способ повышения производительности. Сжатие и объединение в цепочку всех ваших кодов JavaScript и CSS (Compressing and concatenating all your JavaScript code and CSS) даже лучше.
• Стоит прочитать документацию Apache, касающуюся Мультипроцессорных модулей (Multi-Processing Modules), чтобы узнать об их функциональности; следуйте ссылкам на специальную документацию для выбранных вами мультипроцессорных модулей.
• В Разделе Linux сайта developerWorks найдите дополнительные ресурсы для Linux-разработчиков.
• Регулярно посещайте раздел технических мероприятий и Web-трансляций developerWorks.

Получить продукты и технологии

• Если в ваш дистрибутив не входит eAccelerator, будут полезны инструкции Установка из исходных кодов (Install From Source).
• Альтернативный PHP кэш (Alternative PHP Cache) и Платформа Zend (Zend Platform) — альтернативы eAccelerator.
• Siege позволяет вам моделировать пользователей, так что вы можете узнать размер трафика, который способен обслужить ваш сайт.
• Рано или поздно вы захотите кэшировать некоторые элементы вашего сайта и распределить нагрузку между Web-серверами. Squid в режиме акселератора (известный как обратный прокси) или Проект Linux Virtual Server (Linux Virtual Server Project) — отличные инструменты.
• Закажите инструментарий SEK для Linux, комплект из двух DVD, содержащий новейшие пробные версии программного обеспечения IBM DB2®, Lotus®, Rational®, Tivoli® и WebSphere® для Linux.
• Постройте ваш следующий проект разработки в Linux при помощи ознакомительных версий ПО IBM, доступных для загрузки непосредственно с сайта developerWorks.

• процессы (наличие, количество потребляемых ресурсов)
• файлы, директории и файловые системы на изменения (дата создания/изменения, изменения размера и контрольной суммы)
• сетевые хосты (пинг и коннект на определенный порт по определенному протоколу)

При возникновении проблемы monit отправляет e-mail (шаблоны можно модифицировать) и может перезапустить сервис.
В monit встроен простенький веб-сервер, который позволяет посмотреть состояние объектов мониторинга, включить/выключить определенный объект.
Monit умеет перезапускать сервисы если они падают или не выполняется какое-то условие.

Monit построен с идеей того что система мониторинга должна быть максимально надежной и простой. И это действительно выполняется: на monit можно положиться.

Конечно из-за своей простоты monit не обладает тем количеством возможностей, которыми обладают Enterptise-системы мониторинга. Однако существует дополнение к monit под названием M/Monit, которое позволяет управлять несколькими серверами с monit из одного места. К сожалению, M/Monit распространяется под коммерческой лицензией и за деньги.

Посмотрим что он умеет:

Установка проста:
emerge -av monit

После этого вам необходимо отредактировать файл /etc/monitrc. Он достаточно хорошо документирован и там много примеров, вот еще несколько:

/etc/monitrc

set daemon 120 # проверять объекты каждые 2 минуты
set logfile syslog facility log_daemon
set mailserver localhost # тут для большей надежности можно указать несколько smtp-серверов
set eventqueue # задаем очередь сообщений - чтобы monit мог отправить алерт позже, если в данный момент почтовый сервер не доступен
basedir /var/monit
slots 10
set mail-format { from: monit@ myserver.com }
set alert admin1 admin2 # список получателей алертов
# конфигурация встроенного http сервера
set httpd port 2812 and
use address 0.0.0.0
allow 1.2.3.4
allow admin:password
include /etc/monit.d/*

/etc/monit.d/system

# проверка общих ресурсов сервера
check system myserver
if loadavg (1min) > 30 then alert
if loadavg (5min) > 20 then alert
if memory usage > 75% then alert
if cpu usage (user) > 70% then alert


# проверка apache2:
check process apache with pidfile /var/run/apache2.pid
start program = "/etc/init.d/apache2 start"
stop program = "/etc/init.d/apache2 stop"
if totalmem > 500.0 MB for 5 cycles then restart
if children > 250 then restart
if loadavg(5min) greater than 30 for 8 cycles then stop
if failed host myserver.com port 80 protocol http
and request "/index.html"
then restart
if failed port 443 type tcpssl protocol http
with timeout 15 seconds
then restart
if 3 restarts within 5 cycles then timeout



# проверка свободного места на фс
check device data with path /dev/sdb1
start program = "/bin/mount /data"
stop program = "/bin/umount /data"
if space usage > 80% for 5 times within 15 cycles then alert
if inode usage > 80% then alert
group server

Ссылки:

• Официальный сайт monit
• M/Monit
• Установка monit на freebsd

CMS – 1C-Bitrix

Был выполнен перенос текущего сайта с самописанной CMS на 1C-Bitrix, редакции Старт  (www.1c-bitrix.ru).

Мы не стремимся занять чьето место,  мы не предлагам чего-то нового, революционного, мы предлагаем вам сделать быстро ваше представительство в сети.  Такое, каким вы его видите, каким вы хотите, что видели другие.

Деньги? Деньги не главное! Интересным проектам, социальным проектам и просто хорошим людям скидки,  вплоть до «бесплатно«.