dbus-daemon сжирает 500 мегабайт оперативки и выше

vall	# 9 месяцев, 1 неделя назад
Темы: 45 Сообщения: 1786 Участник с: 28 марта 2017	Установлен dbus-broker. Память не течёт. Но в стандартном приложении KDE "Системный монитор" в инструменте "Приложения" можем наблюдать 4 замечательных процесса (картинка). Удаляем dbus-broker и используем стандартный dbus-daemon. Память тут же потекла. Зато никаких 4 замечательных процессов мы уже НЕ наблюдаем (картинка). Информация к размышлению :) Мнения и соображения приветствуются.

# 9 месяцев, 1 неделя назад

Сообщения: 1786

Участник с: 28 марта 2017

Установлен dbus-broker. Память не течёт. Но в стандартном приложении KDE "Системный монитор" в инструменте "Приложения" можем наблюдать 4 замечательных процесса (картинка).

Удаляем dbus-broker и используем стандартный dbus-daemon. Память тут же потекла. Зато никаких 4 замечательных процессов мы уже НЕ наблюдаем (картинка).

Информация к размышлению :) Мнения и соображения приветствуются.

vasek	# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Насколько я понял проблема утечки dbus-broker решена - смотрим самый последний пост (Apr 14, 2021) в приведенной выше статье на GitHub `I summarized how we found the resource leak in openQA and fixed it. Maybe this serves as help to others facing similar problems and trying to make sense of it: https://dvdhrm.github.io/2021/04/14/locating-dbus-resource-leaks/` Ошибки не исчезают с опытом - они просто умнеют

vasek

# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Насколько я понял проблема утечки dbus-broker решена - смотрим самый последний пост (Apr 14, 2021) в приведенной выше статье на GitHub

I summarized how we found the resource leak in openQA and fixed it. Maybe this serves as help to others facing similar problems and trying to make sense of it:
https://dvdhrm.github.io/2021/04/14/locating-dbus-resource-leaks/

Ошибки не исчезают с опытом - они просто умнеют

nafanja	# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	vasek dbus-broker временное решение,... как починять стандартный dbus, вернусь обратно на него. Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja	# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	nafanja vasek, подскажи, как сдампить всю память процесса в файл? вот сам нашел где то скриптик `#!/usr/bin/env bash grep rw-p /proc/$1/maps \ \| sed -n 's/^\([0-9a-f]\)-\([0-9a-f]\) .$/\1 \2/p' \ \| while read start stop; do \ gdb --batch --pid $1 -ex \ "dump memory $1-$start-$stop.dump 0x$start 0x$stop"; \ done` vasek, как думаешь подойдет? мне просто интересно посмотреть чем же забиваются сотни мегабайт... Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874*

nafanja

# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

nafanja
vasek, подскажи, как сдампить всю память процесса в файл?

вот сам нашел где то скриптик

#!/usr/bin/env bash

grep rw-p /proc/$1/maps \
| sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' \
| while read start stop; do \
    gdb --batch --pid $1 -ex \
        "dump memory $1-$start-$stop.dump 0x$start 0x$stop"; \
done

vasek, как думаешь подойдет? мне просто интересно посмотреть чем же забиваются сотни мегабайт...

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

vall	# 9 месяцев, 1 неделя назад
Темы: 45 Сообщения: 1786 Участник с: 28 марта 2017	vall 4 замечательных процесса (картинка). ???

vs220	# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)
Темы: 22 Сообщения: 8070 Участник с: 16 августа 2009	vall процесса Отдельно показывает сервисы . Первый https://archlinux.org/packages/?name=xdg-desktop-portal-kde Нужен нет решать вам , для флатпаков, вайланда и прочих изолированных штук Второй кскрин - два монитора, проэктор , опять же надо/нет Третий поддержка для людей с ограниченными возможностями, если надо оставляете, если нет можно выпилить через конфиг пакмана. Четвертое не знаю что Кошелек скорее всего KDE Wallet или подобное

vs220

# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)

Темы: 22

Сообщения: 8070

Участник с: 16 августа 2009

vall
процесса

