Использование блока диска размером 8к по сравнению с блоком размером 4к более выгодно поскольку

Содержание
  1. Разрешение 4K «забуксовало» или 6 причин, по которым Full HD монитора вам хватит еще надолго
  2. реклама
  3. реклама
  4. реклама
  5. Full HD достаточно для многих и пользователи не видят разницы с 4K
  6. реклама
  7. Массовые видеокарты не могут осилить 4K в играх уже много лет
  8. 4K контента мало даже в 2021 году
  9. Вес 4K контента очень тяжел для современных накопителей
  10. Высокогерцовые Full HD мониторы
  11. Дешевизна Full HD мониторов
  12. Выводы
  13. Производительность дисковых систем серверов HP ProLiant DL360 от Gen5 до Gen8. Всё, что вы не знали и боялись спросить
  14. Влияние аппаратного кэша
  15. Операции последовательного доступа
  16. Операции случайного доступа
  17. Операции комбинированного доступа
  18. Разница между 3Gbps и 6Gbps дисками
  19. Операции последовательного доступа
  20. Операции случайного доступа
  21. Операции комбинированного доступа
  22. Разница между поколениями серверов
  23. Операции последовательного доступа
  24. Операции случайного доступа
  25. Операции комбинированного доступа
  26. Последовательный доступ.
  27. SQL Server Log: размер блока 64KB, 0%/100% чтение/запись, 100% последовательный доступ
  28. Web Server Log: размер блока 8KB, 0%/100% чтение/запись, 100% последовательный доступ
  29. Media Streaming: размер блока 64KB, 98%/2% чтение/запись, 100% последовательный доступ
  30. Случайный доступ. Базы данных OLTP и Exchange.
  31. OLTP DB: размер блока 8KB, 70%/30% чтение/запись, 100% случайный доступ
  32. Decision Support System DB: размер блока 1MB, 100% Read, 100% случайный доступ
  33. Exchange Server: размер блока 4KB, 67%/33% чтение/запись, 100% случайный доступ
  34. Video On Demand: размер блока 512KB, 100%/0% чтение/запись, 100% случайный доступ
  35. Комбинированный доступ.
  36. Workstation: размер блока 8KB, 80%/20% чтение/запись, 80%/20% случайный доступ/последовательный доступ
  37. Web File Server64k: размер блока 64KB, 95%/5% чтение/запись, 75%/25% случайный доступ/последовательный доступ
  38. Web File Server8k: размер блока 8KB, 95%/5% чтение/запись, 75%/25% случайный доступ/последовательный доступ
  39. Web File Server4k: размер блока 4KB, 95%/5% чтение/запись, 75%/25% случайный доступ/последовательный доступ
  40. Подведение итогов
  41. Какие факторы влияют на производительность систем хранения и как?
  42. Основы производительности накопителей
  43. При расчете производительности жесткого диска можно пренебречь снижением количества IOPS при увеличении размера блока, почему?
  44. Оптимальный размер блока (кластера)
  45. Почему стандарт 4 КБ?
  46. Уровень RAID
  47. Зависимость от приложений

Разрешение 4K «забуксовало» или 6 причин, по которым Full HD монитора вам хватит еще надолго

реклама

реклама

Широкоформатные ЖК-мониторы завоевали рынок буквально за пару-тройку лет, нарастив разрешение от популярного в 16:10 формате 1440×900 до Full HD или 1920×1080 в формате 16:9, датой рождения которого можно считать 2007 год.

реклама

Казалось бы, прогресс не остановить и разрешение 4K или 3840×2160, датой рождения которого можно считать 18 октября 2012 года, давно должно быть уже забыто и заменено на 8K или даже 12K (11520×6480). Но в реальности 4K забуксовало и большинство из нас до сих пользуются разрешением Full HD, которое присутствует на рынке уже 14(!) лет. Давайте разберемся в причинах этого парадокса.

Full HD достаточно для многих и пользователи не видят разницы с 4K

Если вы не из любителей сидеть впритык к монитору то, скорее всего, не особо замечаете разницу между Full HD и 4K разрешениями на массовых мониторах 21-23″ при одинаковых размерах элементов на экране. А если взять телевизоры распространенных диагоналей в районе 40-46 дюймов и сесть на расстоянии двух-трех метров, то разницу между Full HD и 4K картинкой заметит только человек с идеальным зрением.

реклама

Это подтверждают и многочисленные исследования, в которых зрители попросту не видят разницу между Full HD и 4K даже на гораздо больших размерах изображения, выдаваемых кинопроектором. Причина в том, что разрешения подошли вплотную к разрешающей способности человеческого глаза и он попросту не в состоянии заметить разницу на адекватном расстоянии просмотра.

Массовые видеокарты не могут осилить 4K в играх уже много лет

GeForce RTX 3060Ti тоже не смогла в 4K

С трассировкой лучей ситуация еще плачевнее и GeForce RTX 3080 и GeForce RTX 3090 способны обеспечить средний FPS выше 60 только в Full HD. 4K-гейминг опять оказался чем-то заманчивым, маячащим на горизонте, но недостижимым, и в этот раз его еще сильнее отодвинет ресурсоемкий рейтрейсинг в играх. И такова ситуация на топовых видеокартах, покупателей которых единицы процентов, а на массовых xx60 видеокартах можно даже не задумываться о 4K в новых ААА-играх.

