создание отчетов perfmon выше о IOPs, чем возможный?
Я видел эту проблему с объединяемым в команду NICs - один изворотливый порт коммутатора, который команда не распознает, как отказавший, но или неправильно конфигурируется или немного повреждается, может только влиять на трафик to\from определенные пары хоста не все пары хостов. Это может очень сбивать с толку.
например:
Сервер X может говорить счастливо с Сервером A
Сервер X может говорить счастливо с Сервером B
Но Сервер A и Сервер B не могут говорить друг с другом.
Я не видел это с Hyper-V, но я видел его несколько раз с VMware ESX - хотя в этом случае проблема не была последовательна через весь VM's на хосте, как это находится в Вашем случае.
Each drive can do 180 random IOPs. Is your workload totally random? I bet what you're seeing is sequential reads/writes.
Я предполагаю, что это кеширование. Вы сказали, что кэш записи отключен, но я вижу «Кэш ускорителя массива», я не знаком с этим, но кэширование памяти объясняет всплески высокой пропускной способности.
If you're benchmarking using realistic activity patterns, and the application performance is acceptable and within the specs of the hardware, then you're in good shape. However, understanding your read/write patterns and the capabilities of your storage system is also important.
You're using an HP Smart Array controller, so there are a number of factors involved in its performance.
1). You have the write cache, which is just the physical disk cache on each drive. Maybe 8-32 megabytes. This is probably disabled in your setup.
2). You also have the battery-backed write cache (BBWC) or flash-backed write cache (FBWC) on the actual controller. This is either 512MB or 1GB, protected by a non-volatile cache mechanism. This appears to be enabled.
3). The cache ratio you described in your question is the percentage of the above dedicated to reads and writes. It's denoted by the "Array Accelerator" terminology.
By having the array accelerator enabled, you're going to have low-latency writes committed to cache before going to disk. Basically, your application can say, "yeah, I wrote that" because the storage system says, "it's written" and can coalesce writes and commit them to rotating disk in sequential batches.
You have a 384MB or 768MB write buffer, based on your current settings, so that accounts for the high IOPS figures during your test. You have a small amount of read cache available as well. If your working set of data is small enough, you could be working entirely in cache, which is far faster than disk.
Here's the output of a Smart Array P410 configuration on a ProLiant DL380 G7. As you can see, there's a lot involved in the basic setup, and there are a few optimizations. I think you may have only disabled one small item, leaving the rest in place.
Smart Array P410i in Slot 0 (Embedded)
Bus Interface: PCI
Slot: 0
Serial Number: 500143801664FE50
Cache Serial Number: PBCDF0CRHZV1JS
RAID 6 (ADG) Status: Disabled
Controller Status: OK
Hardware Revision: C
Firmware Version: 5.14
Rebuild Priority: Medium
Expand Priority: Medium
Surface Scan Delay: 15 secs
Surface Scan Mode: Idle
Queue Depth: Automatic
Monitor and Performance Delay: 60 min
Elevator Sort: Enabled
Degraded Performance Optimization: Disabled
Inconsistency Repair Policy: Disabled
Wait for Cache Room: Disabled
Surface Analysis Inconsistency Notification: Disabled
Post Prompt Timeout: 0 secs
Cache Board Present: True
Cache Status: OK
Cache Ratio: 25% Read / 75% Write
Drive Write Cache: Enabled
Total Cache Size: 1024 MB
Total Cache Memory Available: 912 MB
No-Battery Write Cache: Enabled
Cache Backup Power Source: Capacitors
Battery/Capacitor Count: 1
Battery/Capacitor Status: OK
SATA NCQ Supported: True