Nginx + php-fpm - ошибка recv()

Я получаю следующую ошибку в журнале nginx

[ошибка] 17734#0: *6643 Ошибка recv() (104: сброс соединения по узлу) при чтении заголовка ответа из восходящего потока, клиент: [вырезать], сервер: [вырезать], запрос: "GET /venues HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", хост: "[cut]"

У меня есть специальная коробка с 8 ГБ оперативной памяти, четырехъядерный чип. Хороший сервер. Nginx, php-fpm и mysql все последние версии, работающие под Ubuntu 10.04

Я получаю это только при стресс-тестировании сервера с осадой. Если я увеличу количество одновременных подключений до 100, я могу получить до 20% всех запросов на сбой.

Кроме того, я не получаю это на страницах, где нет запросов mysql. И только несколько сбоев на страницах с умеренным количеством запросов. Бит, я не уверен, нужно ли что-то делать с этим.

У меня есть ощущение, что это как-то связано с php. Но я не могу понять это.

Любые предложения о том, где даже начать искать?

Обновление: и журнал ошибок php молчит. Нет записей о том, что что-то идет не так

2 ответа

Скорее всего, у вас закончились работники php-fpm. В журнале ничего не было, потому что в самом коде нет ничего плохого - рабочие просто заняты обработкой ваших запросов. Если вы не получили это на страницах без запросов MySQL, узким местом была БД MySQL. Вы должны определить длительные запросы (используя mytop или медленная функция журнала или, возможно, некоторая пользовательская регистрация PHP вокруг вашей обработки SQL) и их оптимизация. Конечно, "длинные запросы" на самом деле довольно короткие в мире с высокой нагрузкой. Даже запрос 200 мс достаточно длинный, чтобы поставить ваш сервер на колени.

Это может быть решено. я сообщил об аналогичной проблеме с открытием и повторным использованием постоянных сокетов tcp практически без нагрузки. в git есть патч для этого:

https://groups.google.com/forum/

Другие вопросы по тегам