Re: AMD, Intel and RAID controllers
От | Greg Smith |
---|---|
Тема | Re: AMD, Intel and RAID controllers |
Дата | |
Msg-id | alpine.GSO.2.01.0910292132001.17549@westnet.com обсуждение исходный текст |
Ответ на | Re: AMD, Intel and RAID controllers (Scott Marlowe <scott.marlowe@gmail.com>) |
Список | pgsql-performance |
On Fri, 2 Oct 2009, Scott Marlowe wrote: > On Fri, Oct 2, 2009 at 12:47 AM, alpesh gajbe <alpeshgajbe@gmail.com> wrote: > >> We have a Proliant DL585 G5 with 16 cores and 32 GB Ram in the terms of >> processors we found that buying amd makes much more sense because in the >> same price we could put more processors >> on the machine and utilize the multiple cores effectively with PG > > I just bought a machine with 12 2.2GHz AMD cores for less than it > would have cost me for 8 2.26GHz Nehelem cores, so yeah, I've found > the same thing. And as you go up the price difference keeps getting > larger. Huh, apparently I never sent this response...the whole Intel/AMD comparison at this point really depends on how fast you need any individual core to be. The Intel i7 systems I was suggesting I like are expensive, but they are the fastest cores around right now by a good margin too. If your demands are for lots of cores and you don't care how much any one of them executes, then sure the AMD systems will save you quite a bit of cash as suggested above. But it's not difficult to run into situations with a PostgreSQL server where you're bottlenecked waiting for something that can only run on one core at a time. Big reports and COPY are common examples. If that's your situation, there's no substitute for making the individual cores as fast as feasible, and there the price premium Intel charges can easily be worthwhile. And as I already suggested a while ago, if you're disk bound, you shouldn't be worrying about optimizing your processor choice very much at all. Get something cheaper and throw money at spindles and caching instead. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-performance по дате отправления: