Question on hardware & server capacity

Поиск
Список
Период
Сортировка
От Steve Wolfe
Тема Question on hardware & server capacity
Дата
Msg-id 008701c2b286$4c9c2ae0$88693fd1@WEASEL
обсуждение исходный текст
Ответы Re: Question on hardware & server capacity  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Question on hardware & server capacity  (Hannu Krosing <hannu@tm.ee>)
Список pgsql-performance
  Well, our current database server is getting tremendously loaded, and
right now there isn't a clear-cut choice as to an upgrade path - at least
not within the commodity hardware market.

  The machine is a dual AthlonMP 2000, with 2 gigs of RAM.  the loads on
the machine are getting out of hand, and performance is noticeably slowed.
'top' shows the CPU's as being anywhere from 30% to 50% idle, with (on
average) 5-10 postmasters in the "non-idle" state.  'vmstat' shows bi/bo
pegged at zero (copious quantities of disk cache, fsync turned off),
interrupts fluctuating between 200 and 1,000 per second (avg. is approx
400), context switches between 1300 and 4500 (avg. is approx 2300).  I
logged some queries, and found that in an average second, the machine
forks off 10 new backends, and responds to 50 selects and 3 updates.

  My feelings are that the machine is being swamped by both the number of
context switches and the I/O, most likely the memory bandwidth.  I'm
working on implementing some connection pooling to reduce the number of
new backends forked off, but there's not much I can do about the sheer
volume (or cost) of queries.

  Now, if quad-Hammers were here, I'd simply throw hardware at it.
Unfortunately, they're not.  So far, about the only commodity-level answer
I can think of would be a dual P4 Xeon, with the 533 MHz bus, and
dual-channel DDR memory.  That would give each processor approximately
double the memory bandwidth over what we're currently running.

  I'm fairly sure that would at least help lower the load, but I'm not
sure by how much.  If anyone has run testing under similar platforms, I'd
love to hear of the performance difference.  If this is going to chop the
loads in half, I'll do it.  If it's only going to improve it by 10% or so,
I'm not going to waste the money.

Steve


В списке pgsql-performance по дате отправления:

Предыдущее
От: george young
Дата:
Сообщение: Re: preliminary testing, two very slow situations...
Следующее
От: Hilmar Lapp
Дата:
Сообщение: join over 12 tables takes 3 secs to plan