У нас есть несколько тайм-аутов, которые сводят меня с ума, практически без нагрузки (возможно, несколько человек заходят на серверы в минуту).
Мы используем nginx для перенаправления не-SSL на SSL, прерывания SSL, а затем обратного прокси-запроса к haproxy, который отправляет его на один из наших серверов приложений.
Наши серверы приложений работают под управлением пассажира (рельсы) + nginx. У нас есть mysql master + slave и экземпляр memcached, который мы недавно начали использовать для некоторых запросов.
Вот типичная ошибка, которую я вижу на первом уровне в журнале ошибок nginx, который передает запросы в haproxy (с запутанными деталями):
2012/02/25 06:42:15 [ошибка] 7838 # 0: * 60797 тайм-аут восходящего потока (110: тайм-аут соединения) при чтении заголовка ответа из восходящего потока, клиент: 1.2.3.4, сервер: domain.com, запрос: "GET / api / v1 / some_route HTTP / 1.1", восходящий поток: "http://127.0.0.1:82/api/v1/some_route", хост:" domain.com "
Я не уверен, что это haproxy, пассажир + nginx, rails, memcached. Один из эмпирических данных заключается в том, что они, кажется, происходят группами, то есть если мы получаем один тайм-аут, мы видим несколько других, а затем они исчезают.
Любая помощь будет принята с благодарностью. С радостью выложу любые конфиги или все, что может помочь.
(вероятно, стоит упомянуть, что я не являюсь пользователем nginx или действительно rails, так что это всего лишь начальные предположения, чтобы, возможно, начать обсуждение с некоторыми идеями для ответа)
Судя по деталям вашей записи в журнале, кажется, что внешний запрос внутренне перенаправляется nginx на сервере со строкой хоста domain.com "на локальный haproxy, работающий на localhost: 82?
Если это так, то я бы действительно попытался связать записи журнала от nginx с haproxy, то есть найти тот же запрос в журнале haproxy.
Учитывая, что я не знаю о nginx, поэтому предполагаю, что вам нужно определить, соответствует ли это сообщение 110 proxy_connect_timeout или proxy_read_timeout, первое означает, что nginx не получил никакого ответа от haproxy (хост A отправляет SYN, ваш localhost: 82 сбросил пакет), а второе означает, что он подключился, но не отправил никаких данных обратно (Syn-Syn-ack , но нет данных в потоке).
В последнем случае проблема, скорее всего, находится еще дальше в вашем веб-стеке, и вам следует искать ту же запись в журналах memcache или mysql.
Например, установите свой медленный журнал запросов конфигурация my.conf на mysql и посмотрите, есть ли в этом файле журнала запись, соответствующая вашему запросу. Я думаю, что по умолчанию я находится в /var/lib/mysql/slow.log, но я думаю, что это может быть некоторая настройка.
В более общем плане, на тех платформах, где вы создали довольно сложная система, полезно иметь некоторую централизованную инфраструктуру ведения журналов для работы с корреляцией событий. Я сейчас развертываю logstash, для таких целей, очевидно, есть splunk и logblaze для коммерческих альтернатив.
У меня возникла проблема, когда ответ http только частично возвращался в мой браузер. Проблема заключалась в автокешировании nginx. Я установил nginx в специальный каталог. Я обнаружил, что если добавить строки
в http proxy_cache_path / var / lib / nginx / proxy levels = 1: 2 keys_zone = my-cache: 8m max_size = 1000m inactive = 600m; proxy_temp_path / var / cache / tmp;
и в папке proxy_cache my-cache; proxy_cache_valid 200 302 60 м; proxy_cache_valid 404 1 мес .;
и изменил разрешения на каталоги tmp и proxy, после чего весь HTTP-ответ был отправлен в мой браузер