4K контента мало даже в 2021 году

Вес 4K контента очень тяжел для современных накопителей

Лига справедливости Зака Снайдера идет 4 часа и страшно представить, сколько будет весить в 4K

А жесткие диски сегодня стоят немало, например, популярный WD Purple (WD40PURZ), предназначенный под системы видеонаблюдения, но активно покупающийся в обычные ПК из-за использования традиционной записи CMR, стоит почти 10000 рублей. Нетрудно посчитать, что на такой диск уместится всего около 70 фильмов в 4K со средним размером в 50 ГБ.

А WD Purple с объемом 6 ТБ стоит уже 15000 рублей, что для многих пользователей является уже довольно серьезной суммой, которую они скорее потратят на увеличение производительности ПК или качественную периферию.

Высокогерцовые Full HD мониторы

Массовое распространение высокогерцовых Full HD мониторов легко утилизирует мощности видеокарт, которые могли бы направляться на работу в высоких разрешениях. Для многих покупателей выбор в играх между 4K картинкой с 60 FPS и Full HD с 144 FPS явно склоняется в пользу более плавной картинки с высокой частотой кадров.

Дешевизна Full HD мониторов

Если на рынке телевизоров купить современную модель без поддержки 4K разрешения уже довольно затруднительно, то рынок мониторов предлагает огромное количество качественных бюджетных мониторов Full HD. Например, популярный монитор ASUS VA24EHE, с оптимальной для Full HD диагональю 23.8″, и 75 Гц IPS матрицей стоит всего 9510 рублей.

Выводы

Подводя итоги, может показаться, что я ретроград и негативно отношусь к мониторам с высоким разрешением, но это не так. Я бы с радостью играл сейчас на большом экране с разрешением 8К, но увы, прогресс в эти последние 10 лет топтался на месте. Конечно, в мониторы внедряются новые технологии, но они больше похожи на потуги маркетологов, пытающихся заставить вас купить новый монитор взамен ваших 22-24″ LG или Samsung, которые все не хотят ломаться.

Вспомните, всего несколько лет назад каждый уважающий себя монитор или телевизор имел поддержку 3D, а где эта технология сейчас? Скорее всего, такая же участь постигнет и моду на гнутые мониторы, так называемые Curved. Не особо пользуются спросом и UltraWide мониторы, ведь особенность наших глаз не позволяет воспринимать информацию на периферии зрения и даже на обычном 27″ 16:9 мониторе глаза просто «разбегаются».

А вот компромиссное решение, в виде мониторов 2560×1440 или QHD, с классическим соотношением сторон 16:9 набирает популярность. Причина в довольно высокой плотности пикселов, но такой, какую нормально переваривают в играх видеокарты уровня GeForce RTX 2070 SUPER. Да и цена на такие мониторы довольно демократичная, например Philips 245E1S с диагональю 24″, и IPS матрицей 75 Гц стоит 15470 рублей.

Ну а если у вас, как и у меня, уже много лет трудится старый монитор Full HD и не собирается ломаться, то может стоит подождать еще пару-тройку лет, дав гонке технологий сделать еще один рывок?

Пишите в комментарии, какой монитор стоит у вас? И как вы относитесь к новшествам на рынке мониторов?

Цены в блоге актуальны на 21.03.2021

Источник

Производительность дисковых систем серверов HP ProLiant DL360 от Gen5 до Gen8. Всё, что вы не знали и боялись спросить

Мы постоянно сталкиваемся с типовой задачей о развёртывании офисного сервера для различных компаний. Чаще всего клиент хочет купить сервер, на котором будут работать офисная почта, например, postfix+*SQL, ejabberd с тем же *SQL, samba, а также *SQL под 1С. В этом случае возникает необходимость изучения производительности дисковых массивов применительно к серверам «рабочей группы» одной и той же модели, но различных поколений. Поскольку наша компания в большей степени специализируется на продукции Hewlett-Packard, анализу подверглись 1U серверы HP ProLiant 360 5-го, 6-го, 7-го и 8-го поколений:

Во всех конфигурациях контроллера используем кэш размером 256Mb. Стоит отметить отличие в пропускной способности PCI Express шины, посредством которой подключены контроллеры: P400i и P410i — 2GBps (гигабайта в секунду), P420 — 8 GBps (гигабайт в секунду).

Первый вопрос, который логично возникает в этом случае: в каких попугаях измерять производительность? Изучив статью уважаемого amarao, мы установили, что подобные измерения стоит проводить как минимум по двум параметрам: IOPS — количество дисковых Input/Output операций в секунду: чем их больше, тем лучше и Latency — время обработки операции: чем меньше, тем лучше.

Было решено произвести сравнение производительности различных конфигураций применительно к разным типовым задачам, поскольку эти задачи подразумевают различные варианты нагрузки на дисковую подсистему. Характер нагрузки определяется следующими параметрами: размер блока, соотношение операций чтение-запись, случайный/последовательный доступ.

Последовательный доступ к данным характерен для записи всевозможных логов, при трансляции и записи аудио/видео и тому подобного. Суть в том, что доступ характеризуется локализованной областью диска, без необходимости прыгать по всей поверхности.

