linux, Maxsite CMS @ 20 Февраль 2009
Не секрет, что базовые настройки из пакетов - далеко не оптимальны. После аренды VPS у меня на этой связке из 256Мб доступной оперативной памяти было использовано порядка 190Мб, что согласитесь - многовато. Основными потребителями памяти в связке, понятное дело, являются apache и mysql. Сейчас мы рассмотрим как это потребление можно уменьшить, и при этом повысить производительность системы в целом. Особо хочу сказать, что читать, возможно, имеет смысл только тем, кто уже как то сталкивался с настройкой серверов(в любом случае с удовольствием приму любые советы).
В начале apache benchmark давал результаты производительности на тестовой странице Maxsite CMS(моей тестовой, а не умолчальной) с загрузкой одного JS и одного CSS + 2 картинки, что то около 4-5 запросов в секунду. После оптимизации у меня на странице блога выдавало порядка 20 запросов. На лицо увеличение производительности в 5! раз. И всё от внимательной правки конфигурации.
В статье не будет каких-либо конкретных советов типа сделайте так то и получите результат, у меня стоит сейчас задача получить максимальную производительность в текущей конфигурации(500Мгц, 256Мб RAM). Перечисленные настройки оптимальны для _конкретного_ сервера, получение оптимальных настроек делается из постепенной правки конфигурационных файлов, запусков apache benchmark и наблюдением за top, чтобы реализовывалась и максимальная загрузка процессора и конфигурационный файл не был излишне загруженым лишними вещами(то есть, чтобы конфигурация была _действительно_ оптимальной для текущих ресурсов).
Итак, конфигурацию nginx особого смысла трогать не имеет, только на предмет настроек expires, отдачи статики, проксирования запросов на apache и конкретной настройки под проект.
Приступим к конфигурации непосредственно apache:
Первая парадигма которую я использую - ничего лишнего. Если проект использует rewrite - оставляем для него mod_rewrite, если не использует mod_perl - удаляем его из используемых модулей apache. Конкретных советов тут дать сложновато, у меня блог использует следующие mod_
И то, часть только для тестов используется.
Вторая парадигма - если сервер может выдержать какое то количество запросов, то незачем делать конфигурацию, которая бы подходила для более мощного сервера.
Приступим к разбору конфигурации /etc/apache2/apache2.conf
Особый интерес в моём случае вызывает часть конфигурации отвечающая за форки апача, а точнее за работу менеджера процессов. Я предпочёл более надёжному worker более быстрый - prefork, о различиях между mpm информации в поисковиках вполне достаточно, даже на официальном сайте... или в конфиге.
Очень хорошее описание конфигурации написано .
Третья парадигма - если есть ресурсы - кэшируй. И лучше сразу в оперативную память. Я для кэширования скриптов использовал eAccelerator, как наиболее простой в установке и обслуживании, так и как, наверное, самый эффективный. Ещё можно использовать memcached, но он не такой быстрый, но удобен в масштабировании. Раздел с кэшем eAccelerator я поместил в tmpfs выделив под это дело 32Мб памяти. Также имеет смысл, если у Вас достаточно памяти(а не как у меня) монтировать /tmp под tmpfs тоже. Для кэша Maxsite CMS я тоже думаю выделить раздел в tmpfs, думаю лишним не будет.
MySQL тоже поддаётся тюнингу, и причём очень неплохому. В доках есть образец конфига my.conf для операционных систем с малым количеством RAM.
Я использовал его в качестве базовой конфигурации, чуть чуть изменив его. При этом увеличил потребление оперативной памяти где то на 10-15Мб относительно самого my-small.
Также добавил skip-innodb в конфиг, поскольку сейчас я использую только myisam с индексированными таблицами. Относительно базового конфига я выделил чуть больше памяти под кэш mysql, что подняло производительность на что-то около 10%.
Понятное дело, что всё это тестировалось на ОЧЕНЬ быстрой CMS с очень мощной системой кэширования, тот же самый вордпресс тюнингованный у меня выдавал изначально порядка 0.8-1 запроса, а после тюнинга и моих патчей - аж 3-4 :)
P.S. Сейчас тестирую opensource систему Piwik, на замену Google Analytics, весьма неплохая штучка. Всё красиво и Веб-два-нольно :)
В начале apache benchmark давал результаты производительности на тестовой странице Maxsite CMS(моей тестовой, а не умолчальной) с загрузкой одного JS и одного CSS + 2 картинки, что то около 4-5 запросов в секунду. После оптимизации у меня на странице блога выдавало порядка 20 запросов. На лицо увеличение производительности в 5! раз. И всё от внимательной правки конфигурации.
В статье не будет каких-либо конкретных советов типа сделайте так то и получите результат, у меня стоит сейчас задача получить максимальную производительность в текущей конфигурации(500Мгц, 256Мб RAM). Перечисленные настройки оптимальны для _конкретного_ сервера, получение оптимальных настроек делается из постепенной правки конфигурационных файлов, запусков apache benchmark и наблюдением за top, чтобы реализовывалась и максимальная загрузка процессора и конфигурационный файл не был излишне загруженым лишними вещами(то есть, чтобы конфигурация была _действительно_ оптимальной для текущих ресурсов).
Итак, конфигурацию nginx особого смысла трогать не имеет, только на предмет настроек expires, отдачи статики, проксирования запросов на apache и конкретной настройки под проект.
Приступим к конфигурации непосредственно apache:
Первая парадигма которую я использую - ничего лишнего. Если проект использует rewrite - оставляем для него mod_rewrite, если не использует mod_perl - удаляем его из используемых модулей apache. Конкретных советов тут дать сложновато, у меня блог использует следующие mod_
alias authn_file authz_groupfile authz_user dir mime rewrite setenvif
auth_basic authz_default authz_host autoindex env php5 rpaf И то, часть только для тестов используется.
Вторая парадигма - если сервер может выдержать какое то количество запросов, то незачем делать конфигурацию, которая бы подходила для более мощного сервера.
Приступим к разбору конфигурации /etc/apache2/apache2.conf
Особый интерес в моём случае вызывает часть конфигурации отвечающая за форки апача, а точнее за работу менеджера процессов. Я предпочёл более надёжному worker более быстрый - prefork, о различиях между mpm информации в поисковиках вполне достаточно, даже на официальном сайте... или в конфиге.
StartServers 1
MinSpareServers 1
MaxSpareServers 5
MaxClients 50
MaxRequestsPerChild 300
Очень хорошее описание конфигурации написано .
Третья парадигма - если есть ресурсы - кэшируй. И лучше сразу в оперативную память. Я для кэширования скриптов использовал eAccelerator, как наиболее простой в установке и обслуживании, так и как, наверное, самый эффективный. Ещё можно использовать memcached, но он не такой быстрый, но удобен в масштабировании. Раздел с кэшем eAccelerator я поместил в tmpfs выделив под это дело 32Мб памяти. Также имеет смысл, если у Вас достаточно памяти(а не как у меня) монтировать /tmp под tmpfs тоже. Для кэша Maxsite CMS я тоже думаю выделить раздел в tmpfs, думаю лишним не будет.
MySQL тоже поддаётся тюнингу, и причём очень неплохому. В доках есть образец конфига my.conf для операционных систем с малым количеством RAM.
cp /usr/share/doc/mysql-server-5.0/examples/my-small.cnf /etc/mysql/my.cnfЯ использовал его в качестве базовой конфигурации, чуть чуть изменив его. При этом увеличил потребление оперативной памяти где то на 10-15Мб относительно самого my-small.
key_buffer = 1M
max_allowed_packet = 2M
table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 64K
query_cache_limit = 256K
query_cache_size = 4MТакже добавил skip-innodb в конфиг, поскольку сейчас я использую только myisam с индексированными таблицами. Относительно базового конфига я выделил чуть больше памяти под кэш mysql, что подняло производительность на что-то около 10%.
Понятное дело, что всё это тестировалось на ОЧЕНЬ быстрой CMS с очень мощной системой кэширования, тот же самый вордпресс тюнингованный у меня выдавал изначально порядка 0.8-1 запроса, а после тюнинга и моих патчей - аж 3-4 :)
P.S. Сейчас тестирую opensource систему Piwik, на замену Google Analytics, весьма неплохая штучка. Всё красиво и Веб-два-нольно :)
Апрель 3rd, 2009 at 15:18
Эээ... "Я предпочёл более надёжному worker более быстрый - prefork"
А не наоборот? Конечно, с поточным worker будут проблемы с php, и его придется пускать в fastcgi, но worker как многопоточный менеджер должен быть быстрее.
Апрель 3rd, 2009 at 15:21
Зависит от мощности машины :) У меня то одноядерник(был, сейчас обратно на спейсвеб переехал, здеся лучше как-то), да ещё слабый. В инете можно нагуглить бенчмарки.