Question on hardware & server capacity
От | Steve Wolfe |
---|---|
Тема | Question on hardware & server capacity |
Дата | |
Msg-id | 008701c2b286$4c9c2ae0$88693fd1@WEASEL обсуждение исходный текст |
Ответы |
Re: Question on hardware & server capacity
Re: Question on hardware & server capacity |
Список | 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 по дате отправления: