Andrew Beekhof 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.
It should be compressed if you have specified compression method ha.cf.
However it would be
good to have some proof that it is compressed. Having a message > 256K
after compression means
the uncompressed one probably has 1M ~2M
Another way that might be interesting is to provide an API that has much
higher bound, which is suited for local
usage only.
> 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.
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.
Andrew, if you can send log/debug file to me, I may (or may not) find
some clue
-Guochun
_______________________________________________________
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/
