[Pacemaker] lrmd Memory Usage

Greg Murphy greg.murphy at gamesparks.com
Wed May 7 10:31:30 UTC 2014


Thanks Andrew, much appreciated.

I’ll try upgrading to 1.11 and report back with how it goes.



On 07/05/2014 01:20, "Andrew Beekhof" <andrew at beekhof.net> wrote:

>
>On 6 May 2014, at 7:47 pm, Greg Murphy <greg.murphy at gamesparks.com> wrote:
>
>> Here you go - I’ve only run lrmd for 30 minutes since installing the
>>debug
>> package, but hopefully that’s enough - if not, let me know and I’ll do a
>> longer capture.
>> 
>
>I'll keep looking, but almost everything so far seems to be from or
>related to the g_dbus API:
>
>...
>==37625==    by 0x6F20E30: g_dbus_proxy_new_for_bus_sync (in
>/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3800.1)
>==37625==    by 0x507B90B: get_proxy (upstart.c:66)
>==37625==    by 0x507B9BF: upstart_init (upstart.c:85)
>==37625==    by 0x507C88E: upstart_job_exec (upstart.c:429)
>==37625==    by 0x10CE03: lrmd_rsc_dispatch (lrmd.c:879)
>==37625==    by 0x4E5F112: crm_trigger_dispatch (mainloop.c:105)
>==37625==    by 0x58A13B5: g_main_context_dispatch (in
>/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
>==37625==    by 0x58A1707: ??? (in
>/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
>==37625==    by 0x58A1B09: g_main_loop_run (in
>/lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
>==37625==    by 0x10AC3A: main (main.c:314)
>
>Which is going to be called every time an upstart job is run (ie.
>recurring monitor of an upstart resource)
>
>There were several problems with that API and we removed all use of it in
>1.1.11.
>I'm quite confident that most, if not all, of the memory issues would go
>away if you upgraded.
>
>
>> 
>> 
>> On 06/05/2014 10:08, "Andrew Beekhof" <andrew at beekhof.net> wrote:
>> 
>>> Oh, any any chance you could install the debug packages? It will make
>>>the
>>> output even more useful :-)
>>> 
>>> On 6 May 2014, at 7:06 pm, Andrew Beekhof <andrew at beekhof.net> wrote:
>>> 
>>>> 
>>>> On 6 May 2014, at 6:05 pm, Greg Murphy <greg.murphy at gamesparks.com>
>>>> wrote:
>>>> 
>>>>> Attached are the valgrind outputs from two separate runs of lrmd with
>>>>> the
>>>>> suggested variables set. Do they help narrow the issue down?
>>>> 
>>>> They do somewhat.  I'll investigate.  But much of the memory is still
>>>> reachable:
>>>> 
>>>> ==26203==    indirectly lost: 17,945,950 bytes in 642,546 blocks
>>>> ==26203==      possibly lost: 2,805 bytes in 60 blocks
>>>> ==26203==    still reachable: 26,104,781 bytes in 544,782 blocks
>>>> ==26203==         suppressed: 8,652 bytes in 176 blocks
>>>> ==26203== Reachable blocks (those to which a pointer was found) are
>>>>not
>>>> shown.
>>>> ==26203== To see them, rerun with: --leak-check=full
>>>> --show-reachable=yes
>>>> 
>>>> Could you add the --show-reachable=yes to VALGRIND_OPTS variable?
>>>> 
>>>>> 
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> Greg
>>>>> 
>>>>> 
>>>>> On 02/05/2014 03:01, "Andrew Beekhof" <andrew at beekhof.net> wrote:
>>>>> 
>>>>>> 
>>>>>> On 30 Apr 2014, at 9:01 pm, Greg Murphy <greg.murphy at gamesparks.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi
>>>>>>> 
>>>>>>> I¹m running a two-node Pacemaker cluster on Ubuntu Saucy (13.10),
>>>>>>> kernel 3.11.0-17-generic and the Ubuntu Pacemaker package, version
>>>>>>> 1.1.10+git20130802-1ubuntu1.
>>>>>> 
>>>>>> The problem is that I have no way of knowing what code is/isn't
>>>>>> included
>>>>>> in '1.1.10+git20130802-1ubuntu1'.
>>>>>> You could try setting the following in your environment before
>>>>>> starting
>>>>>> pacemaker though
>>>>>> 
>>>>>> # Variables for running child daemons under valgrind and/or checking
>>>>>> for
>>>>>> memory problems
>>>>>> G_SLICE=always-malloc
>>>>>> MALLOC_PERTURB_=221 # or 0
>>>>>> MALLOC_CHECK_=3     # or 0,1,2
>>>>>> PCMK_valgrind_enabled=lrmd
>>>>>> VALGRIND_OPTS="--leak-check=full --trace-children=no
>>>>>>--num-callers=25
>>>>>> --log-file=/var/lib/pacemaker/valgrind-%p
>>>>>> --suppressions=/usr/share/pacemaker/tests/valgrind-pcmk.suppressions
>>>>>> --gen-suppressions=all"
>>>>>> 
>>>>>> 
>>>>>>> The cluster is configured with a DRBD master/slave set and then a
>>>>>>> failover resource group containing MySQL (along with its DRBD
>>>>>>> filesystem) and a Zabbix Proxy and Agent.
>>>>>>> 
>>>>>>> Since I built the cluster around two months ago I¹ve noticed that
>>>>>>>on
>>>>>>> the the active node the memory footprint of lrmd gradually grows to
>>>>>>> quite a significant size. The cluster was last restarted three
>>>>>>>weeks
>>>>>>> ago, and now lrmd has over 1GB of mapped memory on the active node
>>>>>>> and
>>>>>>> only 151MB on the passive node. Current excerpts from
>>>>>>> /proc/PID/status
>>>>>>> are:
>>>>>>> 
>>>>>>> Active node
>>>>>>> VmPeak:
>>>>>>> 1146740 kB
>>>>>>> VmSize:
>>>>>>> 1146740 kB
>>>>>>> VmLck:
>>>>>>>    0 kB
>>>>>>> VmPin:
>>>>>>>    0 kB
>>>>>>> VmHWM:
>>>>>>> 267680 kB
>>>>>>> VmRSS:
>>>>>>> 188764 kB
>>>>>>> VmData:
>>>>>>> 1065860 kB
>>>>>>> VmStk:
>>>>>>>  136 kB
>>>>>>> VmExe:
>>>>>>>    32 kB
>>>>>>> VmLib:
>>>>>>> 10416 kB
>>>>>>> VmPTE:
>>>>>>>  2164 kB
>>>>>>> VmSwap:
>>>>>>> 822752 kB
>>>>>>> 
>>>>>>> Passive node
>>>>>>> VmPeak:
>>>>>>> 220832 kB
>>>>>>> VmSize:
>>>>>>> 155428 kB
>>>>>>> VmLck:
>>>>>>>    0 kB
>>>>>>> VmPin:
>>>>>>>    0 kB
>>>>>>> VmHWM:
>>>>>>>  4568 kB
>>>>>>> VmRSS:
>>>>>>>  3880 kB
>>>>>>> VmData:
>>>>>>> 74548 kB
>>>>>>> VmStk:
>>>>>>>  136 kB
>>>>>>> VmExe:
>>>>>>>    32 kB
>>>>>>> VmLib:
>>>>>>> 10416 kB
>>>>>>> VmPTE:
>>>>>>>  172 kB
>>>>>>> VmSwap:
>>>>>>>    0 kB
>>>>>>> 
>>>>>>> During the last week or so I¹ve taken a couple of snapshots of
>>>>>>> /proc/PID/smaps on the active node, and the heap particularly
>>>>>>>stands
>>>>>>> out
>>>>>>> as growing: (I have the full outputs captured if they¹ll help)
>>>>>>> 
>>>>>>> 20140422
>>>>>>> 7f92e1578000-7f92f218b000 rw-p 00000000 00:00 0
>>>>>>> [heap]
>>>>>>> Size:             274508 kB
>>>>>>> Rss:              180152 kB
>>>>>>> Pss:              180152 kB
>>>>>>> Shared_Clean:          0 kB
>>>>>>> Shared_Dirty:          0 kB
>>>>>>> Private_Clean:         0 kB
>>>>>>> Private_Dirty:    180152 kB
>>>>>>> Referenced:       120472 kB
>>>>>>> Anonymous:        180152 kB
>>>>>>> AnonHugePages:         0 kB
>>>>>>> Swap:              91568 kB
>>>>>>> KernelPageSize:        4 kB
>>>>>>> MMUPageSize:           4 kB
>>>>>>> Locked:                0 kB
>>>>>>> VmFlags: rd wr mr mw me ac
>>>>>>> 
>>>>>>> 
>>>>>>> 20140423
>>>>>>> 7f92e1578000-7f92f305e000 rw-p 00000000 00:00 0
>>>>>>> [heap]
>>>>>>> Size:             289688 kB
>>>>>>> Rss:              184136 kB
>>>>>>> Pss:              184136 kB
>>>>>>> Shared_Clean:          0 kB
>>>>>>> Shared_Dirty:          0 kB
>>>>>>> Private_Clean:         0 kB
>>>>>>> Private_Dirty:    184136 kB
>>>>>>> Referenced:        69748 kB
>>>>>>> Anonymous:        184136 kB
>>>>>>> AnonHugePages:         0 kB
>>>>>>> Swap:             103112 kB
>>>>>>> KernelPageSize:        4 kB
>>>>>>> MMUPageSize:           4 kB
>>>>>>> Locked:                0 kB
>>>>>>> VmFlags: rd wr mr mw me ac
>>>>>>> 
>>>>>>> 20140430
>>>>>>> 7f92e1578000-7f92fc01d000 rw-p 00000000 00:00 0
>>>>>>> [heap]
>>>>>>> Size:             436884 kB
>>>>>>> Rss:              140812 kB
>>>>>>> Pss:              140812 kB
>>>>>>> Shared_Clean:          0 kB
>>>>>>> Shared_Dirty:          0 kB
>>>>>>> Private_Clean:       744 kB
>>>>>>> Private_Dirty:    140068 kB
>>>>>>> Referenced:        43600 kB
>>>>>>> Anonymous:        140812 kB
>>>>>>> AnonHugePages:         0 kB
>>>>>>> Swap:             287392 kB
>>>>>>> KernelPageSize:        4 kB
>>>>>>> MMUPageSize:           4 kB
>>>>>>> Locked:                0 kB
>>>>>>> VmFlags: rd wr mr mw me ac
>>>>>>> 
>>>>>>> I noticed in the release notes for 1.1.10-rc1
>>>>>>> 
>>>>>>> 
>>>>>>>(https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-1.1
>>>>>>>.1
>>>>>>> 0-r
>>>>>>> c1) that there was work done to fix "crmd: lrmd: stonithd: fixed
>>>>>>> memory
>>>>>>> leaks² but I¹m not sure which particular bug this was related to.
>>>>>>> (And
>>>>>>> those fixes should be in the version I¹m running anyway).
>>>>>>> 
>>>>>>> I¹ve also spotted a few memory leak fixes in
>>>>>>> https://github.com/beekhof/pacemaker, but I¹m not sure whether they
>>>>>>> relate to my issue (assuming I have a memory leak and this isn¹t
>>>>>>> expected behaviour).
>>>>>>> 
>>>>>>> Is there additional debugging that I can perform to check whether I
>>>>>>> have a leak, or is there enough evidence to justify upgrading to
>>>>>>> 1.1.11?
>>>>>>> 
>>>>>>> Thanks in advance
>>>>>>> 
>>>>>>> Greg Murphy
>>>>>>> _______________________________________________
>>>>>>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>>>>>> 
>>>>>>> Project Home: http://www.clusterlabs.org
>>>>>>> Getting started:
>>>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>>>>>> Bugs: http://bugs.clusterlabs.org
>>>>>> 
>>>>> 
>>>>> <lrmd.tgz>_______________________________________________
>>>>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>>>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>>>>> 
>>>>> Project Home: http://www.clusterlabs.org
>>>>> Getting started:
>>>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>>>>> Bugs: http://bugs.clusterlabs.org
>>>> 
>>> 
>> 
>> <lrmd-dbg.tgz>_______________________________________________
>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>> 
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
>



More information about the Pacemaker mailing list