Increased performance of lsi logic sas1064E
This small article is intended for the lucky owners of some old HP Proliant DL160G5, IBM 3250, Sun Fire X4600 and other servers, with the integrated lsi logic sas1064E controller , as well as its older and younger brothers. I will talk about how a fairly simple way to increase the performance of this controller without any special consequences for myself.
The problem is expressed in a very small, 7-12 megabytes / sec , write speed to discs collected in raid1 or raid0. In the terminology of this controller, these are IM / IME (Integrated Mirroring / Integrated Mirroring Enhanced) and IS (Integrated Striping), respectively.
Even for raid1 of two SATA drives, this speed is incredibly low and the actual use of the server with such a write speed is very limited.
Next, I will describe a small quest that I passed, and the actual decision itself.
')
A small but combat DL160 G5 server immediately after joining the service showed very unusual behavior with respect to write operations. As I wrote above, the speed did not exceed 12 mb / s in the hardware raid, but it was at the level of 50-60 mb / s in the software. It was a bit embarrassing, and using the software raid in the presence of hardware is somehow not right, so it was decided to get to the bottom of it and defeat the cunning enemy.
At once I will say that the source of the problem was the disconnected cache on disks collected in a raid array. And it was impossible to enable it using the OS tools in windows and linux, since the system reported that the cache is not supported by the drive.
On the Internet, I came across only topics from many years ago, in which the problem was never solved or decided to replace the controller with another one or even switch to a software raid.
For example, here is a post in LJ , more , more , and more ... I think enough is enough to engage in archeology.
In many messages, people write that these are controller glitches, but the firmware does not save. So, this is not glitches. According to the official user manual, this behavior of the controller was originally intended:
Disk Write Caching
IM / IS firmware disk write caching by default.
Built-in logic for IM / IS drives disables the default cache
I will make a reservation that this was done deliberately to ensure greater data integrity in the controller's NVRAM, but at the expense of performance. Cases where the integrity of NVRAM can be broken include, but do not exclude other options: a sudden power outage, the failure of a single power supply on the server ...
Thanks, LSI for the clarification, but this is still not a solution to my problem. Next was the search for utilities that would allow me to change this annoying situation and turn on the cache. The standard cfggen.exe utility does not allow managing such parameters, another mptpsir.exe utility allows managing the caching mode, but does not work with this controller ... Dejection :)
And it turned out to be easier than it seemed. In an attempt to find a magic utility that would allow me to change the memory registers of the controller to enable the cache, I bypassed the regular monitoring and control tool for the LSI controllers: MegaRAID Storage Manager (MSM) .
The manual says that the supported OS is win 2000 and win 2003. My target system was Windows 2008 R2, but this did not cause any problems and MSM was installed immediately. I will make a reservation that for its normal operation, you must first install the SNMP service in windows.
After starting, select the local server, enter the local administrator's credentials and get into the setup menu.
Go to the Logical section, select our disk, go to the Operations tab, select the Set Virtual Disk Properties menu item and translate the only parameter to the enabled value.
To achieve complete satisfaction, it remains only to press Go and the disk cache will be instantly turned on. Windows happily announced that it now has the ability to use the cache on the disks and immediately activated it. The result was not long in coming - the recording speed is now higher than 40mb / s, and in addition the rest of the buns work, like hot-plug and hot-swap.
Problem solved. Hooray!
PS Turning on the cache on disks is not a recommended configuration and its inclusion should not be done on productive systems with important data. All this is done at your own risk.
Problem:
The problem is expressed in a very small, 7-12 megabytes / sec , write speed to discs collected in raid1 or raid0. In the terminology of this controller, these are IM / IME (Integrated Mirroring / Integrated Mirroring Enhanced) and IS (Integrated Striping), respectively.
Even for raid1 of two SATA drives, this speed is incredibly low and the actual use of the server with such a write speed is very limited.
Next, I will describe a small quest that I passed, and the actual decision itself.
')
Quest start
A small but combat DL160 G5 server immediately after joining the service showed very unusual behavior with respect to write operations. As I wrote above, the speed did not exceed 12 mb / s in the hardware raid, but it was at the level of 50-60 mb / s in the software. It was a bit embarrassing, and using the software raid in the presence of hardware is somehow not right, so it was decided to get to the bottom of it and defeat the cunning enemy.
At once I will say that the source of the problem was the disconnected cache on disks collected in a raid array. And it was impossible to enable it using the OS tools in windows and linux, since the system reported that the cache is not supported by the drive.
On the Internet, I came across only topics from many years ago, in which the problem was never solved or decided to replace the controller with another one or even switch to a software raid.
For example, here is a post in LJ , more , more , and more ... I think enough is enough to engage in archeology.
In many messages, people write that these are controller glitches, but the firmware does not save. So, this is not glitches. According to the official user manual, this behavior of the controller was originally intended:
Disk Write Caching
IM / IS firmware disk write caching by default.
Built-in logic for IM / IS drives disables the default cache
I will make a reservation that this was done deliberately to ensure greater data integrity in the controller's NVRAM, but at the expense of performance. Cases where the integrity of NVRAM can be broken include, but do not exclude other options: a sudden power outage, the failure of a single power supply on the server ...
Thanks, LSI for the clarification, but this is still not a solution to my problem. Next was the search for utilities that would allow me to change this annoying situation and turn on the cache. The standard cfggen.exe utility does not allow managing such parameters, another mptpsir.exe utility allows managing the caching mode, but does not work with this controller ... Dejection :)
Decision
And it turned out to be easier than it seemed. In an attempt to find a magic utility that would allow me to change the memory registers of the controller to enable the cache, I bypassed the regular monitoring and control tool for the LSI controllers: MegaRAID Storage Manager (MSM) .
The manual says that the supported OS is win 2000 and win 2003. My target system was Windows 2008 R2, but this did not cause any problems and MSM was installed immediately. I will make a reservation that for its normal operation, you must first install the SNMP service in windows.
After starting, select the local server, enter the local administrator's credentials and get into the setup menu.
Go to the Logical section, select our disk, go to the Operations tab, select the Set Virtual Disk Properties menu item and translate the only parameter to the enabled value.
To achieve complete satisfaction, it remains only to press Go and the disk cache will be instantly turned on. Windows happily announced that it now has the ability to use the cache on the disks and immediately activated it. The result was not long in coming - the recording speed is now higher than 40mb / s, and in addition the rest of the buns work, like hot-plug and hot-swap.
Problem solved. Hooray!
PS Turning on the cache on disks is not a recommended configuration and its inclusion should not be done on productive systems with important data. All this is done at your own risk.
Source: https://habr.com/ru/post/116271/
All Articles