The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Эксперименты по борьбе с утечками памяти Telegram Desktop
Известны жалобы о больших утечках памяти в Telegram Desktop на Linux, не
наблюдаемых в таких же объемах на других ОС, в частности Windows и FreeBSD. В
рамках проверки гипотезы о том, что дело в реализации системного аллокатора и
настройках автопроигрывания медиа, помогающие автору TDesktop энтузиасты
создали канал https://t.me/tdesktop_crash, продолжительная прокрутка которого
должна приводить к утечкам памяти. При этом при нормальном поведении закрытие
этого окна (переключение на другой чат) должна освобождать память.

Выяснилось, что на Windows при переключении чата память освобождается, на
обычном Linux glibc - не освобождаются несколько Гб, но происходит почти полное
освобождение через некоторое время, если запустить Telegram Desktop с
аллокатором jemalloc из FreeBSD (пример для Debian, подробности
см. в документации jemalloc):

  LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 telegram-desktop

Аналогичные (или даже лучше) результаты были получены на дистрибутивах без
glibc, например Alpine, где применяется musl.

Поскольку в разных дистрибутивах могут быть разные политики по сборке
(статически и без), и майнтейнеры могут испытывать проблемы с включением
решения, а современные аллокаторы сложны, и, возможно, glibc malloc может быть
соответствующим образом настроен, к экспериментам и помощи приглашаются знатоки.
 