Отдельно показывает сервисы .
Первый https://archlinux.org/packages/?name=xdg-desktop-portal-kde
Нужен нет решать вам , для флатпаков, вайланда и прочих изолированных штук
Второй кскрин - два монитора, проэктор , опять же надо/нет
Третий поддержка для людей с ограниченными возможностями, если надо оставляете, если нет можно выпилить через конфиг
пакмана.
Четвертое не
знаю что
Кошелек скорее всего KDE Wallet или подобное

vall	# 9 месяцев, 1 неделя назад
Темы: 45 Сообщения: 1786 Участник с: 28 марта 2017	Во-первых, спасибо за разъяснение. Мне было вообще неясно. Во-вторых, моя мысль в том, что !возможно! dbus-broker выставляет их "за скобки". А при стандартном dbus-daemon именно они, где-то "внутри" и текут. Но это детали предположения. Главная идея в том, что всё же в данном случае виновник ситуации -- баг KDE. Заключение умозрительное.

vall

# 9 месяцев, 1 неделя назад

Темы: 45

Сообщения: 1786

Участник с: 28 марта 2017

Во-первых, спасибо за разъяснение. Мне было вообще неясно.

Во-вторых, моя мысль в том, что !возможно! dbus-broker выставляет их "за скобки". А при стандартном dbus-daemon именно они, где-то "внутри" и текут. Но это детали предположения. Главная идея в том, что всё же в данном случае виновник ситуации -- баг KDE. Заключение умозрительное.

vasek	# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	nafanja нашел где то скриптик Вряд ли что то получится выяснить, не рекомендую. nafanja просто интересно посмотреть чем же забиваются сотни мегабайт Разумнее для начала использовать самые простые и понятные способы, например 1. Сначала выяснить какой демон течет: system или session? - скорее всего session - узнаем PID процессов ps aux \| grep dbus (лишнее выкинул) `PID process 279 dbus-daemon --system 421 dbus-daemon --session 481 dbus-daemon --config-file` - узнаем какой <PID>, который течет намного больше других, для чего периодически (раза 3, думаю, будет достаточно) смотрим выводы (лишнее выкинул) top -n 1 -p 279,421,481 `PID USER PR VIRT RES SHR COMMAND 279 dbus 20 12696 6240 5024 dbus-daemon 421 vasek 20 12580 6104 4932 dbus-daemon 481 vasek 20 12028 5284 4624 dbus-daemon` и выясняем этот <PID> 2. анализ <PID>, который течет намного больше других ( раза 2, думаю, будет достаточно) pmap -x -p <PID> … можно вывести и в файл … привожу примерный вывод pmap -x 421 Address Kbytes RSS Dirty Mode Mapping 000055f11d763000 32 32 0 r---- dbus-daemon 000055f11d76b000 128 128 0 r-x-- dbus-daemon 000055f11d78b000 52 48 0 r---- dbus-daemon 000055f11d798000 8 8 8 r---- dbus-daemon 000055f11d79a000 4 4 4 rw--- dbus-daemon 000055f11f625000 684 556 556 rw--- [ anon ] 00007f0441c94000 8 8 0 r---- libffi.so.8.1.0 00007f0441c96000 24 24 0 r-x-- libffi.so.8.1.0 00007f0441c9f000 4 4 4 rw--- libffi.so.8.1.0 00007f0441ca0000 164 164 0 r---- libp11-kit.so.0.3.0 00007f0441cc9000 632 88 0 r-x-- libp11-kit.so.0.3.0 ….. total kB 12584 6108 1176 PS - кстати, значения 12584 6108 в последней строчке совпадают с значениями в top (колонки VIRT и RES) Последняя колонка в pmap - показаны библиотеки и др., что занимает память, по которым можно и узнать процесс, которому они принадлежат. Нужно смотреть, что добавилось … но, предположу, что будет добавляться anon, но возможно и ошибаюсь. На мой взгляд, этот анализ хоть и муторный, но понятный ... поможет ли это? - 100% уверенности нет. EDIT 1 - если будет увеличиваться память самого dbus-daemon, что похоже самое вероятное, то значит идет утечка памяти ... и как писал выше, что разумнее тестить на утечку памяти. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

nafanja
нашел где то скриптик

Вряд ли что то получится выяснить, не рекомендую.

nafanja
просто интересно посмотреть чем же забиваются сотни мегабайт