Случайный доступ наиболее характерен для баз данных, веб и файловых серверов: большое количество запросов к разбросанным по диску секторам.

Комбинированный сочетает в себе оба выше описанных сценария, например функционирование БД с записью логов на тот же массив.

Тестируем непосредственно raw-device (прямой доступ, без оглядки на файловую систему), чтобы избежать влияния особенностей реализации файловых систем и всего, что с этим связано на разных платформах.
Под эту задачу были написаны правила для fio и IOMetter.

Очевидно, что для тестирования под Windows необходима установка данной ОС, а это, как минимум, еще один занятый порт и время, посвящённое установке на каждый сервер. Именно поэтому для работы мы выбрали Linux. Дело тут даже не в индивидуальных пристрастиях, а в наличии развитых средств автоматизации процесса «из коробки», позволяющих, к примеру, запустить тестирование сразу после загрузки ОС, а по окончанию тестов, отправить результаты по ssh, ftp или по email.

Было решено собрать небольшой Live-USB образ на базе Debian со всеми необходимыми утилитами. Желающие пересобрать его под свои потребности могут скачать архив. Для сборки потребуется Debian (скорее всего, подойдет и Ubuntu), multistrap, isolinux, squashfs-tools и xorriso. Внеся изменения и доустановив из chroot’a нужные пакеты, выполните скрипт build.sh.

Тем не менее, в одном из случаев мы провели тестирование и под Windows с использованием IOMetter для сравнения полученных результатов с fio.

image loader
image loader

Таким образом удалось изучить производительность различных массивов на наших серверах по 12 типовым профилям нагрузки, выраженным в 3-х группах, сформированных по типу доступа.

Влияние аппаратного кэша

Как известно, кэш представляет собой промежуточный буфер быстрого доступа к информации, запрашиваемый с наибольшей вероятностью. В итоге доступ к данным осуществляется оперативнее, минуя выборку данных из удаленного источника.

Рассмотрим влияние наличия платы аппаратного кэша на примере конфигурации raid10, построенной на четырех 6Gbps дисках.

Операции последовательного доступа

Media Streaming: размер блока 64KB, 98%/2% чтение/запись, 100% последовательный доступ

image loader
image loader

Операции случайного доступа

OLTP DB: размер блока 8KB, 70%/30% чтение/запись, 100% случайный доступ

image loader
image loader

Операции комбинированного доступа

Workstation: размер блока 8KB, 80%/20% чтение/запись, 80%/20% случайный доступ/последовательный доступ

image loader
image loader

Как видно, при установленной плате кэша, производительность возрастает примерно до 40% на операциях как последовательного, так и случайного доступа. Также на гистограммах наглядно демонстрируется, что при включении кэша, колоссально (до нескольких порядков) сокращается время реакции (latency).

Стоит отметить, что использование кэша контроллером (P400i) сервера пятого поколения, мягко говоря, нерационально.

Контроллер сервера восьмого поколения наоборот, принудительно использует кэш, проигнорировав команду на отключение.

Разница между 3Gbps и 6Gbps дисками

Напомним, что параметр «Gbps» (гигабит в секунду) являет собой максимальную скорость передачи данных между диском и контроллером, то есть 3000Mbps и 6000Mbps. При надобности пересчитать в байты делим на 10: 300MBps и 600MBps соответственно. Теоретически, при количестве более шести 3G и более трех 6G дисков, бутылочным горлышком окажется скорость шины. Собственно, попробуем оценить ширину этого самого горлышка. Следует помнить, что жесткий диск является механической системой и указанная скорость передачи данных является предельной, то есть, по факту, в полной мере недостижимой. Напомним также, что контроллер P420i сервера восьмого поколения подключен через PCIe 3.0 (8GBps).

Сравнение проводим на raid10 с включенным кэшем.

Операции последовательного доступа

Media Streaming: размер блока 64KB, 98%/2% чтение/запись, 100% последовательный доступ

image loader
image loader

Операции случайного доступа

OLTP DB: размер блока 8KB, 70%/30% чтение/запись, 100% случайный доступ

image loader
image loader

Операции комбинированного доступа

Workstation: размер блока 8KB, 80%/20% чтение/запись, 80%/20% случайный доступ/последовательный доступ

image loader
image loader

При использовании на данной конфигурации 3Gbps и 6Gbps дисков с 10K оборотов, какой-либо принципиальной разницы нет как по параметру IOPS, так и по Latency. А вот рост производительности при использовании 6Gbps 15K весьма значителен и лучше всего заметен на операциях случайного доступа. Вывод: количество оборотов имеет значение.

К вопросу о PCIe 2.0 и 3.0: на примере конфигурации серверов Gen6, Gen7 и Gen8 с 6Gbps дисками, разница в IOPS составляет максимум 10%, по Latency и вовсе не больше 2%. Вывод: «бутылочное горлышко» PCIe 2.0 достаточно широко для конфигурации из четырех 6Gbps (600MBps) дисков.

Любопытно, что сервер седьмого поколения на конфигурации 3G 10Krpm дал худшую производительность, чем Gen 6 на этих же дисках. С чем это связано, в данном случае, сказать трудно и, возможно, будет выявлено при комплексном тестировании серверов.

