Re: Control on DBus-daemon virtual memory usage ballooning

Hi,

Thanks for the replies.

I used the following command to track  the D-Bus "VM usage":

cat /proc/`pgrep dbus-daemon | awk 'NR==1{print $1}'`/status | grep Vm

When the D-Bus daemon is up without any message handling,  The following is
output:

VmPeak:    3220 kB
VmSize:    3220 kB
VmLck:       0 kB
VmPin:       0 kB
VmHWM:    1352 kB
VmRSS:    1352 kB
VmData:     244 kB
VmStk:     132 kB
VmExe:     148 kB
VmLib:    2092 kB
VmPTE:      20 kB
VmPMD:       8 kB
VmSwap:       0 kB

After I have done the tests, the following is the output of that command:

VmPeak:   13552 kB
VmSize:   13548 kB
VmLck:       0 kB
VmPin:       0 kB
VmHWM:   11696 kB
VmRSS:   11696 kB
VmData:   10568 kB
VmStk:     132 kB
VmExe:     156 kB
VmLib:    2088 kB
VmPTE:      32 kB
VmPMD:       8 kB
VmSwap:       0 kB

And this output remains the same until I restart the D-Bus daemon.

I also use the following command to monitor the system memory usage before
and after I have done the pressure tests:

cat /proc/meminfo | grep Mem

The command output before the test is:

MemTotal:        1022908 kB
MemFree:          554340 kB
MemAvailable:     569412 kB

The command output after the test is:

MemTotal:        1022908 kB
MemFree:          502272 kB
MemAvailable:     558264 kB

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 :(

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.










On Sun, Sep 13, 2020 at 4:05 AM Thiago Macieira <[email protected]> wrote:

> On Friday, 11 September 2020 07:15:10 PDT David Rheinsberg wrote:
> > > I think the internal memory pools, managed by DBusMemPool, may be
> involved
> > > here.
> > I agree, DBusMemPool may behave non-optimally. Though, to analyse a
> > situation I would need a description of the symptoms. The initial
> > report talks about "growing VM usage", which is quite unspecific.
> > Without any actual data, I don't see the point in speculating what
> > could go wrong.
>
> Please show that the RSS of the process is growing, not VSZ. VSZ is not a
> good
> indicator of anything. Up until a few years ago, before library alignment
> changed, applications had huge inaccessible virtual memory areas, for
> example.
>
> Looking at the daemons here, I see the system one has a heap of 4068 kB
> and
> the session one is at 1928 kB (heap, not RSS). That's decidedly on the
> small
> side for modern applications. And consider that the session daemon handles
> far
> more messages (by an orders of magnitude) than the system one, and yet has
> a
> smaller footprint. That tells me the memory consumption isn't connected to
> the
> message traffic, but something else. I guess it's the number of
> configuration
> files that set up allowed traffic rules.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel DPG Cloud Engineering
>
>
>
> _______________________________________________
> dbus mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/dbus
>

_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus