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

vall
же упоминавшийся коллега vs220 в начале этой ветки старался помочь. Но сам не имел этой проблемы (2 дня назад). Однако как только обновил систему вопрос "dbus-daemon сжирает 500 мегабайт оперативки и выше " стал актуальным и для него. Однако лучше, если он сам это всё подтвердит. Чтобы не было путаницы.
vs220
Вот поменял обратно на стандартный dbus и перегрузился

за пол часа 60 метров растет чуть больше метра в минуту, а в прошлый раз прыгнуло до 700
vall, вот тебе и ответ. ;)
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
вот тебе и ответ. ;)
Ну если учесть, что это он пишет сейчас не про KDE.
То как бы и не ответ.
RusWolf
Ну если учесть, что это он пишет сейчас не про KDE.
ну значит и не в KDE дело... соответственно очередное подтверждение БАГА dbus ;)
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
vs220
постоянно раз в 5 сек сигналит org.gtk.vfs.Daemon
Не пробовал вренно деактивировать?

В части утечки памяти - простыми словами - в нормально написанной программе память выделяется по запросу и освобождается, когда она больше не нужна. А вот в случае плохо написанной программы этот процесс работы с памятью не выполняется, то есть память выделяется, но не освобождается, когда она больше не нужна.
Если бы dbus был плохо написан, то эта проблема наблюдалась бы у многих и не зависимо от установленного DE/WM.
Проблема наблюдается насколько видно только при наличии установленного KDE ... течет KDE? - тоже не факт - так как меняя dbus-daemon на альтернативый dbus, проблема вроде бы исчезает (хотя 100% уверенности пока нет). Допустим, что проблемы при смене dbus на алтернативный нет. И похоже что проблема возникает в связке KDE+dbus-daemon ... но то что это связано с утечкой памяти тоже спешить нельзя - нужен анализ, хотя бы самый простой - способов несколько ... и, повторюсь, что с термином утечка памяти нужно быть осторожнее - пока не доказано, это не факт. Конечно, факт увеличения расхода памяти со временем установлен, но это может быть обусловлено и другими причинами.
Ошибки не исчезают с опытом - они просто умнеют
vasek
Не пробовал вренно деактивировать?
Не это нормально для него , и dbus-broker при том же поведении стабильно пять метров держит. Да и стандартный раньше тоже не шалил
вот за 50 минут работы
$ sudo ps_mem |grep dbus
[sudo] пароль для oleg:
696.0 KiB +   1.0 MiB =   1.7 MiB	gdbus
  1.3 MiB +   1.8 MiB =   3.1 MiB	dbus-broker (2)
  1.1 MiB +   2.1 MiB =   3.2 MiB	dbus-broker-launch (2)
останусь на нем проблем с ним нет вроде
vasek, ты хочешь сказать что "кто то" настолько напрягает dbus-daemon, что тот вынужден использовать > 500M памяти, когда норм ~15M???
почему этот "кто то" не напрягает так же dbus-broker???
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
vs220
останусь на нем проблем с ним нет вроде
Похоже, что проблема только в комбинации KDE+dbus-daemon - и тогда слабо верится, что причина в утечке памяти ... хотя, конечно, по-хорошему нужно проверять ... и вижу для этого простой способ использование memleax
Пример использования для dbus-daemon –system (PID=285) - опции никакие не применял (уверен, что падения не будет, иначе нужно использовать)
sudo memleax 285
Warning: no symbol table found for /usr/bin/dbus-daemon
Warning: no debug-line found for /usr/bin/dbus-daemon  # на эти строчки не нужно обращать внимания
== Begin monitoring process 285...
^C # остановил по Ctrl+C через минуту
== Terminate monitoring.
== No expired memory blocks.
Главный вывод, что все исправно - последняя строчка No expired memory blocks
Описание утилиты можно почитать на GitHub

PS - плюс этой утилиты в том, что можно тестить открытые проги ... но могут быть нюнсы ... а потому не рекомендую применять к браузеру (скорее всего упадет при закрытии) ... хотя можно, но, например, с опцией с
Ошибки не исчезают с опытом - они просто умнеют
root@b / # ps_mem |grep dbus
  1.7 MiB +   2.7 MiB =   4.4 MiB       dbus-broker-launch (2)
  2.8 MiB +   4.7 MiB =   7.5 MiB       gmenudbusmenuproxy
 12.7 MiB +  13.3 MiB =  26.0 MiB       dbus-broker (2)
root@b / # systemctl status dbus-broker | egrep 'Active|Memory|CPU'
     Active: active (running) since Thu 2021-11-25 17:08:44 MSK; 4h 39min ago
     Memory: 14.9M
        CPU: 2min 23.381s
чему верить?
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
напрягает dbus-daemon, что тот вынужден использовать > 500M памяти, когда норм ~15M???
Напрягает только у тех, кто использует KDE

nafanja
почему этот "кто то" не напрягает так же dbus-broker???
Гадать не могу, нужно анализировать что там такое происходит - и никто не сказал даже - какой конкретно процесс напрягает dbus-daemon и что там с тем же процессом в dbus-broker??? - или этот процесс не один? ... это утечка памяти??? и т.д.
Ошибки не исчезают с опытом - они просто умнеют
vasek
Напрягает только у тех, кто использует KDE
vs220, используешь KDE??? (еще раз;) )
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
 
Зарегистрироваться или войдите чтобы оставить сообщение.