My Blog

Немного об ИТ и ИБ

Свежие записи

Свежие комментарии

• Denis к записи Zabbix 5.0 на Centos 8 с TimescaleDB и PostgreSQL
• evgen к записи Zabbix 5.0 на Centos 8 с TimescaleDB и PostgreSQL
• Denis к записи Zabbix 5.0 на Centos 8 с TimescaleDB и PostgreSQL
• Denis к записи Zabbix 5.0 на Centos 8 с TimescaleDB и PostgreSQL
• Александр к записи Zabbix 5.0 на Centos 8 с TimescaleDB и PostgreSQL

Архивы

Замер производительности дисковой подсистемы

timespan: 1
————-
duration: 300s
warm up time: 5s
cool down time: 0s
measuring latency
random seed: 0
path: ‘C:\temp\testfile.dat’
think time: 0ms
burst size: 0
software cache disabled
hardware write cache disabled, writethrough on
performing mix test (read/write ratio: 60/40)
block size: 65536
using random I/O (alignment: 65536)
number of outstanding I/O operations: 32
thread stride size: 0
threads per file: 8
using I/O Completion Ports
IO priority: normal

computer name: DESKTOP-03410T6
start time: 2019/10/04 10:28:37 UTC

actual test time: 300.02s
thread count: 8
proc count: 2

CPU | Usage | User | Kernel | Idle
——————————————-
0| 30.84%| 2.54%| 28.31%| 69.16%
1| 31.12%| 2.63%| 28.49%| 68.88%
——————————————-
avg.| 30.98%| 2.58%| 28.40%| 69.02%

Total IO
thread | bytes | I/Os | MiB/s | I/O per s | AvgLat | LatStdDev | file
——————————————————————————————————
0 | 45014319104 | 686864 | 143.09 | 2289.43 | 13.977 | 6.015 | C:\temp\testfile.dat (50GiB)
1 | 45095321600 | 688100 | 143.35 | 2293.55 | 13.952 | 5.956 | C:\temp\testfile.dat (50GiB)
2 | 45007634432 | 686762 | 143.07 | 2289.09 | 13.979 | 6.426 | C:\temp\testfile.dat (50GiB)
3 | 45050494976 | 687416 | 143.20 | 2291.27 | 13.966 | 6.373 | C:\temp\testfile.dat (50GiB)
4 | 45007962112 | 686767 | 143.07 | 2289.10 | 13.979 | 6.095 | C:\temp\testfile.dat (50GiB)
5 | 45066354688 | 687658 | 143.25 | 2292.07 | 13.961 | 6.026 | C:\temp\testfile.dat (50GiB)
6 | 44991053824 | 686509 | 143.02 | 2288.24 | 13.984 | 6.147 | C:\temp\testfile.dat (50GiB)
7 | 45058424832 | 687537 | 143.23 | 2291.67 | 13.964 | 6.722 | C:\temp\testfile.dat (50GiB)
——————————————————————————————————
total: 360291565568 | 5497613 | 1145.28 | 18324.43 | 13.970 | 6.225

Read IO
thread | bytes | I/Os | MiB/s | I/O per s | AvgLat | LatStdDev | file
——————————————————————————————————
0 | 26977763328 | 411648 | 85.76 | 1372.09 | 14.263 | 4.891 | C:\temp\testfile.dat (50GiB)
1 | 27056340992 | 412847 | 86.01 | 1376.09 | 14.244 | 4.892 | C:\temp\testfile.dat (50GiB)
2 | 26995654656 | 411921 | 85.81 | 1373.00 | 14.256 | 4.887 | C:\temp\testfile.dat (50GiB)
3 | 27019444224 | 412284 | 85.89 | 1374.21 | 14.247 | 4.886 | C:\temp\testfile.dat (50GiB)
4 | 26950828032 | 411237 | 85.67 | 1370.72 | 14.260 | 4.877 | C:\temp\testfile.dat (50GiB)
5 | 27014070272 | 412202 | 85.87 | 1373.94 | 14.246 | 4.889 | C:\temp\testfile.dat (50GiB)
6 | 26993623040 | 411890 | 85.81 | 1372.90 | 14.262 | 4.887 | C:\temp\testfile.dat (50GiB)
7 | 27007320064 | 412099 | 85.85 | 1373.59 | 14.243 | 4.881 | C:\temp\testfile.dat (50GiB)
——————————————————————————————————
total: 216015044608 | 3296128 | 686.66 | 10986.52 | 14.253 | 4.886

Write IO
thread | bytes | I/Os | MiB/s | I/O per s | AvgLat | LatStdDev | file
——————————————————————————————————
0 | 18036555776 | 275216 | 57.33 | 917.34 | 13.549 | 7.363 | C:\temp\testfile.dat (50GiB)
1 | 18038980608 | 275253 | 57.34 | 917.46 | 13.514 | 7.244 | C:\temp\testfile.dat (50GiB)
2 | 18011979776 | 274841 | 57.26 | 916.09 | 13.565 | 8.193 | C:\temp\testfile.dat (50GiB)
3 | 18031050752 | 275132 | 57.32 | 917.06 | 13.545 | 8.087 | C:\temp\testfile.dat (50GiB)
4 | 18057134080 | 275530 | 57.40 | 918.39 | 13.560 | 7.536 | C:\temp\testfile.dat (50GiB)
5 | 18052284416 | 275456 | 57.38 | 918.14 | 13.534 | 7.388 | C:\temp\testfile.dat (50GiB)
6 | 17997430784 | 274619 | 57.21 | 915.35 | 13.565 | 7.638 | C:\temp\testfile.dat (50GiB)
7 | 18051104768 | 275438 | 57.38 | 918.08 | 13.546 | 8.767 | C:\temp\testfile.dat (50GiB)
——————————————————————————————————
total: 144276520960 | 2201485 | 458.62 | 7337.90 | 13.547 | 7.793

total:
%-ile | Read (ms) | Write (ms) | Total (ms)
———————————————-
min | 1.584 | 1.644 | 1.584
25th | 11.285 | 11.273 | 11.280
50th | 12.464 | 12.537 | 12.495
75th | 15.208 | 13.985 | 14.480
90th | 21.041 | 16.522 | 19.296
95th | 25.052 | 19.546 | 23.253
99th | 32.767 | 28.304 | 32.083
3-nines | 39.992 | 94.817 | 81.874
4-nines | 46.188 | 247.305 | 160.804
5-nines | 55.537 | 652.923 | 535.564
6-nines | 62.648 | 1091.422 | 949.683
7-nines | 65.221 | 2258.252 | 2258.252
8-nines | 65.221 | 2258.252 | 2258.252
9-nines | 65.221 | 2258.252 | 2258.252
max | 65.221 | 2258.252 | 2258.252

