The OpenNET Project / Index page

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

Эксперименты по борьбе с утечками памяти 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 его используют уже много где, в том числе как правительственный месенджер во франции.
     
  • 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:   [b]15823[/b]
    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 [b]glibc - не освобождаются несколько Гб[/b], но происходит почти полное
    > освобождение через некоторое время, если запустить 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.68, Аноним (68), 19:26, 15/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Телеграм владеет Дуров, данные которого имеет наша власть.

    Не пользуйтесь!

    1) Russia is a mafia state
    2) Putler is its God father who owns the police, the army, the judicial system and most government authorities literally and figuratively
    3) He and his party have been cheating at elections for the past 15 years
    4) There have been attempts to make elections legitimate by introducing "Smart voting" - now Putler's asslickers have found a way to thwart even this

    This country is dead because it's thoroughly corrupted. Pretty much everyone in the government with a modicum of power is stealing one way or another.

     


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




    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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