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

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

# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)

Сообщения: 9252

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

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

vasek, нееее нет...
фишка в том что, занимаемая память dbus это какая то структура. а у этой структуры есть четкое определение какой другой процесс инициировал выделение памяти для него.
так вот я хотел бы проанализировать выделенную память на предмет совпадений на процесс спамер. (подозреваю что этот процесс всего одни.)

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

vasek	# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)
Темы: 47 Сообщения: 11854 Участник с: 17 февраля 2013	nafanja а у этой структуры есть четкое определение какой другой процесс инициировал выделение памяти для него То есть - запросил dbus-daemon для своих нужд дополнительной памяти - и нужно узнать причину запроса?, точнее, кто инициатор? Здесь дамп памяти не поможет - нужен другой инструмент, например, наиболее простой это strace - там будет указан системный вызов mmap (выделение памяти), а выше может что то и будет об инициаторе, но этим никогда не интересовался, а потому будет ли там что то указано и как, сказать не могу. В приведенном выше скрипте указан gdb, но, думаю, в части выявления инициатора вряд ли с помощью этого отладчика что то можно выяснить. И все-таки, для начала неплохо бы набрать информации - какой процесс dbus-daemon (system или session) тратит много памяти, далее, используя pmap определить на что идет эта память? ... а уж дальше думать, можно ли и как выявить этого инициатора. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)

Темы: 47

Сообщения: 11854

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

nafanja
а у этой структуры есть четкое определение какой другой процесс инициировал выделение памяти для него

То есть - запросил dbus-daemon для своих нужд дополнительной памяти - и нужно узнать причину запроса?, точнее, кто инициатор?
Здесь дамп памяти не поможет - нужен другой инструмент, например, наиболее простой это strace - там будет указан системный вызов mmap (выделение памяти), а выше может что то и будет об инициаторе, но этим никогда не интересовался, а потому будет ли там что то указано и как, сказать не могу.
В приведенном выше скрипте указан gdb, но, думаю, в части выявления инициатора вряд ли с помощью этого отладчика что то можно выяснить.

И все-таки, для начала неплохо бы набрать информации - какой процесс dbus-daemon (system или session) тратит много памяти, далее, используя pmap определить на что идет эта память? ... а уж дальше думать, можно ли и как выявить этого инициатора.

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

vasek	# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)
Темы: 47 Сообщения: 11854 Участник с: 17 февраля 2013	Пришла еще одна идея, как можно определить виновника - использовать для этого сам dbus. Запускаем busctl list и узнаем имена действующих юнитов, тех, что активированы (не активированный выделены серым цветом, а активированные белым) и далее запускаем мониторить по одному, чтобы определить который очень часто спамит, командой, типа sudo busctl monitor org.freedesktop.PolicyKit1 `Monitoring bus message stream.` При этом можно смотреть идет ли увеличение памяти - завершить - Ctrl+C Если нашли такой, то можно попробовать его деактивировать и посмотреть что будет .... а можно и проще, не мониторить, а деактивировать поочередно. PS - но можно ли таким образом выявить виновника - 100% уверенности нет. ... и вроде бы у dbus есть функция debug, но ни разу ее не запускал. EDIT 1 - и все забываю спросить - а не пробовал ограничить размер памяти dbus??? - вроде бы по дефолту прописан 1G Ошибки не исчезают с опытом - они просто умнеют

vasek

# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)

Темы: 47

Сообщения: 11854

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

Пришла еще одна идея, как можно определить виновника - использовать для этого сам dbus.
Запускаем busctl list и узнаем имена действующих юнитов, тех, что активированы (не активированный выделены серым цветом, а активированные белым) и далее запускаем мониторить по одному, чтобы определить который очень часто спамит, командой, типа
sudo busctl monitor org.freedesktop.PolicyKit1

Monitoring bus message stream.

При этом можно смотреть идет ли увеличение памяти - завершить - Ctrl+C
Если нашли такой, то можно попробовать его деактивировать и посмотреть что будет .... а можно и проще, не мониторить, а деактивировать поочередно.

