> -----Original Message----- > From: Greg Smith [mailto:greg@xxxxxxxxxxxxxxx] > Sent: Saturday, December 11, 2010 2:18 AM > To: Benjamin Krajmalnik > Cc: pgsql-performance@xxxxxxxxxxxxxx > Subject: Re: Hardware recommendations > > > What sort of total read/write rates are you seeing when iostat is > showing the system 85% busy? That's a useful number to note as an > estimate of just how random the workload is. > I did a vacuum full of the highly bloated, constantly accessed tables, which has improved the situation significantly. I am not seeing over 75% busy right now, but these are some values for the high busy presently: 71% 344 w/s 7644 kw/s 81% 392 w/s 8880 kw/s 79% 393 w/s 9526 kw/s 75% 443 w/s 10245 kw/s 80% 436 w/s 10157 kw/s 76% 392 w/s 8438 kw/s > Have you increased checkpoint parameters like checkpoint_segments? You > need to avoid having checkpoints too often if you're going to try and > use 4GB of memory for shared_buffers. > Yes, I have it configured at 1024 checkpoint_segments, 5min timeout,0.9 compiostat -x 5letion_target > > It's nice to put the logs onto a separate disk because it lets you > measure exactly how much I/O is going to them, relative to the > database. It's not really necessary though; with 14 disks you'll be at > the range where you can mix them together and things should still be > fine. > Thx. I will place them in their own RAID1 (or mirror if I end up going to ZFS) > > > On the processor front, are there advantages to going to X series > processors as opposed to the E series (especially since I am I/O > bound)? Is anyone running this type of hardware, specially on FreeBSD? > Any opinions, especially concerning the Areca controllers which they > use? > > > > It sounds like you should be saving your hardware dollars for more RAM > and disks, not getting faster procesors. The Areca controllers are > fast > and pretty reliable under Linux. I'm not aware of anyone using them > for > PostgreSQL in production on FreeBSD. Aberdeen may have enough > customers > doing that to give you a good opinion on how stable that is likely to > be; they're pretty straight as vendors go. You'd want to make sure to > stress test that hardware/software combo as early as possible > regardless, it's generally a good idea and you wouldn't be running a > really popular combination. > Thx. That was my overall plan - that's why I am opting for drives, cache on the controller, and memory. > -- > Greg Smith 2ndQuadrant US greg@xxxxxxxxxxxxxxx Baltimore, MD > PostgreSQL Training, Services and Support www.2ndQuadrant.us > "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
