On Wed, 25 Mar 2009 13:19:12 -0600
Scott Marlowe <scott.marlowe@gmail.com> wrote:
> Spend your money on more RAM, (32G isn't much more than 16G and
> I've seen it make a world of difference on our servers). Spend it
> on disks. Number of disks is often more important than RPM etc.
> Spend it on fast RAID controllers with battery backed cache.
> Then, consider upgrading your CPUs. We have 8 opteron cores in
> our servers, and 12 Disk RAID-10s under a very fast RAID
> controller, and we are still I/O not CPU bound.
[snip]
> But all of this depends on the type of workload your db has to
> do. If you're running memory hungry select queries, focus on more
> memory. If you're running lots and lots of little queries with a
> mix of update, insert, delete and select, focus on the drives /
> controller. If you're running queries that require a lot of CPU,
> then focus more on that.
Could IO load show up as apparent CPU load?
I mean I've a pretty small DB. It should fit nearly all in RAM... or
at least... after 1 day of load I can see the box may use 50K of
swap.
Anyway when I update the main table (~1M rows and a gin index) I can
see the CPU reaching its limit. Most frequent updates involves
5K-20K changed record.
On normal workload the most intensive queries run in 200ms with few
exceptions and the BIG table is mostly in read access only.
It would be nice if the update would be a bit faster since I'm still
forced to do them during working hours... because people on the
other side are still convinced it is not worth to clean rubbish at
the source, so sometimes updates fail for inconsistent data.
Unfortunately... I can add ram and disks but all the sockets for CPU
are used.
The box has 2 old Xeon HT at 3.2GHz. It's on RAID5 (not my choice)
on a decent controller and has 4Gb of RAM.
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
