Вопросы Теги

Лакируйте 3.0.2 к Apache2, иногда возвращают ошибку 503

Это связано с этим вопросом:

https://stackoverflow.com/questions/3393888/how-can-i-remove-script-virus-from-my-script/

3
задан 28 February 2018 в 11:45
4 ответа

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

Еще один пункт, который следует рассмотреть, - это увеличить / настроить некоторые из ваших предварительных настроек. Если вы видите, что проходит много трафика, эти слишком низкие - ИМО. Вот значения по умолчанию на моем 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 для получения дополнительной информации об этих параметрах.

0
ответ дан 3 December 2019 в 07:35

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

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

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

0
ответ дан 3 December 2019 в 07:35

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

Пожалуйста, имейте в виду, что это было сделано для экземпляра M3.Medium на Amazon EC2 (1x 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):

    по умолчанию бэкэнда {
 .host = "127.0.0.1";
 .port = "8000";
 .connect_timeout = 600 с;
 .first_byte_timeout = 600s;
 .между_байтами_таймаутом = 600 с;
}

  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 ( и еще несколько, но не могу разместить ссылки. Некоторые Googleling для "лака keepalive backend timeout" должны всплыть на поверхность того, что вы хотите)

Больше помощи при отладке: Если вы все еще застряли, попробуйте сделать следующее: - запустите varnishlog -w err.log на вашем сервере Varnish. - На вашем клиенте, возьмите Осаду: http://www.joedog.org/siege-home/ и загрузите его с некоторыми из URL, которые вы видели 503 (подсказка: urls.txt, используйте -i -b -c500 -r10 и этого должно быть достаточно, чтобы запустить 503). - start 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 Хост: 10.201.81.157 936 RxHeader c Принимаю: */* 936 RxHeader c Прием-выемка: gzip 936 RxHeader c User-Agent: Mozilla/5.0 (apple-x86_64-darwin11.4.2) Siege/3.0.5 936 RxHeader c Подключение: закрытие 936 VCL_call c recv lookup 936 VCL_call c hash 936 Хэш c /ip/69.120.68.54 936 Хэш c 10.201.81.157 936 VCL_return c hash 936 HitPass c 357445183 936 VCL_call c pass 936 Бэкэнд c 103 по умолчанию 936 FetchError c http ошибка первого чтения: -1 0 (Success) 936 Бэкэнд c 269 дефолт по умолчанию 936 FetchError c http ошибка первого чтения: -1 0 (Success) 936 VCL_call c error deliver 936 VCL_call c доставить доставку 936 TxProtocol c HTTP/1.1 936 Статус TxStatus c 503 936 TxResponse c Услуга недоступна 936 TxHeader c Server: Varnish 936 TxHeader c Content-Type: text/html; charset=utf-8 936 TxHeader c Retry-After: 5 936 TxHeader c Контент Длина: 418 936 TxHeader c Диапазоны приема: байты 936 TxHeader c Date: Ту, 05 июня 2014 23:05:48 GMT 936 TxHeader c X-Varnish: 357447130 936 ТхГидер c Возраст: 0 936 TxHeader c Via: 1.1 лак 936 TxHeader c Подключение: закрытие 936 Длина c 418

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

1
ответ дан 3 December 2019 в 07:35

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

varnishadm backend.health

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

0
ответ дан 3 December 2019 в 07:35

Теги

Похожие вопросы