Brian Peasland <dba_at_remove_spam.peasland.com> wrote in message news:<3F1E8830.23708CA8_at_remove_spam.peasland.com>...
> > I have since learned that the CPU is
> > pretty busy doing load so the bottleneck could be CPU but we haven't
> > done the work to find out if the IO channels are completely full
> > either.
>
> It sounds like you are finally starting to get to the source of your
> problems. If you are CPU bound, then you can do one of two
> things....find out which processes are consuming the most CPU and see if
> you can reduce that process's reliance on the CPU...or...use faster
> CPUs. Keep in mind that doubling the amount of processors or doubling
> the speed of the processors does not necessarily equate to doubling the
> performance.
>
> >I have been told the 12K has much better IO so it can take
> > advantage of the GBE NAS and it has two NIC's so we can do twice the
> > IO's(?) so maybe with faster processing of the input tapes and better
> > IO to the NAS, we can achieve the SLA's we want?
>
> Databases can be I/O intensive creatures. And I/O can be one of the
> worst problems for a database system. As such, I try to stay away from
> NAS if at all possible. I/O over the network will be worse than direct
> attached disk or a SAN. Even if you are using GBE. You can alleviate
> your I/O bottlenecks by going to multiple NICs on a faster network. You
> can also put the database serve and NAS on a dedicated network so that
> no other network traffic hampers response time. But in the end, you
> won't achieve the I/O performance that direct attached or SAN disks
> will.
>
> HTH,
> Brian
>
I am new to the organisation but I think we might have moved from SAN
to NAS :-( Anyway replacing the NAS is not an option at present since
it's shared by our SAP system. Direct attached storage is not really
an option but going back to a decent SAN might be (can still reuse the
disks). Now doing some more analysis to work out where the problems
are and so what the right solution will be
Received on Sat Jul 26 2003 - 06:32:52 CDT