Использование в сервере пятого поколения 6Gbps 15K дисков дало некоторый прирост в быстродействии, в основном за счет большего количества оборотов в секунду. Разницы между 6G и 3G десятитысячниками, ожидаемо, практически нет.

Разница между поколениями серверов

Операции последовательного доступа

Media Streaming: размер блока 64KB, 98%/2% чтение/запись, 100% последовательный доступ

image loader
image loader

Операции случайного доступа

OLTP DB: размер блока 8KB, 70%/30% чтение/запись, 100% случайный доступ

image loader
image loader

Операции комбинированного доступа

Workstation: размер блока 8KB, 80%/20% чтение/запись, 80%/20% случайный доступ/последовательный доступ

image loader
image loader

Как видно на графиках разница не существенная, особенно между серверами DL360Gen6, DL360Gen7 и DL360Gen8. В типовой нагрузке (профиль workstation) есть небольшая разница и с DL360Gen5. Старенький контроллер P400i в сервере DL360G5 сильно подкачал лишь на операциях последовательного доступа как по количеству IOPS, так и по времени реакции (latency), что не удивительно.

Желающие ознакомиться с детальными результатами тестирования (конфигурации raid5 и raid10 на трех, четырех и восьми дисках), могут скачать csv файл

Последовательный доступ.

SQL Server Log: размер блока 64KB, 0%/100% чтение/запись, 100% последовательный доступ

image loader
image loader

Web Server Log: размер блока 8KB, 0%/100% чтение/запись, 100% последовательный доступ

image loader
image loader

Media Streaming: размер блока 64KB, 98%/2% чтение/запись, 100% последовательный доступ

image loader
image loader

Случайный доступ. Базы данных OLTP и Exchange.

OLTP DB: размер блока 8KB, 70%/30% чтение/запись, 100% случайный доступ

image loader
image loader

Decision Support System DB: размер блока 1MB, 100% Read, 100% случайный доступ

image loader
image loader

Exchange Server: размер блока 4KB, 67%/33% чтение/запись, 100% случайный доступ

image loader
image loader

Video On Demand: размер блока 512KB, 100%/0% чтение/запись, 100% случайный доступ

image loader
image loader

Комбинированный доступ.

Workstation: размер блока 8KB, 80%/20% чтение/запись, 80%/20% случайный доступ/последовательный доступ

image loader
image loader

Web File Server64k: размер блока 64KB, 95%/5% чтение/запись, 75%/25% случайный доступ/последовательный доступ

image loader
image loader

Web File Server8k: размер блока 8KB, 95%/5% чтение/запись, 75%/25% случайный доступ/последовательный доступ

image loader
image loader

Web File Server4k: размер блока 4KB, 95%/5% чтение/запись, 75%/25% случайный доступ/последовательный доступ

image loader
image loader

Подведение итогов

Разница между G8 (P420i) и G6/G7 (с одинаковым контроллером P410i) составляет не более 10% на всех типах задач. Напрашивается вывод, что если исходить исключительно из соотношения «производительность дисковой системы/стоимость», G6 или G7 будут более выгодным приобретением. Комплексное сравнение производительности этих серверов мы проведем в одной из следующих статей.

Gen5 же несколько отстает: напомним, что его контроллер P400i обменивается данными с дисками на скорости 3Gbps. Видно, что на операциях случайного доступа отставание не так велико. С ростом количества операций последовательного доступа, разница растет. В принципе, компенсировать ее можно наращиванием числа дисков в массиве. Таким образом, этот сервер можно рекомендовать, как бюджетное решение для небольшой компании из 10-15 человек.

А теперь попробуем ответить на вопрос: а сколько же мне потребуется IOPS под такую-то задачу? Простой ответ: чем больше, тем лучше. С latency, соответственно, наоборот.

В первую очередь, стоит разобраться, какая именно нагрузка предвидится (что именно будет работать на сервере) и попробовать соотнести с приведенными выше результатами, имитирующими «потолок» для той или иной конфигурации.

Лучше всего — посмотреть какую нагрузку дают ваши приложения. В Linux это можно сделать с помощью программы iostat, входящей в состав пакета sysstat, которая показывает текущее состояние дисковой подсистемы.

image loader

r/s и w/s — IOPS на чтение и запись
r/await и w/await — соответственно latency.
util — уровень загруженности сервера. В наших тестах значение колеблется от 80% до 100%.

Если пиков нагрузки, принимающих значения близкие к нашим результатам будет много и параметр util длительное время колеблется в районе 80-100% — это хороший повод задуматься над оптимизацией дисковой системы.

Возвращаясь к вопросу о выборе конфигурации под потребности небольшой компании: файловый сервер, *SQL и завязанные на нем сервисы, мы бы рекомендовали рассматривать сервер не ниже Gen 6 с контроллером P410i с массивом уровня 10 (минимум 4 диска) из соображений сочетания быстродействия и надежности (raid10 имеет гораздо меньшее время перестроения массива в случае сбоя диска) на 6Gbps 15Krpm носителях. Отметим, что экономить на плате кэша крайне не рекомендуется.

Вообще, для нас результаты тестирования оказались неожиданными. Разница в производительности дисковых подсистем ожидалась гораздо большая, особенно в случае Gen8 с его PCIe 3.0 контроллером, в сравнении с серверами шестого и седьмого поколения. Маркетинг есть, а разницы почти нет — забавно.

