Hi folks,
I'm running PG 8.3.15 on an itanium box and was seeing lots of
floating-point assist faults by the kernel. Searched around, found a
couple references/discussions here and there:
http://archives.postgresql.org/pgsql-general/2008-08/msg00244.php
http://archives.postgresql.org/pgsql-performance/2011-06/msg00093.php
http://archives.postgresql.org/pgsql-performance/2011-06/msg00102.php
I took up Tom's challenge and found that the buffer allocation prediction
code in BgBufferSync() is the likely culprit:
if (smoothed_alloc <= (float) recent_alloc)
smoothed_alloc = recent_alloc;
else
smoothed_alloc += ((float) recent_alloc - smoothed_alloc) /
smoothing_samples;
smoothed_alloc (float) is moving towards 0 during any extended period of
time when recent_alloc (uint32) remains 0. In my case it takes just a
minute or two before it becomes small enough to start triggering the
fault.
Given how smoothed_alloc is used just after this place in the code it
seems overkill to allow it to continue to shrink so small, so I made a
little mod:
if (smoothed_alloc <= (float) recent_alloc)
smoothed_alloc = recent_alloc;
else if (smoothed_alloc >= 0.00001)
smoothed_alloc += ((float) recent_alloc - smoothed_alloc) /
smoothing_samples;
This seems to have done the trick. From what I can tell this section of
code is unchanged in 9.1.1 - perhaps in a future version a similar mod
could be made?
FWIW, I don't think it's really much of a performance impact for the
database, because if recent_alloc remains 0 for a long while it probably
means the DB isn't doing much anyway. However it is annoying when system
logs fill up, and the extra floating point handling may affect some other
process(es).
-Greg
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
