1.8, Аноним (8), 21:10, 16/05/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
Лучше сменить мессенджер. Толку помогать разработчикам телеги если им самим плевать на свой мессенджер. Я уже не говорю о сливах, привязки с номеру, отсутствия реальной приватности, закрытых серверах и никакой противодействии блокировкам (заставить пользовтелей использовать vpn это не заслуга телеграма, а телеграм прокси это профанация отслеживаемая по щелчку пальцев (т.е. даже вреднее чем ее отсутствие)) и тд и тп.
| |
|
|
3.43, Мяукающий Котик (?), 14:57, 08/06/2021 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
Discord. Номер телефона не нужен. Можно включить нормальную двухфакторку с одноразовыми кодами. Доступа к контактам не требует. Если никуда не выкладывать ссылку на сервер (или вообще не создавать ссылку), то его невозможно найти. Удобная организация любого количества каналов и их групп в рамках одного сервера (вместо кучи различных чатов, как в других мессенджерах)
| |
|
|
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 бесплатно не поделятся.
| |
|
|
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. Увы.
| |
1.18, YAAnonim (?), 18:30, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
Читать документацию пробовали? То что он ее сразу не освобождает не значит что она не доступна для выделения (для процесса освобожденная память помечается свободной для выделения). Это не утечка - это ленивое освобождение.
| |
|
|
3.24, Аноним (24), 02:15, 23/05/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Предыдущий оратор наверно имел ввиду то, что освобождённая память в процессе в большинстве случаев доступна для повторного выделения внутри процесса. Конечно при условии, что выделенные "чанки" не на столько малы, что могут быть переиспользованы крайне редко и "зависают" во фрагментированном хипе. Тогда это можно считать утечкой, в чем косвенно виновата и сама программа, а не только глибц, так как не учитывает этот момент и выделяет по 3 байта маллоком.
| |
|
|
1.19, Аноним (24), 21:06, 21/05/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +1 +/– |
У нас в этих наших линуксах всё так "течёт".
Нужно понимать как работает malloc. При выделение памяти маллоком, выделает её не ядро, а выделяет реализация маллок из glibc, а если памяти уже выделенной в процесс не достаточно, то глбиц просит ещё отсыпать у ядра. Но при освобождении не возвращает ядру по разным причинам(в многом виновата фрагментация памяти внутри процесса)
| |
|
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().
| |
|
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 виноват, конэшн.
| |
|
|
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. | |
|
|