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-leave@nginx.org