Comments 8
А с чего вся история начиналась? С жалоб пользователей на тормоза и зависания?
Или это “хроническая болезнь”, и требуется постоянно отслеживать ситуацию, и невозможно построить архитектуру которая исключает проблему утечек памяти?
Тормозов и зависаний нет из за нехватки памяти т.к. свапа нет (чтобы флешка не деградировала). Так что память кончилась = сразу смерть процесса. Следим за лимитами чтобы этого не допускать.
То что болело больше всего - рост потребления в релизах и поиск из за каких изменений это случилось. Именно утечки это редкость. Чаще - просто какой то новый код, который увеличивает потребление.
Ежедневно мы собираем и анализируем memory‑дампы с миллионов колонок
Вам бы сразу расписать, что здесь конкретно имеется ввиду под memory-дампом, - а то ж растаскают по цитатам.
Я таки извиняюсь, а юзерам за тестирование нет ли желания как‑то подкинуть оплату, в той или иной форме? Как ни крути, но это аренда железа (пусть и слабенького — правда, выбирал‑то не юзер, а продавец, так что, когда юзер за многоденег покупает колонку, он думает, что она и тормозить не станет, и глючить не будет, и утечек памяти и прочей ереси ему не достанется), и железа уже юзерского.
Доводы «мы же юзерам делаем лучше», сами понимаете, отводятся одной фразой «это юзеры, так и быть, вашу недоделанную софтину вынуждены юзать, хотя вы, по совести, должны были дать им не глюкало, а полностью работающий код.»
Ну и да, а кто‑то за выбор железа отвечает? Про сбои в работе Алисы даже не спрашиваю (ночью, тихо, в детскую комнату захожу, когда ребенок спит, и говорю "детской" колонке - "Алиса, поставь будильник на 7 утра!" - Алиса, шепетом "Хорошо" - дальше, шепотом же - "Алиса, какая завтра будет погода?" - Алиса, резко на обычной громкости, начинает вещать про погоду)...
Есть нюанс, про который нельзя забывать: пока jemalloc делает дамп, все аллокации в процессе блокируются. У нас эта пауза — 3 мс в среднем и 25 мс на 99,9-м перцентиле (по всем моделям). Цифры небольшие, потому что и дампы небольшие из‑за нашего параметра семплирования в 1 МБ. Для пользователя такое подвисание незаметно.
...
Главный вывод простой: профилировать C++ в проде на миллионах устройств — реально, полезно и не требует заметных ресурсов.
Честно говоря, требуются ли заметные ресурсы или нет кмк мы до конца не поняли - 25мс при записи дампа кмк не жалко, но вот насколько замедляется работа колонки при включенном профилировании?
Здравствуйте!
По нашим замерам, увеличение нагрузки на ЦПУ не больше чем 1% в финальной схеме. Это незаметно. При чём тут нагрузка не сколько за счёт самого по себе профилирования (с семплированием 1МБ оно практически незаметно), но больше за счёт "зажатых" настроек аллокатора (1 арена без thread cache, чтобы по памяти не проиграть - она нам важнее).
Борьба с последствиями, а не болезнью. Использовать RAII как основу не судьба? Если бы начинали как я, когда у тебя вообще нет памяти и ценен каждый байт, каждый регистр, то не разбрасывались мегабайтами. Всего-то надо заставить себя писать программы правильно. А на C++ идиома разработки ПО RAII это база. Иначе надо менять таких разработчиков на ИИ, он сразу так пишет.
Куда уходит память? Семплирующее профилирование колонок с Алисой в проде