Настройка Apache от HEAnet
Выбор MPM
В Apache 2.x доступно множество мульти-процессных модулей (MPM), которые предлагают разные методы управления процессами внутри Apache. В Unix есть, по крайней мере, два наиболее стоящих модуля: prefork MPM и worker MPM.
Мы не стали уделять большого внимания выбору МП-модуля, а начали использовать модуль по умолчанию - prefork MPM. Однако после множества советов, что, основанный на нитях, МП-модуль worker дает увеличение производительности, мы решили оценить его работу.
Данная статья взята из выпуска №3 рассылки “Информационный бюллетень от ApacheDev.ru”. Подписаться на рассылку…
К нашему сожалению, после 5 минут работы МП-модуль worker выдал ошибку доступа к памяти. Дамп ядра не сильно помог нам (и httpd-dev) при поиске возможной причины.
Работая вместе с Aaron Bannert и Jeff Trawick и используя новые модули mod_forensic_id и mod_backtrace, в конце концов мы обнаружили ошибку переполнения стека в МП-модуле worker. Этот баг был исправлен в Apache 2.0.49.
После исправления ошибки мы вновь провели собственные тесты МП-модуля worker, однако при нашей нагрузке он снизил количество запросов обработанных в секунду. Тем не менее, он понизил объем используемой памяти, тем самым, показав свое преимущество перед prefork (он может значительно увеличить производительность на таких платформах как Solaris, которые поддерживают легковесные процессы). Однако для нас более важным критерием является количество обработанных запросов в секунду, а память сейчас относительно дешевая (по сравнению со временем разработки), поэтому мы продолжили использовать МП-модуль prefork.
Однако мы продолжаем периодически тестировать производительность МП-модуля worker, а также других МП-модулей.
Во время тестирования МП-модуля worker мы хорошо изучили как лучше настроить его. МП-модуль worker создает серию дочерних процессов, которые в свою очередь содержат нити. Что более эффективно: иметь больше дочерних процессов с меньшим количеством нитей на процесс или обратное?
После большого количества экспериментов при нашей нагрузке мы обнаружили, что оптимальным будет 32 нити на процесс. При большем числе нитей управление ими становится более трудоемким, чем управление обычными процессами.
В результате мы получили следующую конфигурацию для МП-модуля worker:
<IfModule worker.c>
ServerLimit 900
StartServers 10
MaxClients 28800
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 32
MaxRequestsPerChild 100
</IfModule>
ServerLimit 900
StartServers 10
MaxClients 28800
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 32
MaxRequestsPerChild 100
</IfModule>
Оптимальная настройка МП-модуля prefork производится проще. Главной задачей тут является определение необходимого количества “запасных” серверов, чтобы их было достаточно для обработки новых запросов, когда количество поступающих соединений превысит количество новых процессов, создаваемых Apache в единицу времени.
При нашей нагрузке нам потребовалось только 10 запасных серверов. С таким количеством у нас не было отказов в обработке соединений.
Наша конфигурация для МП-модуля prefork:
<IfModule prefork.c>
StartServers 100
MinSpareServers 10
MaxSpareServers 10
ServerLimit 50000
MaxClients 50000
MaxRequestsPerChild 2000
</IfModule>
StartServers 100
MinSpareServers 10
MaxSpareServers 10
ServerLimit 50000
MaxClients 50000
MaxRequestsPerChild 2000
</IfModule>
Мы установили максимальное количество запросов на процесс в основном из-за того, чтобы еще раз подстраховаться от любой возможной утечки памяти. В системе с несколькими десятками тысяч процессов httpd даже маленькая утечка приведет к большим проблемам.
Статическая линковка или DSO
Модули Apache могут быть скомпилированы в один бинарник или в виде динамически загружаемых объектов (DSO), которые подгружаются основным сервером. При нашей нагрузке мы получили некоторую выгоду в производительности (примерно около 0.2%), когда скомпилировали модули в сервер.
Изменения в конфигурации
Как показано в примере конфигурации highperformance.conf, которая поставляется вместе с Apache, отключение файлов .htaccess может значительно повысить скорость работы сервера. Вот часть файла конфигурации:
<Directory “/ftp/”>
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
IndexOptions NameWidth=* +FancyIndexing \
+SuppressHTMLPreamble +XHTML
</Directory>
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
IndexOptions NameWidth=* +FancyIndexing \
+SuppressHTMLPreamble +XHTML
</Directory>
Такой подход тоже имеет свои недостатки. Когда сервер обслуживает более 50,000 проектов, то некоторые из них обязательно будут содержать файлы .htaccess.
Чтобы определить какие проекты нуждаются в переопределении доступа, мы регулярно запускаем “find ./ -type а -name .htaccess”. Для этого мы создали скрипт, который собирает все файлы .htaccess в один большой файл конфигурации:
#!/bin/sh
for file in `find /ftp/ -type f -name .htaccess`; do
echo “<Directory `basename $file`>”
sed ’s/^/ /’ $file
echo “</Directory>”
echo
done > combined-htaccess.conf
for file in `find /ftp/ -type f -name .htaccess`; do
echo “<Directory `basename $file`>”
sed ’s/^/ /’ $file
echo “</Directory>”
echo
done > combined-htaccess.conf
Отдельные файлы .htaccess изменяются достаточно редко, поэтому такой подход не вызывает никаких проблем. Также мы вручную просматриваем этот файл конфигурации, чтобы убедиться, что он не содержит злонамеренных директив.
Тем не менее, проблема возникает, когда большое число проектов использует множество символических связей с каталогами. Однако редко возникают такие моменты, когда пользователю потребовался контент по только что созданной символической связи, а соответственная директива еще не обновлена.
Постоянное отслеживание изменений файлов .htaccess является довольно трудоемкой задачей. Вместо этого можно разрешить использование .htaccess для корня проектов, например:
<Directory “/ftp/mirrors/www.apache.org/”>
IndexOptions FancyIndexing NameWidth=* FoldersFirst \
ScanHTMLTitles DescriptionWidth=*
HeaderName HEADER.html
ReadmeName README.html
AllowOverride FileInfo Indexes
Options Indexes SymLinksIfOwnerMatch
</Directory>
IndexOptions FancyIndexing NameWidth=* FoldersFirst \
ScanHTMLTitles DescriptionWidth=*
HeaderName HEADER.html
ReadmeName README.html
AllowOverride FileInfo Indexes
Options Indexes SymLinksIfOwnerMatch
</Directory>
Sendfile
Sendfile - это системный вызов, доступный во многих операционных системах. Он позволяет программам передать ядру ОС работу по передаче файлов TCP сокету. Следовательно, лучше заботы о распределении памяти и об оптимальном размере буфера передать ядру, которое оптимизирует все операции чтения.
Использование sendfile включается по умолчанию во время компиляции в случае, если Apache определит, что операционная система поддерживает эту возможность. Следующая директива в конфигурационном файле включает использование sendfile:
EnableSendfile On
Постоянное использование sendfile существенно повысит производительность и эффективность. К сожалению, в нашем случае работа sendfile на нашем оборудовании приводила к порче IPv6 сессий.
Примечание: Это происходило из-за ошибки при расчете контрольной суммы TCP почти на всех сетевых интерфейсах. И Linux использует неверную контрольную сумму при вызове sendfile. Данный баг был обнаружен при помощи Джо Ортона (Joe Orton). Так как HEanet работает с IPv6 так же, как и с IPv4, то простое выключение поддержки IPv6 неприемлемо для нас.
Решение заключалось в исправлении кода сервера, чтобы просто не использовать sendfile, когда поступивший запрос использует IPv6. Теперь эта возможность добавлена в Apache Portable Runtime (APR).
Mmap
Следующей полезной вещью после sendfile является mmap. Использование mmap может быть включено в конфигурации Apache с помощью директивы
EnableMmap On
Поддержка mmap позволяет Apache работать с файлом как с единой областью памяти, что существенно повышает скорость операций I/O за счет отказа от дополнительных операций чтения.
Включение поддержки mmap оказало большое влияние на нашу производительность и позволило нам обрабатывать файлы примерно в 3 раза быстрее. Конечно, использование sendfile (если возможно!) вероятно принесет больший прирост производительности, но использование mmap не влияет на работу с IPv6.
mod_cache
Модуль mod_cache с mod_disc_cache является одной из самых лучших возможностей увеличения производительности вашего сервера. Несмотря на то, что у нас хранится примерно 3 терабайт контента (примерно 6 миллионов файлов), только небольшая его часть популярна в определенное время. В определенное 6-часовое окно скачивается 50,000 различных файлов, что в совокупности представляет только 10Гб уникального контента.
Наши файловые хранилища обслуживаются дисками 7200 RPM IDE, поэтому будет очень хорошо, если мы сможим снизить нагрузку на наши файловые хранилища. Также мы создали 36 Gb RAID-0 хранилище, используя два 18 Гб 15k RPM SCSI диска. Комбинация RAID-0 и 15k RPM дисков делает это хранилище значительно быстрее.
mod_disc_cache кеширует файлы в заданное место при первой их обработке. Повторные запросы обрабатываются уже из кеша, обходя более медленные файловые хранилища. mod_disk_cache содержит хороший пример конфигурации, но в нашей конфигурации мы увеличили CacheDirLevel до 5, чтобы увеличить количество файлов, которое помещается в кеш.
<IfModule mod_cache.c>
<IfModule mod_disk_cache.c>
CacheRoot /usr/local/web/cache/
CacheEnable disk /
CacheDirLevels 5
CacheDirLength 3
</IfModule>
</IfModule>
<IfModule mod_disk_cache.c>
CacheRoot /usr/local/web/cache/
CacheEnable disk /
CacheDirLevels 5
CacheDirLength 3
</IfModule>
</IfModule>
Но следует учесть, что mod_disk_cache до сих пор является экспериментальным в Apache 2.0 и в Apache 2.1, и, вероятно, не удовлетворяет требованиям производственного использования. Тем не менее, если есть время для аккуратного исследования его поведения, то он может стать источником большого повышения производительности.
Еще одна вещь, которую нужно учесть, это то, что Apache не занимается очисткой кеша. Некоторое время для этой цели мы использовали комбинацию find, xargs и rm, однако теперь Apache 2.1 включает утилиту htcacheclean, которая используется для очистки кеша.
htcacheclean запускается либо cron-ом, либо в качестве демона, и периодически очищает кеш. Необходимо только убедиться, что ваше хранилище обладает необходимым объемом свободного места.
Примечание: Многие вопросы повышения производительности приведены в 8 главе книги "Apache для профессионалов". Подробнее о книге…
Параметры компиляции
Вот параметры нашей сборки:
CFLAGS=”-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE”; export CFLAGS
“./configure” \
“--with-mpm=prefork” \
“--prefix=/usr/local/web” \
“--enable-cgid” \
“--enable-rewrite” \
“--enable-expires” \
“--enable-cache” \
“--enable-disk-cache” \
“--without-sendfile”
“./configure” \
“--with-mpm=prefork” \
“--prefix=/usr/local/web” \
“--enable-cgid” \
“--enable-rewrite” \
“--enable-expires” \
“--enable-cache” \
“--enable-disk-cache” \
“--without-sendfile”
Дадим небольшие пояснения. Модули mod_rewrite и mod_expires используются большим количеством обслуживающихся проектов. Наша цель во время компиляции заключалась в том, чтобы сделать исполнительный файл httpd как можно меньше. Параметры CFLAGS позволяют нам использовать файлы размером более 2 Гб.
Комментарий от AlienZzzz — Май 17, 2006 @ 10:02 pm
Комментарий от Администратор — Май 17, 2006 @ 11:20 pm
Комментарий от barzog — Май 18, 2006 @ 10:03 am
LockFile /var/run/accept_aux2.lock
ServerLimit 160
StartServers 20
MaxClients 4000
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
# apachectl -t
Syntax OK
# apachectl -k restart
В логе вижу:
WARNING: MaxClients of 4000 would require 160 servers,
and would exceed the ServerLimit value of 40.
Automatically lowering MaxClients to 1000. To increase,
please see the ServerLimit directive.
Что ему еще надо?
Комментарий от sickboy — Июнь 21, 2007 @ 8:58 pm
__________________
http://btrening.ru/
Комментарий от андрюха — Август 29, 2008 @ 4:11 pm
Комментарий от Смешной человек — Сентябрь 7, 2008 @ 8:24 pm
__
http://plodosad.ru/
Комментарий от Dimon — Сентябрь 26, 2008 @ 11:37 pm
Комментарий от splogmaster — Февраль 7, 2009 @ 7:24 pm
Комментарий от грузоперевозки — Февраль 12, 2009 @ 2:08 pm
Комментарий от скачать фильмы — Февраль 12, 2009 @ 2:09 pm
Комментарий от Madoc — Февраль 12, 2009 @ 2:10 pm
Комментарий от Курсовые — Февраль 12, 2009 @ 2:10 pm
Комментарий от Лок — Февраль 12, 2009 @ 2:11 pm
Настроечки-то помогли!
Комментарий от Лок — Февраль 12, 2009 @ 2:12 pm
Комментарий от Крис — Февраль 12, 2009 @ 2:13 pm
Комментарий от Сонник — Февраль 12, 2009 @ 2:13 pm
Комментарий от работа мечты — Февраль 12, 2009 @ 2:14 pm
Комментарий от пластиковые окна — Февраль 12, 2009 @ 2:15 pm
Комментарий от Blogger008 — Февраль 12, 2009 @ 2:16 pm
Комментарий от Мотивация — Февраль 12, 2009 @ 2:17 pm
Комментарий от Крюгер — Февраль 12, 2009 @ 2:18 pm
Комментарий от наружка — Февраль 12, 2009 @ 2:18 pm
Комментарий от наружка — Февраль 12, 2009 @ 2:19 pm
Комментарий от master — Февраль 12, 2009 @ 2:20 pm
Комментарий от новинки mp3 — Февраль 12, 2009 @ 2:20 pm
Комментарий от stone — Февраль 12, 2009 @ 2:22 pm
Комментарий от Вася — Февраль 12, 2009 @ 2:23 pm
Комментарий от Роман — Февраль 14, 2009 @ 2:43 pm