timespan: 1
————-
duration: 300s
warm up time: 5s
cool down time: 0s
measuring latency
random seed: 0
path: ‘C:\tmp\testfile.dat’
think time: 0ms
burst size: 0
software cache disabled
hardware write cache disabled, writethrough on
performing mix test (read/write ratio: 60/40)
block size: 65536
using random I/O (alignment: 65536)
number of outstanding I/O operations: 32
thread stride size: 0
threads per file: 8
using I/O Completion Ports
IO priority: normal

computer name: DESKTOP-ILCC1T8
start time: 2020/06/24 18:38:41 UTC

actual test time: 300.00s
thread count: 8
proc count: 4

CPU | Usage | User | Kernel | Idle
——————————————-
0| 12.11%| 1.54%| 10.57%| 87.89%
1| 38.89%| 1.15%| 37.73%| 61.11%
2| 11.30%| 1.41%| 9.89%| 88.70%
3| 11.64%| 1.41%| 10.23%| 88.36%
——————————————-
avg.| 18.48%| 1.38%| 17.11%| 81.52%

Total IO
thread | bytes | I/Os | MiB/s | I/O per s | AvgLat | LatStdDev | file
——————————————————————————————————
0 | 47784591360 | 729135 | 151.90 | 2430.45 | 13.167 | 8.482 | C:\tmp\testfile.dat (50GiB)
1 | 46319730688 | 706783 | 147.25 | 2355.94 | 13.583 | 8.590 | C:\tmp\testfile.dat (50GiB)
2 | 47801171968 | 729388 | 151.96 | 2431.29 | 13.163 | 8.474 | C:\tmp\testfile.dat (50GiB)
3 | 47799730176 | 729366 | 151.95 | 2431.22 | 13.162 | 8.471 | C:\tmp\testfile.dat (50GiB)
4 | 47771877376 | 728941 | 151.86 | 2429.80 | 13.172 | 8.495 | C:\tmp\testfile.dat (50GiB)
5 | 46314553344 | 706704 | 147.23 | 2355.68 | 13.586 | 8.602 | C:\tmp\testfile.dat (50GiB)
6 | 47797370880 | 729330 | 151.94 | 2431.10 | 13.164 | 8.475 | C:\tmp\testfile.dat (50GiB)
7 | 47802286080 | 729405 | 151.96 | 2431.35 | 13.162 | 8.474 | C:\tmp\testfile.dat (50GiB)
——————————————————————————————————
total: 379391311872 | 5789052 | 1206.05 | 19296.84 | 13.268 | 8.509

Read IO
thread | bytes | I/Os | MiB/s | I/O per s | AvgLat | LatStdDev | file
——————————————————————————————————
0 | 28635365376 | 436941 | 91.03 | 1456.47 | 12.479 | 8.370 | C:\tmp\testfile.dat (50GiB)
1 | 27787919360 | 424010 | 88.34 | 1413.37 | 12.850 | 8.493 | C:\tmp\testfile.dat (50GiB)
2 | 28664987648 | 437393 | 91.12 | 1457.98 | 12.495 | 8.531 | C:\tmp\testfile.dat (50GiB)
3 | 28679340032 | 437612 | 91.17 | 1458.71 | 12.482 | 8.418 | C:\tmp\testfile.dat (50GiB)
4 | 28613541888 | 436608 | 90.96 | 1455.36 | 12.500 | 8.518 | C:\tmp\testfile.dat (50GiB)
5 | 27764260864 | 423649 | 88.26 | 1412.16 | 12.872 | 8.638 | C:\tmp\testfile.dat (50GiB)
6 | 28665249792 | 437397 | 91.12 | 1457.99 | 12.486 | 8.462 | C:\tmp\testfile.dat (50GiB)
7 | 28652339200 | 437200 | 91.08 | 1457.33 | 12.495 | 8.508 | C:\tmp\testfile.dat (50GiB)
——————————————————————————————————
total: 227463004160 | 3470810 | 723.09 | 11569.37 | 12.580 | 8.493

Write IO
thread | bytes | I/Os | MiB/s | I/O per s | AvgLat | LatStdDev | file
——————————————————————————————————
0 | 19149225984 | 292194 | 60.87 | 973.98 | 14.197 | 8.545 | C:\tmp\testfile.dat (50GiB)
1 | 18531811328 | 282773 | 58.91 | 942.58 | 14.682 | 8.618 | C:\tmp\testfile.dat (50GiB)
2 | 19136184320 | 291995 | 60.83 | 973.32 | 14.163 | 8.288 | C:\tmp\testfile.dat (50GiB)
3 | 19120390144 | 291754 | 60.78 | 972.51 | 14.183 | 8.447 | C:\tmp\testfile.dat (50GiB)
4 | 19158335488 | 292333 | 60.90 | 974.44 | 14.176 | 8.359 | C:\tmp\testfile.dat (50GiB)
5 | 18550292480 | 283055 | 58.97 | 943.52 | 14.656 | 8.437 | C:\tmp\testfile.dat (50GiB)
6 | 19132121088 | 291933 | 60.82 | 973.11 | 14.180 | 8.392 | C:\tmp\testfile.dat (50GiB)
7 | 19149946880 | 292205 | 60.88 | 974.02 | 14.160 | 8.323 | C:\tmp\testfile.dat (50GiB)
——————————————————————————————————
total: 151928307712 | 2318242 | 482.97 | 7727.47 | 14.297 | 8.429

total:
%-ile | Read (ms) | Write (ms) | Total (ms)
———————————————-
min | 0.463 | 0.373 | 0.373
25th | 10.940 | 12.456 | 11.414
50th | 11.907 | 13.555 | 12.539
75th | 13.031 | 14.979 | 13.931
90th | 14.355 | 16.427 | 15.533
95th | 15.398 | 17.417 | 16.615
99th | 19.154 | 21.259 | 20.261
3-nines | 160.887 | 159.757 | 160.363
4-nines | 202.945 | 202.124 | 202.772
5-nines | 215.037 | 214.996 | 215.037
6-nines | 217.878 | 217.198 | 217.843
7-nines | 218.450 | 218.234 | 218.450
8-nines | 218.450 | 218.234 | 218.450
9-nines | 218.450 | 218.234 | 218.450
max | 218.450 | 218.234 | 218.450

