All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Dacentec - HP ProLiant 2xL5420 - Disk Speed
Hi guys,
I am having some problems with a Dacentec server. I hope someone can help.
recently I ordered an HP ProLiant 2xL5420 16GB 2x1TB. It was slow, so I realized that the write speed of the disk was between 10 ~ 30 MB / s (checked with dd) . I got in touch with the support, to know if this speed was correct, after all this is the cheaper server of them. And you get what you pay for.
They tested the speed inside the system recovery (with dd), and gave 120 MB / s. I asked to reinstall centos 6, maybe it was some update, or config that I did wrong. But, it stayed the same, with a fresh installation, speed of 18.4 MB / s ~ 32.2 MB / s in disk write. Btw, it was installed the imgem they provide, which should have been tested with their hardware
I asked to correct the problem, but they basically told that is my problem, since they are 'fully unmanaged': "Our testing ruled out the hardware as the issue [...] This is a possible issue with the OS / Driver involved, or potentially the specific kernel being used. [...] You may wish to check into potential issues with either your specific kernel or with the current CentOS 6 CCISS driver. "
Has anyone had this problem? CentOS 6 CCISS? Is it easy to solve?
If it is something simple to solve I would probably continue with the server. Any recomendations?
Comments
What's the exact dd command you used, and full output?
It's possible they are reading sequential speeds of 120MB/s and you are comparing it to something else like random writes.
My:
[root@titan ~]# dd if=/dev/zero of=./bigfile bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 33.3813 s, 32.2 MB/s
They:
root@sysresccd /root % dd if=/dev/zero of=/dev/vg/root bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 8.83359 s, 122 MB/s
The difference is that they are testing directly on the block device, so mine should have some file system overhead. But nothing like slowing down to 30 MB / s
Server does not have any hw raid controller, right?
Try looking at drive write cache (hdparm -W /dev/sdX), often servers have it disabled by default and without raid card with its own cache it causes severe performance hit. I had it disabled on my (different) dacentec server too.
Enabling it increases performance significantly, but has a downside of potential data/filesystem corruption in case of power loss or another unplanned shutdown.
Yes, it has. A p400 RAID controller. So its necessary the cciss driver, from HP, that the support told. From what I was told when I asked to use CentOS 7, they only have this server with RAID controller. Then, it dosn't have a /dev/sdX .
In that case you should install hpssacli/hpacucli and take a look at controller status/configuration. Like if it does not have a battery and have cache disabled it will be slow too (does not explain speed difference between their and your test though).
And last time i played around with old hp server (it had p212 card) i had to update controller firmware for things to work, not sure if dacentec is fine with you doing it, you should probably ask if you need it...
Also, why not use centos7 instead of 6? If you really need 6 for some your applications it may be better to run it in vm/container on centos7 host.
You should be able to download everything you need from hp site too, at least i had no issues downloading said tools and firmware.
As for the driver.... server and raid card are old. I really doubt that the issue is caused by os/builtin driver itself, it is probably some configuration difference or something like that.
If you want to look at hdd smart and such you should be able to do it like this: "smartctl -a /dev/sdX -d sat+cciss,Y" where sdX is your raid array and Y is your HDD number.
HP raid cards become very slow when the raid battery dies. it is almost as the cache times out or something.
I've had similar problems with a server of my own and my problem was solved by changing the raid battery.
It could be to protect data integrity. When the battery dies and the power goes out, all data in the cache would be lost. I actually appreciate it if the controller then decides not to use the cache anymore to protect data integrity.
This doesn't explain why recovery performance is significantly better. A dead cache battery is dead in recovery too.
I could not solve the RAID problem, but I got the same server without the RAID controller, now I'm using RAID via software.
Thanks for the help, everyone.
Well, sure there is a way, to check the battery status, but as I know, these are kinda expensive, so I would not expect them to swap it.
I guess then, stick with the software raid.