<div dir="ltr">Hi,<div><br></div><div>Thanks for the replies.</div><div><br></div><div>I used the following command to track the D-Bus "VM usage":</div><div><br></div><div>cat /proc/`pgrep dbus-daemon | awk 'NR==1{print $1}'`/status | grep Vm<br></div><div><br></div><div>When the D-Bus daemon is up without any message handling, The following is output:</div><div><br></div><div>VmPeak: 3220 kB<br>VmSize: 3220 kB<br>VmLck: 0 kB<br>VmPin: 0 kB<br>VmHWM: 1352 kB<br>VmRSS: 1352 kB<br>VmData: 244 kB<br>VmStk: 132 kB<br>VmExe: 148 kB<br>VmLib: 2092 kB<br>VmPTE: 20 kB<br>VmPMD: 8 kB<br>VmSwap: 0 kB<br></div><div><br></div><div>After I have done the tests, the following is the output of that command:</div><div><br></div><div>VmPeak: 13552 kB<br>VmSize: 13548 kB<br>VmLck: 0 kB<br>VmPin: 0 kB<br>VmHWM: 11696 kB<br>VmRSS: 11696 kB<br>VmData: 10568 kB<br>VmStk: 132 kB<br>VmExe: 156 kB<br>VmLib: 2088 kB<br>VmPTE: 32 kB<br>VmPMD: 8 kB<br>VmSwap: 0 kB<br></div><div><br></div><div>And this output remains the same until I restart the D-Bus daemon.</div><div><br></div><div>I also use the following command to monitor the system memory usage before and after I have done the pressure tests:</div><div><br></div><div>cat /proc/meminfo | grep Mem<br></div><div><br></div><div>The command output before the test is:</div><div><br></div><div>MemTotal: 1022908 kB<br>MemFree: 554340 kB<br>MemAvailable: 569412 kB<br></div><div><br></div><div>The command output after the test is:</div><div><br></div><div>MemTotal: 1022908 kB<br>MemFree: 502272 kB<br>MemAvailable: 558264 kB<br></div><div><br></div><div>I have changed the D-Bus (session bus) daemon configuration file to limit the "max_incoming_bytes" and "max_outgoing_bytes" to 5MB each as the default configuration file can bring down the whole linux system in a couple of minutes if I run the same pressure test on it :(<br></div><div><br></div><div>That is why I am after a way to free the dbus daemon memory holdup on the D-Bus messages queue, particularly after the receivers have completed disseminating all the incoming data.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 13, 2020 at 4:05 AM Thiago Macieira <<a href="mailto:thiago@kde.org">thiago@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Friday, 11 September 2020 07:15:10 PDT David Rheinsberg wrote:<br>
> > I think the internal memory pools, managed by DBusMemPool, may be involved<br>
> > here.<br>
> I agree, DBusMemPool may behave non-optimally. Though, to analyse a<br>
> situation I would need a description of the symptoms. The initial<br>
> report talks about "growing VM usage", which is quite unspecific.<br>
> Without any actual data, I don't see the point in speculating what<br>
> could go wrong.<br>
<br>
Please show that the RSS of the process is growing, not VSZ. VSZ is not a good <br>
indicator of anything. Up until a few years ago, before library alignment <br>
changed, applications had huge inaccessible virtual memory areas, for example.<br>
<br>
Looking at the daemons here, I see the system one has a heap of 4068 kB and <br>
the session one is at 1928 kB (heap, not RSS). That's decidedly on the small <br>
side for modern applications. And consider that the session daemon handles far <br>
more messages (by an orders of magnitude) than the system one, and yet has a <br>
smaller footprint. That tells me the memory consumption isn't connected to the <br>
message traffic, but something else. I guess it's the number of configuration <br>
files that set up allowed traffic rules.<br>
<br>
-- <br>
Thiago Macieira - thiago (AT) <a href="http://macieira.info" rel="noreferrer" target="_blank">macieira.info</a> - thiago (AT) <a href="http://kde.org" rel="noreferrer" target="_blank">kde.org</a><br>
Software Architect - Intel DPG Cloud Engineering<br>
<br>
<br>
<br>
_______________________________________________<br>
dbus mailing list<br>
<a href="mailto:dbus@lists.freedesktop.org" target="_blank">dbus@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/dbus" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/dbus</a><br>
</blockquote></div>