ЧТО Я ПЫТАЮСЬ СДЕЛАТЬ
Ограничения ресурсов сервера иногда жесткие; чтобы предотвратить исчерпание памяти, мне пришлось ограничить серверные процессы. Мне нужна небольшая помощь специалиста, чтобы узнать, на правильном ли я пути, и, возможно, обнаружить какие-либо очевидные изменения настроек, которые помогут системе работать более стабильно.
ИСТОРИЯ
Недавно моя компания перешла на VPS с виртуального хостинга. По сути, мы переросли наш общий хостинг, и у нас начались проблемы из-за того, что хост приостановил работу нашего сайта из-за чрезмерной загрузки процессора в выходные. Количество пользователей нашего веб-сайта в пятницу и субботу каждую неделю увеличивается вдвое или втрое, что в нашем случае не является неожиданным. (Около 5000 посещений [~ 2500 посетителей] в день в течение недели, около 9500 посещений [~ 4500 посетителей] в выходные дни.)
Теперь, когда мы находимся на VPS, у нас нет проблем с процессором. (Фактически, панель управления CentOS WHM сообщает, что мы находимся на «0,000201% загрузки ЦП».) Однако у нас возникают проблемы нехватки памяти, что приводит к сбоям.
РЕЗЮМЕ ВЫПУСКА
Наш сайт основан на WordPress. Однако, помимо комментариев, здесь очень мало "писательской" активности; в основном пользователи просто видят довольно статичные страницы, которые мы создали.
Когда мы впервые перешли на VPS несколько месяцев назад, в октябре 2012 года, сайт работал хорошо в течение недели, но каждые выходные давил на память. Часто происходили неоднократные сбои (5-20 раз в течение 24 часов, спорадически), обычно начиная с вечера пятницы и продолжаясь до полудня субботы.
В течение недели сервер работал стабильно при использовании памяти 65-90%, а в выходные дни он достигал 100%, что приводило к сбоям.
МЕРЫ, ПРИНЯТЫЕ ДЛЯ ИСПРАВЛЕНИЯ
Поскольку я был новичком в VPS, я начал со всеми настройками по умолчанию. Позже я начал настраивать, следуя советам, которые я читал о решении проблем с памятью здесь, на этом и других сайтах.
Я внес изменения в MySQL, PHP и Apache, которые кратко описаны ниже в разделе «Текущая конфигурация». Я также перекомпилировал Apache и PHP, чтобы удалить ненужные модули. Я установил лучший плагин кеширования для WordPress (W3T) и добавил кеширование кода операции APC. Я также начал использовать сжатие gz и переместил множество статических файлов в отдельный поддомен.
Я написал изящный небольшой скрипт для проверки состояния сервера по расписанию и перезапуска его по мере необходимости, а также он отправляет мне расшифровку журнала ошибок сервера, чтобы помочь в устранении неполадок. (Я знаю, это всего лишь пластырь, если что. Но было важно, чтобы сайт оставался в сети, потому что никто не хочет сидеть и следить за ним по выходным.)
Совсем недавно, примерно неделю назад (январь 2013 г.), я увеличил объем оперативной памяти сервера с 1 ГБ (2 ГБ с возможностью наращивания) до 2 ГБ (3 ГБ с возможностью наращивания). Похоже, это устранило большую часть проблемы, но все же я получаю случайные уведомления (примерно раз в неделю), что сервер зависает, а также ошибки PHP «не удается применить слот процесса».
ТЕКУЩАЯ КОНФИГУРАЦИЯ
Это сервер Apache, работающий под управлением CentOS 6, Apache 2 (Worker MPM), PHP 5.3.20 (FastCGI / fcgi) и MySQL 5.5.28. 2 ГБ ОЗУ (3 ГБ с возможностью наращивания), 24 процессора.
MySQL в настоящее время использует около 618 МБ, около 20,1% ОЗУ. PHP использует до 89 МБ на процесс. Apache использует до 14 МБ на процесс.
Типичный будний день top вывод:
top - 15:31:13 up 89 days, 5:26, 1 user, load average: 1.54, 1.00, 0.70
Tasks: 49 total, 1 running, 48 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 99.7%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3145728k total, 1046444k used, 2099284k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached
К сожалению, у меня нет текущего примера вывода максимума выходных / наиболее загруженного времени.
Конфигурация Apache:
StartServers: 5
MinSpareThreads: 5
MaxSpareServers: 10
ServerLimit: 80
MaxClients: 56
MaxRequestsPerChild: 5000
KeepAlive: Off
Конфигурация PHP:
MaxRequestsPerProcess 500
FcgidMaxProcesses 15
FcgidMinProcessesPerClass 0
FcgidMaxProcessesPerClass 8
FcgidIdleTimeout 30
FcgidIdleScanInterval 15
FcgidProcessLifeTime 60
FcgidIOTimeout 300
FcgidMaxRequestLen 268435456
Конфигурация MySQL:
[mysqld]
max_user_connections = 75
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
skip-external-locking
sort_buffer_size = 512K
# MyISAM #
key_buffer_size = 32M
myisam_sort_buffer_size = 16M
#myisam_recover = FORCE,BACKUP
# SAFETY #
max_allowed_packet = 8M
#max_connect_errors = 1000000
# CACHES AND LIMITS #
tmp_table_size = 104M
max_heap_table_size = 104M
join_buffer_size = 208K
#query_cache_type = 0
query_cache_size = 32M
max_connections = 150
thread_cache_size = 4
#open_files_limit = 65535
table_cache = 512
#table_definition_cache = 1024
table_open_cache = 2048
wait_timeout = 300
# INNODB #
#innodb_flush_method = O_DIRECT
#innodb_log_files_in_group = 2
#innodb_log_file_size = 64M
#innodb_flush_log_at_trx_commit = 1
#innodb_file_per_table = 1
innodb_buffer_pool_size = 416M
# This setting ensures that aio limits are not exceeded
# (default is 65536, each instance of mysql takes 2661 with this enabled)
innodb_use_native_aio = 0
# LOGGING #
log-slow-queries
log-queries-not-using-indexes
Любая помощь / предложения будут очень благодарны. Адрес веб-сайта: 3abn.org.
Моя рекомендация номер один: ОТКРЫТЬ VPS.
Я слышал достаточно ворчаний о проблемах, связанных с памятью (и OOM-Killer) в системах VPS, что, по моему мнению, типичный провайдер хостинга VPS не предоставляет Производственный класс решение - это не «виртуальный частный сервер», а «паравиртуализация поверх существующей ОС с плохо спроектированным ограничением ресурсов, которое, следовательно, ведет себя иначе, чем реальная машина».
(Похоже, вас укусила самая распространенная разница: «VPS» не имеет места подкачки, поэтому, когда вы потребляете хотя бы на один байт RAM больше, чем вам выделил ваш провайдер, все разваливается.)
Если вы не можете или не желаете размещать на собственном оборудовании, размещенном в качественном центре обработки данных, вам следует подумать об облачной службе, которая выглядит как «обычный» сервер со свопом и т.п. (Amazon EC2 - один из таких вариантов). Цена на эти решения находится где-то между решениями «VPS» и выделенным оборудованием, но они обеспечивают условия эксплуатации, которые намного ближе к «реальному оборудованию», и позволяют избежать ситуаций, в которых вы оказались сейчас.
Обратите внимание, что в любом случае вам все равно необходимо правильно определить размер вашей системы - ваш VPS / облачное решение / выделенное оборудование должно иметь достаточно оперативной памяти для обработки пиковой нагрузки без подкачки.
Преимущество (качественных) облачных или выделенных аппаратных решений в том, что у вас больше контроля над тем, что происходит, когда вы достигаете точки подкачки (отключение OOM-killer и разрешение malloc() потерпеть поражение, например).
Вы уже используете PHP с FastCGI, поэтому я не уверен, что еще вы можете сделать, чтобы это уменьшить. Вы здесь как бы на перепутье ..
Пара вариантов:
Изменить: вы говорите, что установили много вещей для кеширования. Кэш = съесть больше ОЗУ, чтобы следующие запросы выполнялись быстрее. Если у вас очень мало ОЗУ - кеширование может быть не лучшим решением в мире.
Из опубликованной вами информации:
. Кажется, ваш VPS работает под управлением OpenVZ или Parallels Virtuozzo. Если хостинг-провайдер превысит доступность (а многие это делают), ваш сервер никогда не сможет использовать третий гигабайт памяти.
Хуже того, вашему VPS может быть разрешено взорваться на небольшой период, но затем убийца OOM начнет убивать процессы. Убийца OOM может быть настроен (со стороны хостинг-провайдера), чтобы попытаться предотвратить убийство более важных процессов (скажем, ssh, bind, apache, mysql - с использованием приоритетов), но поскольку другие клиенты на том же узле могут работать та же типовая настройка, это не помогает.
Получите 3G гарантированно, без пакетной передачи.
. Если веб-страницы действительно статические и маленькие, вы можете использовать кэширующий обратный прокси-сервер. Да, кеширование использует память. Но кеширование также предотвращает порождение процессов PHP, которые, как правило, очень требовательны.
(вам нужно посчитать и / или попробовать ... Это не абсолютное решение)
. Отключите APC или запустите PHP-FPM.
С Fcgi каждый процесс PHP имеет свой собственный кеш кодов операций APC. Используйте FPM для всех процессов PHP, чтобы использовать общий кеш. Или отключите APC. В любом случае, похоже, он вам не нужен (кеш-код операций намного эффективнее для сокращения использования ЦП, чем использование памяти;))