Re: possible improvement between G4 and G5

There are a few things that you can do to help force yourself to be I/O
bound. These include:

- RAID 5 for write intensive applications, since multiple writes per synch
write is good. (There is a special case for logging or other streaming
sequential writes on RAID 5)

- Data journaling file systems are helpful in stress testing your
checkpoints

- Using midsized battery backed up write through buffering controllers. In
general, if you have a small cache, you see the problem directly, and a huge
cache will balance out load and defer writes to quieter times. That is why a
midsized cache is so useful in showing stress in your system only when it is
being stressed.

Only partly in jest,
/Aaron

BTW - I am truly curious about what happens to your system if you use
separate RAID 0+1 for your logs, disk sorts, and at least the most active
tables. This should reduce I/O load by an order of magnitude.

"Vivek Khera" <khera(at)kcilink(dot)com> wrote in message
news:x7smez7tqj(dot)fsf(at)yertle(dot)int(dot)kciLink(dot)com(dot)(dot)(dot)
> >>>>> "JB" == Josh Berkus <josh(at)agliodbs(dot)com> writes:
>
> JB> Aaron,
> >> I do consulting, so they're all over the place and tend to be complex.
Very
> >> few fit in RAM, but still are very buffered. These are almost all
backed
> >> with very high end I/O subsystems, with dozens of spindles with battery
> >> backed up writethrough cache and gigs of buffers, which may be why I
worry
> >> so much about CPU. I have had this issue with multiple servers.
>
> JB> Aha, I think this is the difference. I never seem to be able to
> JB> get my clients to fork out for adequate disk support. They are
> JB> always running off single or double SCSI RAID in the host server;
> JB> not the sort of setup you have.
>
> Even when I upgraded my system to a 14-spindle RAID5 with 128M cache
> and 4GB RAM on a dual Xeon system, I still wind up being I/O bound
> quite often.
>
> I think it depends on what your "working set" turns out to be. My
> workload really spans a lot more of the DB than I can end up caching.
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Vivek Khera, Ph.D. Khera Communications, Inc.
> Internet: khera(at)kciLink(dot)com Rockville, MD +1-301-869-4449 x806
> AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>