On 04/09/2013, at 4:09 PM, Vladislav Bogdanov <[email protected]> wrote:
> 04.09.2013 07:16, Andrew Beekhof wrote: >> >> On 03/09/2013, at 9:20 PM, Moullé Alain <[email protected]> >> wrote: >> >>> Hello, >>> >>> A simple question : is there a maximum number of resources (let's >>> say simple primitives) that Pacemaker can support at first at >>> configuration of ressources via crm, and of course after >>> configuration when Pacemaker has to monitor all the primitives ? >> >> Simple answer: it depends >> >>> (more precisely, could we envisage around 500 or 600 primitives, or >>> is it completely mad ? ;-) ) >>> >>> (I know it is dependant on node power, CPU, mem, etc., but I'm >>> speaking here only of eventual Pacemaker limitations) >> >> There is no inherent limit, the policy engine can cope with many >> thousands. >> >> The CIB is less able to cope - for which batch-limit is useful (to >> throttle the number of operation updates being thrown at the CIB >> which limits its CPU usage). The other limit is local and cluster >> messaging sizes - once the compressed cib gets too big for either or >> both transports you can no longer even run 'cibadmin -Q' >> >> For IPC, the limit is tuneable via the environment. For corosync, its >> high (1Mb) but (I think) only tuneable at compile time. > > Are there any possibilities/plans to implement "partial" messages? This is part of the reason we send only the changes that result from an update. Message fragmenting would have to happen at the corosync/libqb level.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
