On 3/7/13 12:15 AM, Daniel Farina wrote:
> I have only done some cursory research, but cpu-time of 20% seem to
> expected for InnoDB's CRC computation[0]. Although a galling number,
> this comparison with other systems may be a way to see how much of
> that overhead is avoidable or just the price of entry. It's unclear
> how this 20% cpu-time compares to your above whole-system results, but
> it's enough to suggest that nothing comes for (nearly) free.
That does provide a useful measuring point: how long does the
computation take compared to the memcpy that moves the buffer around.
It looks like they started out with 3.2 memcpy worth of work, and with
enough optimization ended up at 1.27 worth.
The important thing to keep in mind is that shared_buffers works pretty
well at holding on to the most frequently accessed information. A
typical server I see will show pg_statio information suggesting 90%+ of
block requests are coming from hits there, the rest misses suggesting a
mix of OS cache and real disk reads. Let's say 90% are hits, 5% are
fetches at this 20% penalty, and 5% are real reads where the checksum
time is trivial compared to physical disk I/O. That works out to be a
real average slowdown of 6%. I think way more deployments are going to
be like that case, which matches most of my pgbench runs, than the worse
case workloads.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
