Re: CPUs for new databases
От | Ivan Voras |
---|---|
Тема | Re: CPUs for new databases |
Дата | |
Msg-id | ia7r55$5ih$1@dough.gmane.org обсуждение исходный текст |
Ответ на | Re: CPUs for new databases (James Cloos <cloos@jhcloos.com>) |
Ответы |
Re: CPUs for new databases
Re: CPUs for new databases |
Список | pgsql-performance |
On 10/27/10 01:45, James Cloos wrote: >>>>>> "JB" == Josh Berkus<josh@agliodbs.com> writes: > > JB> In a general workload, fewer faster cores are better. We do not scale > JB> perfectly across cores. The only case where that's not true is > JB> maintaining lots of idle connections, and that's really better dealt > JB> with in software. > > I've found that ram speed is the most limiting factor I've run into for > those cases where the db fits in RAM. The less efficient lookups run > just as fast when the CPU is in powersving mode as in performance, which > implies that the cores are mostly waiting on RAM (cache or main). > > I suspect cache size and ram speed will be the most important factors > until the point where disk i/o speed and capacity take over. FWIW, yes - once the IO is fast enough or not necessary (e.g. the read-mostly database fits in RAM), RAM bandwidth *is* the next bottleneck and it really, really can be observed in actual loads. Buying a QPI-based CPU instead of the cheaper DMI-based ones (if talking about Intel chips), and faster memory modules (DDR3-1333+) really makes a difference in this case. (QPI and DMI are basically the evolution the front side bus; AMD had HT - HyperTransport for years now. Wikipedia of course has more information for the interested.)
В списке pgsql-performance по дате отправления: