Назад | Перейти на главную страницу

Varnish 3.0.2 для Apache2 иногда возвращает ошибку 503

Привет, ребята, надеюсь, вы мне поможете.

У меня есть Ngingx, анализирующий http и https в кеш-лак (3.0.2). С лака отправляется в apache2. Вот уже некоторое время я отслеживаю какие-то странные ошибки 503. Но я не могу найти серебряную пулю.

В настоящее время я регистрирую 503 ошибки с помощью varnish следующим образом:

sudo varnishlog -c -m TxStatus:503 >> /home/rj/varnishlog503.log

а затем обращаясь к журналу доступа apache, чтобы увидеть, были ли обработаны какие-либо запросы 503.

Сегодня у меня была проверка работоспособности с помощью брандмауэра:

20 SessionOpen  c 127.0.0.1 34319 :8081
20 ReqStart     c 127.0.0.1 34319 607335635
20 RxRequest    c HEAD
20 RxURL        c /health-check
20 RxProtocol   c HTTP/1.0
20 RxHeader     c X-Real-IP: 192.168.3.254
20 RxHeader     c Host: 192.168.3.189
20 RxHeader     c X-Forwarded-For: 192.168.3.254
20 RxHeader     c Connection: close
20 RxHeader     c User-Agent: Astaro Service Monitor 0.9
20 RxHeader     c Accept: */*
20 VCL_call     c recv lookup
20 VCL_call     c hash
20 Hash         c /health-check
20 VCL_return   c hash
20 VCL_call     c miss fetch
20 Backend      c 33 aurum aurum
20 FetchError   c http first read error: -1 11 (No error recorded)
20 VCL_call     c error deliver
20 VCL_call     c deliver deliver
20 TxProtocol   c HTTP/1.1
20 TxStatus     c 503
20 TxResponse   c Service Unavailable
20 TxHeader     c Server: Varnish
20 TxHeader     c Content-Type: text/html; charset=utf-8
20 TxHeader     c Retry-After: 5
20 TxHeader     c Content-Length: 879
20 TxHeader     c Accept-Ranges: bytes
20 TxHeader     c Date: Wed, 06 Jun 2012 12:35:12 GMT
20 TxHeader     c X-Varnish: 607335635
20 TxHeader     c Age: 60
20 TxHeader     c Via: 1.1 varnish
20 TxHeader     c Connection: close
20 Length       c 879
20 ReqEnd       c 607335635 1338986052.649786949 1338986112.648169994 0.000160217 59.997980356 0.000402689

Теперь внутренний сервер (apache) не имеет ошибок 503 в журнале доступа на данный момент. Итак, я запутался. Этот лак бросает 503, потому что думает, что apache тормозит? На данный момент идет большой трафик, поэтому я знаю, что сервер запущен и работает.

У меня есть другие коды ошибок 503 с сообщениями, и я получаю, поэтому на самом деле нет шаблона. Вроде бы случайные времена и случайные запросы. Даже утром, когда кажется, что сервер ничего не делает.

Я вижу в журнале еще одну закономерность:

4 VCL_call     c recv pass
4 VCL_call     c hash
4 Hash         c /?id=412
4 VCL_return   c hash
4 VCL_call     c pass pass
4 FetchError   c no backend connection
4 VCL_call     c error deliver
4 VCL_call     c deliver deliver

Здесь fetcherror говорит «нет соединения с сервером». Краткое изложение ошибок FetchErrors в сегодняшнем журнале:

16 FetchError   c http first read error: -1 11 (No error recorded)
 5 FetchError   c http first read error: -1 11 (No error recorded)
 4 FetchError   c http first read error: -1 11 (No error recorded)
19 FetchError   c http first read error: -1 11 (No error recorded)
 5 FetchError   c http first read error: -1 11 (No error recorded)
23 FetchError   c http first read error: -1 11 (No error recorded)
24 FetchError   c http first read error: -1 11 (No error recorded)
16 FetchError   c http first read error: -1 11 (No error recorded)
 6 FetchError   c http first read error: -1 11 (No error recorded)
 4 FetchError   c http first read error: -1 11 (No error recorded)
 5 FetchError   c http first read error: -1 11 (No error recorded)
 4 FetchError   c http first read error: -1 11 (No error recorded)
 4 FetchError   c http first read error: -1 11 (No error recorded)
22 FetchError   c http first read error: -1 11 (No error recorded)
 6 FetchError   c http first read error: -1 11 (No error recorded)
21 FetchError   c http first read error: -1 11 (No error recorded)
26 FetchError   c no backend connection
 4 FetchError   c no backend connection
20 FetchError   c http first read error: -1 11 (No error recorded)
39 FetchError   c http first read error: -1 11 (No error recorded)

Я не менял значения тайм-аута по умолчанию для лака. Это моя конфигурация для одного из внутренних серверов.

backend xenon {
    .host = "192.168.3.187";
    .port = "80";
    .probe = {
        .url = "/health-check/";
        .interval = 3s;
        .window = 5;
        .threshold = 2;
    }
}

Я запускаю модуль prefork на apache2 с этой конфигурацией

<IfModule mpm_prefork_module>
    StartServers          1
    MinSpareServers       2
    MaxSpareServers       5
    MaxClients           200
    MaxRequestsPerChild  75
</IfModule>

и только файлы PHP отправляются на сервер. Все остальные статические файлы обрабатываются Nginx.

Любые идеи?

------- РЕДАКТИРОВАТЬ --------------

Еще немного отладочной информации

Я запустил varnishadm debug.health

Backend radon is Healthy
Current states  good:  5 threshold:  2 window:  5
Average responsetime of good probes: 0.002560
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy
Backend xenon is Healthy
Current states  good:  5 threshold:  2 window:  5
Average responsetime of good probes: 0.002760
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy
Backend iridium is Healthy
Current states  good:  5 threshold:  2 window:  5
Average responsetime of good probes: 0.000849
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy
Backend aurum is Healthy
Current states  good:  5 threshold:  2 window:  5
Average responsetime of good probes: 0.002100
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy

И я отслеживал varnishstat от двух балансировщиков нагрузки.

 3224774         3.99         2.61 backend_conn - Backend conn. success
      27         0.00         0.00 backend_unhealthy - Backend conn. not attempted
      63         0.00         0.00 backend_fail - Backend conn. failures
  358798         0.00         0.29 backend_reuse - Backend conn. reuses
   21035         0.00         0.02 backend_toolate - Backend conn. was closed
  379834         0.00         0.31 backend_recycle - Backend conn. recycles
      26         0.00         0.00 backend_retry - Backend conn. retry

3217751         5.99         2.61 backend_conn - Backend conn. success
      32         0.00         0.00 backend_fail - Backend conn. failures
  364185         0.00         0.30 backend_reuse - Backend conn. reuses
   27077         0.00         0.02 backend_toolate - Backend conn. was closed
  391263         0.00         0.32 backend_recycle - Backend conn. recycles
      36         0.00         0.00 backend_retry - Backend conn. retry

Обратите внимание, что ни один из них не сообщил о backend_fail.

/ Ронни

Я столкнулся с этим с Apache, и решение было комбинацией следующего (обратите внимание, что я использую Apache / 2.4.7 (Ubuntu) + varnish 3.0.5-2 в Ubuntu 14.04 LTS в AWS EC2):

Имейте в виду, что это было сделано для экземпляра M3.Medium на Amazon EC2 (1 ядро ​​Intel Xeon E5-2670 + 3,75 ГБ ОЗУ). При необходимости отрегулируйте для вашего оборудования!

  1. В /etc/default/varnish, отредактируйте параметры запуска:

     DAEMON_OPTS="-a :80 \
     -T localhost:6082 \
     -f /etc/varnish/default.vcl \
     -S /etc/varnish/secret \
     -p thread_pools=2 \
     -p thread_pool_max=600 \
     -p listen_depth=1024 \
     -p lru_interval=900 \
     -p connect_timeout=600 \
     -p max_restarts=6 \
     -s malloc,1G"

  2. В /etc/varnish/default.vcl или независимо от того, какой у вас VCL, измените тайм-ауты серверной части (обратите внимание, что мы также устанавливаем их в / etc / default / varnish):

    backend default {
    .host = "127.0.0.1";
    .port = "8000";
    .connect_timeout = 600s;
    .first_byte_timeout = 600s;
    .between_bytes_timeout = 600s;
}

  3. Отключите KeepAlives. На этой странице содержится дополнительная информация (зависит от программного обеспечения внутреннего веб-сервера): http://www.feedthebot.com/pagespeed/keep-alive.html

Для Apache все, что мне нужно было сделать, это изменить строку 92 в /etc/apache2/apache2.conf на следующее:

    KeepAlive Off

Я думаю, что здесь происходит то, что KeepAlives, реализованный в программном обеспечении внутреннего веб-сервера, отправляет явные сбросы соединения, с которыми Varnish плохо работает. Вероятно, в этой истории есть нечто большее, и я призываю вас вникнуть в нее и опубликовать свои выводы здесь, чтобы будущие поколения могли учиться у них.

Дополнительное чтение: - https://www.varnish-cache.org/trac/wiki/Future_Feature#Keepalivetimeoutonbackendconnections (и еще несколько, но не могу публиковать ссылки. Поиск в Google "тайм-аута поддержки активности поддержки активности бэкэнда лаком" должен выявить то, что вы хотите)

Дополнительная помощь по отладке: если вы все еще застряли, попробуйте сделать следующее: - start varnishlog -w err.log на вашем сервере Varnish - на вашем клиенте получите Siege: http://www.joedog.org/siege-home/ и загрузите его с некоторыми URL-адресами, которые вы видели 503 (подсказка: urls.txt, используйте -i -b -c500 -r10 и этого должно хватить для срабатывания 503-х) - старт varnishlog -r temp -c -m 'TxStatus:503' > err-parsed.txt. Это захватит все записи журнала Varnish, где Varnish возвратил 503. FWIW, вот полный текст одной из моих ошибок. TL; DR ошибка, о которой сообщает Varnish, была FetchError c http first read error: -1 0 (Success) :

936 SessionOpen c 10.8.226.98 51895 :80 936 ReqStart c 10.8.226.98 51895 357447130 936 RxRequest c GET 936 RxURL c /ip/69.120.68.54 936 RxProtocol c HTTP/1.1 936 RxHeader c Host: 10.201.81.157 936 RxHeader c Accept: */* 936 RxHeader c Accept-Encoding: gzip 936 RxHeader c User-Agent: Mozilla/5.0 (apple-x86_64-darwin11.4.2) Siege/3.0.5 936 RxHeader c Connection: close 936 VCL_call c recv lookup 936 VCL_call c hash 936 Hash c /ip/69.120.68.54 936 Hash c 10.201.81.157 936 VCL_return c hash 936 HitPass c 357445183 936 VCL_call c pass pass 936 Backend c 103 default default 936 FetchError c http first read error: -1 0 (Success) 936 Backend c 269 default default 936 FetchError c http first read error: -1 0 (Success) 936 VCL_call c error deliver 936 VCL_call c deliver deliver 936 TxProtocol c HTTP/1.1 936 TxStatus c 503 936 TxResponse c Service Unavailable 936 TxHeader c Server: Varnish 936 TxHeader c Content-Type: text/html; charset=utf-8 936 TxHeader c Retry-After: 5 936 TxHeader c Content-Length: 418 936 TxHeader c Accept-Ranges: bytes 936 TxHeader c Date: Thu, 05 Jun 2014 23:05:48 GMT 936 TxHeader c X-Varnish: 357447130 936 TxHeader c Age: 0 936 TxHeader c Via: 1.1 varnish 936 TxHeader c Connection: close 936 Length c 418