Заметки ИТ инженера

DiskSpd — нагрузочное тестирование дисковой подсистемы

В проектах по анализу производительности SQL Server-ов я часто использую утилиту SQLIO (SQLIO Disk Subsystem Benchmark Tool) для нагрузочного тестирования дисковой подсистемы, чтобы определить её возможности и пригодность для того или иного типа дисковой нагрузки, характерной для SQL Server. При этом всегда стоял остро вопрос со сбором результатов тестов (они генерируются в виде текстовых файлов) в таблицу Excel для построения графиков.

Прошло 10 лет.. и наконец-то у меня дошли руки автоматизировать процесс сбора результатов 🙂 , тем более что появилась новая утилита такого же формата — DiskSpd (DiskSpd: A Robust Storage Performance Tool).

Далее кратко:
— скрипт PowerShell, запускающий утилиту с необходимыми параметрами и собирающий весь вывод утилиты в один CSV-файл.
Скрипт запускает сразу несколько тестов, в тексте скрипта есть комментарии с подробностями, моими рекомендациями по значениям параметров.
Запускаем скрипт с параметрами, например такими:

DiskSpd_forSQL.ps1 -PathForTestFile M:\Temp -TestFileSize 64G -durationSec 180 -threadCount 40

Так выглядит вывод скрипта в окне PowerShell:

Архив со скриптом можно скачать здесь.
— Excel-файл с таблицей и графиками, в том же архиве где и скрипт.

Результаты тестов из сгенерированного файла «DiskSpd_TestsSum.csv» вставляем в Excel-файл и получаем такую таблицу и графики:

На этом пока всё 😉
Не скучайте!

З.Ы.:
Если у вас есть что дополнить, по делу, то обязательно пишите, в комментариях.

З.З.Ы.:
05.04.2021
Скрипт обновлён, добавил поддержку Windows Storage Spaces в части возможности задать размещение тестового файла на SSD (Performance) слое tiered виртуального диска (необходимо задействовать параметр -S2D_PutTestFileToSSDTier).
Определение того, что тестовый файл создаётся на tiered диске, происходит автоматически.

Использование DISKSPD для проверки производительности хранилища рабочей нагрузки Use DISKSPD to test workload storage performance

Применимо к: Azure Stack ХЦИ, версия 20H2; Windows Server 2019 Applies to: Azure Stack HCI, version 20H2; Windows Server 2019

В этом разделе содержатся рекомендации по использованию DISKSPD для тестирования производительности хранилища рабочей нагрузки. This topic provides guidance on how to use DISKSPD to test workload storage performance. Вы создали кластер Azure Stack ХЦИ, все готово к работе. You have an Azure Stack HCI cluster set up, all ready to go. Отлично, но как вы будете получать обещанные метрики производительности, будь то задержка, пропускная способность или операции ввода-вывода? Great, but how do you know if you’re getting the promised performance metrics, whether it be latency, throughput, or IOPS? Это можно сделать, если вы захотите включить DISKSPD. This is when you may want to turn to DISKSPD. После прочтения этой статьи вы узнаете, как выполнять DISKSPD, понимать подмножество параметров, интерпретировать выходные данные и получать общее представление о переменных, влияющих на производительность хранилища рабочей нагрузки. After reading this topic, you’ll know how to run DISKSPD, understand a subset of parameters, interpret output, and gain a general understanding of the variables that affect workload storage performance.

Что такое DISKSPD? What is DISKSPD?

DISKSPD — это создающая ввод-вывод программа командной строки для микротестирования. DISKSPD is an I/O generating, command-line tool for micro-benchmarking. Отлично, Итак, что означают все эти термины? Great, so what do all these terms mean? Все, кто настраивает кластер Azure Stack ХЦИ или физический сервер, имеют причину. Anyone who sets up an Azure Stack HCI cluster or physical server has a reason. Это может быть настройка среды веб-размещения или запуск виртуальных рабочих столов для сотрудников. It could be to set up a web hosting environment, or run virtual desktops for employees. Независимо от реального случая использования может возникнуть необходимость имитировать тест перед развертыванием приложения. Whatever the real-world use case may be, you likely want to simulate a test before deploying your actual application. Однако тестирование приложения в реальной ситуации зачастую усложняется — именно здесь DISKSPD входит в. However, testing your application in a real scenario is often difficult – this is where DISKSPD comes in.

DISKSPD — это средство, которое можно настроить для создания собственных искусственных рабочих нагрузок и тестирования приложения перед развертыванием. DISKSPD is a tool that you can customize to create your own synthetic workloads, and test your application before deployment. Замечательная вещь в том, что он дает возможность настраивать и изменять параметры, чтобы создать конкретный сценарий, напоминающий реальную рабочую нагрузку. The cool thing about the tool is that it gives you the freedom to configure and tweak the parameters to create a specific scenario that resembles your real workload. DISKSPD позволяет получить представление о том, что может быть в системе до развертывания. DISKSPD can give you a glimpse into what your system is capable of before deployment. В своей основе DISKSPD просто выдает множество операций чтения и записи. At its core, DISKSPD simply issues a bunch of read and write operations.

Теперь вы понимаете, что такое DISKSPD, но когда его использовать? Now you know what DISKSPD is, but when should you use it? DISKSPD усложняет эмуляцию сложных рабочих нагрузок. DISKSPD has a difficult time emulating complex workloads. Но DISKSPD отлично подходит, если Рабочая нагрузка не очень приближена к однопотоковому копированию файлов, и вам требуется простое средство, создающее допустимые базовые результаты. But DISKSPD is great when your workload is not closely approximated by a single-threaded file copy, and you need a simple tool that produces acceptable baseline results.

Краткое руководство. Установка и запуск DISKSPD Quick start: install and run DISKSPD

Без дальнейшей работы с ADO давайте приступим к работе: Without further ado, let’s get started:

На компьютере управления откройте PowerShell с правами администратора, чтобы подключиться к целевому компьютеру, который необходимо протестировать с помощью DISKSPD, и введите следующую команду и нажмите клавишу ВВОД. From your management PC, open PowerShell as an administrator to connect to the target computer that you want to test using DISKSPD, and then type the following command and press Enter.

