On Wed, Dec 12, 2012 at 11:17 PM, Vladislav Bogdanov
wrote:
> Ok, the main conclusion I can make is that pacemaker does not have any
> memory leaks in code paths used by a static cluster.
Huzah! :)
___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.
12.12.2012 05:35, Andrew Beekhof wrote:
> On Tue, Dec 11, 2012 at 5:49 PM, Vladislav Bogdanov
> wrote:
>> 11.12.2012 06:52, Vladislav Bogdanov wrote:
>>> 11.12.2012 05:12, Andrew Beekhof wrote:
On Mon, Dec 10, 2012 at 11:34 PM, Vladislav Bogdanov
wrote:
> 10.12.2012 09:56, Vladislav
On Tue, Dec 11, 2012 at 5:49 PM, Vladislav Bogdanov
wrote:
> 11.12.2012 06:52, Vladislav Bogdanov wrote:
>> 11.12.2012 05:12, Andrew Beekhof wrote:
>>> On Mon, Dec 10, 2012 at 11:34 PM, Vladislav Bogdanov
>>> wrote:
10.12.2012 09:56, Vladislav Bogdanov wrote:
> 10.12.2012 04:29, Andrew B
On Tue, Dec 11, 2012 at 2:52 PM, Vladislav Bogdanov
wrote:
> 11.12.2012 05:12, Andrew Beekhof wrote:
>> On Mon, Dec 10, 2012 at 11:34 PM, Vladislav Bogdanov
>> wrote:
>>> 10.12.2012 09:56, Vladislav Bogdanov wrote:
10.12.2012 04:29, Andrew Beekhof wrote:
> On Fri, Dec 7, 2012 at 5:37 PM,
11.12.2012 06:52, Vladislav Bogdanov wrote:
> 11.12.2012 05:12, Andrew Beekhof wrote:
>> On Mon, Dec 10, 2012 at 11:34 PM, Vladislav Bogdanov
>> wrote:
>>> 10.12.2012 09:56, Vladislav Bogdanov wrote:
10.12.2012 04:29, Andrew Beekhof wrote:
> On Fri, Dec 7, 2012 at 5:37 PM, Vladislav Bogda
11.12.2012 05:12, Andrew Beekhof wrote:
> On Mon, Dec 10, 2012 at 11:34 PM, Vladislav Bogdanov
> wrote:
>> 10.12.2012 09:56, Vladislav Bogdanov wrote:
>>> 10.12.2012 04:29, Andrew Beekhof wrote:
On Fri, Dec 7, 2012 at 5:37 PM, Vladislav Bogdanov
wrote:
> 06.12.2012 09:04, Vladislav
On Mon, Dec 10, 2012 at 11:34 PM, Vladislav Bogdanov
wrote:
> 10.12.2012 09:56, Vladislav Bogdanov wrote:
>> 10.12.2012 04:29, Andrew Beekhof wrote:
>>> On Fri, Dec 7, 2012 at 5:37 PM, Vladislav Bogdanov
>>> wrote:
06.12.2012 09:04, Vladislav Bogdanov wrote:
> 06.12.2012 06:05, Andrew B
On Mon, Dec 10, 2012 at 5:56 PM, Vladislav Bogdanov
wrote:
> 10.12.2012 04:29, Andrew Beekhof wrote:
>> On Fri, Dec 7, 2012 at 5:37 PM, Vladislav Bogdanov
>> wrote:
>>> 06.12.2012 09:04, Vladislav Bogdanov wrote:
06.12.2012 06:05, Andrew Beekhof wrote:
> I wonder what the growth looks l
10.12.2012 09:56, Vladislav Bogdanov wrote:
> 10.12.2012 04:29, Andrew Beekhof wrote:
>> On Fri, Dec 7, 2012 at 5:37 PM, Vladislav Bogdanov
>> wrote:
>>> 06.12.2012 09:04, Vladislav Bogdanov wrote:
06.12.2012 06:05, Andrew Beekhof wrote:
> I wonder what the growth looks like with the rec
10.12.2012 04:29, Andrew Beekhof wrote:
> On Fri, Dec 7, 2012 at 5:37 PM, Vladislav Bogdanov
> wrote:
>> 06.12.2012 09:04, Vladislav Bogdanov wrote:
>>> 06.12.2012 06:05, Andrew Beekhof wrote:
I wonder what the growth looks like with the recent libqb fix.
That could be an explanation.
>
On Fri, Dec 7, 2012 at 5:37 PM, Vladislav Bogdanov wrote:
> 06.12.2012 09:04, Vladislav Bogdanov wrote:
>> 06.12.2012 06:05, Andrew Beekhof wrote:
>>> I wonder what the growth looks like with the recent libqb fix.
>>> That could be an explanation.
>>
>> Valid point. I will watch.
>
> On a almost s
06.12.2012 09:04, Vladislav Bogdanov wrote:
> 06.12.2012 06:05, Andrew Beekhof wrote:
>> I wonder what the growth looks like with the recent libqb fix.
>> That could be an explanation.
>
> Valid point. I will watch.
On a almost static cluster the only change in memory state during 24
hours is +70
06.12.2012 06:05, Andrew Beekhof wrote:
> I wonder what the growth looks like with the recent libqb fix.
> That could be an explanation.
Valid point. I will watch.
>
> On Sat, Sep 15, 2012 at 5:23 AM, Vladislav Bogdanov
> wrote:
>> 14.09.2012 09:54, Vladislav Bogdanov wrote:
>>> 13.09.2012 15:1
I wonder what the growth looks like with the recent libqb fix.
That could be an explanation.
On Sat, Sep 15, 2012 at 5:23 AM, Vladislav Bogdanov
wrote:
> 14.09.2012 09:54, Vladislav Bogdanov wrote:
>> 13.09.2012 15:18, Vladislav Bogdanov wrote:
>>
>> ...
>>
>>> and now it runs on my testing clust
14.09.2012 09:54, Vladislav Bogdanov wrote:
> 13.09.2012 15:18, Vladislav Bogdanov wrote:
>
> ...
>
>> and now it runs on my testing cluster.
>>
>> Ipc-related memory problems seem to be completely fixed now, processes
>> own memory (RES-SHR in terms of htop) does not grow any longer (after 40
>>
13.09.2012 15:18, Vladislav Bogdanov wrote:
...
> and now it runs on my testing cluster.
>
> Ipc-related memory problems seem to be completely fixed now, processes
> own memory (RES-SHR in terms of htop) does not grow any longer (after 40
> minutes). Although I see that both RES and SHR counters
13.09.2012 06:16, Andrew Beekhof wrote:
> On Thu, Sep 13, 2012 at 12:30 AM, Vladislav Bogdanov
> wrote:
>> 12.09.2012 10:35, Andrew Beekhof wrote:
>>> On Tue, Sep 11, 2012 at 6:14 PM, Vladislav Bogdanov
>>> wrote:
07.09.2012 09:25, Vladislav Bogdanov wrote:
> 06.09.2012 12:58, Vladislav
On Thu, Sep 13, 2012 at 12:30 AM, Vladislav Bogdanov
wrote:
> 12.09.2012 10:35, Andrew Beekhof wrote:
>> On Tue, Sep 11, 2012 at 6:14 PM, Vladislav Bogdanov
>> wrote:
>>> 07.09.2012 09:25, Vladislav Bogdanov wrote:
06.09.2012 12:58, Vladislav Bogdanov wrote:
...
> lrmd seems not to
12.09.2012 10:35, Andrew Beekhof wrote:
> On Tue, Sep 11, 2012 at 6:14 PM, Vladislav Bogdanov
> wrote:
>> 07.09.2012 09:25, Vladislav Bogdanov wrote:
>>> 06.09.2012 12:58, Vladislav Bogdanov wrote:
>>> ...
lrmd seems not to clean up gio channels properly:
>>>
>>> I prefer to call g_io_channel
On Tue, Sep 11, 2012 at 6:14 PM, Vladislav Bogdanov
wrote:
> 07.09.2012 09:25, Vladislav Bogdanov wrote:
>> 06.09.2012 12:58, Vladislav Bogdanov wrote:
>> ...
>>> lrmd seems not to clean up gio channels properly:
>>
>> I prefer to call g_io_channel_unref() right after g_io_add_watch_full()
>> inst
07.09.2012 09:25, Vladislav Bogdanov wrote:
> 06.09.2012 12:58, Vladislav Bogdanov wrote:
> ...
>> lrmd seems not to clean up gio channels properly:
>
> I prefer to call g_io_channel_unref() right after g_io_add_watch_full()
> instead of doing so when deleting descriptor (g_source_remove() is
> en
06.09.2012 12:58, Vladislav Bogdanov wrote:
...
> lrmd seems not to clean up gio channels properly:
I prefer to call g_io_channel_unref() right after g_io_add_watch_full()
instead of doing so when deleting descriptor (g_source_remove() is
enough there). So channel will be automatically freed after
07.09.2012 03:03, Andrew Beekhof wrote:
...
>>> cib shows tons of reachable memory in finished child processes. Not
>>> important but log is huge, so it is very hard to find real errors.
>>
>> I found two minor (very slow) leaks in cib too:
>>
>> ==1732== 80 bytes in 20 blocks are still reachable
On 06/09/2012, at 10:43 PM, Vladislav Bogdanov wrote:
> 06.09.2012 12:58, Vladislav Bogdanov wrote:
>> 06.09.2012 12:39, Andrew Beekhof wrote:
>>> On Thu, Sep 6, 2012 at 5:33 PM, Vladislav Bogdanov
>>> wrote:
06.09.2012 10:19, Andrew Beekhof wrote:
> On Thu, Sep 6, 2012 at 5:14 PM, Vl
- Original Message -
> From: "Vladislav Bogdanov"
> To: pacemaker@oss.clusterlabs.org
> Sent: Thursday, September 6, 2012 4:58:45 AM
> Subject: Re: [Pacemaker] pacemaker processes RSS growth
>
> 06.09.2012 12:39, Andrew Beekhof wrote:
> > On Thu,
06.09.2012 12:58, Vladislav Bogdanov wrote:
> 06.09.2012 12:39, Andrew Beekhof wrote:
>> On Thu, Sep 6, 2012 at 5:33 PM, Vladislav Bogdanov
>> wrote:
>>> 06.09.2012 10:19, Andrew Beekhof wrote:
On Thu, Sep 6, 2012 at 5:14 PM, Vladislav Bogdanov
wrote:
> Hi,
>
> I noticed t
06.09.2012 12:39, Andrew Beekhof wrote:
> On Thu, Sep 6, 2012 at 5:33 PM, Vladislav Bogdanov
> wrote:
>> 06.09.2012 10:19, Andrew Beekhof wrote:
>>> On Thu, Sep 6, 2012 at 5:14 PM, Vladislav Bogdanov
>>> wrote:
Hi,
I noticed that some pacemaker processes grow during operation (co
On Thu, Sep 6, 2012 at 5:33 PM, Vladislav Bogdanov wrote:
> 06.09.2012 10:19, Andrew Beekhof wrote:
>> On Thu, Sep 6, 2012 at 5:14 PM, Vladislav Bogdanov
>> wrote:
>>> Hi,
>>>
>>> I noticed that some pacemaker processes grow during operation (commit
>>> 8535316). Running on top of corosync 2.0.1
06.09.2012 10:19, Andrew Beekhof wrote:
> On Thu, Sep 6, 2012 at 5:14 PM, Vladislav Bogdanov
> wrote:
>> Hi,
>>
>> I noticed that some pacemaker processes grow during operation (commit
>> 8535316). Running on top of corosync 2.0.1.
>> I notched RSS size (RES as htop reports) with interval of ~18
On Thu, Sep 6, 2012 at 5:14 PM, Vladislav Bogdanov wrote:
> Hi,
>
> I noticed that some pacemaker processes grow during operation (commit
> 8535316). Running on top of corosync 2.0.1.
> I notched RSS size (RES as htop reports) with interval of ~18 hours.
> First column is notched after ~1 hour of
Hi,
I noticed that some pacemaker processes grow during operation (commit
8535316). Running on top of corosync 2.0.1.
I notched RSS size (RES as htop reports) with interval of ~18 hours.
First column is notched after ~1 hour of operation.
Results are:
pengine 23568 23780
crmd 1
31 matches
Mail list logo