Разумнее для начала использовать самые простые и понятные способы, например
1. Сначала выяснить какой демон течет: system или session? - скорее всего session
- узнаем PID процессов
ps aux | grep dbus (лишнее выкинул)

PID               process
279      dbus-daemon --system
421      dbus-daemon --session
481      dbus-daemon --config-file

- узнаем какой <PID>, который течет намного больше других, для чего периодически (раза 3, думаю, будет достаточно) смотрим выводы (лишнее выкинул)
top -n 1 -p 279,421,481

 PID USER      PR   VIRT    RES    SHR    COMMAND
    279 dbus       20     12696   6240   5024     dbus-daemon
    421 vasek      20    12580   6104   4932     dbus-daemon
    481 vasek      20    12028   5284   4624     dbus-daemon

и выясняем этот <PID>
2. анализ <PID>, который течет намного больше других ( раза 2, думаю, будет достаточно)
pmap -x -p <PID> … можно вывести и в файл
… привожу примерный вывод

pmap -x 421
 Address                Kbytes     RSS   Dirty Mode  Mapping
000055f11d763000      32      32       0       r---- dbus-daemon
000055f11d76b000     128     128     0       r-x-- dbus-daemon
000055f11d78b000      52      48       0       r---- dbus-daemon
000055f11d798000       8       8        8        r---- dbus-daemon
000055f11d79a000       4       4        4        rw--- dbus-daemon
000055f11f625000     684    556    556     rw---   [ anon ]
00007f0441c94000       8       8       0        r---- libffi.so.8.1.0
00007f0441c96000      24      24     0        r-x-- libffi.so.8.1.0
00007f0441c9f000       4       4       4        rw--- libffi.so.8.1.0
00007f0441ca0000     164     164   0        r---- libp11-kit.so.0.3.0
00007f0441cc9000     632      88    0       r-x-- libp11-kit.so.0.3.0
…..
total kB                 12584    6108    1176

PS - кстати, значения 12584 6108 в последней строчке совпадают с значениями в top (колонки VIRT и RES)
Последняя колонка в pmap - показаны библиотеки и др., что занимает память, по которым можно и узнать процесс, которому они принадлежат. Нужно смотреть, что добавилось … но, предположу, что будет добавляться anon, но возможно и ошибаюсь.
На мой взгляд, этот анализ хоть и муторный, но понятный ... поможет ли это? - 100% уверенности нет.

EDIT 1 - если будет увеличиваться память самого dbus-daemon, что похоже самое вероятное, то значит идет утечка памяти ... и как писал выше, что разумнее тестить на утечку памяти.

Ошибки не исчезают с опытом - они просто умнеют

vs220	# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)
Темы: 22 Сообщения: 8070 Участник с: 16 августа 2009	vall виновник ситуации Если дело в баге очереди то все же предположительно имхо виновник дбус демон, так как не может нормально обрабатывать такие ситуации. Дбус брокен нацелен именно на предотвращение такого поведения. Может vasek с nafanja конкретней что выяснят. Понаблюдайте за потреблением этих процессов растет ли за несколько часов сильно.

vs220

# 9 месяцев, 1 неделя назад (отредактировано 9 месяцев, 1 неделя назад)

Темы: 22

Сообщения: 8070

Участник с: 16 августа 2009

vall
виновник ситуации

Если дело в баге очереди то все же предположительно имхо виновник дбус демон, так как не может нормально обрабатывать такие ситуации. Дбус брокен нацелен именно на предотвращение такого поведения.
Может vasek с nafanja конкретней что выяснят.

Понаблюдайте за потреблением этих процессов растет ли за несколько часов сильно.

vasek	# 9 месяцев, 1 неделя назад
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	nafanja, и все-таки наиболее вороятнее идет утечка памяти и разумнее потестить на утечку памяти - то есть никакие дополнительные процессы в pmap не появятся, а только добавяться новые адреса (о чем и дополнил предыдущий пост). Ошибки не исчезают с опытом - они просто умнеют

vasek

# 9 месяцев, 1 неделя назад

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

nafanja, и все-таки наиболее вороятнее идет утечка памяти и разумнее потестить на утечку памяти - то есть никакие дополнительные процессы в pmap не появятся, а только добавяться новые адреса (о чем и дополнил предыдущий пост).

Ошибки не исчезают с опытом - они просто умнеют