Error log question

[Илья Шипицин]

вт, 26 июл. 2022 г. в 02:35, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Mon, Jul 25, 2022 at 11:05:56AM +0300, Gena Makhomed wrote:
>
> > On 24.07.2022 1:15, Maxim Dounin wrote:
> >
> >  >> My nginx error log is being filled with errors which I believe are
> being
> >  >> surfaced from OpenSSL. The log entries number in the hundreds of
> >  >> thousands per day and I understand they are most likely due to
> >  >> conditions beyond my control. Examples of the log entries are:
> >
> > [...]
> >
> >  >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not
> allocate
> >  >> new session in SSL session shared cache "le_nginx_SSL" while SSL
> >  >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443
> >  >
> >  > This error indicate that nginx wasn't able to allocate new session
> >  > in the SSL session cache defined by the "ssl_session_cache"
> >  > directive, and removing an old session didn't help.  This
> >  > basically indicate that the SSL session cache is too small, and it
> >  > would be a good idea to either configure a larger cache or reduce
> >  > ssl_session_timeout.  The logging level is probably a bit too
> >  > scary, see https://trac.nginx.org/nginx/ticket/621 for details.
> >
> > Максим, Вы говорите, что "The message is probably a bit too scary
> > (while the situation itself is mostly harmless)".
> >
> > Тикету https://trac.nginx.org/nginx/ticket/621 уже 8 лет.
> >
> > Разве не проще один раз пофиксить эту проблему в исходниках nginx,
> > чем постоянно рассказывать пользователям в списках рассылки о том,
> > что "The logging level is probably a bit too scary"?
> >
> > Если просто поменять [alert] на [warn] - ничего ведь не сломается?
> > Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно.
>
> По конкретному тикету есть несколько моментов:
>
> - Перед тем, как менять уровень логгирования - надо как минимум
>   проверить, что в случае невозможности выделения памяти для сессии
>   действительно ничего не ломается.
>

можно, наверное, поменять alert на warn, а потом еще лет 8 исследовать
описанные моменты, которые действительно требуют время


>
> - А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли
>   смысла изменить логику удаления старых сессий в случае нехватки
>   памяти, чтобы ошибок не возникало.  Или даже переделать логику
>   выделения памяти под сессии, дабы минимизировать вероятность
>   неуспеха.  Или прикрутить логику, аналогичную реализованной для
>   памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744).
>
> Всё это требует времени, которое конечно.
>
> Кроме того, "постоянно рассказывать" - на моей памяти примерно
> первый раз за прошедшие с момента появления этого тикета 8 лет.
> То есть проблемы, фактически, нет.
>
> > Сейчас в nginx trac открыто 263 тикета
> > https://trac.nginx.org/nginx/report/1
> > разве не было бы логично уменьшить их количество
> > до минимально возможного числа, в идеале - до нуля?
>
> Было бы логично, конечно.  Лично я регулярно занимаюсь тем, что
> уменьшаю количество открытых тикетов.  Открытых тикетов про
> проблемы в коде сейчас - 70 штук, большую часть просто так не
> закрыть.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list -- nginx-ru на nginx.org
> To unsubscribe send an email to nginx-ru-leave на nginx.org
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20220726/52fc54ac/attachment.htm>