В жизни каждого ресурса, который вы посещаете, бывают моменты, когда оборудование не справляется с текущей нагрузкой.
Причины могут быть самыми разнообразными, и их не всегда можно радикально искоренить в разумные сроки.
В таких случаях перед разработчиками стоит задача снизить нагрузку с минимальными неудобствами для посетителей.
Не претендую на гениальность своего решения, но надеюсь, что оно кому-то поможет. В моем случае проблема в том, что нагрузка на базу данных время от времени резко возрастает. Как обычно бывает в таких случаях, происходит лавина — запросы начинают тормозить, пользователи нервничают и нажимают перезагрузку, Cron-скрипты тормозят и в результате сервер зависает. Кроме того, проблем добавляют поисковые роботы — они склонны выдергивать с сайта глубокие страницы, которые обычно не живут в кеше.
В результате для них генерируются страницы и кэш заполняется ненужными данными.
Со второй частью проблемы можно справиться довольно легко — просто не кэшируйте обращения к старым страницам или обращения от роботов.
Но вполне можно пойти дальше и хотя бы на время снять нагрузку с роботов, когда сервер перегружен.
Передо мной стояли две задачи: 1. Как определить момент возникновения повышенной нагрузки 2. Что вы можете сделать в эти моменты, чтобы облегчить жизнь? Для решения первой проблемы я использовал знаменитый чудо-инструмент zabbix, так как он активно и успешно применяется уже давно и позволяет мониторить несколько серверов, а также выполнять на них команды при возникновении необходимых условий.
В моем случае я выбрал среднюю нагрузку на сервер базы данных.
А мне нужно среагировать на другом сервере, на котором живет nginx. Я создал триггер с условием system.cpu.load[,avg1].
last(0)> 3.5, назначил ему выполнение удаленной команды
ХОСТ: /path/lowerage.sh {СТАТУС} {ITEM.LASTVALUE} {TIME}
А на сервере я разместил простой скрипт: if [ "${1}" != "ON" ] ; then
/bin/unlink /tmp/cpu_load_high
else
/usr/bin/touch /tmp/cpu_load_high
fi
echo "lowerage ${1} ${2} ${3}" |/usr/bin/mail -s lowerage [email protected]
В результате при увеличении нагрузки создавался файл, из которого можно было танцевать дальше.
Перейдем плавно к собственно действиям.
Прежде всего, я ограничил запуск Cron-скриптов в критические моменты.
Решение тривиальное, просто добавьте условие в корону.
Пример: /бин/тест! -r /tmp/cpu_load_high && /usr/bin/fetch -o — сайт/cron.php Потом я стал аккуратно нажимать на поисковых роботов.
Я решил их отключать в критические моменты на уровне nginx. С последним пришлось поумничать, дело в том, что nginx не понимает вложенных if, а мне нужно как минимум два условия.
Выручил финт ушами.
Ниже приведен фрагмент файла конфигурации, реализующий вышеизложенное: if (-f /tmp/cpu_load_high) {
set $troubleflag T;
}
if ($http_user_agent ~ (?:Yandex|Google|Yahoo|Rambler|msnbot) ) {
set $oblomflag Y$troubleflag;
}
if ($oblomflag = YT) {
return 444;
}
Кстати, я не уверен, что вариант с вернуть 444 оптимальный.
В этом случае nginx просто разрывает соединение.
Я думаю, что роботов не должно слишком обижать такое поведение.
Вот, собственно, и все.
В дальнейшем еще можно не обрабатывать некоторые тяжелые запросы в критические моменты — перенаправлять пользователя на страницу с извинениями.
Спасибо за внимание.
UPD: в комментариях предложили ссылку googlewebmastercentral.blogspot.com/2006/08/all-about-googlebot.html где Google рекомендует использовать код 503. Теги: #Nginx #оптимизация сервера #оптимизация #zabbix
-
Утилизация Печатных Плат В Горячей Воде.
19 Oct, 24 -
Бизнес На Трекерах
19 Oct, 24 -
Рейтинг Топ-50 Digital-Агентств России 2011
19 Oct, 24
