LINUX.ORG.RU
ФорумAdmin

Отладка nginx

 ,


0

2

Снова здравствуй, ЛОР.

Есть один сервер, на нём крутится nginx+lua. Всё это добро обслуживает обслуживает очень много запросов, но есть одна проблема: рандомно один из воркеров nginx'а начинает отжирать 100% CPU и не торопится умирать (ждал часа два точно)

Как узнать, какой запрос повесил nginx? Если убить его KILL- сигналом, то ничего толкового он не говорит. Если убить TERMом, он вообще не завершается.

★★★★☆

nginx+lua и все ? БД, записи в файл и т п есть ?

Jopich
()
Ответ на: комментарий от annerleen

Ну а чего ты тогда хошь ? БД хоть какая ? nginx + lua асинхронны, спотыкаются на какой нибудь синхронный запрос и все ...

Jopich
()
Ответ на: комментарий от Jopich

Постгрес.
Это понятно. Ну он же должен когда-нибудь закончится, нет? Или один запрос выполняется полтора часа и не может завершится? Если да, то интересно, какой же это запрос — про это и вопрос в треде.

annerleen ★★★★☆
() автор топика
Ответ на: комментарий от annerleen

там же в postgresql транзакционная модель- соотв наверное транзакция и тянется 2 часа. Ну а правильнее конечно не заниматься ерундой и заюзать более подходящую нетранзакционную БД для этого

Jopich
()
Ответ на: комментарий от Jopich

конечно могу, я знаю.

Проблема только в том, что запросов около 2 млн в день, и как поймать именно «косячный» - проблема.

Достаточно было бы узнать URL запроса, чтобы понять, в какой части проблема, но как это понять - пока непонятно.

annerleen ★★★★☆
() автор топика
Ответ на: комментарий от annerleen

Гм там может быть и проблема в том что запрос не выполняется ТК висит транзакция т е отловить url у тебя не получится а так настраивай логгирование запросов в пострескл

Jopich
()

IMHO, самый простой способ — дождаться, пока снова повиснет, подцепиться к процессу через gdb, сбросить корку, а уже потом не спеша её ковырять. Перед операцией нужно либо поставить отладочные символы, либо собрать свою версию с отладкой.

Почти во всех местах в коде nginx есть доступ к экземпляру ngx_http_request_t. Запрос — в r->method и r->unparsed_uri. Посмотри остальные поля, там тоже много интересного. Если r->main не равно r, вместо r бери r->main.

i-rinat ★★★★★
()
Ответ на: комментарий от annerleen

Включи логирование запросов в базе и когда начнутся тормоза смотри те, которое висят и не закрываются. По самому запросу обычно легко понять откуда он пришел.

ya-betmen ★★★★★
()
Ответ на: комментарий от annerleen

Запрос у тебя обычный хттп? Можешь сопоставить время начала и время конца обработки?

ya-betmen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.