необходимо броадкастить сообщение. Как только приходит клиент, я создаю нового ресивера на броадкасте, далее жду сообщений с броадкаста. Проблема в том, что оно течёт. При отключении клиента от сокета приложение всё так же холдит память и не хочет отдавать обратно вплоть до сегфолта. Аллокатор - jemalloc с максимально агрессивным конфигом. И, судя по-всему, течёт броадкаст. Из зависимостей - токио 1.11, tokio-tungstenite 0.15. Вопрос: что я делаю не так (пример) ? Если кто-нибудь даст наводку, буду очень признателен. Пример, который течёт - https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=14c08055f0d64da0b1243b26ee080284
Насколько сильно течёт? И что значит "не хочет отдавать вплоть до сегфолта"? ООМ киллер убивает или что? На первый взгляд единственное место, которое может течь - это спавн accept_connection. Эти таски точно завершаются? Если TCP соединение не закрыто нормальным образом, оно может долго висеть.
ООМ киллер убивает, да. Каждый коннекшн отъедает порядка 50кб резидент мемори. Проблема еще в том, что тут нет возможности напрямую закрыть tcp-коннекшн =| (ну или я в глаза долблюсь). Сейчас перетестил. И правда, проблема не в броадкасте. Наверное, легче и правда использовать вебсокет из актикса.
спрошу из академического интереса: разве не память ядра при незакрытых соеднинениях будет расти? OOM киллер же не придет убивать ядро 😂
Закрыть tcp можно через .get_mut().shutdown().await; (shutdown из AsyncWriteExt)
Забавно. Если обычным сигинтом закрыть клиента (или вкладочку в браузере) без Message::Close, то возвращает ошибку и точно так же течёт. code: 107, kind: NotConnected, message: "Transport endpoint is not connected"
.set_linger(None) сделать. Чтобы не держал неотосланные данные после shutdown. Может быть с write_timeout поиграться.
Спасибо большое! Посмотрю, что из этого выйдет.
Обсуждают сегодня