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

nafanja
вопрос в другом, вывод каких команд требуется? ;)
А вот это и есть самое сложное при анализе - никогда ничего точно не знаешь, приходится частенько продвигаться методом проб и ошибок, много читать, гуглить ... а это все требует много времени ...
Ошибки не исчезают с опытом - они просто умнеют
vs220
https://dvdhrm.github.io/rethinking-the-dbus-message-bus/
За сылку спасибо, почитаем.
Ошибки не исчезают с опытом - они просто умнеют
safocl, https://www.linux.org.ru/forum/general/16647548?cid=16659305 ну как успехи, проблема осталась?
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja, в части команд для поиска - хотя это уже и не нужно, но я бы для начала попробовал поискать наличие процесса (или нескольких?), которые напрягают, точнее постоянно увеличивают память, просматривая периодически карту памяти dbus-daemon в части увеличения значений выделения памяти и какой процесс захватывает эту память.
Ошибки не исчезают с опытом - они просто умнеют
vasek, подскажи, как сдампить всю память процесса в файл?
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
как сдампить всю память процесса в файл?
1. Есть такое понятие, как карта памяти процесса, посмотреть которую можно, используя утилиту pmap, которая парсит инфу из файлов /proc/PID/ (например, /proc/PID/maps, /proc/PID/smaps
2. Полную информацию о типах памяти процесса (но без ее распределения в памяти), можно посмотреть в файлах /proc/PID/status, /proc/PID/stat

Но мороки с этим очень много, сразу что то анализировать и не рекомендую - если просто заинтересовало, то влазить в это нужно не спеша, сначала лучше разобраться с терминологией и основными понятиями (виды памяти, выделение, распределение и др.).
И лучше, наверное, спросить совета у молодых спецов - я уже и практически и теоретически этим не занимаюсь, многое забылось, как говорится, остались одни вершки.
Ошибки не исчезают с опытом - они просто умнеют
nafanja
ну как успехи, проблема осталась?
Прошу коллег разъяснить: KDE - почти невиновно; NVIDIA (495) - источник спама? И только dbus-broker не ведётся на происки зелёных? )))

Как следует из этого.
vall
; NVIDIA (495) - источник спама?
У меня например нвидия не спамит, а dbus-daemon "течет"

У вас в журнале есть спам ?

journalctl |grep dbus|grep Rejected

По ссылке выше описание бага утечки памяти при переполнении очереди сообщений

откатить на dbus-daemon
journalctl -f 
vs220
У вас в журнале есть спам ?

vall
Просмотрел сейчас – нет.
Мне, как и nafanja, интересно было бы услышать мнение обо всём этом коллеги safocl'a. Вопрос он поставил хороший. Но почему-то сейчас отмалчивается.
 
Зарегистрироваться или войдите чтобы оставить сообщение.