PS - но можно ли таким образом выявить виновника - 100% уверенности нет. ... и вроде бы у dbus есть функция debug, но ни разу ее не запускал.

EDIT 1 - и все забываю спросить - а не пробовал ограничить размер памяти dbus??? - вроде бы по дефолту прописан 1G

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

vasek	# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)
Темы: 47 Сообщения: 11854 Участник с: 17 февраля 2013	В части скритпа nafanja #!/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 насколько понимаю его работу, данный скрипт считывает область памяти, указанную в /proc/PID/maps, приаттачивается к процессу отладчиком gdb, считывает этот кусок памяти и пишет в файл … и этих файлов будет столько же сколько областей памяти в /proc/PID/maps --- и вряд ли что то будет про процессы. Если уж так хочется снять дамп процесса, то можно это сделать и подругому, используя утилиту gcore из пакета gdb - получишь полный дамп памяти процесса, но размер может быть большим, так как это полная память занятая процессом … и далее можно анализировать этот дамп самим gdb или используя strings - смотреть строки понятные человеку … но это большой труд и не уверен, будет ли там нужная тебе информация. Пример, как это можно провернуть В качестве подопытного возмем PID=432 /usr/bin/dbus-daemon --session - делаем полный дамп PID=432 с выводом в файл ~/dump sudo gcore -o ~/dump 432* В результате получим файл ~ /dump.432 (утилита автоматом допишет PID в конец) Смотрим размер полученного файла stat -c %s ~/dump.432 - 2766872 Это файл elf file ~/dump.432 `/home/vasek/dump.432: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from '/usr/bin/dbus-daemon', real uid: 1000, effective uid: 1000, real gid: 100, effective gid: 100, execfn: '/usr/bin/dbus-daemon', platform: 'x86_64'` и чтобы его посмотреть нужно вытащить из него читаемые строки, используя strings strings ~/dump.432 > ~/dump_stings.432 (один нюанс - по дефолту будут только строки длиной более 4-х символов) Смотрим объем полученного файла stat -c %s ~/dump_strings.432 - 282796 ну и посмотрим что там внутри (1-ые 10 строк) cat ~/dump_strings.432 \| head -10 `/lib64/ld-linux-x86-64.so.2 libdbus-1.so.3 _ITM_deregisterTMCloneTable __gmon_start__ _ITM_registerTMCloneTable _dbus_list_get_first dbus_connection_preallocate_send _dbus_credentials_new_from_current_process _dbus_string_append_byte dbus_connection_set_max_received_unix_fds` Как то так, но поможет ли это тебе, не уверен. PS - обычно дампы анализируют gbd, но работа с ним не так и проста - у меня так и не хватило терпения освоить его ... хотя по правде не особо это и интересовало, достаточно было получение одного Call Trace. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)

Темы: 47

Сообщения: 11854

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

В части скритпа

nafanja
#!/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

насколько понимаю его работу, данный скрипт считывает область памяти, указанную в /proc/PID/maps, приаттачивается к процессу отладчиком gdb, считывает этот кусок памяти и пишет в файл … и этих файлов будет столько же сколько областей памяти в /proc/PID/maps --- и вряд ли что то будет про процессы.
Если уж так хочется снять дамп процесса, то можно это сделать и подругому, используя утилиту gcore из пакета gdb - получишь полный дамп памяти процесса, но размер может быть большим, так как это полная память занятая процессом … и далее можно анализировать этот дамп самим gdb или используя strings - смотреть строки понятные человеку … но это большой труд и не уверен, будет ли там нужная тебе информация.
Пример, как это можно провернуть
В качестве подопытного возмем PID=432 /usr/bin/dbus-daemon --session
- делаем полный дамп PID=432 с выводом в файл ~/dump
sudo gcore -o ~/dump 432
В результате получим файл ~ /dump.432 (утилита автоматом допишет PID в конец)
Смотрим размер полученного файла
stat -c %s ~/dump.432 - 2766872
Это файл elf
file ~/dump.432

