Существует много мест, это могло пойти не так, как надо, поэтому давайте запустимся с некоторых основ.
we should theoretically be getting 200mbps
In your dreams. when doing not random IO, where msot time is spend jumping from sector to sector. But with random io and few slow end user discs that sounds about right - welcome to a worls where you get around 300 IOPS for a pair of diskcs, and a SSD gives you 60.000. Now maybe you understand that SSD kiklkl a SAN for random IO, and the MB/S number that end users love osm uch has no relevance for database storage backends.
You also sabotage is:
enabling multiple I/Os per thread with 2 outstanding
Ok, given that SATA NCQ (Native Command Queueing) intelligently reorders up to 32 pending requests in teh disc, sending on only 2 at the same time is suboptimal. You get 2x2 = 4 outstanding, but can handle 32 per disc.
Taht said, at the end you need (a) faster discs (b) more of them to get higher IOPS. Or a decent second level cache (Adaptec raid controlelrs can use SSD as read & write cache).
Нет, вы правы, это совсем не здорово - вы не упоминаете схему SAN, но, учитывая, что это R10, вы можете представить наихудший сценарий с минимум 4 x дешевых дисков SATA поверх одного из этих Каналы со скоростью 1 Гбит / с (я сомневаюсь, что оба будут использоваться одновременно из-за согласованности MAC), даже в этом случае я бы ожидал, как минимум, удвоить количество Мбит / с случайного чтения, которое вы видите, и это наихудший случай. Что-то не так.
Поскольку вы не упоминаете, что такое SAN, я предполагаю, что это общий iSCSI.
Какие диски в нем? Какие скорости? Какой кэш, если таковой имеется, присутствует в RAID-10?
Я согласен, что 22 МБ / с - это ужасно медленно, но если в RAID-10 всего 4 диска SATA, 350 с лишним IOPS будет примерно правильным.