вт, 26 июл. 2022 г. в 02:35, Maxim Dounin <mdou...@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-le...@nginx.org >
_______________________________________________ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org