В этом примере мы используем виртуальную машину (ВМ) с именем «NODE1». In this example, we’re running a virtual machine (VM) called “node1.”

Чтобы скачать средство DISKSPD, введите следующие команды и нажмите клавишу ВВОД: To download the DISKSPD tool, type the following commands and press Enter:

Используйте следующую команду для распаковки скачанного файла: Use the following command to unzip the downloaded file:

Перейдите в каталог DISKSPD и укажите соответствующий исполняемый файл для операционной системы Windows, которая работает на целевом компьютере. Change directory to the DISKSPD directory and locate the appropriate executable file for the Windows operating system that the target computer is running.

В этом примере используется версия AMD64. In this example, we’re using the amd64 version.

Можно также загрузить средство DISKSPD непосредственно из репозитория GitHub , содержащего код с открытым кодом, и вики-страницу, которая содержит подробные сведения о всех параметрах и спецификациях. You can also download the DISKSPD tool directly from the GitHub repository that contains the open-source code, and a wiki page that details all the parameters and specifications. В репозитории в разделе выпуски выберите ссылку для автоматической загрузки ZIP-файла. In the repository, under Releases, select the link to automatically download the ZIP file.

В ZIP-файле вы увидите три вложенных папки: AMD64 (64-разрядные системы), x86 (32-разрядные системы) и ARM64 (системы ARM). In the ZIP file, you’ll see three subfolders: amd64 (64-bit systems), x86 (32-bit systems), and ARM64 (ARM systems). Эти параметры позволяют запускать средство в каждом клиенте или версии сервера Windows. These options enable you to run the tool in every Windows client or server version.

Запустите DISKSPD с помощью следующей команды PowerShell. Run DISKSPD with the following PowerShell command. Замените все в квадратных скобках, включая квадратные скобки, соответствующими параметрами. Replace everything inside the square brackets, including the brackets themselves with your appropriate settings.

Ниже приведен пример команды, которую можно выполнить. Here is an example command that you can run:

Если у вас нет тестового файла, создайте его с помощью параметра -c . If you do not have a test file, use the -c parameter to create one. Если вы используете этот параметр, не забудьте включить имя тестового файла при определении пути. If you use this parameter, be sure to include the test file name when you define your path. Пример: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. For example: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. В примере команда IO. dat — это имя файла теста, а test01.txt — имя выходного файла DISKSPD. In the example command, IO.dat is the test file name, and test01.txt is the DISKSPD output file name.

Укажите параметры ключа Specify key parameters

Ну, это было просто верно? Well, that was simple right? К сожалению, это не так. Unfortunately, there is more to it than that. Давайте расскажем, что мы сделали. Let’s unpack what we did. Во первых, существуют различные параметры, которые можно мучиться с помощью и могут получить конкретные. First, there are various parameters that you can tinker with and it can get specific. Однако мы использовали следующий набор базовых параметров: However, we used the following set of baseline parameters:

Параметры DISKSPD чувствительны к регистру. DISKSPD parameters are case sensitive.

-T2: указывает количество потоков на целевой или тестовый файл. -t2: This indicates the number of threads per target/test file. Это число часто определяется количеством ядер ЦП. This number is often based on the number of CPU cores. В этом случае для нагрузки всех ядер ЦП использовалось два потока. In this case, two threads were used to stress all of the CPU cores.

-o32: указывает количество необработанных запросов ввода-вывода на один объект для каждого потока. -o32: This indicates the number of outstanding I/O requests per target per thread. Это также называется глубиной очереди, и в данном случае для нагрузки ЦП использовались 32. This is also known as the queue depth, and in this case, 32 were used to stress the CPU.

-b4K: указывает размер блока в байтах, КИБ, MIB или гиб. -b4K: This indicates the block size in bytes, KiB, MiB, or GiB. В этом случае для имитации произвольного теста ввода-вывода использовался размер блока 4 КБ. In this case, 4K block size was used to simulate a random I/O test.

-r4K: указывает, что случайные операции ввода-вывода выдаются по заданному размеру в байтах, КИБ, MIB, гиб или блоках (переопределяет параметр -s ). -r4K: This indicates the random I/O aligned to the specified size in bytes, KiB, MiB, Gib, or blocks (Overrides the -s parameter). Общий размер в 4 КБ для правильного согласования с размером блока. The common 4K byte size was used to properly align with the block size.

-W0: указывает процент операций, которые являются запросами записи (-W0 эквивалентен 100% Read). -w0: This specifies the percentage of operations that are write requests (-w0 is equivalent to 100% read). В этом случае для простого теста были использованы 0% операций записи. In this case, 0% writes were used for the purpose of a simple test.

-D120: это указывает длительность теста, не включая бесшумность или прогрев. -d120: This specifies the duration of the test, not including cool-down or warm-up. Значение по умолчанию — 10 секунд, но для любой серьезной рабочей нагрузки рекомендуется использовать не менее 60 секунд. The default value is 10 seconds, but we recommend using at least 60 seconds for any serious workload. В этом случае для снижения числа выбросов было использовано 120 секунд. In this case, 120 seconds were used to minimize any outliers.

-СУВ: отключает кэширование записи программного обеспечения и оборудования (эквивалентно -sh). -Suw: Disables software and hardware write caching (equivalent to -Sh).

-D: захватывается Статистика операций ввода-вывода, например стандартное отклонение, в миллисекундах (для каждого потока, для каждого целевого объекта). -D: Captures IOPS statistics, such as standard deviation, in intervals of milliseconds (per-thread, per-target).

-L: измеряет статистику задержки. -L: Measures latency statistics.

-c5g: задает размер образца файла, используемого в тесте. -c5g: Sets the sample file size used in the test. Его можно задать в байтах, КИБ, MiB, гиб или блоках. It can be set in bytes, KiB, MiB, GiB, or blocks. В этом случае использовался целевой файл размером 5 ГБ. In this case, a 5 GB target file was used.

Полный список параметров см. в репозитории GitHub. For a complete list of parameters, refer to the GitHub repository.

Общие сведения о среде Understand the environment

