Лак 503 при доставке медленной страницы
Varnish продолжает выдавать сервис 503, недоступный при попытке загрузить страницу, создание которой занимает больше времени на веб-сервере.
В варнишлоге я вижу FetchError c http read error: 0
ошибка, хотя я не совсем уверен, что это значит.
Я также попытался увеличить время ожидания бэкэнда:
backend default {
.host = "x.x.x.x";
.port = "80";
.connect_timeout = 600s;
.first_byte_timeout = 600s;
.between_bytes_timeout = 600s;
}
Бэкэнд является сервером Apache.
Все остальные страницы работают нормально.
Есть идеи?
1 ответ
Сообщение об ошибке означает (ссылки на номера строк относятся к лаку 2.1.3):
При получении заголовка [bin/varnishd/cache_fetch.c:399], либо:
а) произошло переполнение [bin/varnishd/cache_httpconn.c:170]
или же
б) произошла ошибка при вызове read() [bin/varnishd/cache_httpconn.c:175]
Число в конце - это значение errno, поэтому, так как оно равно 0 (без ошибок), я бы предположил, что опция a) произошла с read()
не должен возвращать отрицательное число без установки errno.
Переполнение обнаружено с помощью следующего кода [bin/varnishd/cache_httpconn.c:167], возвращающего отрицательный результат:
i = (htc->ws->r - htc->rxbuf.e) - 1; /* space for NUL */
htc->ws
это struct ws
[bin/varnishd/cache.h:126], который является "структурой рабочего пространства". Член r - это зарезервированная длина этого рабочего пространства. htc->rxbuf
относится к struct txt
[bin/varnishd/cache.h:109], но нет комментариев, описывающих, на что ссылаются участники (b & e). Возможно, начало и конец?
Я не знаю, как изменяются размеры рабочих пространств (или даже если они есть), но - и я на самом деле нахожусь в угадывании территории - я бы предположил, что некоторые возможные причины проблемы:
- Очень большое количество заголовков
- Очень длинные заголовки
- Ошибка в том, как Varnish изменяет размеры рабочих пространств (если это так)
Может быть полезно попытаться найти точку, в которой ошибка может быть вызвана, путем поиска в пространстве:
- Длина заголовка
- Номера заголовков
и посмотрите, сможете ли вы надежно воспроизвести проблему.
Вы можете обойти эту проблему, увеличив http_headers
вариант времени выполнения. (Если вы используете < 2.1, я думаю, что это опция компиляции или компоновки)