Источник

Какие факторы влияют на производительность систем хранения и как?

Системы хранения данных для подавляющего большинства веб-проектов (и не только) играют ключевую роль. Ведь зачастую задача сводится не только к хранению определенного типа контента, но и к обеспечению его отдачи посетителям, а также обработки, что накладывает определенные требования к производительности.

В то время, как при производстве накопителей используется множество других метрик, чтоб описать и гарантировать должную производительность, на рынке систем хранения и дисковых накопителей, принято использовать IOPS, как сравнительную метрику, с целью «удобства» сравнения. Однако производительность систем хранения, измеряемая в IOPS (Input Output Operations per Second), операциях ввода / вывода (записи / чтения), подвержена влиянию большого множества факторов.

В этой статье я хотел бы рассмотреть эти факторы, чтобы сделать меру производительности, выраженную в IOPS, более понятной.

Начнем с того, что IOPS вовсе не IOPS и даже совсем не IOPS, так как существует множество переменных, которые определяют сколько IOPS мы получим в одних и других случаях. Также следует принять во внимание, что системы хранения используют функции чтения и записи и обеспечивают различное количество IOPS для этих функций в зависимости от архитектуры и типа приложения, в особенности в случаях, когда операции ввода / вывода происходят в одно и тоже время. Различные рабочие нагрузки предъявляют различные требования к операциям ввода / вывода (I/O). Таким образом, системы хранения, которые на первый взгляд должны были бы обеспечивать должную производительность, в действительности могут не справится с поставленной задачей.

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

Для того, чтоб приобрести полноценное понимание в вопросе, начнем с основ. IOPS, пропускная способность (MB/s или MiB/s) и время отклика в миллисекундах (мс) являются общепринятыми единицами измерения производительности накопителей и массивов из них.

IOPS обычно рассматривают в ключе измерения способности устройства хранения производить чтение / запись блоками размером 4-8КБ в случайном порядке. Что типично для задач онлайн-обработки транзакций, баз данных и для запуска различных приложений.

Понятие пропускной способности накопителя обычно же применимо при чтении / записи крупного файла, к примеру, блоками 64КБ и более, последовательно (в 1 поток, 1 файл).

Время отклика — время, которое необходимо накопителю для того, чтоб начать производить операцию записи / чтения.

Преобразование между IOPS и пропускной способностью может быть выполнено следующим образом:

IOPS = пропускная способность / размер блока;
Пропускная способность = IOPS * размер блока,

где размер блока — количество информации, переданное на протяжении одной операции ввода / вывода (I/O). Таким образом, зная такую характеристику жесткого диска (HDD SATA), как пропускную способность — мы с легкостью можем вычислить количество IOPS.

К примеру, возьмем стандартный размер блока — 4КБ и стандартную пропускную способность, заявленную производителем для последовательной записи или чтения (I/O) — 121 Мбайт / с. IOPS = 121 МБ / 4 КБ, в результате чего получим значение порядка 30 000 IOPS для нашего жесткого диска SATA. Если же размер блока увеличить и сделать равным 8 КБ, значение будет порядка 15 000 IOPS, то есть снизится практически пропорционально увеличению размера блока. Однако нужно четко понимать, что тут мы рассматривали IOPS в ключе последовательной записи или чтения.

Все меняется драматическим образом для традиционных жестких SATA дисков, если чтение и запись будут случайными. Тут начинает играть роль задержка (latency), которая очень критична в случае жестких дисков HDDs (Hard Disk Drives) SATA / SAS, а порой даже и в случае твердотельных накопителей SSD (Solid State Drive). Хотя последние зачастую обеспечивают производительность на порядки лучшую, чем у «вращающихся» накопителей, за счет отсутствия движущихся элементов, но все же могут возникать ощутимые задержки при записи, в виду особенностей технологии, и, как следствие, при использовании их в массивах. Глубокоуважаемый amarao провел довольно полезное исследование по использованию твердотельных накопителей в массивах, как выяснилось, производительность будет зависеть от latency самого медленного из дисков. Более подробно с результатами Вы можете ознакомиться в его статье: SSD + raid0 — не всё так просто.

Но вернемся к производительности отдельно взятых накопителей. Рассмотрим случай с «вращающимися» накопителями. Время, требуемое для выполнения одной случайной операции ввода / вывода будет определятся такими составляющими:

где T(A) — время доступа (access time или seek time), также известное, как время поиска, то есть время, требуемое для того, чтоб считывающая головка, была помещена на дорожку с нужным нам блоком информации. Зачастую в спецификации диска производителем указываются 3 параметра:

— время, требуемое, чтоб переместиться с самой дальней дорожке к самой ближней;
— время, требуемое для перемещения между смежными дорожками;
— среднее время доступа.

Таким образом мы приходим к волшебному выводу, что показатель T(A) может быть улучшен, если мы размещаем наши данные на как можно более близких дорожках, а все данные располагаются как можно дальше от центра пластины (требуется меньше времени для перемещения блока магнитных головок, а на внешних дорожках данных больше, так как больше длина дорожки и она вращается быстрее, нежели внутренняя). Теперь становится понятно почему дефрагментация может быть так полезна. Особенно с условием размещения данных на внешних дорожках в первую очередь.

