Только что закончили настройку SAN для бедных с iSCSI и хотите протестировать ее. Какие еще есть хорошие тесты производительности ввода-вывода для Linux, помимо:
hdparm -tT /dev/sda1
Как мне получить измерение IOPS?
Спасибо.
По крайней мере, в Linux во всех ответах синтетического тестирования следует упомянуть фио - это действительно генератор ввода-вывода швейцарского армейского ножа.
Краткое изложение его возможностей:
blktrace можно воспроизвестиСтатистика, которую он дает вам, покрывает
В список функций и вывода продолжается и продолжается.
Он не будет генерировать единое число, которое представляет все в конце, но если вы серьезно относитесь к пониманию производительности хранилища, вы будете знать, что это одно число не может объяснить все, что вам нужно знать. Даже Линус Торвальдс считает, что fio - это хорошо:
Брендан Грегг (инженер по производительности Netflix) также положительно упомянул fio:
Другие мои любимые тесты - fio by @axboe [...]
PS: Вы собираетесь опубликовать тесты, которые вы сделали с помощью fio, на веб-сайте / в документе и т. Д.? Не забывай следовать https://github.com/axboe/fio/blob/master/MORAL-LICENSE !
Я бы рекомендовал использовать Бонни ++ для тестирования производительности диска. Он создан специально для таких вещей.
Я могу предложить вам прочитать эти два сообщения / статьи:
http://www.linuxinsight.com/how_fast_is_your_disk.html http://www.linuxforums.org/forum/red-hat-fedora-linux/153927-iscsi-raid1-lvm-setup-poor-write-performance.html
В частности:
Во-первых, я предлагаю вам использовать более точный и управляемый инструмент для проверки производительности. hdparm был разработан для изменения параметров устройства IDE, и тест, который он выполняет, довольно прост. Вы также не можете сказать, что происходит при использовании hdparm на составных устройствах на LVM и iSCSI. Кроме того, hdparm не тестирует скорость записи, которая не связана со скоростью чтения, поскольку для обоих есть разные оптимизации (кеши обратной записи, алгоритмы упреждающего чтения и предварительной выборки и т. Д.).
Я предпочитаю использовать старую и хорошую команду dd, которая позволяет вам точно контролировать размеры блоков, длину тестов и использование буферного кеша. Он также дает вам красивый и краткий отчет о скорости передачи. Вы также можете протестировать производительность буферного кэша.
Также помните, что здесь задействовано несколько уровней, включая файловую систему. hdparm только проверяет доступ к устройству RAW.
ТЕСТОВЫЕ КОМАНДЫ Я предлагаю использовать следующие команды для тестов:
a) Для необработанных устройств, разделов, томов LVM, программных RAID-массивов, iSCSI LUN (сторона инициатора). Размер блока 1 Мбайт подходит для тестирования скорости массовой передачи для большинства современных устройств. Для тестов TPS используйте небольшие размеры, например 4k. Измените счетчик, чтобы сделать тест более реалистичным (я предлагаю длительный тест для проверки устойчивой скорости против кратковременных помех). Флаг odirect позволяет избежать использования буферного кеша, поэтому результаты теста должны быть повторяемыми.
Тест чтения: dd if = / dev / zero of = / dev / bs = 1M count = 1024 oflag = direct Тест записи: dd if = / dev / of = / dev / null bs = 1M count = 1024 iflag = direct
Пример вывода для dd с блоками 512x1M: 536870912 байт (537 МБ) скопировано, 10,1154 с, 53,1 МБ / с
Тест WRITE РАЗРУШИТЕЛЬНЫЙ !!!!!! Это нужно делать ПЕРЕД СОЗДАНИЕМ ФАЙЛЕСИСТЕМЫ НА УСТРОЙСТВЕ !!!! На необработанных устройствах помните, что таблица разделов будет стерта. В этом случае вы должны заставить ядро перечитать таблицу разделов, чтобы избежать проблем (с fdisk). Однако производительность на всем устройстве и в одном разделе должна быть одинаковой.
б) Для файловой системы просто измените устройство на имя файла в точке монтирования. Тест чтения: dd if = / dev / zero of = / mount-point / test.dat bs = 1M count = 1024 oflag = прямой тест записи: dd if = / mount-point / test.dat of = / dev / null bs = 1M count = 1024 iflag = direct
Обратите внимание, что даже при доступе к файлу мы не используем буферный кеш.
c) Для сети просто протестируйте необработанные сокеты TCP в обоих направлениях между серверами. Остерегайтесь брандмауэра, блокирующего TCP-порт 5001.
server1 # dd if = / dev / zero bs = 1M count = 1024 | netcat 5001 server2 # netcat -l -p 5001 | дд из = / dev / null
ТЕСТОВЫЕ СЛОИ Теперь у вас есть инструмент для проверки производительности диска для каждого уровня. Просто следуйте этой последовательности:
a) Проверьте производительность локального диска на серверах iSCSI. б) Протестируйте производительность TCP сети между целями iSCSI и инициаторами. c) Протестируйте производительность диска на iSCSI LUN на инициаторе iSCSI (это окончательная необработанная производительность протокола iSCSI). г) Проверить производительность логического тома LVM. д) Проверить производительность на больших файлах поверх файловой системы.
Между слоем, ответственным за потерю, и следующим слоем должен быть большой разрыв в производительности. Но я не думаю, что это LVM. Я подозреваю слой файловой системы.
Теперь несколько советов по возможным проблемам:
a) Вы не описали, определили ли вы разделенный том LVM на iSCSI LUN. Удаление может создать узкое место, если для целей iSCSI использовалась синхронная запись (см. Проблему со временем ниже). Помните, что поведение цели iSCSI по умолчанию - синхронная запись (без кэширования ОЗУ). б) Вы не описали тип схемы доступа к вашим файлам: -Долгая последовательная передача больших объемов данных (100 МБ)? -Последовательности случайных обращений к малым блокам? -Много маленьких файлов?
Возможно, я ошибаюсь, но подозреваю, что ваша система может страдать от последствий проблемы с ATIME. Проблема «временного» является следствием «оригинальных представлений о конструкции ядра Linux», от которых мы страдаем в последние годы из-за людей, желающих участвовать в разработке ОС, которая не знакома с производительностью и последствиями проектных решений.
В двух словах. В течение почти 40 лет UNIX обновляла «время последнего доступа» к индексу каждый раз, когда над его файлом выполняется одна операция чтения / записи. Буферный кеш содержит обновления данных, которые некоторое время не передаются на диск. Однако в дизайне Linux каждое обновление ATIME inode должно обновляться СИНХРОННО И НЕМЕДЛЕННО на диск. Просто осознайте значение чередующейся синхронизации. передает в потоке операций поверх протокола iSCSI.
Чтобы проверить, применимо ли это, просто выполните этот тест: -Прочитайте длинный файл (не менее 30 секунд) без использования кеша. Конечно с дд !!! -В то же время контролируйте ввод / вывод с помощью «iostat -k 5».
Если вы наблюдаете небольшой, но непрерывный поток операций записи при чтении данных, это может быть обновление inode.
Решение: В Linux ситуация становится настолько странной, что в некоторые файловые системы (XFS, EXT3 и т.д.) добавлена опция монтирования, чтобы отключить обновление atime. Конечно, это отличает семантику файловых систем от стандартов POSIX. Некоторые приложения, отслеживающие время последнего доступа к файлам, могут выйти из строя (в основном программы чтения электронной почты и серверы, такие как Pine, Elm, Cyrus и т. Д.). Просто перемонтируйте вашу файловую систему с опциями «noatime, nodiratime». В последних дистрибутивах также есть "норматива", которая сокращает время устаревания inodes.
Напишите, пожалуйста, о результатах этих тестов и результатах вашего расследования.
Это зависит от назначения диска. Самый быстрый и простой способ - это "дд", как уже упоминалось, но я бы рекомендовал дополнительно iozone и Орион.
Тестирование диска:
$ dd if=/dev/zero of=/tmp/zero bs=1k count=100k
Сетевой тест:
$ yes | pv | ssh $host "cat > /dev/null"
В дополнение к другим, вы также можете использовать тестовую метку.