On 5/29/06, Andrew Beekhof <[EMAIL PROTECTED]> wrote:
On 5/29/06, Alan Robertson <[EMAIL PROTECTED]> wrote: > Andrew Beekhof wrote: > > Running CTS on 6 nodes has shown MAXMSG to be too small - the PE cannot > > send its transition graph and the cluster stalls indefinitely. > > So, that means the CIB is > 256K compressed? Or is it > 256K uncompressed?its being added with ha_msg_addstruct_compress(msg, field, xml); and sent via IPC to the crmd (from the pengine) whether its actually been compressed or not i dont know. > > > We could increase the value but looking through the code this seems to > > be an artificial limitation to various degrees... > > > > * In some cases its used as a substitute for get_netstringlen(msg) - I > > believe these should be fixed > > > > * In some cases its used to pre-empt checks by "child" functions - I > > believe these should be removed. > > > > The two cases that seem to legitimately use MAXMSG are the HBcomm > > plugins and the decompression code (though even that could retry a > > "couple" of time with larger buffers). > > > > > > Alan, can you please take a look at the use of MAXMSG in the IPC > > layer which is really not my area of expertise (especially the HBcomm > > plugins) and verify that my assessment is correct (and possibly get > > someone to look at fixing it). > > Unfortunately, this means various buffers get locked into memory at this > size. Our processes are already pretty huge. get_netstringlen() is an > expensive call. Thats basically the tradeoff... either we increase MAXMSG and take a hit on the process size, or we do more dynamically and take a runtime hit. Not being a guru in the IPC layer, I dont know which is worse. However, my suspicion was that get_(net)stringlen was not too bad for flat messages and would therefore be preferred. > Why do you think that predicting that child buffers will be too large is > a bad idea? How do you understand that removing it will help? For low values of MAXMSG I think its fine to do that. But we keep upping the value and allocating 256k for regular heartbeat packets seems like a real waste.
though it may be that the HBcomm plugins cant work any other way in which case we just have to keep upping MAXMSG
> Is your concern related to compressed/uncompressed sizes? As above. I'm doing my part and indicating that it can/should be compressed, but i dont know the internals well enough to say for sure.
_______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