Производительность в значительной степени зависит от среды. Performance heavily depends on your environment. Итак, какова наша среда? So, what is our environment? Наша спецификация включает кластер Azure Stack ХЦИ с пулом носителей и Локальные дисковые пространства (S2D). Our specification involves an Azure Stack HCI cluster with storage pool and Storage Spaces Direct (S2D). В частности, есть пять виртуальных машин: DC, NODE1, NODE2, Node3 и узел управления. More specifically, there are five VMs: DC, node1, node2, node3, and the management node. Сам кластер — это кластер из трех узлов с трехуровневой зеркально отраженной структурой устойчивости. The cluster itself is a three-node cluster with a three-way mirrored resiliency structure. Поэтому поддерживаются три копии данных. Therefore, three data copies are maintained. Каждый узел кластера является Standard_B2ms виртуальной машиной с максимальным пределом в 1920 операций ввода-вывода в секунду. Each “node” in the cluster is a Standard_B2ms VM with a maximum IOPS limit of 1920. В каждом узле есть четыре накопителя P30 SSD Premium с максимальным предельным числом операций ввода-вывода в секунду, равным 5000. Within each node, there are four premium P30 SSD drives with a maximum IOPS limit of 5000. Наконец, на каждом накопителе SSD имеется 1 ТБ памяти. Finally, each SSD drive has 1 TB of memory.

Тестовый файл создается в едином пространстве имен, предоставляемом общий том кластера (CSV) для использования всего пула дисков. You generate the test file under the unified namespace that the Cluster Shared Volume (CSV) provides (C:\ClusteredStorage) to use the entire pool of drives.

В примере среды отсутствует Hyper -V или вложенная структура виртуализации. The example environment does not have Hyper-V or a nested virtualization structure.

Как вы увидите, вы полностью можете независимо достигать ограничений ввода-вывода или пропускной способности в пределах виртуальной машины или диска. As you’ll see, it’s entirely possible to independently hit either the IOPS or bandwidth ceiling at the VM or drive limit. И поэтому важно понимать размер виртуальной машины и тип диска, так как в обоих случаях предельное число операций ввода-вывода в секунду и пропускная способность. And so, it is important to understand your VM size and drive type, because both have a maximum IOPS limit and a bandwidth ceiling. Эти знания помогают определить узкие места и оценить результаты производительности. This knowledge helps to locate bottlenecks and understand your performance results. Дополнительные сведения о том, какой размер может подойти для вашей рабочей нагрузки, см. в следующих ресурсах: To learn more about what size may be appropriate for your workload, see the following resources:

Общие сведения о выходных данных Understand the output

Зная о параметрах и среде, вы можете интерпретировать выходные данные. Armed with your understanding of the parameters and environment, you’re ready to interpret the output. Во-первых, цель предыдущего теста — обеспечить максимальное количество операций ввода-вывода в секунду без учета задержки. First, the goal of the earlier test was to max out the IOPS with no regard to latency. Таким образом вы можете визуально увидеть, достигли ли вы ограничения искусственного ввода-вывода в Azure. This way, you can visually see whether you reach the artificial IOPS limit within Azure. Если необходимо графически визуализировать общее количество операций ввода-вывода в секунду, используйте центр администрирования Windows или диспетчер задач. If you want to graphically visualize the total IOPS, use either Windows Admin Center or Task Manager.

На следующей схеме показано, как выглядит процесс DISKSPD в нашем примере среды. The following diagram shows what the DISKSPD process looks like in our example environment. В нем показан пример операции записи MiB из одного узла без координатора. It shows an example of a 1 MiB write operation from a non-coordinator node. Трехуровневая структура устойчивости, а также операция из узла без координатора, приводит к двум прыжкам в сети, уменьшая производительность. The three-way resiliency structure, along with the operation from a non-coordinator node, leads to two network hops, decreasing performance. Если вы не знаете, что такое узел координатора, не беспокойтесь! If you’re wondering what a coordinator node is, don’t worry! Вы узнаете о нем в разделе вещи, которые следует учесть . You’ll learn about it in the Things to consider section. Красные квадратики представляют узкие места виртуальной машины и диска. The red squares represent the VM and drive bottlenecks.

Теперь, когда у вас есть визуальное понимание, рассмотрим четыре основных раздела выходных данных TXT-файла: Now that you’ve got a visual understanding, let’s examine the four main sections of the .txt file output:

Входные параметры Input settings

В этом разделе описана выполняемая команда, входные параметры и дополнительные сведения о тестовом запуске. This section describes the command you ran, the input parameters, and additional details about the test run.

Сведения об использовании ЦП CPU utilization details

В этом разделе представлены такие сведения, как время тестирования, количество потоков, количество доступных процессоров и среднее использование каждого ядра ЦП во время тестирования. This section highlights information such as the test time, number of threads, number of available processors, and the average utilization of every CPU core during the test. В этом случае существует два ядра ЦП, которые усреднены примерно на 4,67% использования. In this case, there are two CPU cores that averaged around 4.67% usage.

Всего операций ввода-вывода Total I/O

Этот раздел содержит три подраздела. This section has three subsections. В первом разделе показаны общие данные о производительности, включая операции чтения и записи. The first section highlights the overall performance data including both read and write operations. Во втором и третьем разделах операции чтения и записи разбиваются на отдельные категории. The second and third sections split the read and write operations into separate categories.

В этом примере можно увидеть, что общее число операций ввода-вывода составило 234408 в течение 120-секунды. In this example, you can see that the total I/O count was 234408 during the 120-second duration. Таким же, операции ввода-вывода = 234408/120 = 1953,30. Thus, IOPS = 234408 /120 = 1953.30. Средняя задержка составила 32,763 миллисекунд, а пропускная способность — 7,63 MiB/с. The average latency was 32.763 milliseconds, and the throughput was 7.63 MiB/s. С более ранних сведений мы понимаем, что 1953,30 операций ввода-вывода в секунду превышено ограничение 1920 на число операций ввода-вывода для Standard_B2ms виртуальной машины. From earlier information, we know that the 1953.30 IOPS are near the 1920 IOPS limitation for our Standard_B2ms VM. Не считаете это? Don’t believe it? При повторном выполнении теста с другими параметрами, например при увеличении глубины очереди, вы обнаружите, что результаты по-прежнему ограничены по этому номеру. If you rerun this test using different parameters, such as increasing the queue depth, you’ll find that the results are still capped at this number.

В последних трех столбцах показано стандартное отклонение операций ввода-вывода в 17,72 (от параметра-D), стандартное отклонение задержки в 20,994 миллисекунд (из параметра-L) и путь к файлу. The last three columns show the standard deviation of IOPS at 17.72 (from -D parameter), the standard deviation of the latency at 20.994 milliseconds (from -L parameter), and the file path.

Из результатов можно быстро определить, что конфигурация кластера — плохой. From the results, you can quickly determine that the cluster configuration is terrible. Вы видите, что она достигла ограничения на виртуальную машину 1920 до ограничения SSD, равного 5000. You can see that it hit the VM limitation of 1920 before the SSD limitation of 5000. Если вы ограничили диском SSD, а не виртуальной машиной, то можете использовать до 20000 операций ввода-вывода (4 диска * 5000), разустановив тестовый файл на нескольких дисках. If you were limited by the SSD rather than the VM, you could have taken advantage of up to 20000 IOPS (4 drives * 5000) by spanning the test file across multiple drives.

В итоге необходимо решить, какие значения приемлемы для конкретной рабочей нагрузки. In the end, you need to decide what values are acceptable for your specific workload. На следующем рисунке показаны некоторые важные связи, которые помогут оценить компромиссы: The following figure shows some important relationships to help you consider the tradeoffs:

Вторая связь на рисунке важна, и ее иногда называют минимальным законодательством. The second relationship in the figure is important, and it’s sometimes referred to as Little’s Law. В этом законодательстве есть три характеристики, которые управляют поведением процесса, и необходимо изменить один из них, чтобы повлиять на другие два, и, таким образом, весь процесс. The law introduces the idea that there are three characteristics that govern process behavior and that you only need to change one to influence the other two, and thus the entire process. Если вы не довольны производительностью системы, у вас есть три измерения свободы, влияющие на нее. And so, if you’re unhappy with your system’s performance, you have three dimensions of freedom to influence it. В нашем примере это «пропускная способность» (операций ввода-вывода в секунду), задержка — «время очереди», а в поле «глубина очереди» — «Инвентаризация». Little’s Law dictates that in our example, IOPS is the «throughput» (input output operations per second), latency is the «queue time», and queue depth is the «inventory».

Анализ процентилей с задержкой Latency percentile analysis

В этом последнем разделе подробно описана задержка процентилей на тип операции хранилища с минимальным значением до максимального значения. This last section details the percentile latencies per operation type of storage performance from the minimum value to the maximum value.

Этот раздел важен, так как он определяет «качество» операций ввода-вывода. This section is important because it determines the “quality” of your IOPS. Он показывает, сколько операций ввода-вывода смогли достичь определенного значения задержки. It reveals how many of the I/O operations were able to achieve a certain latency value. Вы можете выбрать допустимую задержку для этого процентиля. It’s up to you to decide the acceptable latency for that percentile.

Более того, «девять» относятся к количеству девяти. Moreover, the “nines” refer to the number of nines. Например, «3-девять» эквивалентны 99-м процентиль. For example, “3-nines” is equivalent to the 99th percentile. Число девяти показывает, сколько операций ввода-вывода выполнялось в этом процентиль. The number of nines exposes how many I/O operations ran at that percentile. Со временем вы будете обращаться к точке, где больше не имеет смысла принимать значения задержки. Eventually, you’ll reach a point where it no longer makes sense to take the latency values seriously. В этом случае можно увидеть, что значения задержки остаются постоянными после 4-девяти. In this case, you can see that the latency values remain constant after “4-nines.” На этом этапе значение задержки основано только на одной операции ввода-вывода из операций 234408. At this point, the latency value is based on only one I/O operation out of the 234408 operations.

Полезная информация Things to consider

Теперь, когда вы начали использовать DISKSPD, необходимо рассмотреть несколько моментов, чтобы получить реальные результаты теста. Now that you’ve started using DISKSPD, there are several things to consider to get real-world test results. Они включают в себя особое внимание к заданным параметрам, работоспособности дискового пространства и переменным, владельцам CSV, а также разнице между DISKSPD и копированием файлов. These include paying close attention to the parameters you set, storage space health and variables, CSV ownership, and the difference between DISKSPD and file copy.

Сравнение DISKSPD и реального мира DISKSPD vs. real-world

Искусственный тест DISKSPD дает вам сравнительно сравнимые результаты для реальной рабочей нагрузки. DISKSPD’s artificial test gives you relatively comparable results for your real workload. Однако необходимо обратить внимание на заданные параметры и определить, соответствуют ли они реальному сценарию. However, you need to pay close attention to the parameters you set and whether they match your real scenario. Важно понимать, что искусственные рабочие нагрузки никогда не будут идеально представлять реальную рабочую нагрузку приложения во время развертывания. It’s important to understand that synthetic workloads will never perfectly represent your application’s real workload during deployment.

Подготовка Preparation

Перед выполнением теста DISKSPD существует несколько рекомендуемых действий. Before running a DISKSPD test, there are a few recommended actions. Сюда входит проверка работоспособности дискового пространства, проверка использования ресурсов, чтобы другая программа не влияла на тест, и подготовка диспетчера производительности, если требуется получить дополнительные данные. These include verifying the health of the storage space, checking your resource usage so that another program doesn’t interfere with the test, and preparing performance manager if you want to collect additional data. Тем не менее, поскольку цель этой статьи — быстро получить DISKSPD, она не посвящена этим действиям. However, because the goal of this topic is to quickly get DISKSPD running, it doesn’t dive into the specifics of these actions. Дополнительные сведения см. в статье Проверка производительности дисковых пространств с помощью искусственных рабочих нагрузок в Windows Server. To learn more, see Test Storage Spaces Performance Using Synthetic Workloads in Windows Server.

Переменные, влияющие на производительность Variables that affect performance

Производительность хранилища — это детальнаяая вещь. Storage performance is a delicate thing. Это означает, что существует множество переменных, которые могут повлиять на производительность. Meaning, there are many variables that can affect performance. И, скорее всего, вы можете столкнуться с числом, не соответствующим ожиданиям. And so, it’s likely you may encounter a number that is inconsistent with your expectations. Ниже перечислены некоторые переменные, влияющие на производительность, хотя это не исчерпывающий список. The following highlights some of the variables that affect performance, although it’s not a comprehensive list:

• Пропускная способность сети Network bandwidth
• Вариант устойчивости Resiliency choice
• Конфигурация диска хранилища: NVME, SSD, HDD Storage disk configuration: NVME, SSD, HDD
• Буфер ввода-вывода I/O buffer
• Кэш Cache
• Конфигурация RAID RAID configuration
• Прыжки сети Network hops
• Скорость вращения жестких дисков Hard drive spindle speeds

Владение CSV CSV ownership

