Перейти к содержанию

Слабый сервер — не настроенный сервер или как настроить сервер под wordpress?

Всем привет, потихоньку начал перебираться на выделенные сервера для своих проектов и вот опыт освоения одной из более менее подходящих площадок. Взял я себе самый простенький тариф за 250 руб в мес и начал тестировать. Сначала развернул на него свой блог, затем закачал еще несколько лендингов и пару сервисов для собственного использования. Если интересно, то читайте как сделать собственный блог на wordpress в предыдущем материале.

Сервер по рекомендации знакомого выбрал достаточно быстро. В первую очередь, я опирался на близость и качество поддержки и оперативность оказания различных услуг.  Выбор был сделан в пользу компании flops.ru, а сервер был выбран со следующими характеристиками:

555f0f05af

  • процессор intel Xeon E5-2620
  • оперативной памяти 512Мб
  • и жесткий дик SSD объемом 16Гб.
  • операционная система Centos 6 (Эту ОС я выбрал потому что был опыт работы, ну и как мне кажется она самая оптимальная для шустрого сервера для сайтов)

На этом можно заканчивать пролог и начинать истории, по ведающую о самостоятельной настройке выделенного настройке.

Почему мне понадобилась настройка сервера. Первое время вопросов к его работе не было совсем, все сайты работали отлично, глюков и сбоев не было, но всему хорошему рано или поздно приходит конец. Увеличилась нагрузка на сервер, расшарил некоторые сервисы для своих знакомых и железка перестала справляться. Вроде даже после этого все бы хорошо, но в течении недели я увидел на почте несколько писем об убийстве процессов. Некий OOM-killer то и дело налево и направо убивал процессы, например такие важные для функционирования веб-приложений и сайта, как apache:

Виртуальный сервер centos: нехватка RAM. Процесс httpd убит OOM-killer.

(вот подонок возмутился я и пошел жаловаться в тех поддержку)

Написал тикет в техподдержку с просьбой разъяснить, что да как… А самое главное выяснить почему раньше все было хорошо, а теперь то и дело сайты мои падают и как с этим жить дальше. И предельно короткие сроки мне ответили следующее:

7cf32ade8d

И пошел я читать мануалы по настройке сервера, которые мне посоветовал сапорт, Многое конечно было не понятно, но почитав пару часов похожие посты я открыл для себя немного полезной информации с которой поделюсь с вами и из всего “пройденного” материала ниже я приеду краткую выжимку. Чтобы вам, дорогие читатели было легче разобраться в тонкостях оптимизации серверов. И так приступим!

Настройка сервера для сайта на WordPress

Первое что необходимо это настроить apache (httpd) и начинать следует с модулей мультипроцессовой обработки  

PreFork и Worker не буду вдаваться в детали что это такое и зачем оно нужно, сейчас это абсолютно не важно, ведь задача не расcказать про их работу а оптимизировать ее, но все же ссылки выше могут вам помочь. Итак заходим через FTP на свой сервер и желательно с правами администратора, идем прямиком сюда

/etc/httpd/conf/httpd.conf Открывать этот файл можно в блокноте или как я в SublimeText. В этом файле находятся инструкции по конфигурации сервера. Далее ищем в нем блок prefork отвечающий за настройку модуля и изменяем его следующим образом:

<IfModule prefork.c>

StartServers       1

MinSpareServers    1

MaxSpareServers   3

MaxClients       10

MaxRequestsPerChild  3000

</IfModule>

затем переходим ко второму модулю и это — worker, у меня он находиться чуть ниже по коду и выглядит так, соответственно вам нужно сделать его таким же:

<IfModule worker.c>

StartServers         1

MaxClients         300

MinSpareThreads     5

MaxSpareThreads     15 

ThreadLimit           25 

ThreadsPerChild        5 

MaxClients            25 

MaxRequestsPerChild  200

</IfModule>

Затем пройдемся немного по модулям, у меня оказалось слишком много не нужных модулей, где-то ⅔ я закомментировал. Для корректной работы водпресcа нужны только перечисленные ниже модули, соответственно их оставляем:

LoadModule dir_module modules/mod_dir.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule alias_module modules/mod_alias.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule rewrite_module modules/mod_rewrite.so

Все остальные комментируем символом # в начале строки. Например так:

#LoadModule rewrite_module modules/mod_rewrite.so

Для этого можно использовать автозамену в вашем текстовом редакторе. После того как все сделали сохраняем файл и перезагружаем при помощи ssh(я для работы через ssh использую приложение Putty) апач командой

service apache2 restart или service httpd restart 

Уже этого должно хватить чтобы значительно ускорить работу сайта, а также оптимизировать расходуемые сервером ресурсы. Но мы пойдем немножко дальше и внесем несколько изменений в настройки PHP.

Итак второе что нужно сделать — это зайти в конфигурационный файл php, лежит он /etc/php.ini вашего сервера. Здесь уменьшаем память и немного играемся с кешем:

memory_limit = 48M
realpath_cache_ttl=300
realpath_cache_size=1M

Еще одним мощным плюсом будет установка делается это так:

yum install apc

акселератора APC его конечно рекомендуют тоже настроить следующим образом:

[APC]
extension=apc.so
apc.enabled=1
apc.shm_segments=1

;32M per WordPress install
apc.shm_size=128M

;Relative to the number of cached files (you may need to watch your stats for a day or two to find out a good number)
apc.num_files_hint=7000

;Relative to the size of WordPress
apc.user_entries_hint=4096

;The number of seconds a cache entry is allowed to idle in a slot before APC dumps the cache
apc.ttl=7200
apc.user_ttl=7200
apc.gc_ttl=3600

;Setting this to 0 will give you the best performance, as APC will
;not have to check the IO for changes. However, you must clear 
;the APC cache to recompile already cached files. If you are still
;developing, updating your site daily in WP-ADMIN, and running W3TC
;set this to 1
apc.stat=1

;This MUST be 0, WP can have errors otherwise!
apc.include_once_override=0

;Only set to 1 while debugging
apc.enable_cli=0

;Allow 2 seconds after a file is created before it is cached to prevent users from seeing half-written/weird pages
apc.file_update_protection=2

;Leave at 2M or lower. WordPress does't have any file sizes close to 2M
apc.max_file_size=2M

;Ignore files
apc.filters = "/var/www/apc.php"
 
apc.cache_by_default=1
apc.use_request_time=1
apc.slam_defense=0
apc.mmap_file_mask=/var/www/temp/apc.XXXXXX
apc.stat_ctime=0
apc.canonicalize=1
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.lazy_classes=0
apc.lazy_functions=0

Но я решил оставить практически стандартную конфигурацию, только подредактировал размер сегмента и увеличил время жизни кеша. Потому что свою задачу уже решил.

# кэширование
apc.enabled=1
# значение кол-ва сегментов кэша в памяти
apc.shm_segments=1
# размер сегмента
apc.shm_size=128M
# время жизни кэша
apc.ttl=7200
# максимальных объем файлов
apc.max_file_size=1M
# проверять изменения файла (при обращении к нему)
apc.stat=1

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

yum install varnish

Затем добавил его в автозагрузку

chkconfig varnish on

После чего залез в конфигурацию, которая лежала в /etc/sysconfig/varnish и добавил туда

DAEMON_OPTS="-a :6081 \
             -T localhost:6082 \
             -f /etc/varnish/production.vcl \
             -u varnish -g varnish \
             -s file,/var/lib/varnish/varnish_storage.bin,1G \
             -p connect_timeout=600s \
             -p first_byte_timeout=600s \
      -p between_bytes_timeout=600s"

что оно значит я выяснять не стал, но приблизительно тут все понятно. Ну и последнее что я сделал — это запустил varnish командой

service varnish start.

Что мне дали эти настройки конфигурации веб-сервера и приложений?

  1. Самое главное вот уже на протяжении 3х месяцев бесперебойная работа сервера.  
  2. Мгновенное открытие сайта
  3. Очень мощный инструмент кеширования веб-приложений
Опубликовано в рубрикеБлог