What tool are you referring to that leads you to determine that the SAN is saturated?
What type of Dell SAN (model)? You say network @ 50%, so does this mean iSCSI? Netapp type filer using NFS?
Anyone here have experience with Dell San arrays?
We have a process we run to back up a 200g oracle db. We tar and gzip it.
When the DB was less than 200g it finished in 4 or 5 hours. Last week we were up to 8 hours with a hair over 200gigs of data. Now it's even longer. All system indicators show the system performing the tar gzip is running okay. The SAN is showing 100% busy, but our SAN guy says thats normal even with Windows boxes.
The network is less than 50% utilized during this time period. So, I'm thinking the SAN is our slowdown, but I can't prove it.
We tried just tar'ing the files, leaving the gzip processing off. The process still slow, averaging 5 gigs an hour. We had to kill it.
Any ideas, or has anyone else seen something like this?
I'll try to explain it better. The slow processing is the only reason I think the SAN is causing the slowdown. We're running a Dell CX600. The windows admin who runs the SAN see's performance numbers saying the SAN is at 100% busy. But, he says that is normal. He see this when the SAN is doing it's regular operations. So, he does not belive the SAN is the problem.
I say the network is 50% busy because our network shop runs a performance tool which shows the health of the network. Our backup process takes hours. The network utilization during those hours is less than 50% during the time period in question.
The Dell 6650 4 way has a load average less than 2, and is chugging along averaging 25% busy.
SCSI drives, but gigabit network. Not sure what iSCSI is.Originally Posted by outlaw
We're using NavSphere and Powerpath to connect to the SAN using OCFS file system.
Hope this helps explain the enviroment. I'm new to it also, and hope I did not misstate it.
Last edited by DotHQ; 03-03-2006 at 05:32 PM.
My understanding thus far:
Your database server, the PE 6650 is fibre channel attached to the CX600. The database itself is on a RAID 1+0 SCSI device, probably /dev/emcpower[x].
What process are you using to do the exports? Exporting and then tarring and gzipping with another SAN LUN as the destination? Or are you tarring and gzipping with the destination being a NFS or CIFS share exported from the windows box?
Basically, detail the steps you are using to ship the database export.
My experience with OCFS is that it is slow as molasses. We run it under Windows, but since it is a file system, it might be the same issue under linux.Originally Posted by Outlaw
Can you copy the database to another partition using a different, more common file system and then compress the copy there? what about copying it to another machine and compressing it there?
My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive.