On 2/21/07, Alan Robertson <[EMAIL PROTECTED]> wrote:
Lars Marowsky-Bree wrote:
> Andrew's measured 10% performance increase suggests that we should make
> this the default, IMHO, at least on Linux: apparently, our glibc
> allocators are better than heartbeats.
>
> I've been running tests with it and not found any issues.
>
> I'll probably make this the default on SLES, but think it'd make sense
> for upstream as well.

Heartbeat on the average on a real running system should take < 1% or
less of system resources.

yeah, when its not doing anything.

you know full well that we use significantly more during failover.

how about we also factor in that cluster nodes only account for, say,
5% of a site's resources?
then the it only changes the percentages from 0.05% to 0.049%... yeah,
totally not worth it.

A 10% overhead for something the user never benefits from is
significant, but If you want to fiddle the numbers so you can feel
better - go ahead.

 Dropping that to .9% really doesn't excite me
at all.  And, my guess is that it makes the most difference for the CRM
-- which does LOTS more mallocs than anything else (as it must), and
usually does nothing most of the time on a real running system.  So, my
guess is that it drops it more like 5% or so rather than 10%.

Andrew has been having some trouble with use-after-frees recently.  Our
code catches that -- if it's enabled ;-).

apparently not all the time

If it's disabled, it doesn't
help anything.

If you're referring to what Coverity caught last week, those have been
in existence for a long time and clmalloc never caught them because
they were in error paths.

The others were found after running Valgrind which gives you both a
stack-trace of where it happened and a complete stack-trace of who
free'd it originally.  Slightly more useful than "that memory is
already free'd, bye".  I dont know why clmalloc didnt complain in the
past.
_______________________________________________________
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/

Reply via email to