In response to my blog post on lseek contention, someone posted a
comment wherein they proposed using fstat() rather than lseek() to get
file sizes.
http://rhaas.blogspot.com/2011/08/linux-and-glibc-scalability.html
I tried that on a RHEL 6.1 machine with 64-cores running
2.6.32-131.6.1.el6.x86_64, and it's pretty clear that the locking
characteristics are completely different. At 1 client, the lseek
method appears to be slightly faster, although it's not beyond belief
that the difference could be in the noise. Above 40 cores, however,
the fstat method thumps the lseek method up one side and down the
other.
Patch and test results are attached. Test runs are 5-minute runs with
scale factor 100 and shared_buffers=8GB.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company