T(L) — задержка, вызванная вращением диска, то есть время, требуемое для того, чтоб считать или записать конкретный сектор на нашей дорожке. Легко понять, что оно будет лежать в пределах от 0 до 1/RPS, где RPS — количество оборотов в секунду. К примеру при характеристике диска в 7200 RPM (оборотов в минуту) мы получим 7200/60 = 120 оборотов в секунду. То есть один оборот происходит за (1/120) * 1000 (количество миллисекунд в секунде) = 8,33 мс. Средняя же задержка в этом случае, будет равна половине времени, затрачиваемому на один оборот — 8,33/2 = 4,16 мс.

T(R/W) — время чтения или записи сектора, которое определяется размером выбранного при форматировании блока (от 512 байт и до… нескольких мегабайт, в случае с более емкими накопителями — от 4 килобайт, стандартный размер кластера) и пропускной способностью, которая указана в характеристиках накопителя.

Среднюю задержку вращения, которая приблизительно равна времени, затраченному на половину оборота, зная скорость вращения 7200, 10 000 или 15 000 RPM, легко определить. И выше мы уже показали как.

Остальные же параметры (среднее время поиска чтения и записи) определить сложнее, они определяются уже в результате тестов и указываются производителем.

Для расчета количества случайных IOPs жесткого диска возможно применить следующую формулу, при условии когда количество одновременных операций чтения и записи одинаково (50%/50%):

1/( ( (среднее время поиска чтения + среднее время поиска записи) / 2) / 1000) + (средняя задержка вращения / 1000)).

Многие интересуются, почему именно такое происхождение формулы? IOPS — количество операций ввода или вывода в секунду. Именно потому мы делим в числителе 1 секунду (1000 миллисекунд) на время с учетом всех задержек в знаменателе (выраженное также в секундах или миллисекундах), требуемое для осуществления одной операции ввода или вывода.

То есть формула может быть записана и таким образом:

1000 (мс) / ((среднее время поиска чтения (мс) + среднее время поиска записи (мс)) /2) + средняя задержка вращения (мс))

Для накопителей с различным количеством RPM (вращений в минуту), мы получим следующие значения:

Для 7200 RPM накопителя IOPS = 1/(((8,5+9,5)/2)/1000) + (4,16/1000)) = 1/((9/1000) +
(4,16/1000)) = 1000/13,16 = 75,98;
Для 10K RPM SAS накопителя IOPS = 1/(((3,8+4,4)/2)/1000) + (2,98/1000)) =
1/((4,10/1000) + (2,98/1000)) = 1000/7,08 = 141,24;
Для 15K RPM SAS накопителя IOPS = 1/(((3,48+3,9)/2)/1000) + (2,00/1000)) =
1/((3,65/1000) + (2/1000)) = 1000/5,65 = 176,99.

Таким образом мы видим драматические изменения, когда с десятков тысяч IOPS при последовательном чтении или записи, производительность падает до нескольких десятков IOPS.

И уже, при стандартном размере сектора в 4КБ, и наличию столь малого числа IOPS, мы получим значение пропускной способности отнюдь не в сотню мегабайт, а менее, чем в мегабайт.

Эти примеры также иллюстрируют причину незначительных изменений в номинальных дисковых IOPS от разных производителей для дисков с одним и тем же показателем RPM.

Теперь становится понятным, почему данные производительности, лежат в довольно широких диапазонах:

7200 RPM (Rotate per Minute) HDD SATA — 50-75 IOPS;
10K RPM HDD SAS — 110-140 IOPS;
15K RPM HDD SAS — 150-200 IOPS;
SSD (Solid State Drive) — десятки тысяч IOPS на чтение, сотни и тысячи на запись.

Однако номинальный дисковый IOPS остается все же далеко неточными, так как не учитывает различий в характере нагрузок в отдельно взятых случаях, что очень важно понимать.

Также, для лучшего понимания темы, рекомендую ознакомиться еще с одной полезной статьей от amarao: Как правильно мерять производительность диска, благодаря которой становиться также понятным, что latency вполне не фиксирована и также зависит от нагрузки и ее характера.

Единственное, хотелось бы добавить:

При расчете производительности жесткого диска можно пренебречь снижением количества IOPS при увеличении размера блока, почему?

Мы уже поняли, что для «вращающихся» накопителей, время, требуемое для случайного чтения или записи, складывается из следующих компонент:

И далее даже рассчитали производительность при случайном чтении и записи в IOPS. Вот только параметром T(R/W) мы там по сути пренебрегли, и это не случайно. Мы знаем, что допустим, последовательное чтение может быть обеспечено на скорости в 120 мегабайт в секунду. Становится понятным, что блок в 4КБ, будет считан за примерно 0,03 мс, время на два порядка меньшее, нежели время остальных задержек (8 мс + 4 мс).

Таким образом, если при размере блока в 4КБ мы имеем 76 IOPS (основная задержка была вызвана вращением накопителя и временем позиционирования головки, а не самим процессом чтения или записи), то при размере блока в 64КБ, падение IOPS будет не в 16 раз, как при последовательном чтении, а лишь на несколько IOPS. Так как время, затрачиваемое на непосредственно чтение или запись, возрастет на 0,45 мс, что составляет лишь порядка 4% от общего времени задержки.

