Я получаю следующую ошибку в журнале nginx
[ошибка] 17734 # 0: * 6643 recv () не удалось (104: сброс соединения одноранговым узлом) при чтении заголовка ответа из восходящего потока, клиент: [вырезать], сервер: [вырезать], запрос: «GET / Venues HTTP / 1.1» , восходящий поток: "fastcgi: //127.0.0.1: 9000", хост: "[вырезать]"
У меня есть специальная коробка с оперативной памятью 8 ГБ, четырехъядерный чип. Хороший сервер. Nginx, php-fpm и mysql все последние версии работают под ubuntu 10.04
Я получаю это только при стресс-тесте сервера с осадой. Если я увеличу количество одновременных подключений до 100, я могу получить до 20% всех запросов с ошибкой.
Более того, я не получаю этого на страницах, на которых нет запросов mysql. И всего несколько сбоев на страницах с умеренным количеством запросов. Немного, я не уверен, что это связано с этим.
У меня такое чувство, что это как-то связано с php. Но я не могу этого понять.
Есть предложения, с чего начать поиск?
Обновление: и журнал ошибок php молчит. Нет записей о том, что что-то пошло не так
Скорее всего, у вас закончились рабочие php-fpm. В журнале ничего не было, потому что в самом коде ничего не было неправильного - рабочие просто были заняты обработкой ваших запросов. Если вы не получили этого на страницах без запросов MySQL, узким местом была база данных MySQL. Вы должны идентифицировать долго выполняющиеся запросы (используя mytop или функция медленного журнала или, может быть, какое-то настраиваемое ведение журнала PHP вокруг вашей обработки SQL) и оптимизируйте их. Конечно, «длинные запросы» на самом деле довольно короткие в нашем высоконагруженном мире. Даже запроса в 200 мс достаточно, чтобы поставить ваш сервер на колени.
это может быть решено. Я сообщил о подобной проблеме с открытием и повторным использованием постоянных TCP-сокетов практически без нагрузки. теперь в git есть патч для этого:
https://groups.google.com/forum/#!topic/highload-php-en/qGu3Eaifj9s