Re: Adding basic NUMA awareness
От | Andres Freund |
---|---|
Тема | Re: Adding basic NUMA awareness |
Дата | |
Msg-id | x7hiy5tyhxlxmisanlr3zu4eax4vqldutrcymx3jocjo4djkqm@v5f3ca657klu обсуждение исходный текст |
Ответ на | Adding basic NUMA awareness (Tomas Vondra <tomas@vondra.me>) |
Ответы |
Re: Adding basic NUMA awareness
|
Список | pgsql-hackers |
Hi, On 2025-07-08 14:27:12 +0200, Tomas Vondra wrote: > On 7/8/25 05:04, Andres Freund wrote: > > On 2025-07-04 13:05:05 +0200, Jakub Wartak wrote: > > The reason it would be advantageous to put something like the procarray onto > > smaller pages is that otherwise the entire procarray (unless particularly > > large) ends up on a single NUMA node, increasing the latency for backends on > > every other numa node and increasing memory traffic on that node. > > > > That's why the patch series splits the procarray into multiple pieces, > so that it can be properly distributed on multiple NUMA nodes even with > huge pages. It requires adjusting a couple places accessing the entries, > but it surprised me how limited the impact was. Sure, you can do that, but it does mean that iterations over the procarray now have an added level of indirection... > The thing I'm not sure about is how much this actually helps with the > traffic between node. Sure, if we pick a PGPROC from the same node, and > the task does not get moved, it'll be local traffic. But if the task > moves, there'll be traffic. I don't have any estimates how often this > happens, e.g. for older tasks. I think the most important bit is to not put everything onto one numa node, otherwise the chance of increased latency for *everyone* due to the increased memory contention is more likely to hurt. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: