Стандартные показатели производительности томов Azure NetApp Files для Linux
В этой статье описываются тесты производительности Azure NetApp Files для Linux с обычным томом.
Все рабочие нагрузки потоковой передачи файлов (тесты тестов на основе горизонтального масштабирования)
Цель теста горизонтального масштабирования — показать производительность тома Файла Azure NetApp при масштабировании (или увеличении) числа клиентов, генерирующих одновременную рабочую нагрузку на тот же том. Как правило, эти тесты могут отправлять том на край своих ограничений производительности и указывают на рабочие нагрузки, такие как отрисовка мультимедиа, ИИ/ML и другие рабочие нагрузки, использующие большие вычислительные фермы для выполнения работы.
Конфигурация тестов с высоким масштабируемым масштабированием операций ввода-вывода
Эти тесты используют следующие показатели:
- Один обычный том Azure NetApp Files 100-TiB с набором данных 1-ТиБ с использованием уровня производительности "Ультра"
- FIO (с параметром randrepeat=0)
- Размер блока 4-KiB и 8 КиБ
- 6 D32s_v5 виртуальных машин с RHEL 9.3
- NFSv3
- Руководство по QoS
- Параметры подключения: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Конфигурация эталонного теста масштабирования высокой пропускной способности
Эти тесты используют следующие показатели:
- Один регулярный том Azure NetApp Files с набором данных 1-TiB с помощью FIO уровня производительности "Ультра" (с параметром randrepeat=0)
- FIO (с параметром randrepeat=0)
- Размер блока 64-KiB и 256-KiB
- 6 D32s_v5 виртуальных машин с RHEL 9.3
- NFSv3
- Руководство по QoS
- Параметры подключения: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Конфигурация тестов параллельного сетевого подключения (nconnect)
Эти тесты используют следующие показатели:
- Один обычный том Azure NetApp Files с набором данных 1 ТиБ с помощью уровня производительности "Ультра"
- FIO (с параметром randrepeat=0)
- 4-KiB и 64-KiB wsize/rsize
- Одна D32s_v4 виртуальная машина под управлением RHEL 9.3
- NFSv3 с и без
nconnect - Параметры подключения: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Тесты тестов на основе масштабирования
Цель теста масштабирования — показать производительность тома Azure NetApp File при увеличении (или увеличении) количества заданий, генерирующих одновременную рабочую нагрузку для нескольких TCP-подключений на одном клиенте, к одному тому (например, с nconnect).
Без nconnectэтого эти рабочие нагрузки не могут отправлять ограничения максимальной производительности тома, так как клиент не может генерировать достаточную пропускную способность ввода-вывода или сети. Как правило, эти тесты свидетельствуют о том, что взаимодействие с одним пользователем может находиться в рабочих нагрузках, таких как отрисовка мультимедиа, базы данных, ИИ/ML и общие общие файловые ресурсы.
Высокомасштабируемые тесты масштабирования операций ввода-вывода
В следующих тестах производительность, достигнутная для Azure NetApp Files с высокой рабочей нагрузкой ввода-вывода и операций ввода-вывода, используется:
- 32 клиента
- 4-KiB и 8-KiB случайные операции чтения и записи
- Набор данных 1-TiB
- Коэффициенты чтения и записи: 100%:0%, 90%:10%, 80%:20%, т. д.
- Кэширование файловой системы и без нее (использование
randrepeat=0в FIO)
Дополнительные сведения см . в статье "Методология тестирования".
Результаты: 4 КиБ, случайное кэширование клиента
В этом тесте FIO выполнялся без randrepeat параметра случайной обработки данных. Таким образом, неопределенное количество кэширования вступило в игру. Эта конфигурация приводит к значительно лучшему общему количеству производительности, чем тесты запускаются без кэширования с использованием всего стека операций ввода-вывода.
На следующем графике тестирования показан регулярный том Azure NetApp Files, который может обрабатываться примерно от 130 000 чистых случайных операций записи 4-KiB и примерно 460 000 чистых случайных 4 КИБ считывается во время этого теста. Сочетание операций чтения и записи для рабочей нагрузки, скорректированной на 10 % для каждого запуска.
По мере увеличения объема операций ввода-записи операций чтения и операций ввода-операций в режиме записи общий объем операций ввода-записи увеличивается.
Результаты: 4 КиБ, случайное кэширование клиента, исключенное
В этом тесте FIO был запущен с параметром randrepeat=0 случайных данных, уменьшая влияние кэширования на производительность. Это привело к сокращению операций ввода-вывода и операций ввода-вывода примерно на 8 % и примерно на 17 % при чтении операций ввода-вывода, но отображает более репрезентативные показатели производительности того, что на самом деле может сделать хранилище.
На следующем графике тестирования показан регулярный том Azure NetApp Files, который может обрабатываться примерно от 120 000 чистых случайных операций записи 4-KiB и примерно 388 000 чистых случайных операций чтения 4-KiB. Сочетание операций чтения и записи для рабочей нагрузки, скорректированной на 25 % для каждого запуска.
По мере увеличения объема операций ввода-записи операций чтения и операций ввода-операций в режиме записи общий объем операций ввода-записи увеличивается.
Результаты: 8 КиБ, случайное кэширование клиента, исключенное
Более крупные размеры операций чтения и записи приводят к меньшему общему объему операций ввода-вывода, так как с каждой операцией можно отправлять больше данных. Размер чтения и записи 8 КИБ использовался для более точной имитации использования большинства современных приложений. Например, многие приложения EDA используют 8-KiB чтения и записи.
В этом тесте FIO выполнялся со randrepeat=0 случайными данными, чтобы снизить влияние кэширования клиента. На следующем графике тестирования показано, что регулярный том Azure NetApp Files может обрабатываться примерно от 111 000 чистых случайных операций записи 8-KiB и примерно 293 000 чистых случайных операций чтения 8-КиБ. Сочетание операций чтения и записи для рабочей нагрузки, скорректированной на 25 % для каждого запуска.
По мере увеличения объема операций ввода-записи операций чтения и операций ввода-операций в режиме записи общий объем операций ввода-записи увеличивается.
Параллельное сравнение
Чтобы иллюстрировать, как кэширование может повлиять на тесты производительности, на следующем графике показан общий объем операций ввода-вывода для 4-КиБ-тестов с механизмами кэширования и без нее. Как показано выше, кэширование обеспечивает небольшое повышение производительности для довольно согласованного тренда ввода-вывода в секунду.
Конкретное смещение, потоковая передача случайных рабочих нагрузок чтения и записи: масштабирование тестов с помощью параллельных сетевых подключений (nconnect)
В следующих тестах показан высокий тест ввода-вывода с использованием одного клиента с 4-KiB случайными рабочими нагрузками и набором данных 1-TiB. Сочетание рабочих нагрузок, созданное каждый раз, использует другую глубину ввода-вывода. Чтобы повысить производительность для одной клиентской рабочей нагрузки, nconnect параметр подключения использовался для улучшения параллелизма по сравнению с подключениями клиентов без nconnect параметра подключения.
При использовании стандартного TCP-подключения, предоставляющего только один путь к хранилищу, меньше общих операций отправляются в секунду, чем если подключение может использовать больше TCP-подключений (например, с nconnect) на точку подключения. При использовании nconnectобщая задержка операций обычно ниже. Эти тесты также выполняются, randrepeat=0 чтобы намеренно избежать кэширования. Дополнительные сведения об этом параметре см . в статье "Методология тестирования".
Результаты: 4 КиБ, случайные, без nconnectкэширования исключенные
На следующих графиках показано параллельное сравнение операций чтения и записи 4 КиБ и без nconnect выделения улучшений производительности при использовании nconnect: более высокая общая задержка ввода-вывода и операций ввода-вывода.
Тесты высокой пропускной способности
В следующих тестах показана производительность, достигнутная для Azure NetApp Files с высокой пропускной способностью.
Рабочие нагрузки с высокой пропускной способностью являются более последовательными и часто удобочитаются и записываются с низкими метаданными. Пропускная способность, как правило, более важна, чем I/OPS. Эти рабочие нагрузки обычно используют более крупные размеры чтения и записи (64K до 256K), которые создают более высокую задержку, чем меньшие размеры чтения и записи, так как большие полезные данные, естественно, будут обрабатываться дольше.
Ниже приведены примеры рабочих нагрузок высокой пропускной способности:
- Репозитории мультимедиа
- Для высокопроизводительных вычислений
- ИИ/ML/ML/ТОО
В следующих тестах показана высокая пропускная способность с использованием 64-KiB и 256-KiB последовательных рабочих нагрузок и набора данных 1-ТиБ. При использовании различных коэффициентов чтения и записи (например, 100%:0%, 90%:100%, 90%:10%, 80%:20% и т. д.).
Результаты: 64 КиБ последовательного ввода-вывода, включена кэширование
В этом тесте FIO выполнялся с помощью логики цикла, которая более агрессивно заполняла кэш, поэтому неопределенное количество кэширования повлияло на результаты. Это приводит к немного лучшему общему числу производительности, чем тесты выполняются без кэширования.
На приведенном ниже графике тестирование показывает, что обычный том Azure NetApp Files может обрабатываться примерно от 4500MiB/с чистой последовательной записи 64-KiB и приблизительно 1600MiB/с чистой последовательной записи 64-KiB. Сочетание чтения и записи для рабочей нагрузки было скорректировано на 10 % для каждого запуска.
Результаты: 64 KiB последовательных операций ввода-вывода, считывает и записывает, базовые показатели без кэширования
В этом базовом тесте тестирование демонстрирует, что обычный том Azure NetApp Files может обрабатываться примерно от 3600 МиБ/с чистой последовательной 64-KiB чтения и примерно 2400 МиБ/секунды чистой последовательной записи 64-KiB. Во время тестов 50/50 смесь показала общую пропускную способность по пару с чистой последовательной рабочей нагрузкой чтения.
В отношении чистого чтения базовые показатели 64-КИБ были немного лучше, чем базовые показатели 256-КИБ. Если дело доходит до чистой записи и всех смешанных рабочих нагрузок чтения и записи, однако базовые показатели 256-КиБ превзировали 64 КИБ, что указывает на более большой размер блока 256 КИБ является более эффективным для рабочих нагрузок с высокой пропускной способностью.
Сочетание чтения и записи для рабочей нагрузки было скорректировано на 25 % для каждого запуска.
Результаты: 256 КиБ последовательного ввода-вывода без кэширования
В следующих двух базовых тестах FIO использовался для измерения объема последовательного ввода-вывода (чтения и записи) одного регулярного тома в Azure NetApp Files. Чтобы создать базовые показатели, отражающие истинную пропускную способность, которую может достичь полностью некачеченная рабочая нагрузка чтения, FIO была настроена для запуска с параметром randrepeat=0 для создания набора данных. Каждая итерация теста была смещена путем чтения полностью отдельного большого набора данных, не являющегося частью теста, для очистки любого кэширования, которое могло произойдить с помощью набора данных теста.
На этом графе тестирование показывает, что обычный том Azure NetApp Files может обрабатываться примерно от 3500 МиБ/с чистой последовательной записи 256-KiB и приблизительно 2500 МиБ/с чистой последовательной записи 256-KiB. Во время тестов 50/50 смесь показала, что общая пропускная способность достигла максимума выше чистой последовательной рабочей нагрузки чтения.
Параллельные сетевые подключения (nconnect)
В следующих тестах показан высокий тест ввода-вывода с использованием одного клиента с 64-КиБ случайными рабочими нагрузками и набором данных 1 ТиБ. Сочетание рабочих нагрузок, созданное каждый раз, использует другую глубину ввода-вывода. Чтобы повысить производительность для одной клиентской рабочей нагрузки, nconnect параметр подключения использовался для улучшения параллелизма по сравнению с подключениями клиентов, которые не использовали nconnect параметр подключения. Эти тесты выполнялись только с исключением кэширования.
Результаты: 64KiB последовательных операций ввода-вывода, сравнение кэша пропускной способности чтения
Чтобы продемонстрировать, как кэширование влияет на результаты производительности, FIO использовался в следующем сравнении микромарка для измерения количества последовательных операций ввода-вывода (чтение и запись) одного регулярного тома в Azure NetApp Files. Этот тест отличается от преимуществ частично кэшируемой рабочей нагрузки.
В результате без кэширования тестирование было разработано для устранения любого кэширования, как описано в базовых тестах, приведенных выше.
В другом результате FIO использовался для регулярных томов Azure NetApp Files без randrepeat=0 параметра и использования логики итерации циклического тестирования, которая медленно заполняла кэш с течением времени. Сочетание этих факторов создало неопределенное количество кэширования, повышая общую пропускную способность. Эта конфигурация привела к немного лучшему общему числу производительности чтения, чем тесты выполняются без кэширования.
Результаты теста, отображаемые на графике, отображают параллельное сравнение производительности чтения и без влияния кэширования, где кэширование составило до ~4500 МиБ/секунды, а кэширование не достигается около 3600 МиБ/секунды.
Параллельное сравнение (с и без)nconnect
На следующих графиках показано параллельное сравнение 64-KiB последовательных операций чтения и записи без nconnect выделения улучшений производительности при использовании nconnect: более высокая общая пропускная способность, низкая задержка.
