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.