В результате мы получим 76-4% = 72,96 IOPS, что согласитесь, совсем не критично при расчетах, так как падение IOPS не в 16 раз, а лишь на несколько процентов! И при расчетах производительности систем куда важнее не забыть учесть другие важные параметры.

Волшебный вывод: при расчете производительности систем хранения, основанных на жестких дисках, следует подбирать оптимальный размер блока (кластера), для обеспечения нужной нам максимальной пропускной способности в зависимости от типа данных и используемых приложений, причем падением IOPS при увеличении размера блока с 4КБ до 64КБ или даже 128КБ можно пренебречь, либо учитывать, как 4 и 7% соответсвенно, если в поставленной задаче они будут играть важную роль.

Также становится понятным, почему не всегда есть смысл использовать очень большие блоки. Скажем, при видеостриминге, двухмегабайтный размер блока может оказаться далеко не самым оптимальным вариантом. Так как падение количества IOPS будет более, чем в 2 раза. Помимо прочего добавятся другие деградационные процессы в массивах, связанные с многопоточностью и вычислительной нагрузкой при распределении данных по массиву.

Оптимальный размер блока (кластера)

Оптимальный размер блока нужно учитывать в зависимости от характера нагрузки и типа используемых приложений. Если идет работа с данными небольшого размера, к примеру с базами данных — следует выбрать стандартные 4 КБ, если же речь идет о стриминге видеофайлов — размер кластера лучше выбирать от 64 КБ и более.

Следует помнить, что размер блока не столь критичен для SSD, сколько для стандартных HDD, так как позволяет обеспечить нужную пропускную способность в виду небольшого количества случайных IOPS, количество которых снижается незначительно при увеличении размера блока, в отличии от SSD, где наблюдается практически пропорциональная зависимость.

Почему стандарт 4 КБ?

Для многих накопителей, в особенности твердотельных, значения производительности, к примеру записи, начиная с 4 КБ, становятся оптимальными, это видно из графика:

image loader

В то время, как на чтение, скорость также довольно существенна и более менее сносна начиная с 4 КБ:

image loader

Именно по этой причине 4 КБ размер блока очень часто применяют за стандартный, так как при меньшем размере идут большие потери производительности, а при увеличении размера блока, в случае работы с небольшими данными, данные будут распределены менее эффективно, занимать весь размер блока и квота накопителя будет использоваться не эффективно.

Уровень RAID

Если Ваша система хранения представляет собой массив накопителей объединенных в RAID определенного уровня, то производительность системы будет зависеть в значительной степени от того, какой именно уровень RAID был применен и какой процент от общего числа операций приходится на операции записи, ведь именно запись является причиной снижения производительности в большинстве случаев.

Так, при RAID0, на каждую операцию ввода будет расходоваться лишь 1 IOPS, ведь данные будут распределены по всем накопителям без дублирования. В случае же зеркала (RAID1, RAID10), каждая операция записи будет потреблять уже 2 IOPS, так как информация должна быть записана на 2 накопителя.

В более высоких уровнях RAID потери еще существеннее, к примеру в RAID5 штрафной коэффициент будет уже 4, что связано с тем, каким образом данные распределяются по дисках.

RAID5 используется вместо RAID4 в большинстве случаев, так как распределяет четность (контрольные суммы) по всем дискам. В массиве RAID4 один из дисков ответственен за всю четность, в то время как данные распространены более чем на 3 диска. Именно потому мы применяем штрафной коэффициент 4 в массиве RAID5, так как мы читаем данные, читаем четность, затем пишем данные и пишем четность.

В массиве RAID6 все аналогично, за исключением того, что мы вместо вычисления четности единожды, делаем это дважды и таким образом имеем 3 операции чтения и 3 записи, что дает нам уже штрафной коэффициент 6.

Казалось бы, что в таком массиве, как RAID-DP все будет аналогично, так как это по сути модифицированный массив RAID6. Но не тут то было… Хитрость заключается в том, что применяется отдельная файловая система WAFL (Write Anywhere File Layout), где все операции записи последовательны и производятся на свободное место. WAFL в основном напишет новые данные в новое местоположение на диске и затем переместит указатели на новые данные, устраняя таким образом операции чтения, которые должны иметь место. Кроме того идет запись журнала в NVRAM, который отслеживает транзакции записи, инициирует запись и может восстановить их при необходимости. Идет запись в буфер в начале, а затем они уже «сливаются» на диск, что ускоряет процесс. Вероятно эксперты в NetApp могут просветить нас более подробно в комментариях, за счет чего достигается экономия, я пока что еще не до конца разобрался в этом вопросе, но запомнил, что штрафной коэффициент RAID будет всего лишь 2, а не 6. «Хитрость» весьма существенна.

При больших массивах RAID-DP, которые состоят из десятков дисков, существует понятие уменьшения «штрафа четности», который возникает при записи четности. Так при росте массива RAID-DP, требуется меньшее количество дисков, выделяемых под четность, что приведет к снижению потерь, связанных с записями четностей. Однако в небольших массивах, либо с целью повышения консерватизма, мы можем пренебречь этим явлением.

Теперь, зная о потерях IOPS в результате применения того либо другого уровня RAID, мы можем рассчитать производительность массива. Однако, пожалуйста, примите к сведению, что другие факторы, такие как пропускная способность интерфейса, неоптимальное распределение прерываний по ядрах процессора и т.п., пропускная способность RAID-контроллера, превышение допустимой глубины очереди — могут оказывать негативное влияние.

В случае пренебрежения этими факторами, формула будет следующей:

Функциональные IOPS = (Исходные IOPS * % операций записи / штрафной коэффициент RAID) + (Исходные IOPS * % чтения), где Исходные IOPS = усредненный IOPS накопителей * количество накопителей.

Рассчитаем для примера производительность массива RAID10 из 12 дисков HDD SATA, если известно, что одновременно происходит 10% операций записи и 90% операций чтения. Допустим, что диск обеспечивает 75 случайных IOPS, при размере блока 4КБ.

Исходные IOPS = 75*12 = 900;
Функциональные IOPS = (900*0,1/2) + (900*0,9) = 855.

Таким образом видим, что при малой интенсивности записи, что в основном наблюдается в системах, рассчитанных на отдачу контента, влияние штрафного коэффициента RAID минимально.

В целях консерватизма я рекомендую добавлять от 20% от нужного числа IOPS, при проектировании систем.

Зависимость от приложений

Производительность нашего решения очень сильно может зависеть от приложений, которые будут исполнятся впоследствии. Так это может быть обработка транзакций — «структурированных» данных, которые организованы, последовательны и предсказуемы. Зачастую в этих процессах можно применить принцип пакетной обработки, распределив эти процессы во времени так, когда нагрузка минимальна, тем самым оптимизировав потребление IOPS. Однако в последнее время появляется все больше и больше медийных проектов, где данные «не структурированы» и требуют совсем иных принципов их обработки.

По этой причине подсчет необходимой производительности решения для конкретного проекта может стать весьма сложной задачей. Некоторые из производителей сторедж-хранилищ и экспертов утверждают, что IOPS не имеют значения, так как клиенты в подавляющем большинстве используют до 30-40 тысяч IOPS, в то время, как современные системы хранения обеспечивают сотни тысяч и даже миллионы IOPS. То есть современные хранилища удовлетворяют нужды 99% клиентов. Тем не менее это утверждение может быть справедливо далеко не всегда, лишь для бизнес-сегмента, который размещает хранилища у себя, локально, но не для проектов, размещаемых в дата-центрах, которые зачастую, даже при использовании готовых решений хранения, должны обеспечивать довольно высокую производительность и отказоустойчивость.

В случае размещения проекта в дата-центре, в большинстве случаев, все же более экономично строить системы хранения самостоятельно на основе выделенных серверов, нежели использовать готовые решения, так как становится возможным более эффективно распределить нагрузку и подобрать оптимальное оборудование для тех, либо других процессов. Помимо прочего, показатели производительности готовых систем хранения, далеки от реальных, так как в большинстве своем основаны на данных профилей синтетических тестов производительности, при применении 4 или 8 КБ размера блока, в то время как большинство клиентских приложений работает сейчас в средах с размером блока от 32 до 64 КБ.

Как видим из графика:

image loader

Менее, чем 5% систем хранения, настроены с применением блока менее 10 КБ и менее, чем 15% используют блоки с размером менее 20 КБ. Кроме того, даже для определенного приложения, редко когда возникает потребления I/O лишь одного типа. К примеру у базы данных будут различные профили I/O для различных процессов (файлы с данными, логирование, индексы …). А значит, заявленные синтетические тесты производительности систем, могут быть далекими от истины.

А что на счет задержек?

Даже если мы будем игнорировать тот факт, что инструменты, применяемые для измерения latency, имеют тенденцию измерять средние времена ожидания и упускают то, что один единственный I/O в каком-то из процессов, может занимать куда больше времени, чем другие, таким образом замедляя ход всего процесса, то совсем не учитывают то, насколько время ожидания I/O изменится в зависимости от размера блока. Помимо прочего это время также будет зависеть от конкретного приложения.

Таким образом мы приходим к еще одному волшебному выводу, что не только размер блока является не очень хорошей характеристикой при измерении производительности IOPS систем, но и latency может оказаться вполне бесполезным параметром.

Хорошо, если ни IOPS, ни время ожидания не являются хорошей мерой измерения производительности системы хранения, то что тогда?

Только реальный тест исполнения приложения на конкретном решении…

Этот тест будет тем реальным методом, который наверняка позволит понять, насколько производительным будет решение для Вашего случая. Для этого понадобится запустить копию приложения на отдельно взятом хранилище и симулировать нагрузку за определенный период. Только так можно получить достоверные данные. И разумеется, нужно измерять не метрики хранилища, а метрики приложения.

Тем не менее учет приведенных выше факторов, влияющих на производительность наших систем, может быть весьма полезным при подборе хранилища или построении определенной инфраструктуры на основе выделенных серверов. С определенной степенью консерватизма становится возможным подобрать более-менее реальное решение, исключить некоторые технические и программные изъяны в виде не оптимального размера блока при разбивке или не оптимальной работы с дисками. Решение, конечно, не будет на 100% гарантировать расчетную производительность, но в 99% случаев можно будет говорить, что решение справится с нагрузкой, особенно, если добавлять консерватизм в зависимости от типа приложения и его особенностей в расчет.

Источник

Adblock
detector