У меня серьезные проблемы с производительностью на сервере с очень низким iops.
сервер:
вот одна информация о samsung 840:
hpacucli ctrl slot=0 pd 2I:1:6 show detail
physicaldrive 2I:1:6
Port: 2I
Box: 1
Bay: 6
Status: OK
Drive Type: Data Drive
Interface Type: Solid State SATA
Size: 512.1 GB
Firmware Revision: DXM04B0Q
Serial Number: S12SNEAD102607E
Model: ATA Samsung SSD 840
SATA NCQ Capable: True
SATA NCQ Enabled: True
Current Temperature (C): 16
Maximum Temperature (C): 70
Usage remaining: 100.00%
Power On Hours: 0
SSD Smart Trip Wearout: False
PHY Count: 1
PHY Transfer Rate: 6.0Gbps
Drive Authentication Status: OK
Carrier Application Version: 11
Carrier Bootloader Version: 6
и вот результат теста
sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.1.3
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [m] [99.8% done] [7152KB/2400KB/0KB /s] [1788/600/0 iops] [eta 00m:02s]
test: (groupid=0, jobs=1): err= 0: pid=36718: Thu Mar 5 18:15:12 2015
read : io=3071.7MB, bw=2536.5KB/s, iops=634, runt=1240097msec
write: io=1024.4MB, bw=866133B/s, iops=211, runt=1240097msec
cpu : usr=0.28%, sys=1.18%, ctx=401767, majf=0, minf=2347
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
READ: io=3071.7MB, aggrb=2536KB/s, minb=2536KB/s, maxb=2536KB/s, mint=1240097msec, maxt=1240097msec
WRITE: io=1024.4MB, aggrb=845KB/s, minb=845KB/s, maxb=845KB/s, mint=1240097msec, maxt=1240097msec
Disk stats (read/write):
dm-1: ios=785968/267543, merge=0/0, ticks=50476776/28341176, in_queue=79704028, util=100.00%, aggrios=788659/265218, aggrmerge=1953/2589, aggrticks=50709304/27483028, aggrin_queue=78191444, aggrutil=100.00%
sda: ios=788659/265218, merge=1953/2589, ticks=50709304/27483028, in_queue=78191444, util=100.00%
запуск той же скамьи на обычном жестком диске показывает больше операций ввода-вывода в секунду, чем на твердотельном диске
Любая идея ?
Из-за того, как работают твердотельные накопители MLC, им требуется локальный кеш DRAM приличного размера для поглощения входящих записей при одновременной записи в резервную NAND.
Однако аппаратные карты RAID часто отключить кэш диска и полагаются исключительно на собственный (на карте) кеш DRAM. Хотя это не проблема классических жестких дисков, внутренняя природа чипов NAND (и твердотельных накопителей, построенных на их основе), не допускающая перезаписи, приводит к значительной потере производительности, если невозможно использовать внутренний кэш DRAM.
Приведу пример: Crucial M550 емкостью 256 ГБ с последовательной записью более 400 МБ / с падает до 5 МБ / с с отключенным внутренним кешем. При случайной записи потери также велики. Это точная причина, по которой корпоративные SSD использовали (в прошлом) SLC NAND: время их программирования намного меньше по сравнению с MLC или даже eMLC.
По этой причине я всегда немного нервничаю, комбинируя SSD потребительского класса с фирменными аппаратными картами RAID. С другой стороны, Linux mdraid фантастически хорошо работает с SSD любого класса.
Для вашего конкретного случая вы можете провести тест, пытаясь повторно включить внутренний дисковый кеш (контроллер DELL / LSI дает такую возможность, я не знаю о контроллере HP). Однако помните, что при включенном кэше записи на диске вы подвержены потере данных в случае отключения электроэнергии (если на ваших дисках не предусмотрена защита от потери питания, но это довольно редко в потребительском пространстве).