Надеюсь это поможет!

Надеюсь, это опечатка, но вы упомянули, что в журналах доступа нет ошибок? Ошибки будут в журнале ошибок (-: Проверить там, если вы еще этого не сделали? Файл называется error_log. Также проверьте свой httpd.conf для уровня журнала ошибок. Попробуйте установить его на debugи перезапустите, чтобы просмотреть дополнительные сведения в журналах ошибок. Я считаю, что по умолчанию warn. Обратите внимание, что при отладке возникают накладные расходы на производительность, поэтому делайте это, пока не получите необходимые данные и не установите их обратно на warn.

Еще один пункт, который следует учитывать, - это увеличить / настроить некоторые параметры предварительной вилки. Если вы видите, что "проходит много трафика", это слишком мало - ИМО. Вот значения по умолчанию для моего RHEL 6.1, apache 2.2:

<IfModule prefork.c>
    StartServers            8
    MinSpareServers         5
    MaxSpareServers        20
    ServerLimit           256
    MaxClients            256
    MaxRequestsPerChild  4000
</IfModule>

Оптимальные настройки зависят от вашей установки apache и оборудования, которое вы используете - памяти, процессоров и т. Д. Я бы начал с плавного увеличения первых трех. Видеть Предварительный форк Apache MPM для получения дополнительной информации об этих параметрах.

503 означает, что работоспособный бэкэнд недоступен. Apache не ответил на зонд с таймаутом или 200

varnishadm backend.health

Может дать статус работоспособности серверной части. Это причина, по которой в ваших журналах Apache не зарегистрировано 503

Если это загруженный сервер, то я предполагаю, что это так, поскольку вы заявляете: «На данный момент проходит много трафика, поэтому я знаю, что сервер запущен и работает». Вы оценили сначала свою конфигурацию apache, чтобы иметь возможность обрабатывать трафик наплыв? И, во-вторых, вы используете nginx для прокси-запросов на лак. Вы установили значение повтора для запросов? Например, при использовании прокси-сервера apache вы можете сделать что-то вроде этого

ProxyPass / http://192.1.1.11:9001/ retry=3 timeout=5

Это заставит прокси-сервер выполнить n повторных попыток для этих запросов. Найдите аналог этого для nginx. Это может помочь уменьшить количество 503, однако, если это проблема трафика, вам необходимо решить ее в конечном итоге. Также вы можете использовать haproxy, а не nginx для такого проксирования, поскольку это то, для чего он создан.