Всем привет! Скажите, никто не пытался уменьшить размер процесса ssl,

которые ассоциируется с открытым соединением (не помню точное название этого процесса, но там была какая-то реализация gen_statem)? Сам процесс хранит в своем состоянии сертификат сервера, приватный ключ сертификата и цепочку сертификатов УЦ. В итоге получается около 100-150 Кб данных в состоянии процесса. Если таких процессов сотни тысяч, получается немало.
Я находил информацию о том, что если в настройках приложения ssl указывать ссылку на файл сертификата и на файл с приватным ключом сертификата, то ssl хранит сами файлы в ets, а в состоянии процесса хранит только ссылку. Я так пробовал, но в состоянии процесса все равно хранится и ссылка на файлы и сам сертификат с приватным ключом.
Никто такую задачу не решал, не пытался уменьшить размер состояния процесса-соединения в ssl?

бинари копируются в/из ets, не очень понятно, как это уменьшит потребление памяти, потому что в моменте сотни тысяч процессов будут иметь свою копию данных

+1 к сборке мусора (для начала) 45> erlang:process_info(<0.549.0>, memory). {memory,197560} 46> erlang:garbage_collect(<0.549.0>). true 47> erlang:process_info(<0.549.0>, memory). {memory,122680}

есть опция к сокету HibernateAfter = maps:get(hibernate_after, SSLOpts, infinity),

Почитаю, спасибо!

а вообще не очень понятны условия, в которых это становится проблемой. 10000 сокетов по 150КБ — это всего 1.5 ГБ, что не выглядит ужасом.

Если у тебя сервер на 2 гигабайта это проблема

мне гораздо интереснее реальные условия автора вопроса, а не домыслы

Да я просто пошутил, эх...

Условия сложно раскрыть. В целом ситуация такая, есть long polling сервер, к которому подключаются 100.000 клиентов. Чисто на подключение уходит 11 Гб + еще будет уходить сколько-то Гб на на саму работу в рамках подключения. Поэтому хотелось бы уменьшить эти 11 Гб, потому что 11 Гб просто на открытие соединения выглядит объемно. Удалось раскрыть условия?

да, это понятная задача. Ну и в целом да, hibernate или ужесточение GC (глобально или в receiver_spawn_opts) — низковисящие фрукты

Да, 100.000 клиентов - это начальная цифра. Самих клиентов в пределе будет больше в несколько раз

где-то в issues otp на гитхабе поднималась тема ssl и потребления памяти. рекомендую поиском пройтись

Спасибо, на receiver_spawn_opts тоже посмотрю

Попробую

и открытый есть на тему сертов https://github.com/erlang/otp/issues/8598

То есть язык и архитектура, которые де-факто слывут лучшими в мире распределенных и параллельных систем имеют проблемы с SSL?! 👀

Слишком толсто. Меня всё устраивает. А если б не устраивало, починил бы сам

В последних версиях переключились на третью версию опенссл, перелопатили стек и до сих пор что-то допиливают/улучшают. Так что некоторые проблемы есть, но они решаются.

Ни на что не намекал, просто в удивлении.

Нет там потребления 1.5гб на 1000 соединений - это виртуальное потребление, на деле почти все данные расшарены и процесс потребляет на порядки меньше (ну или только в пике, до первого gc). И то, что указали выше - сделать hibernate_after - это не костыль. Просто тут торговля - или всё в памяти и кэшах, чтобы быстро, или компактится для уменьшения потребления. У человека юзкейс - долгоживущие малоактивные процессы, так что просто флажок надо выставить и всё будет хорошо. Ну и люди в чате тоже правильно говорят - а ты думаешь в других серверах будет лучше? Здесь то избыточное потребление озу из за того, что каждый процесс изолирован, можно и без изоляции - а потом смотреть кордампы, когда ssl что-то там не осилил и все возможные секьюр ищьюсы с чтением за пределами памяти и коррамтами памяти, утечками и вот это всё.