UNIX for Advanced & Expert Users

Hi everyone, newbie forum poster here. I'm an Oracle DBA and I require some guidance from the Unix gurus here about how to pinpoint where a problem is within a Solaris 9 system running on an 8 CPU Fujitsu server that acts as our Oracle database server. Our sysadmins are trying their best to resolve the issue but none of us are 100% sure where the issue resides - I'm hoping people here can help shed some light on things or help point us in a new/better direction.

Environment:
Server: Fujitsu P650, (7 cpu in use, 48GB RAM) Solaris 9 Generic_122300-22 sun4us sparc FJSV,GPUZC-M
Old Storage: EMC Clarion fibre attached storage
New Storage: NetApp storage, 3040 Controller, NFS mounted volumes via multi trunked1GB ethernet connection (not round robin)
Database: Oracle 9i

Problem: We are migrating our storage from fibre EMC to NFS NetApp and are encountering huge performance degradation... pin pointing where the problem is has been problematic. (As a DBA I seriously questioned this move, but this point is now moot as the money has been spent and we have to deal with it.)

Detail: We've been slowly migrating our databases off of the fibre EMC to NFS NetApp Some of our high performance databases struggled mightily on the NetApp storage and there has been lots of finger pointing as to why.

Symptoms: Over time (hours to days) database jobs and response times nosedive - lots of hooting and hollering from the business System response time can be extremely slow.. simple commands “df -h” “ls” slow in responding. However system load is typically minimal, almost non-existant. (low 1's and 2's for load) however at times we can see high kernel processing times.

Advice from our sysadmins: Current advice from one admin is that the Fujitsu server is older hardware that is not built for this kind of transaction processing. They have been monitoring “counters on the PCI bus (66MHz) and are seeing overflow issues” (forgive me if this isn't well articulated) and noticing that it “has problems keeping up”. Another sys admin feels that the PCI bus has nothing to do with it and that it is networking related: specifically that while we have trunking in place to the NetApp filer, it is not round robin and as a result the pipe from the server to the storage is too small for any given transaction (which from Oracle will necessarily be single threaded) Having conflicting reports from the sys admins is not great.

Are there any recommendations on where the problem possibly lies? (obviously this is very difficult to do from a few paragraphs). Or perhaps more realistically, aside from looking at top/prstat to see low load, iostat to see ok I/O processing times, sysadmins checking counters on a PCI bus, is there any other tools, either available in Solaris or 3rd party that can be used to definitively say “AHA! That is definitely where the bottleneck is!”

Many thanks in advance..

There was a time you could buy HP Glance for solaris (if still possible try to get a free evaluation limited time copy). there is also sysload that is quite good...
NFS can be tricky to configure and optimize properly...
You havent said much about your network switches.. Ive seen switches go nuts and drive big cluster down (with NFS, oracle apps etc...)

What is the network protocol used for the EMC fiber channel and what were the specs of that channel?

My first thoughts are that the EMC fiber channel is much higher performing than NFS over Ethernet.

That is the first place I would check.

Also, I hope you have not completely shut down the original system. That is unwise, because you have no baseline to check against any more.

I would tend to think your troubles are IO related as you state your system is slow while processing is low. The nose diving points to a severe bottleneck situation, perhaps when Oracle has trouble writing to its archived redo logs or there is reporting activity during the day.

I know that if you want to use Oracle on Netapp / NFS there are some very specific instructions/settings for NFS on both server (the Netapp) and client (your Fujitsu Server) that you have to follow really meticulously.

Also, I think it may be advisable to create a separate storage LAN of VLAN, so you are not interfering with other traffic, or maybe have separate segments and spread the storage over several NFS mountpoints to different segments. If possible I would implement Jumbo ethernet frames, to optimize sequential IO a bit (full table scans, index scans).

Your server appears to have room for many slow (dedicated) PCI slots, so I would tend to spread the load over the PCI-slots to reach the required bandwidth.

Just some thoughts.. good luck.

S.

You post that this is Gigabit Ethernet. The fibre connection from your old solution would be better.

First check that all ethernet cards on the server are set to NOT autonegotiate and that none of the ports on the hub/switch are set to autonegotiate and that no port involving your storage device is set to autonegotiate. If you have to change anything, schedule a cold start afterwards.

A 66MHz, 64-bit PCI bus can handle 4 gbps, so unless it's a badly-engineered bus, that shouldn't be your problem.

Also, do NOT remove the autonegotiate feature from your network cards and switches if you're running gigE over copper.

1. If your links are not running at 1000 mbps, full-duplex, there's a problem. Papering over that underlying problem by forcing the link to 1000 mpbs full-duplex doesn't fix the problem.

2. Disabling autonegotiation on copper gigE places you outside the specifications of IEEE 802.3: (http://www.sun.com/blueprints/0704/817-7526.pdf)

I'd look to be sure you do all the tuning that Oracle advises for running over NFS. Especially make sure you're using jumbo frames.

And you might very well need to look into replacing your old hardware and software. There have been a lot of hardware and software advances in networking performance since Solaris 9 was current.

achenlie is correct. If you have dropped to half-duplex it will be chronically slow. Just re-patching a cable can be enough to cause this issue when autonegotiation is in force. If you have the problem it may well be fixed by a total cold start where you bring up the network first, then the storage, then the servers.
Imho whether Jumbo Packets will cause or cure a performance issue depends on the network hardware.

To get an idea of scale, can your DBA post the contents of the following Oracle 9i system table along with how long the Oracle server had been up at the time:

Code:

v$sysstat

This table includes i/o stats and other useful pointers such as counts of performance killers like disc sorts.