Re: Horrible CREATE DATABASE Performance in High Sierra
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Brent Dearth <brent.dearth@gmail.com>, pgsql-hackers@postgresql.org
Date: 2017-10-03T03:06:09Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2017-10-02 19:50:51 -0400, Tom Lane wrote: >> What I saw was that the backend process was consuming 100% of (one) CPU, >> while the I/O transaction rate viewed by "iostat 1" started pretty low >> --- under 10% of what the machine is capable of --- and dropped from >> there as the copy proceeded. I did not think to check if that was user >> or kernel-space CPU, but I imagine it has to be the latter. > So that's pretty clearly a kernel bug... Hm. I wonder if it's mmap() or > msync() that's the problem here. I guess you didn't run a profile? Interestingly, profiling with Activity Monitor seems to blame the problem entirely on munmap() ... which squares with the place I hit every time when randomly stopping the process with gdb^Hlldb, so I'm inclined to believe it. This still offers no insight as to why CREATE DATABASE is hitting the problem while regular flush activity doesn't. > One interesting thing here is that in the CREATE DATABASE case there'll > probably be a lot larger contiguous mappings than in *_flush_after > cases. So it might be related to the size of the mapping / flush "unit". Meh, the mapping is only 64K in this case vs. 8K in the other. Hard to credit that it breaks that easily. regards, tom lane
Commits
-
Increase distance between flush requests during bulk file copies.
- c3723317d08c 10.1 landed
- 643c27e36ff3 11.0 landed
- 13a8924ecf00 9.6.6 landed