Very poor SCSI hd performance on IBM x336 with LSI 1030 RAID1

ibmlsiperformanceraid

I'm experiencing very poor performance on an IBM x336 server with dual 73GB 15k hard drives on a U320 controller, LSI 1030. We're getting maybe 3.5MB/sec max (per HD Tune utility). It should be over 100MB/sec at least, I would think (another x335 box is running 70-80MB/sec). The server was recently setup and didn't really notice the problem, but may have been there from the beginning, so not sure. I have installed the IBM ServerRAID Windows utility. The server is running Windows 2008 R2 Web edition (if that matters).

I thought maybe one of the drives was bad, so far I have removed one of the drives out of the array and tested again, but still the same results. I'm waiting for the RAID1 to resync and I will try pulling the other drive next.

I've also used the ServerRAID utility but haven't noticed anything in there that might indicate a problem.

Not sure if I'm on the right path here. So looking for some advice to track this down.

Best Answer

Does the server have a battery-backed cache for the storage controller and if so, is the battery missing, disconnected or failed?

Dramatic differences in throughput like you describe have been seen in instances where the cache is missing, malfunctioning or disabled on a server, vs an identical server where the cache is operating correctly.

On a brand new machine, there may be a period when you first power it on where the battery-backed cache is charging, and caching will be disabled until it's ready to go. This can be up to 24h after it's initially powered up.

Also, during RAID rebuilds, caching is often disabled by the controller. Check the perfomance again once the rebuild is complete.

Related Solutions

X345 and ServeRaid 5i – Defunct Drives

The orange led doesn't mean that the drive is broken: it means that it's marked as failed.

Recently I had the same issue on a ServeRaid 6i: two drives disappeared. The raid was level 5. I put one of the two online and I rebuilt the second. At the end of the process I got my array rebuild. Of course it was not a broken disk but a weird bug into the controller or into the disks.

Some disks seem to have broken firmware that cause the disk to deattach from the array randomly.

Linux – Apache2 benchmarks – very poor performance

The thing that jumps out at me is worker vs prefork. To isolate, you should try running prefork on the "new" / "second" server.

I'm also skeptical of the "old" benchmark:

Transfer rate:  1086267.40 kb/s received

that is equal to 1.03 GB/s, or 8.2 Gbps. Obviously, that is faster than a 1 Gbps port. Are you running the same test here, or benchmarking the old locally and the new remotely?

Hopefully this is not too basic of a question, but are you benching the same load/application? Eg, if you were to compare loading a static file, like an image, to a php page that is doing some processing, you're going to get different results. If your php page is also touching a database, and the database is different on the two servers, that's also going to affect the results.

I would suggest -- again, in the interest of isolation -- benchmarking static files between the two. If you don't see a difference there, try the same simple php page on both (that is not part of another app, just doing something simple like hello world in a loop).

Once you've done an apples vs apples benchmark on the various pieces, you should have enough information to isolate down what is causing the difference (is it your database server? the file system? the apache forking model? the apache version? the network? the benchmark itself?).

Best Answer

Related Solutions

X345 and ServeRaid 5i – Defunct Drives

Linux – Apache2 benchmarks – very poor performance

Related Topic