13.05.2021 , Автор: nuclight , Источник: https://t.me/tdesktop_crash...
Ключи: telegram, memory, debug
Раздел:    Корень / Администратору / Система / Linux специфика / Оптимизация и тюнинг в Linux

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Аноним (1), 00:16, 14/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-то я не понял - проблема в glibc или в Telegram?
     
     
  • 2.2, Аноним (2), 05:12, 14/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В телеграм конечно же проблема, пусть его разработчики чинят, но им пофиг
     
     
  • 3.4, nuclight (??), 20:15, 14/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В glibc конечно же. Переменная окружения MALLOC_MMAP_THRESHOLD_=128 вроде более лучшие результаты выдает.
     
     
  • 4.5, slepnoga (??), 13:20, 15/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Течет телега, а виноват глибц.
    Естественно, ведь телега это.
     
     
  • 5.7, nuclight (??), 10:04, 16/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Так у меня на фре нет glibc, и телега не течёт, например.
     
     
  • 6.14, Аноним (14), 22:22, 18/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    У меня такая же нога и не болит.
     

  • 1.3, Аноним (3), 10:03, 14/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    см malloc_trim()
     
  • 1.6, PedeRust (?), 20:57, 15/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    glibc срочно на расте переписать, иначе пользоваться этим заскорузлым говном невозможно
     
     
  • 2.28, макпыф (ok), 13:42, 25/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    надеюсь вы шутите
     
  • 2.67, Shshsh (?), 08:36, 05/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В Rust'е алокатор ещё хуже работает, если что.
     

  • 1.8, Аноним (8), 21:10, 16/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучше сменить мессенджер. Толку помогать разработчикам телеги если им самим плевать на свой мессенджер. Я уже не говорю о сливах, привязки с номеру, отсутствия реальной приватности, закрытых серверах и никакой противодействии блокировкам (заставить пользовтелей использовать vpn это не заслуга телеграма, а телеграм прокси это профанация отслеживаемая по щелчку пальцев (т.е. даже вреднее чем ее отсутствие)) и тд и тп.
     
     
  • 2.9, Аноним (1), 23:35, 16/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А что вместо? Signal? Matrix?
     
     
  • 3.10, отвечатель (?), 00:28, 17/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    сигнал - гораздо более безопасный месенджер
     
     
  • 4.15, Аноним (15), 23:14, 19/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, в котором на Андроиде даже нельзя зарегаться без Google Apps.
     
     
  • 5.25, Аноним (25), 17:13, 23/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    И, внезапно, без номера телефона
     
     
  • 6.37, незнаю (?), 22:08, 29/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Этот номер еще и нельзя скрыть, насколько помню. И правда безопасный.
     
  • 3.12, КО (?), 17:47, 17/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients
    Вон Jitsi твой телефон не нужен
     
     
  • 4.13, Аноним (1), 18:20, 17/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Matrix (Element) тоже не нужен, но он вроде как пофункциональнее будет.
     
  • 3.43, Мяукающий Котик (?), 14:57, 08/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Discord. Номер телефона не нужен. Можно включить нормальную двухфакторку с одноразовыми кодами. Доступа к контактам не требует. Если никуда не выкладывать ссылку на сервер (или вообще не создавать ссылку), то его невозможно найти. Удобная организация любого количества каналов и их групп в рамках одного сервера (вместо кучи различных чатов, как в других мессенджерах)
     
     
  • 4.44, rem (??), 11:45, 10/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    а еще он на модном электроне, который не умеет под вяленого, зато умеет жрать 300 мегов рамы
     
  • 4.51, sage (??), 14:32, 14/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Discord часто требует номер телефона.
     
     
  • 5.54, Мяукающий Котик (?), 17:32, 14/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Discord часто требует номер телефона.

    Не требует, а всего лишь предлагает один раз ввести. От этого можно отказаться

     
     
  • 6.61, sage (??), 15:19, 28/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    От этого нельзя отказаться, он перестаёт работать, пока не введёшь и не подтвердишь через СМС.
     
  • 4.66, Капитан (??), 12:48, 15/07/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Уже бы сразу товарищу майору сообщения отправлял.
    spyware.neocities.org/articles/discord.html
     
  • 3.48, Аноним (48), 00:13, 11/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Matrix его используют уже много где, в том числе как правительственный месенджер во франции.
     
  • 3.72, develop7 (ok), 14:25, 08/11/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Threema не нужен ни телефон, ни email. Jami (ex-Ring) тоже.
     
  • 2.27, Аноним (27), 11:58, 24/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А вместе с мессенджером поменять круг общения, да? А если я не хочу и меня устраивают эти родители и жена?
     
     
  • 3.55, Аноним (55), 04:12, 15/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Поменяйте только клиент. Есть opensource клиенты.
    Plus Messenger на Андроид даже более функциональный, чем оффициальный.
     

  • 1.11, Аноним (11), 08:51, 17/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >но происходит почти полное освобождение через некоторое время, если запустить Telegram Desktop с аллокатором jemalloc из FreeBSD

    Firefox использует jemalloc, однако на Винде не текёт (вернее память жрёт, но не крешится), а на Линуксе текёт (жрёт память, при этом ещё и крешится). Вообще на Линуксе программы почему-то крешатся по памяти. Видимо СПО - говно:

    >современные аллокаторы сложны

    ... и требуют инвестиций в разработку и отладку, которые по карману только крупным корпорациями вроде Microsoft и Apple, которые своими know how бесплатно не поделятся.

     
     
  • 2.16, Crazy Alex (ok), 12:25, 20/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Видимо ты тролль
     
     
  • 3.30, Аноним (30), 18:47, 25/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Видимо ты тролль

    Вдимо нет.

     
  • 3.41, yourc (?), 18:05, 30/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Видимо ты тролль

    Это пох, здешний виндузятник. Здорово тралит новую волну линуксоидов) Скиллы эникейские, но умеет притворяться щарящим, чем люто доставляет. Енжой.

     
     
  • 4.59, Michael Shigorin (ok), 22:10, 24/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Чадо, тот "пох", который тут оригинальный -- он тролль ещё тот, да только вот не ребёнку, который глазки смайликам выкалывает, про старпёрские m4d sk1llz рассусоливать.  В отличие от нас с Вами он наверняка способен и аллокатор написать (я знаю, что это за человек).
     
  • 2.36, nuclight (??), 18:48, 29/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Firefox использует jemalloc, однако на Винде не текёт (вернее память жрёт, но
    > не крешится), а на Линуксе текёт (жрёт память, при этом ещё
    > и крешится). Вообще на Линуксе программы почему-то крешатся по памяти. Видимо
    > СПО - говно:

    Здесь надо уточнять, какой версии jemalloc. Была выявлена регрессия https://github.com/jemalloc/jemalloc/issues/2069 - с предыдущей версией jemalloc (4) телега не течет, со свежей (5) течет.

     

  • 1.17, timur.davletshin (ok), 08:38, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё бы классно, но jemalloc на холодном старте заметно более прожорлив, чем умолчальный аллокатор в относительно новых версиях glibc (имя ему pmalloc2, если память не врёт). Раньше был смысл в таких телодвижениях, т.к. jemalloc был более производителен на SMP, но сейчас разница производительности нивелирована (с 2.26 версии). Лично у меня на разница в потреблении памяти на Debian 10 достигает 40-50% не в пользу jemalloc на холодном старте, но через какое-то время падает, но тоже не в пользу jemalloc. Увы.
     
     
  • 2.35, nuclight (??), 18:47, 29/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Здесь надо уточнять, какой версии jemalloc. Была выявлена регрессия https://github.com/jemalloc/jemalloc/issues/2069 - с предыдущей версией jemalloc телега не течет, со свежей течет.
     

  • 1.18, YAAnonim (?), 18:30, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Читать документацию пробовали? То что он ее сразу не освобождает не значит что она не доступна для выделения (для процесса освобожденная память помечается свободной для выделения). Это не утечка - это ленивое освобождение.
     
     
  • 2.21, Аноним (21), 10:36, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Для выделение каким процессом? В каком количестве? Твоя диванная экспертиза делает мне смешно.
     
     
  • 3.24, Аноним (24), 02:15, 23/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Предыдущий оратор наверно имел ввиду то, что освобождённая память в процессе в большинстве случаев доступна для повторного выделения внутри процесса. Конечно при условии, что выделенные "чанки" не на столько малы, что могут быть переиспользованы крайне редко и "зависают" во фрагментированном хипе. Тогда это можно считать утечкой, в чем косвенно виновата и сама программа, а не только глибц, так как не учитывает этот момент и выделяет по 3 байта маллоком.
     

  • 1.19, Аноним (24), 21:06, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    У нас в этих наших линуксах всё так "течёт".

    Нужно понимать как работает malloc. При выделение памяти маллоком, выделает её не ядро, а выделяет реализация маллок из glibc, а если памяти уже выделенной в процесс не достаточно, то глбиц просит ещё отсыпать у ядра. Но при освобождении не возвращает ядру по разным причинам(в многом виновата фрагментация памяти внутри процесса)

     
     
  • 2.22, Аноним (1), 18:04, 22/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    "Что течёт? — Всё течёт!" (из к/ф "Глубже!")

    Так течёт или не течёт?

     
     
  • 3.23, Аноним (24), 02:10, 23/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Да, и вина всему частые мелкие аллокации скриптовых языков, на коих всё понаписано, что kde, что gnome.
     
  • 2.32, X86 (ok), 14:01, 27/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Значит просто нужно больше памяти
     

  • 1.20, Аноним (20), 21:23, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    "Фрагментация памяти", слышали про такое?
     
     
  • 2.26, Ан (??), 10:58, 24/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    нет а что это?
     
  • 2.31, acroobat (ok), 11:28, 26/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    tmpfs?
     
  • 2.42, anonymous (??), 12:45, 06/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее всего фрагментация.

    Делаем несколько мелких аллокаций подряд, занимаем непрерывный кусок в куче malloc().
    Потом делаем free() на все аллокации, кроме последней. Реализация malloc/free в glibc не вызовет munmap(), если последний чанк помечен как non-free. Это несмотря на то, что уже освобожденные куски оставляют неиспользованными целые страницы, на которые можно вызвать munmap().  

    Проблема заметна в долго выполняющихся программах на C++: браузеры, мессенджеры и т.д.
    В Firefox не просто так поменяли аллокатор из glibc на jemalloc.

     
     
  • 3.46, pavlinux (ok), 22:17, 10/06/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Скорее всего фрагментация.
    > Делаем несколько мелких аллокаций подряд, занимаем непрерывный кусок в куче malloc().
    > Потом делаем free() на все аллокации, кроме последней. Реализация malloc/free в glibc
    > не вызовет munmap(), если последний чанк помечен как non-free.

    Спецом от anonymous пишите, чтоб не позориться от этого бреда?

    Какая пля куча malloc?  :рукалицо:  
    Сколько malloc(), столько же и free(), нет никакой кучи malloc  


    > Это несмотря на то, что уже освобожденные куски оставляют неиспользованными целые страницы,  
    > на которые можно вызвать munmap().

    Чo? освобожденные и неиспользованные это одно и тоже, unmap на них приведет к double free;

    Хватить пиз....олить, тиоретеги... Где отладка с valgring, duma, mtrace, tcmalloc, heaptrack,...  

     
     
  • 4.50, anonymous (??), 14:27, 14/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Какая пля куча malloc?  :рукалицо:
    > Сколько malloc(), столько же и free(), нет никакой кучи malloc  

    heap.

    Изучите, как устроен аллокатор в glibc (искать по словам ptmalloc, dlmalloc) и еще раз внимательно перечитайте сообщение выше.

    > освобожденные и неиспользованные это одно и тоже, unmap на них приведет к double free;

    Идите учить матчасть. free() в glibc не всегда приводит к munmap().

     
  • 4.56, Аноним (56), 18:00, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда хотел поумничать, но в результате обделался
     
     
  • 5.57, anonymous (??), 21:43, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда хотел поумничать, но в результате обделался

    Минуты позора спасают годы жизни (c)

    Проблема с фрагментацией кучи в аллокаторе glibc известна как минимум 20 лет как.
    Частично решается применением специализированных аллокаторов типа tcmalloc, jemalloc в специфическом софте.

     

  • 1.45, pavlinux (ok), 15:38, 10/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Блин, посаны..., исходники всего этого добра доступны, какого ..уя вы целый месяц соплю жуёте?
    Гадают, бзд/жлибс/телега... Не можете отловить мямлика?
     
     
  • 2.60, Michael Shigorin (ok), 22:15, 24/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Блин, посаны..., исходники всего этого добра доступны,
    > какого ..уя вы целый месяц соплю жуёте?

    Ну спросите начальство, вдруг благоволят выделить рабочего времени на отладку/отлов/исправление проблемы и запихивание патча в апстрим ;-)  Это ж целое достижение будет.

     

  • 1.47, pavlinux (ok), 22:39, 10/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Сцк, пля, этот так сложно было?

    $ heaptrack /opt/Telegram/Telegram.exec
    heaptrack output will be written to "/tmp/heaptrack/heaptrack.Telegram.exec.20713.zst"

    heaptrack stats:
    allocations:           4368434
    leaked allocations:   15823
    temporary allocations: 470613
    Heaptrack finished! Now run the following to investigate the data:

    $ heaptrack --analyze "/tmp/heaptrack/heaptrack.Telegram.exec.20713.zst"


    total runtime: 142.65s.
    bytes allocated in total (ignoring deallocations): 7.04GB (49.39MB/s)
    calls to allocation functions: 4368434 (30623/s)
    temporary memory allocations: 482100 (3379/s)
    peak heap memory consumption: 1.58GB
    peak RSS (including heaptrack overhead): 21.56GB
    total memory leaked: 10.09MB


    https://pastebin.pl/view/c64c21a1

    15000 протеканий!!! Glibc виноват, конэшн.

     
     
  • 2.49, Аноним (1), 10:33, 12/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А если то же самое, но с MALLOC_MMAP_THRESHOLD_=128?
     
     
  • 3.53, anonymous (??), 14:50, 14/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > А если то же самое, но с MALLOC_MMAP_THRESHOLD_=128?

    Будет на любую аллокацию > 128B делать mmap() новой страницы, оверхед в (размер страницы / 128) раз. RSS распухнет в десятки раз, но после free() память будет возвращаться через munmap().

    Есть аллокаторы (например, openbsd malloc), в которых для аллокаций данного размера создаются отдельные кучи через mmap(), и при вызове free() на все аллокации, размещенные в данной странице, немедленно вызывается munmap().

     
  • 2.52, anonymous (??), 14:35, 14/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > peak heap memory consumption: 1.58GB
    > peak RSS (including heaptrack overhead): 21.56GB
    > total memory leaked: 10.09MB

    А теперь сравните реальные утечки 10.09MB с peak heap memory consumption = 1.58G
    и внимательно перечитайте текст новости:

    > Выяснилось, что на Windows при переключении чата память освобождается, на
    > обычном Linux glibc - не освобождаются несколько Гб, но происходит почти полное
    > освобождение через некоторое время, если запустить Telegram Desktop с
    > аллокатором jemalloc из FreeBSD ...
    > ...
    > Аналогичные (или даже лучше) результаты были получены на дистрибутивах без
    > glibc, например Alpine, где применяется musl.

     

  • 1.58, Федор Михалыч (?), 14:35, 24/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    в винде тоже падает хорошо
     
     
  • 2.62, нворд (?), 15:15, 29/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Зато жрёт меньше.
    А под линем жрёт больше но гораздо меньше падает.
     

  • 1.63, Аноним (63), 16:25, 12/07/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эксперименты по борьбе... результатов не дали.
     
     
  • 2.64, ilyafedin (ok), 23:07, 14/07/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Почему нет, в 2.8 прицепили кастомный аллокатор, теперь нормально работает
     

  • 1.70, Аноним (70), 01:05, 09/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    hardened_malloc
    https://github.com/GrapheneOS/hardened_malloc
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру