Hi Nuno,
I do use the default appia setting:
<channel name="TCP SEQ Channel" template="tcp_sequencer" initialized="yes">
<memorymanagement size="40000000" up_threshold="15000000"
down_threshold="7000000" />
<chsession name="hederalayer">
<parameter name="gossip_address">224.1.1.5</parameter>
</chsession>
</channel>
<template name="tcp_sequencer">
<session name="TcpComplete" sharing="private">
<protocol>org.continuent.appia.protocols.tcpcomplete.TcpCompleteLayer</protocol>
</session>
<session name="gbl" sharing="private">
<protocol>org.continuent.appia.protocols.group.bottom.GroupBottomLayer</protocol>
</session>
<session name="gol" sharing="private">
<protocol>org.continuent.appia.protocols.group.heal.GossipOutLayer</protocol>
</session>
<session name="suspectl" sharing="private">
<protocol>org.continuent.appia.protocols.group.suspect.SuspectLayer</protocol>
</session>
<session name="intral" sharing="private">
<protocol>org.continuent.appia.protocols.group.intra.IntraLayer</protocol>
</session>
<session name="interl" sharing="private">
<protocol>org.continuent.appia.protocols.group.inter.InterLayer</protocol>
</session>
<session name="hl" sharing="private">
<protocol>org.continuent.appia.protocols.group.heal.HealLayer</protocol>
</session>
<session name="stablel" sharing="private">
<protocol>org.continuent.appia.protocols.group.stable.StableLayer</protocol>
</session>
<session name="ll" sharing="private">
<protocol>org.continuent.appia.protocols.group.leave.LeaveLayer</protocol>
</session>
<session name="vsl" sharing="private">
<protocol>org.continuent.appia.protocols.group.sync.VSyncLayer</protocol>
</session>
<session name="total" sharing="private">
<protocol>org.continuent.appia.protocols.total.sequencer.TotalSequencerLayer</protocol>
</session>
<session name="hederalayer" sharing="private">
<protocol>org.continuent.hedera.appia.HederaSupportLayer</protocol>
</session>
</template>
Where this the Informations you needed?
There was no other unnormal logging...
Thanks for your support!
Best Regards,
Malte
> Hi again,
>
> another question: how is Appia configured? can you post the appia.xml
> config file?
>
> Thanks for your feedback,
> Nuno Carvalho
>
> On May 24, 2007, at 9:24 , Nuno Carvalho wrote:
>
>> Hi,
>>
>> I cannot know by the logs what is causing the memory lick, it could
>> be caused by Appia, but also by other parts of Sequoia. These
>> messages are the cause of the high memory usage, because messages
>> start failing to appear on time and Appia starts to suspect that
>> the other controller has failed. So, these messages seem to be
>> caused by the memory lick.
>>
>> There is nothing more in the logs that is not normal, like messages
>> being sent, but not being delivered, or something like that?
>>
>> kind regards,
>> Nuno Carvalho
>>
>> On May 24, 2007, at 6:45 , [EMAIL PROTECTED] wrote:
>>
>>> Hi @all,
>>>
>>> we've a Scenario with 2 Controllers (Sequoia 2.10.6) and about 50
>>> vdbs.
>>> When I left yesterday, they both had a memory usage around 500MB.
>>> When I arrived this morning, one of them used the complete RAM
>>> (1024 MB).
>>> (There is still the problem of the group communication, mentioned
>>> in the
>>> other topic).
>>> There was no database usage the whole night (I know this, because
>>> nobody
>>> else but me do have any access to the databases.), why do the
>>> memory usage
>>> might grow like this?
>>>
>>> The Logfile do not give a hint, only this interesting thing:
>>>
>>> 2007-05-23 14:42:11,716 INFO
>>> controller.virtualdatabase.test_big_50_C
>>> First controller in group test_big_50_C
>>> 2007-05-23 14:42:11,719 INFO sequoia.controller.recoverylog Checking
>>> recovery log consistency
>>> 2007-05-23 14:42:11,724 INFO controller.core.Controller Adding
>>> VirtualDatabase test_big_50_C
>>> 2007-05-24 04:02:28,861 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:28,987 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:28,995 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:29,508 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:29,558 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:34,830 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:34,833 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:36,251 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:44,975 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:45,266 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:57,933 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:57,936 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:58,029 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:58,044 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:58,049 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:58,056 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:58,095 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:58,098 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:58,139 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:58,196 DEBUG continuent.hedera.gms Appia reported
>>> block()
>>> 2007-05-24 04:02:58,293 DEBUG continuent.hedera.gms Appia reported
>>> new view:
>>> version: 1
>>> group: [Group:test_big_34_C]
>>> id: [ViewID:2;[AppiaHedera@/xxx.234.68.193:36941]]
>>> previous: [[ViewID:1;[AppiaHedera@/xxx.234.68.193:36941]],]
>>> view: [[AppiaHedera@/xxx.234.68.193:36941],]
>>> addresses: [/xxx.234.68.193:36941,]
>>>
>>> 2007-05-24 04:02:58,295 INFO continuent.hedera.gms
>>> Member(address=/xxx.234.68.194:33472, uid=xxx.234.68.194:33472)
>>> failed in
>>> Group(gid=test_big_34_C)
>>> 2007-05-24 04:02:58,398 WARN
>>> controller.virtualdatabase.test_big_34_C
>>> Controller Member(address=/xxx.234.68.194:33472, uid=xxx.
>>> 234.68.194:33472)
>>> has left the cluster.
>>> 2007-05-24 04:02:58,408 INFO
>>> controller.virtualdatabase.test_big_34_C 0
>>> requests were waiting responses from Member(address=/xxx.
>>> 234.68.194:33472,
>>> uid=xxx.234.68.194:33472)
>>> 2007-05-24 04:02:58,816 DEBUG continuent.hedera.gms Appia reported
>>> new view:
>>> version: 1
>>>
>>> There follow a few more "faild in Group" entries, I did not check
>>> until
>>> now, but I think nearly all my vdbs left the cluster over night...
>>> So there was nothing on the cluster for about 13 hours, and then
>>> without
>>> any reason, all the vdbs leave my cluster?! Might this be a reason
>>> for the
>>> high memory usage? Or could the memory usage be a reason for the vdbs
>>> leaving the cluster?
>>>
>>> Do anyone have an Idea for me?
>>>
>>>
>>> _______________________________________________
>>> Sequoia mailing list
>>> [email protected]
>>> https://forge.continuent.org/mailman/listinfo/sequoia
>>
>>
>> --
>> Nuno Carvalho
>> University of Lisbon, Portugal
>> http://dialnp.di.fc.ul.pt
>>
>>
>>
>> _______________________________________________
>> Sequoia mailing list
>> [email protected]
>> https://forge.continuent.org/mailman/listinfo/sequoia
>
>
> --
> Nuno Carvalho
> University of Lisbon, Portugal
> http://dialnp.di.fc.ul.pt
>
>
>
> _______________________________________________
> Sequoia mailing list
> [email protected]
> https://forge.continuent.org/mailman/listinfo/sequoia
>
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