/home/vasek/dump.432: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from '/usr/bin/dbus-daemon', real uid: 1000, effective uid: 1000, real gid: 100, effective gid: 100, execfn: '/usr/bin/dbus-daemon', platform: 'x86_64'

и чтобы его посмотреть нужно вытащить из него читаемые строки, используя strings
strings ~/dump.432 > ~/dump_stings.432 (один нюанс - по дефолту будут только строки длиной более 4-х символов)
Смотрим объем полученного файла
stat -c %s ~/dump_strings.432 - 282796
ну и посмотрим что там внутри (1-ые 10 строк)
cat ~/dump_strings.432 | head -10

/lib64/ld-linux-x86-64.so.2
libdbus-1.so.3
_ITM_deregisterTMCloneTable
__gmon_start__
_ITM_registerTMCloneTable
_dbus_list_get_first
dbus_connection_preallocate_send
_dbus_credentials_new_from_current_process
_dbus_string_append_byte
dbus_connection_set_max_received_unix_fds

Как то так, но поможет ли это тебе, не уверен.

PS - обычно дампы анализируют gbd, но работа с ним не так и проста - у меня так и не хватило терпения освоить его ... хотя по правде не особо это и интересовало, достаточно было получение одного Call Trace.

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

User6260	# 2 года, 12 месяцев назад
Темы: 1 Сообщения: 53 Участник с: 08 мая 2013	vasek User6260 Единственное, я последний раз обновлял систему около 2-х недель назад. Отпишись после обновления. Вот после вчерашнего обновления ситуация `systemctl status dbus \| egrep 'Active\|Memory\|CPU' Active: active (running) since Sun 2021-11-28 11:05:23 +07; 4h 52min ago Memory: 5.1M CPU: 268ms` Вроде все хорошо. Я тут в теме прочитал, что может быть виноваты драйвера NVIDIA. У меня NVIDIA, драйвера версии 340 (у меня старая видюшка, уже не поддерживается современными драйверами).

User6260

# 2 года, 12 месяцев назад

Темы: 1

Сообщения: 53

Участник с: 08 мая 2013

vasek
User6260
Единственное, я последний раз обновлял систему около 2-х недель назад.
Отпишись после обновления.

Вот после вчерашнего обновления ситуация

systemctl status dbus | egrep 'Active|Memory|CPU'
     Active: active (running) since Sun 2021-11-28 11:05:23 +07; 4h 52min ago
     Memory: 5.1M
        CPU: 268ms

Вроде все хорошо. Я тут в теме прочитал, что может быть виноваты драйвера NVIDIA. У меня NVIDIA, драйвера версии 340 (у меня старая видюшка, уже не поддерживается современными драйверами).

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

nafanja

# 2 года, 12 месяцев назад

Темы: 94

Сообщения: 9252

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

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

vasek, я тебя понял а ты меня нет.
представь dbus это почтальон и у него есть сумка с письмами, так вот (мне кажется) эта сумка и раздувается от количества писем. а у письма есть отправитель, получатель и данные. вот я и хочу узнать кто отправитель и получатель проанализировав письма в сумке почтальона.
а ты предлагаешь другой метод, следить за почтальоном, у кого он берет письма.

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

vs220	# 2 года, 12 месяцев назад
Темы: 25 Сообщения: 8524 Участник с: 16 августа 2009	nafanja у письма есть отправитель, получатель и данные. вот я и хочу узнать кто отправитель и получатель dbus-monitor busctl

