Вопрос или проблема
У меня есть varnish 4 перед веб-сервером Apache. Все хорошо, за исключением случайных ошибок 502.
Что странно, в файле varnishlog нет записей об этой ошибке! (все остальные запросы фиксируются)
Мои параметры:
VARNISH_MIN_THREADS=50
VARNISH_MAX_THREADS=1000
VARNISH_THREAD_TIMEOUT=120
Что я могу сделать, чтобы это исправить?
Мой default.vcl:
vcl 4.0;
backend default {
.host = "127.0.0.1";
.port = "8055";
}
backend php53 {
.host = "127.0.0.1";
.port = "8053";
}
sub vcl_recv {
# Совместимость с журналом Apache
if (req.http.X-Forwarded-For) {
set req.http.X-Forwarded-For = client.ip;
} else {
set req.http.X-Forwarded-For = client.ip;
}
if (
req.http.Host ~ "site1" ||
req.http.Host ~ "site2")
{
set req.backend_hint = php53;
}
if (req.http.Host ~ "mainsite" ){
if (req.method == "POST") {
return (pipe);
}
if (req.method == "GET" && (req.url ~ "^/admin")) {
return (pass);
}
}
if (req.method != "GET" && req.method != "HEAD")
{
return (pass);
}
if (req.url ~ "(?i)\.(jpeg|jpg|png|gif|ico)$") {
unset req.http.Cookie;
return (hash);
} else {
return (pass);
}
}
sub vcl_backend_response {
if (beresp.http.Content-Length !~ "[0-9]{7,10}") {
return(deliver);
}
}
У меня ошибки 502 на ‘mainsite’ (prestashop ecommerce, с большим количеством изображений)
Моя текущая статистика:
MAIN.uptime 151353 1.00 Время работы дочернего процесса
MAIN.sess_conn 59309 0.39 Сессий принято
MAIN.sess_drop 0 0.00 Сессий отклонено
MAIN.sess_fail 0 0.00 Ошибки при принятии сессий
MAIN.backend_conn 24076 0.16 Успешное подключение к бэкенду
MAIN.backend_unhealthy 0 0.00 Подключение к бэкенду не пытались
MAIN.backend_busy 0 0.00 Слишком много подключений к бэкенду
MAIN.backend_fail 85 0.00 Ошибки подключения к бэкенду
MAIN.backend_reuse 53606 0.35 Повторное использование подключения к бэкенду
MAIN.backend_toolate 11249 0.07 Подключение к бэкенду было закрыто
MAIN.backend_recycle 64856 0.43 Переработка подключения к бэкенду
MAIN.backend_retry 0 0.00 Повторное подключение к бэкенду
MAIN.threads 100 . Общее количество потоков
MAIN.threads_created 108 0.00 Создано потоков
MAIN.threads_destroyed 8 0.00 Уничтожено потоков
MAIN.threads_failed 0 0.00 Ошибка создания потоков
MAIN.busy_sleep 3 0.00 Количество запросов, отправленных в спящий режим
MAIN.busy_wakeup 3 0.00 Количество запросов, разбуженных после сна
MAIN.sess_queued 11 0.00 Сессий в очереди для работы потока
ps aux | grep -i varnish | grep -v grep :
root 22319 0.0 0.5 121896 84060 ? SLs 12:21 0:00 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -p thread_pool_min=50 -p thread_pool_max=1000 -p thread_pool_timeout=120 -u varnish -g varnish -S /etc/varnish/secret -s malloc,1G
varnish 22321 0.4 0.5 321348 92604 ? Sl 12:21 0:00 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -p thread_pool_min=50 -p thread_pool_max=1000 -p thread_pool_timeout=120 -u varnish -g varnish -S /etc/varnish/secret -s malloc,1G
Вы смотрели журнал ошибок Apache для “mainsite”?
Вставьте вывод :
ps aux | grep -i varnish | grep -v grep
А также проверьте, что ваш размер malloc не слишком велик, чтобы обслуживать большие размеры содержимого
Попробуйте: beresp.http.Content-Length !~ "держите этот размер маленьким"
(если так)
Заметка: измените это на регулярное выражение, чтобы удовлетворить ваши требования, где указано, что размер должен быть маленьким
и проверьте, сохраняется ли ошибка.
Ответ или решение
Ваша проблема с произвольными ошибками 502 при использовании Varnish в качестве обратного прокси-сервера для Apache может быть результатом различных факторов. Рассмотрим основные причины и решения для устранения этих ошибок.
Теория (Theory)
Ошибка 502 Bad Gateway указывает на то, что Varnish не получает действительного ответа от бекенда, в данном случае Apache. Это может происходить по нескольким причинам, таким как:
- Проблемы с подключением к серверу Apache.
- Проблемы с конфигурацией, приводящие к тому, что Varnish не может обработать или получить ответ от Apache.
- Высокая нагрузка на сервер Apache, из-за чего он не успевает обрабатывать запросы.
- Ошибки в самом Varnish или неверные настройки, такие как перегрузка потоков.
Пример (Example)
Рассмотрим настройки и журнал работы вашего проекта:
-
Настройки потоков Varnish: Вы указали
VARNISH_MIN_THREADS=50
,VARNISH_MAX_THREADS=1000
иVARNISH_THREAD_TIMEOUT=120
. Эти значения выглядят подходящими, однако стоит проверить, нет ли перегрузки потоков, что могло бы приводить к ошибкам. -
Повторное использование и перегрузка соединений: Статистика показывает, что растет количество
backend_toolate
, что может указывать на задержки или тайм-ауты в подключении к Apache. Параметрыbackend_fail
иbackend_toolate
указывают на определенные проблемы с временем ответа от Apache.
Применение (Application)
Для повышения стабильности и устранения ошибок предлагается предпринять следующие шаги:
-
Проверка журналов Apache: Изучите журналы ошибок Apache, чтобы выявить, нет ли проблем на стороне бекенда.
-
Тайм-ауты Apache: Убедитесь, что параметры тайм-аута Apache достаточны для обработки актуальной нагрузки. Увеличьте значение
KeepAliveTimeout
и проверьте настройкиMaxRequestWorkers
на сервере Apache. -
Оптимизация регулярок в конфигурации Varnish: Проверьте регулярные выражения в вашей
default.vcl
конфигурации, чтобы убедиться, что они не слишком жесткие и соответствуют вашим требованиям. -
Настройки размера памяти Varnish: Убедитесь, что размер
malloc
достаточен для обслуживания запросов с крупным контентом. В вашем случае стоит проанализировать, какие именно ответы вызывают ошибки, и убедиться, что Varnish имеет достаточно памяти для их обработки. -
Моделирование и тестирование нагрузки: Используйте инструменты для моделирования нагрузки, чтобы убедиться, что конфигурация Varnish и Apache справляется с реальной нагрузкой вашей системы.
Заключение
Для оптимизации работы связки Varnish и Apache важно учитывать параметры тайм-аутов, мониторить производительность и изучать логи, чтобы вовремя определять и устранять потенциальные проблемы. Обеспечение достаточного объема памяти и адаптация настроек тайм-аута помогут улучшить устойчивость системы и минимизировать появление ошибок 502.