Узел называется владельцем тома или узлом координатора (узел без координатора будет узлом, который не владеет указанным томом). A node is known as a volume owner or the coordinator node (a non-coordinator node would be the node that does not own a specific volume). Каждому стандартному тому назначается узел, и другие узлы могут получить доступ к этому стандартному тому через прыжки сети, что приводит к снижению производительности (более высокую задержку). Every standard volume is assigned a node and the other nodes can access this standard volume through network hops, which results in slower performance (higher latency).

Аналогично, общий том кластера (CSV) также имеет «Owner». Similarly, a Cluster Shared Volume (CSV) also has an “owner.” Однако CSV является «динамическим» в том смысле, что он будет переключаться и изменять владельца при каждом перезапуске системы (RDP). However, a CSV is “dynamic” in the sense that it will hop around and change ownership every time you restart the system (RDP). Поэтому важно убедиться, что DISKSPD выполняется из узла координатора, владеющего CSV-файлом. As a result, it’s important to confirm that DISKSPD is run from the coordinator node that owns the CSV. В противном случае может потребоваться изменить владельца CSV вручную. If not, you may need to manually change the CSV ownership.

Чтобы подтвердить владение CSV-файлом: To confirm CSV ownership:

Проверьте владение, выполнив следующую команду PowerShell: Check ownership by running the following PowerShell command:

Если владение CSV неверно (например, если вы работаете в NODE1, но NODE2 владеет CSV), переместите этот CSV-файл в правильный узел, выполнив следующую команду PowerShell: If the CSV ownership is incorrect (For example, you are on Node1 but Node2 owns the CSV), then move the CSV to the correct node by running the following PowerShell command:

Копирование файлов и DISKSPD File copy vs. DISKSPD

Некоторые считают, что они могут «протестировать производительность хранилища», скопировав и вставляя файл гигантских и измеряя время, затрачиваемое этим процессом. Some people believe that they can “test storage performance” by copying and pasting a gigantic file and measuring how long that process takes. Основная причина этого подхода, скорее всего, заключается в том, что это просто и быстро. The main reason behind this approach is most likely because it’s simple and fast. Идея не имеет смысла в том смысле, что она тестирует определенную рабочую нагрузку, но при этом сложно классифицировать этот метод как «тестирование производительности хранилища». The idea is not wrong in the sense that it tests a specific workload, but it’s difficult to categorize this method as “testing storage performance.”

Если реальной целью является проверка производительности копирования файлов, это может быть вполне действительной причиной для использования этого метода. If your real-world goal is to test file copy performance, then this may be a perfectly valid reason to use this method. Однако если ваша цель заключается в измерении производительности хранилища, рекомендуется не использовать этот метод. However, if your goal is to measure storage performance, we recommend to not use this method. Процесс копирования файлов можно считать, используя другой набор параметров (например, очередь, параллелизации и т. д.), характерный для файловых служб. You can think of the file copy process as using a different set of “parameters” (such as queue, parallelization, and so on) that is specific to file services.

В следующей краткой сводке объясняется, почему использование копирования файлов для измерения производительности хранилища может не дать искомых результатов: The following short summary explains why using file copy to measure storage performance may not provide the results that you’re looking for:

Копии файлов могут быть не оптимизированы . Существует два уровня параллелизма: один внутренний и другой внешний. File copies might not be optimized, There are two levels of parallelism that occur, one internal and the other external. На внутреннем уровне, если копирование файлов осуществляется для удаленного целевого объекта, подсистема Копифиликс применяет некоторую параллелизации. Internally, if the file copy is headed for a remote target, the CopyFileEx engine does apply some parallelization. Внешне существуют различные способы вызова подсистемы Копифиликс. Externally, there are different ways of invoking the CopyFileEx engine. Например, копии из проводника являются отдельными потоками, но средство Robocopy является многопоточным. For example, copies from File Explorer are single threaded, but Robocopy is multi-threaded. По этим причинам важно понимать, какие именно последствия теста нужны. For these reasons, it’s important to understand whether the implications of the test are what you are looking for.

Каждая копия имеет две стороны. Every copy has two sides. При простом копировании и вставке файла можно использовать два диска: исходный диск и целевой диск. When you simply copy and paste a file, you may be using two disks: the source disk and the destination disk. Если один из них медленнее другого, то фактически измеряется производительность более медленного диска. If one is slower than the other, you essentially measure the performance of the slower disk. Существуют и другие случаи, когда обмен данными между источником, назначением и подсистемой копирования может повлиять на производительность уникальными способами. There are other cases where the communication between the source, destination, and the copy engine may affect the performance in unique ways.

Эксперименты и распространенные рабочие нагрузки Experiments and common workloads

Этот раздел содержит несколько других примеров, экспериментов и типов рабочих нагрузок. This section includes a few other examples, experiments, and workload types.

Подтверждение узла координатора Confirming the coordinator node

Как упоминалось ранее, если у тестируемой виртуальной машины нет файла CSV, вы увидите отправку производительности (операций ввода-вывода в секунду, пропускная способность и задержка), а не тестирование, когда узел владеет CSV-файлом. As mentioned previously, if the VM you are currently testing does not own the CSV, you’ll see a performance drop (IOPS, throughput, and latency) as opposed to testing it when the node owns the CSV. Это происходит потому, что каждый раз при выполнении операции ввода-вывода система выполняет сетевой переход на узел координатора для выполнения этой операции. This is because every time you issue an I/O operation, the system does a network hop to the coordinator node to perform that operation.

В случае трех-узловых зеркальных отражений операции записи всегда выполняют переход в сеть, так как необходимо хранить данные на всех дисках на трех узлах. For a three-node, three-way mirrored situation, write operations always make a network hop because it needs to store data on all the drives across the three nodes. Поэтому операции записи выполняют сетевой переход. Therefore, write operations make a network hop regardless. Однако, если используется другая структура устойчивости, это может измениться. However, if you use a different resiliency structure, this could change.

Пример: Here is an example:

• Выполнение на локальном узле: .\DiskSpd-2.0.21a\amd64\diskspd.exe-T4-o32-b4k-r4k-W0-SH-D-L C:\ClusterStorage\test01\targetfile\IO.dat Running on local node: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
• Запуск на нелокальном узле: .\DiskSpd-2.0.21a\amd64\diskspd.exe-T4-o32-b4k-r4k-W0-SH-D-L C:\ClusterStorage\test01\targetfile\IO.dat Running on nonlocal node: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

