On Tue, 2003-07-22 at 11:50, Bruce Momjian wrote: > Jord Tanner wrote: > > On Tue, 2003-07-22 at 10:39, Bruce Momjian wrote: > > > But CPU affinity isn't realated to hyperthreading, as far as I know. > > > CPU affinity tries to keep processes on the same cpu in case there is > > > still valuable info in the cpu cache. > > > > > > > It is true that CPU affinity is designed to prevent the dump of valuable > > CPU cache. My thought is that if you are trying to prevent CPU > > contention, you could use CPU affinity to prevent 2 postmaster processes > > from running simultaneously on the same die. Am I out to lunch here? > > I've not worked with CPU affinity before, so I'm not familiar with the > > intimate details. > > I guess you could but it is the backends that use the cpu. I don't > think manually specifying affinity will work for most applications.
This is beating a dead horse, but I'll take one more kick at it. CPU affinity is defined by a bit mask, so multiple processors can be selected. It is also inherited by child processes, so assigning CPU 0 and CPU 2 (which I assume would be on different dies in a dual processor hyper-threading system) to the parent postmaster should prevent CPU contention with respect to the postgres backend. I would be very interested to see if any advantage could be gained by a combination of multiple HT processors and cpu affinity over multiple non-HT processors. Yet Another Performance Testing To Do (YAPTTD)! -- Jord Tanner <[EMAIL PROTECTED]> ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
