| |
| 2.2, Аноним (2), 05:12, 14/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
В телеграм конечно же проблема, пусть его разработчики чинят, но им пофиг
| | |
| |
| 3.4, nuclight (??), 20:15, 14/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
 В glibc конечно же. Переменная окружения MALLOC_MMAP_THRESHOLD_=128 вроде более лучшие результаты выдает.
| | |
|
|
| 1.6, PedeRust (?), 20:57, 15/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
glibc срочно на расте переписать, иначе пользоваться этим заскорузлым говном невозможно
| | |
| 1.8, Аноним (8), 21:10, 16/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Лучше сменить мессенджер. Толку помогать разработчикам телеги если им самим плевать на свой мессенджер. Я уже не говорю о сливах, привязки с номеру, отсутствия реальной приватности, закрытых серверах и никакой противодействии блокировкам (заставить пользовтелей использовать vpn это не заслуга телеграма, а телеграм прокси это профанация отслеживаемая по щелчку пальцев (т.е. даже вреднее чем ее отсутствие)) и тд и тп.
| | |
| |
| |
| |
| 4.15, Аноним (15), 23:14, 19/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
Ага, в котором на Андроиде даже нельзя зарегаться без Google Apps.
| | |
| |
| |
| 6.37, незнаю (?), 22:08, 29/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
Этот номер еще и нельзя скрыть, насколько помню. И правда безопасный.
| | |
|
|
|
| |
| 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 мегов рамы
| | |
| |
| 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 бесплатно не поделятся.
| | |
| |
| |
| 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 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Читать документацию пробовали? То что он ее сразу не освобождает не значит что она не доступна для выделения (для процесса освобожденная память помечается свободной для выделения). Это не утечка - это ленивое освобождение.
| | |
| |
| 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.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. | | |
|
| |
| 2.62, нворд (?), 15:15, 29/06/2021 [^] [^^] [^^^] [ответить]
| +/– |
Зато жрёт меньше.
А под линем жрёт больше но гораздо меньше падает.
| | |
|
|