vasek	# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)
Темы: 47 Сообщения: 11854 Участник с: 17 февраля 2013	User6260 Пользуюсь KDE …. после вчерашнего обновления Вроде все хорошо Как видим у кого то все нормально, у кого то нет - напрашивается простое сравнение задействованных процессов - может так и поймается багованный? Предлагаю сравнить выводы `busctl list --user \| sed '/(activatable)/d' \| awk '{print $3}'` думаю, достаточно одних user, system можно и не сравнивать ... Например, мой вывод - проблем нет PROCESS pulseaudio systemd gvfsd-fuse at-spi2-registr at-spi2-registr palemoon palemoon pcmanfm gvfsd-metadata gvfs-udisks2-vo gvfs-gphoto2-vo gvfs-afc-volume gsettings-helpe gvfs-mtp-volume gvfsd-trash gvfsd-computer mako dconf-service tilix gvfsd-network gvfsd-dnssd gedit waybar gedit busctl waybar tilix at-spi-bus-laun gvfsd dconf-service tilix waybar pulseaudio at-spi-bus-laun systemd mako systemd gedit gvfs-afc-volume gvfsd gvfs-gphoto2-vo gvfs-mtp-volume gvfsd-metadata gvfs-udisks2-vo gvfsd-trash gvfsd-computer gvfsd-network gvfsd-dnssd pulseaudio Ошибки не исчезают с опытом - они просто умнеют

vasek

# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)

Темы: 47

Сообщения: 11854

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

User6260
Пользуюсь KDE …. после вчерашнего обновления Вроде все хорошо

Как видим у кого то все нормально, у кого то нет - напрашивается простое сравнение задействованных процессов - может так и поймается багованный?
Предлагаю сравнить выводы

busctl list --user | sed '/(activatable)/d' | awk '{print $3}'

думаю, достаточно одних user, system можно и не сравнивать ... Например, мой вывод - проблем нет

PROCESS
pulseaudio
systemd
gvfsd-fuse
at-spi2-registr
at-spi2-registr
palemoon
palemoon
pcmanfm
gvfsd-metadata
gvfs-udisks2-vo
gvfs-gphoto2-vo
gvfs-afc-volume
gsettings-helpe
gvfs-mtp-volume
gvfsd-trash
gvfsd-computer
mako
dconf-service
tilix
gvfsd-network
gvfsd-dnssd
gedit
waybar
gedit
busctl
waybar
tilix
at-spi-bus-laun
gvfsd
dconf-service
tilix
waybar
pulseaudio
at-spi-bus-laun
systemd
mako
systemd
gedit
gvfs-afc-volume
gvfsd
gvfs-gphoto2-vo
gvfs-mtp-volume
gvfsd-metadata
gvfs-udisks2-vo
gvfsd-trash
gvfsd-computer
gvfsd-network
gvfsd-dnssd
pulseaudio

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

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

RusWolf	# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)
Темы: 11 Сообщения: 2795 Участник с: 16 июля 2016	vasek Как видим у кого то все нормально, у кого то нет Постоянно смотрю этот топик. Наконец добрались руки дома, до четвёртого компа с KDE. B вот на нём наконец случилось чудо :) `[wolf@wolf-pc ~]$ systemctl status dbus \| grep Memory Memory: 26.6M` Вчера, за шесть часов работы набежало 387MB, но больше не подымалось уже. P.S. пока писал сообщение, уже набежало: `[wolf@wolf-pc ~]$ systemctl status dbus \| grep Memory Memory: 29.5M` https://t.me/arch_linuxru

RusWolf

# 2 года, 12 месяцев назад (отредактировано 2 года, 12 месяцев назад)

Темы: 11

Сообщения: 2795

Участник с: 16 июля 2016

vasek
Как видим у кого то все нормально, у кого то нет

Постоянно смотрю этот топик.
Наконец добрались руки дома, до четвёртого компа с KDE.
B вот на нём наконец случилось чудо :)

[wolf@wolf-pc ~]$ systemctl status dbus | grep Memory
     Memory: 26.6M

Вчера, за шесть часов работы набежало 387MB, но больше не подымалось уже.

P.S. пока писал сообщение, уже набежало:

[wolf@wolf-pc ~]$ systemctl status dbus | grep Memory
     Memory: 29.5M

https://t.me/arch_linuxru