Abhijit Menon-Sen <a...@2ndquadrant.com> wrote: > Spread shared memory across NUMA memory nodes > Marked waiting on author, but status unclear. Any updates?
The review was a little sparse: http://www.postgresql.org/message-id/CADyhKSXs+oUetngSbeiM0tVSRy=QeCaSNBQBDbM=sfqtdg+...@mail.gmail.com In particular, there was no benchmarking of any sort in the review. I did some benchmarking on a 16 core Power PC machine with 4 NUMA memory nodes, and found that the benefit was overall about 2% in the unbalanced memory node tests I was able to devise. Unless memory usage was unbalanced I saw no overall difference. Timings with the patch varied less from run to run than without the patch. Where I saw worse performance in the field (prompting me to work on this patch) was on an Intel 40 core 4 memory node system. Perhaps that is necessary to see the really bad behavior. I am not sure that the modest worst-case benefits I have seen justify applying the patch, especially since to see that I also needed to set up a custom cpuset to run PostgreSQL under so that the OS also used interleaving for its cache. I did have one outlier for the unpatched code which was about 20% worse than average, and no such outliers for patched code. I have seen reports of much worse performance hits from an unbalanced load than I was able to reliably produce, so I was hoping that someone with more creativity in creating worst case tests would see what they could do. IMV, the best argument for the patch is as insurance against such pessimal events. The suggestion that there be a GUC to suppress the interleaving of the main shared memory segment among NUMA memory nodes is interesting. I'm dubious, but I guess it would allow an opt-out escape hatch if someone found unexpected performance problems with it in the field. It's certainly trivial to add; the main argument against it is that it is another knob that might confuse users. Anyway, Waiting on Author is probably not the best state for this patch; there's nothing that I feel there is a consensus to change. I'm OK with either Needs Review or Returned with Feedback. If someone can produce a benchmark showing more benefit than I was able to show, it can be revived in a later CF. Perhaps as more machines with high core counts and multiple NUMA memory nodes become more common the cases where we run into trouble will become more clear. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
