On Wed, Aug 29, 2007 at 10:24:16AM +0400, Alexey Rymonin wrote:
> Hello Igor,
>
> Wednesday, August 29, 2007, 12:59:46 AM, you wrote:
>
> >> Я могу поставить на них nginx и запустить стрес тест на всех трех
> >> вресиях ядра... Сэмулировать нагрузку превышающую текущую, на мелких
> >> файлах, тостых файлах, нот фаундах, форбиденах и больших клиенских
> >> запросах (чтобы в буфер не влезал)... если эта ошибка ядра, то скорее
> >> всего рано или поздно
> >> она повториться...
>
> > Это было бы интересно при включённом отладочном логе. Его можно вращать
> > раз в минуту.
>
> Я так и сделаю... поскольку на отладочный лог было бы очень интересно
> посмотреть...
> Игорь... у меня на этом же сервере в качестве MTA стоит Exim, который
> под соляркой также юзает /dev/poll. И он работает без нареканий с тех пор как
> сервак
> запустили... Странно это, поскольку если бы это был баг ядра, он бы
> тоже должен бы писать хоть что-то....
Это зависит от того, как обрабатывать. Я, наверное, сделаю там проверку
на NULL и буду писать в лог о таких случаях.
> Игорь, у меня к вам еще два вопроса есть:
> 1) А методы работы с событием(сокетом) синхронизированные?
> Не может ли появиться событие на сокет пока идет код его удаления из
> пула, встать в очередь и сразуже по окончанию процедцры вернуться и
> вызвать падение? Это бы объясняло редкость возникновения баги....
В nginx'е передача событий в ядро делается пачками, ровно перед получением
пачки готовых событий. Но при закрытии сокета вся накопивашая пачка
сразу скидывается в /dev/poll, а потом закрывается сокет.
После удаления события из ядра оно не должно приходить.
Если же оно приходит, то это race condition в ядре.
> 2) Игорь, а что такое DP_ISPOLLED?
>
Способ узнать, зарегистрирован ли дескриптор в /dev/poll.
Для программ типа nginx'а его использование бессмысленно, так как nginx
ведёт собственный учёт. Скорее всего, он предназначен для библиотек,
когда проще сходить в ядро, перед тем, как добавить события, чем вести
собственный учёт.
Кстати, в вышеупомянутой проверке на NULL я буду вызывать DP_ISPOLLED,
чтобы проверить, дейстивтельно ядро считает, что дескрптор ещё присутствует
в /dev/poll, или же это фантомные события, оставшиеся после удаления.
> Ну а я пока соберу с дебагом, и будем ждать еще одну корку... я
> думаю что тогда станет уже совершенно понятно...
>
> > p *ngx_cycle->files[28]
> (dbx) p *ngx_cycle->files[28]
> dbx: reference through nil pointer
Это выглядит старнно в сочетании с предыдущим удалением:
(dbx) p change_list[0]
change_list[0] = {
fd = 28
events = 2048
revents = 0
}
и приходом событий для этого удалённого дескриптора:
(dbx) p event_list[0]
event_list[0] = {
fd = 28
events = 1
revents = 1
}
По идее nginx, должен быть уже упасть на 28.
--
Игорь Сысоев
