Всем привет, потихоньку начал перебираться на выделенные сервера для своих проектов и вот опыт освоения одной из более менее подходящих площадок. Взял я себе самый простенький тариф за 250 руб в мес и начал тестировать. Сначала развернул на него свой блог, затем закачал еще несколько лендингов и пару сервисов для собственного использования. Если интересно, то читайте как сделать собственный блог на wordpress в предыдущем материале.
Сервер по рекомендации знакомого выбрал достаточно быстро. В первую очередь, я опирался на близость и качество поддержки и оперативность оказания различных услуг. Выбор был сделан в пользу компании flops.ru, а сервер был выбран со следующими характеристиками:
- процессор intel Xeon E5-2620
- оперативной памяти 512Мб
- и жесткий дик SSD объемом 16Гб.
- операционная система Centos 6 (Эту ОС я выбрал потому что был опыт работы, ну и как мне кажется она самая оптимальная для шустрого сервера для сайтов)
На этом можно заканчивать пролог и начинать истории, по ведающую о самостоятельной настройке выделенного настройке.
Почему мне понадобилась настройка сервера. Первое время вопросов к его работе не было совсем, все сайты работали отлично, глюков и сбоев не было, но всему хорошему рано или поздно приходит конец. Увеличилась нагрузка на сервер, расшарил некоторые сервисы для своих знакомых и железка перестала справляться. Вроде даже после этого все бы хорошо, но в течении недели я увидел на почте несколько писем об убийстве процессов. Некий OOM-killer то и дело налево и направо убивал процессы, например такие важные для функционирования веб-приложений и сайта, как apache:
Виртуальный сервер centos: нехватка RAM. Процесс httpd убит OOM-killer.
(вот подонок возмутился я и пошел жаловаться в тех поддержку)
Написал тикет в техподдержку с просьбой разъяснить, что да как… А самое главное выяснить почему раньше все было хорошо, а теперь то и дело сайты мои падают и как с этим жить дальше. И предельно короткие сроки мне ответили следующее:
И пошел я читать мануалы по настройке сервера, которые мне посоветовал сапорт, Многое конечно было не понятно, но почитав пару часов похожие посты я открыл для себя немного полезной информации с которой поделюсь с вами и из всего “пройденного” материала ниже я приеду краткую выжимку. Чтобы вам, дорогие читатели было легче разобраться в тонкостях оптимизации серверов. И так приступим!
Настройка сервера для сайта на 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.
Что мне дали эти настройки конфигурации веб-сервера и приложений?
- Самое главное вот уже на протяжении 3х месяцев бесперебойная работа сервера.
- Мгновенное открытие сайта
- Очень мощный инструмент кеширования веб-приложений