В этом примере можно ясно увидеть, что на следующем рисунке показано снижение задержки, увеличение числа операций ввода-вывода в секунду и увеличение пропускной способности, когда узел координатора владеет CSV-файлом. From this example, you can clearly see in the results of the following figure that latency decreased, IOPS increased, and throughput increased when the coordinator node owns the CSV.

Рабочая нагрузка оперативной обработки транзакций (OLTP) Online Transaction Processing (OLTP) workload

Запросы рабочей нагрузки оперативной обработки транзакций (OLTP) (обновление, вставка, удаление) сосредоточены на задачах, ориентированных на транзакции. Online Transactional Processing (OLTP) workload queries (Update, Insert, Delete) focus on transaction-oriented tasks. По сравнению с оперативной аналитической обработкой (OLAP), OLTP зависит от задержки хранилища. Compared to Online Analytical Processing (OLAP), OLTP is storage latency dependent. Так как каждая операция выполняется с небольшим количеством операций ввода-вывода, то, что вы следите, — это число выполняемых в секунду действий. Because each operation issues little I/O, what you care about is how many operations per second you can sustain.

Можно разработать тест рабочей нагрузки OLTP, чтобы сосредоточиться на случайной, небольшой производительности ввода-вывода. You can design an OLTP workload test to focus on random, small I/O performance. Для этих тестов Сосредоточьтесь на том, насколько вы можете повысить пропускную способность и поддерживать приемлемые задержки. For these tests, focus on how far you can push the throughput while maintaining acceptable latencies.

Базовый вариант проектирования для этого теста рабочей нагрузки должен включать как минимум: The basic design choice for this workload test should at a minimum include:

• 8 КБ размер блока => напоминает размер страницы, который SQL Server использует для своих файлов данных 8 KB block size => resembles the page size that SQL Server uses for its data files
• 70% Read, 30% записи => похожа на типичное поведение OLTP 70% Read, 30% Write => resembles typical OLTP behavior

Рабочая нагрузка оперативной аналитической обработки (OLAP) Online Analytical Processing (OLAP) workload

Рабочие нагрузки OLAP сосредоточены на получении и анализе данных, что позволяет пользователям выполнять сложные запросы для извлечения многомерных данных. OLAP workloads focus on data retrieval and analysis, allowing users to perform complex queries to extract multidimensional data. В отличие от OLTP, эти рабочие нагрузки не зависят от задержки хранилища. Contrary to OLTP, these workloads are not storage latency sensitive. Они наделяют очередь на множество операций, не волнует много времени на пропускную способность. They emphasize queueing many operations without caring much about bandwidth. В результате рабочие нагрузки OLAP часто приводят к длительному времени обработки. As a result, OLAP workloads often result in longer processing times.

Можно спроектировать тест рабочей нагрузки OLAP, чтобы сосредоточиться на последовательной и большой производительности операций ввода-вывода. You can design an OLAP workload test to focus on sequential, large I/O performance. Для этих тестов Сосредоточьтесь на объеме данных, обрабатываемых в секунду, а не на количестве операций ввода-вывода. For these tests, focus on the volume of data processed per second rather than the number of IOPS. Требования к задержке также менее важны, но это субъективная информация. Latency requirements are also less important, but this is subjective.

Базовый вариант проектирования для этого теста рабочей нагрузки должен включать как минимум: The basic design choice for this workload test should at a minimum include:

512 КБ размер блока => напоминает размер ввода-вывода, когда SQL Server загружает пакет 64 страниц данных для просмотра таблицы с помощью метода упреждающего чтения. 512 KB block size => resembles the I/O size when the SQL Server loads a batch of 64 data pages for a table scan by using the read-ahead technique.

1 поток на файл => в настоящее время необходимо ограничить тестирование одним потоком для каждого файла, так как при тестировании нескольких последовательных потоков могут возникнуть проблемы в DISKSPD. 1 thread per file => currently, you need to limit your testing to one thread per file as problems may arise in DISKSPD when testing multiple sequential threads. Если вы используете более одного потока, скажем два, и параметр -s , потоки будут приступать к недетерминированной выдаче операций ввода-вывода в одном и том же расположении. If you use more than one thread, say two, and the -s parameter, the threads will begin non-deterministically to issue I/O operations on top of each other within the same location. Это обусловлено тем, что каждый из них следит за собственным порядковым смещением. This is because they each track their own sequential offset.

Существует два «решения» для решения этой проблемы: There are two “solutions” to resolve this issue:

В первом решении используется параметр -Si . The first solution involves using the -si parameter. При использовании этого параметра оба потока совместно используют одно блокируемое смещение, чтобы потоки могли совместно выполнять один последовательный шаблон доступа к целевому файлу. With this parameter, both threads share a single interlocked offset so that the threads cooperatively issue a single sequential pattern of access to the target file. Это позволяет не использовать одну точку в файле более одного раза. This allows no one point in the file to be operated on more than once. Однако, поскольку они по-прежнему выполняют состязание друг с другом для выполнения операции ввода-вывода в очереди, операции могут поступать не по порядку. However, because they still do race each other to issue their I/O operation to the queue, the operations may arrive out of order.

Это решение хорошо работает, если один поток оказывается ограничен ЦП. This solution works well if one thread becomes CPU limited. Вы можете использовать второй поток на втором ядре ЦП, чтобы обеспечить больший объем операций ввода-вывода хранилища в систему ЦП для дальнейшей насыщенности. You may want to engage a second thread on a second CPU core to deliver more storage I/O to the CPU system to further saturate it.

Второе решение включает использование-T . The second solution involves using the -T . Это позволяет указать размер смещения (между вводом-выводом) между операциями ввода-вывода, выполняемыми в одном и том же целевом файле, различными потоками. This allows you to specify the offset size (inter-I/O gap) between I/O operations performed on the same target file by different threads. Например, потоки обычно начинаются со смещения 0, но эта спецификация позволяет порасстоянию двух потоков, чтобы они не перекрывали друг друга. For example, threads normally start at offset 0, but this specification allows you to distance the two threads so that they will not overlap each other. В любой многопоточной среде потоки, скорее всего, будут находиться на разных частях рабочего целевого объекта, и это способ моделирования этой ситуации. In any multithreaded environment, the threads will likely be on different portions of the working target, and this is a way of simulating that situation.

Следующие шаги Next steps

Дополнительные сведения и подробные примеры оптимизации параметров устойчивости см. в разделе также: For more information and detailed examples on optimizing your resiliency settings, see also: