On 26.07.2022 0:34, Maxim Dounin wrote:
>> 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] - ничего ведь не сломается?
Почему же Вы этого не хочете или не можете сделать? Ведь это не сложно.
По конкретному тикету есть несколько моментов:
- Перед тем, как менять уровень логгирования - надо как минимум
проверить, что в случае невозможности выделения памяти для сессии
действительно ничего не ломается.
- А ещё неплохо бы сесть и внимательно посмотреть, не имеет ли
смысла изменить логику удаления старых сессий в случае нехватки
памяти, чтобы ошибок не возникало. Или даже переделать логику
выделения памяти под сессии, дабы минимизировать вероятность
неуспеха. Или прикрутить логику, аналогичную реализованной для
памяти под элементы кэша (http://hg.nginx.org/nginx/rev/c9d680b00744).
Если не будет в логах ошибок - каким образом тогда пользователь
сможет понять, что размер кэша для сессий SSL слишком маленький?
Может же быть так, что установлен размер кэша для примерно 4000 сессий,
а активных клиентов будет примерно в десять раз больше - в этом случае
nginx будет постоянно удалять "старые" сессии, ничего при этом в логах
не сообщая пользователю. Наверное это не самый лучший вариант поведения?
Или наоборот, когда выставлен очень большой размер для кэша сессий SSL,
а используется не более 10% - это тоже неоптимальная настройка nginx.
Пользователи nginx-plus наверное смогут установить на свои сервера
nginx-amplify-agent и возможно смогут увидеть в NGINX Amplify,
что кэш для сессий SSL переполнен и его следует увеличить. (?)
Но что в таком случае делать пользователям open source версии nginx?
Насколько я понимаю, в NGINX Amplify для open source версии nginx
метрик для кэша сессий SSL нет.
Особенно, если пользователи nginx используют Rocky Linux 8.6,
при запуске скрипта install.sh выдается такое сообщение про ошибку:
Checking OS compatibility ... rocky is currently unsupported, apologies!
Хотя по своей сути Rocky Linux 8.6 ведь ничем не отличается от RHEL 8.6.
Это же 1:1 бинарно совместимая с RHEL8 сборка EL8 из тех же исходников.
Если вручную прописать в файле /etc/yum.repos.d/nginx-amplify.repo
[nginx-amplify]
name=nginx amplify repo
baseurl=http://packages.amplify.nginx.com/py3/rhel/8/$basearch
gpgcheck=1
enabled=1
В таком случае NGINX Amplify Agent нормально устанавливается
на Rocky Linux 8.6 и даже нормально запускается.
Этот список рассылки, nginx-ru наверное не очень подходит
для обсуждения NGINX Amplify Agent и NGINX Amplify?
Куда лучше всего будет писать bug reports и feature requests
по NGINX Amplify Agent и NGINX Amplify, напрямую емейлом разработчикам?
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org
