Linux-实际硬件RAID控制器调整（scsi和cciss）

我管理的大多数Linux系统都具有硬件RAID控制器（主要是HP Smart Array）。他们都在运行RHEL或CentOS。

我正在寻找现实世界中的可调参数，以帮助优化设置的性能，这些设置将硬件RAID控制器与SAS磁盘（智能阵列，Perc，LSI等）和电池后备或闪存后备缓存结合在一起。假设RAID 1 + 0和多个主轴（4+个磁盘）。

我花了大量时间为低延迟和金融交易应用程序调整Linux网络设置。但是，这些选项中的许多选项都有充分的文档记录（更改发送/接收缓冲区，修改TCP窗口设置等）。工程师在存储方面正在做什么？

从历史上看，我对I / O调度电梯进行了更改，最近选择了deadline和noop调度程序来提高应用程序的性能。随着RHEL版本的发展，我还注意到SCSI和CCISS块设备的已编译默认值也已更改。随着时间的推移，这对建议的存储子系统设置产生了影响。但是，自从我看到任何明确的建议以来已经有一段时间了。而且我知道操作系统默认设置不是最佳的。例如，对于服务器级硬件上的部署而言，默认的128kb预读缓冲区似乎很小。

以下文章探讨了在块队列上更改预读缓存和nr_requests值对性能的影响。

http://zackreed.me/articles/54-hp-smart-array-p410-controller-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array-p400-with -linux-why-tuning-really-matters
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

例如，建议对HP Smart Array RAID控制器进行以下更改：

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

还有什么可以可靠地调整以提高存储性能的？
我在生产方案中专门寻找sysctl和sysfs选项。

我发现，当我不得不针对较低的延迟和吞吐量进行调整时，我已经将nr_requests从其默认值调整为最低（低至32）。批量较小的想法等于较低的延迟。

另外，对于read_ahead_kb，我发现对于顺序读取/写入，增加此值可提供更好的吞吐量，但是我发现此选项确实取决于您的工作负载和IO模式。例如，在我最近调整的数据库系统上，我更改了此值以匹配单个数据库页面大小，这有助于减少读取延迟。在我的案例中，增加或减少该值被证明会损害性能。

至于块设备队列的其他选项或设置：

max_sectors_kb =我已将此值设置为与硬件允许的单次传输相匹配（检查sysfs中max_hw_sectors_kb（RO）文件的值以查看允许的值）

nomerges =这使您可以禁用或调整用于合并io请求的查找逻辑。（关闭此功能可以节省一些CPU周期，但是为我的系统更改此功能时我没有看到任何好处，因此我将其保留为默认值）

rq_affinity =我还没有尝试过，但这是内核文档背后的解释

如果此选项为“ 1”，则块层将请求完成情况迁移到最初提交请求的cpu“组”中。对于某些工作负载，由于具有缓存效果，因此可以大大减少CPU周期。
对于需要最大化完成处理分布的存储配置，将此选项设置为“ 2”将强制完成在请求的cpu上运行（绕过“组”聚合逻辑）”

调度器 =您说您尝试了截止日期，没有休息。我已经测试了noop和截止日期，但是发现截止日期赢得了我最近对数据库服务器所做的测试。

NOOP表现不错，但是对于我们的数据库服务器，通过调整截止时间调度程序，我仍然能够获得更好的性能。

位于/ sys / block / {sd，cciss，dm-} * / queue / iosched /下的截止时间调度程序的选项：

fifo_batch =类似于nr_requests，但特定于调度程序。经验法则是将其调低以降低延迟或提高吞吐量。控制读取和写入请求的批处理大小。

write_expire =设置写批处理的到期时间，默认值为5000ms。再次减小此值可减少您的写入延迟，而增大该值可增加吞吐量。

read_expire =设置读取批处理的到期时间，默认值为500ms。同样的规则在这里适用。

front_merges =我倾向于将其关闭，并且默认情况下处于启用状态。我认为调度程序无需浪费CPU周期来尝试预先合并IO请求。

writes_starved =由于截止日期是为读取准备的，因此默认设置是在处理写入批处理之前处理2个读取批处理。我发现默认值2适合我的工作量。

最重要的是，一切都取决于您的工作量。

read_ahead_kb如果提前从某些文件中读取大量数据（例如在流视频时）真的很有帮助，则可以为您提供帮助。有时会严重伤害您。是的，默认的128 KB听起来可能很小，但是并发性足够大时，它听起来似乎很大！另一方面，对于仅将视频从一种格式转换为另一种格式的服务器（例如视频编码服务器）而言，进行调整可能是一个好主意。

nr_requests过度调整后，很容易使您的RAID控制器泛滥，这又会损害性能。

在现实世界中，您需要注意延迟。如果您连接到SAN，采取一看iostat，sar或任何你喜欢用，看看I / O请求的服务时间是通过屋顶。当然，这对本地磁盘也有帮助：如果延迟非常大，请考虑通过降级max_requests和其他设置来调低I / O电梯设置。

仅供参考read_ahead_kb，blockdev --setra只是使用不同单位（kB与扇区）设置相同设置的不同方法：

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

所以

blockdev --setra 65536 /dev/cciss/c0d0

在您的示例中无效。