Re: снова про утечку сокето в

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Wed, Jun 22, 2011 at 12:01:28AM +0400, Костенко Евгений wrote:

> Несколько месяцев назад задавал в этой рассылке вопрос про aio и утечку
> сокетов.
> Maxim Dounin подсказал копать в сторону gdb и содержания внутренних структур
> nginx (http://forum.nginx.org/read.php?21,171856,173232#msg-173232)
> В другом обсуждении с участием Игоря нашел как выдрать из coredump'ов нужные
> структуры (http://forum.nginx.org/read.php?21,16913,17565#msg-17565)

Аналогичный набор команд для gdb доступен по приведённой мной 
ссылке в исходном треде:

http://wiki.nginx.org/Debugging#Socket_leaks

Там же есть инструкции, как получить идентификатор соединения 
чтобы выцепить нужные данные из debug log'а.

> Собственно на рестарте появилось куча "корок" и жалоб в глобальном error.log
> на "open socket #N left in connection M"
> Запускаем gdb и смотрим что внутри
> 
> (gdb) qq 34

Покажите сообщение об ошибке и имя используемого core-файла, дабы 
не возникало сомнений в правильности выбора числа 34.

> $18 = {len = 43, data = 0x801d2fb5c "/bla/bla/archive1.zip"}

Здесь "/bla/bla/archive1.zip" подставлено руками, или на самом 
деле имеет место повреждение данных запроса?

> $19 = {len = 46, data = 0x8099ac400 "GET /a52babab9bb8355b156358f434627bb0
> HTTP/1.1\r\nAccept"}
> discard_body    0
> lingering_close 0
> lingering_time  0
> keepalive       1
> $20 = 0x46d7a7 <ngx_http_upstream_rd_check_broken_connection>
> $21 = 0x470f3b <ngx_http_upstream_process_downstream>
> $22 = 0x4b79fa "reading upstream"
> status  200
> count   1
> blocked 0
> sent    33580
> length  -1
> Cannot access memory at address 0x0
> 
> (gdb) qq 35
> $23 = {len = 26, data = 0x801d33c64 "/bla/bla/archive2.zip"}
> $24 = {len = 46, data = 0x801852400 "GET /1d5859a513539b9b412d534212728832
> HTTP/1.1\r\nUser-Agent"}
> discard_body    0
> lingering_close 0
> lingering_time  0
> keepalive       1
> $25 = 0x459b5b <ngx_http_test_reading>
> $26 = 0x4596ac <ngx_http_writer>
> $27 = 0x0
> status  206
> count   1
> blocked 0
> sent    242367
> length  -1
> Cannot access memory at address 0x0
> 
> Смена версии ОС с 8.0 на 8.1/8.2, как собссно и обновление nginx с 0.8.x до
> 1.0.x не дает результата
> За сутки количество writing соединений зашкаливает на 20-30тыс, хотя сутя по
> netstat таковых не более тысячи
> 
> Подскажите пожалуйста, куда дальше копать и что смотреть?

Для начала покажите строки логов и имена корок, а также вывод

set $c = &ngx_cycle->connections[456]
p $c->log->connection
p *$c
set $r = (ngx_http_request_t *) $c->data
p *$r

в gdb, где 456 - номер соединения из строки лога про "open socket 
#123 left in connection 456".

Но скорее всего это ситуацию не прояснит, и нужен будет debug log 
для соответствующих запросов.  Т.е. включать debug log и 
"debug_points abort;", после появления сокетов в состоянии CLOSED 
делать reload (можно - выключив debug log), потом получать в gdb 
идентификатор соединения и смотреть логи.

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru