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
filesize.patch
Description: Binary data
pgbench -S at 32 cores - fstat patch comparison.ods
Description: application/vnd.oasis.opendocument.spreadsheet
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
