Метка «IOPS»

в 5:02, , рубрики: disk performance, fio, hdd, IOPS, linux, performance tests, ssd, дисковая подсистема, Серверная оптимизация, системное администрирование, метки: , , , , , , ,

Навеяно постом уважаемого amarao о том, как надо измерять производительность дисков.

Цель:

Протестировать производительность имеющихся в наличии средств хранения информации и убедиться в верности выбранной методики, а также понять разницу в производительности между разными видами накопителей, а также enterprise-level и consumer-level жёсткими дисками.

Оборудование:

  1. SD-карта Sandisk Class 10 UHS 1 Extreme Pro 8 GB (до 95 Мбайт/с чтение, до 90 Мбайт/с запись)
  2. SD-карта Team Class 10 32 GB (до 20 Мбайт/с)
  3. SD-карта Transcend 2GB без класса скорости
  4. SATA-диск consumer-level Hitachi Deskstar HDS723020BLA642 2 ТБ 7200 об/мин, 64 Мбайт
  5. SATA-диск enterprise-level Western Digital RE3 WD2502ABYS-23B7A0 250 GB 7200 об/мин 16 Мбайт
  6. SATA-диск consumer-level Seagate Barracuda 7200.11 ST3320613AS 320 GB 7200 об/мин 16 Mбайт
  7. CD-ROM
  8. RAM-диск /dev/ram в Linux

Методика тестирования:

Методика полностью описана в посте. Есть правда несколько не совсем понятных моментов:

Мы подбираем такую глубину параллельности операций, чтобы latency оставалось в разумных пределах.

Задача подобрать такой iodepth, чтобы avg.latency была меньше 10мс.

Так как в тестировании используется не СХД и не диски SAS, а различные накопители SATA, то параллельность нам измерять нету смысла.
Очищать диск перед каждым тестированием (dd if=/dev/zero of=/dev/sdz bs=2M oflag=direct) очень времязатратно, поэтому будет это делать перед тестированием один раз на каждый накопитель.
Тестировать весь диск полностью очень времязатратно, поэтому будем использовать тестирование в течении 30 секунд.
Итак, сформулируем методику тестирования для нашего случая:
Получить значение IOPS, выдаваемое накопителем при произвольном чтении и записи блоками по 4 Кбайт и задержке avg.latency не более 10 мс за время теста в 30 секунд. Также для полноты картины измерим скорость линейной записи.Читать полностью »

в 14:10, , рубрики: amazon, ebs, IOPS, Блог компании 1С-Битрикс, Веб-разработка, системное администрирование, метки: , , ,

В последнее время в облачных средах и хостингах все чаще стали попадаться «виртуальные» жесткие диски. Техническая служба хостера может заверять, что «виртуальный» диск — быстрый, как десяток рейдов 10 (рейд 100 ;-) ) и держит сотни, а то и тысячи IOPS – однако MySQL заметно для клиентов тормозит. А как это доказать хостеру?

Проблема в том, что измерить «скорость» виртуального жесткого диска изнутри виртуальной машины – непросто, т.к. неясно, что мерить в первую очередь, чем и зачем ;-) А сделать это нужно, чтобы убедить администраторов виртуальной конфигурации, что дело не в приложении и настройках MySQL. И нужно было, как говориться, просто «помыть руки» перед чтением мануала к хранилищу.

В статье я проиллюстрирую простую методику нахождения «точки опрокидывания» производительности виртуального жесткого диска, с использованием доступных в дистрибутивах инструментов – sysbench и iostat. Также мы измерим «точку опрокидывания» известных своей тормознутостью виртуальных дисков EBS от Амазона – как обычных EBS, так и Provisioned IOPS EBS (1000 и 2000 IOPS).
Читать полностью »

в 4:35, , рубрики: IOPS, raid, ит-инфраструктура, метки: ,

iopsIOPS (количество операций ввода/вывода – от англ. Input/Output Operations Per Second) – один из ключевых параметров при измерении производительности систем хранения данных, жестких дисков (НЖМД), твердотельных диски (SSD) и сетевых хранилища данных (SAN).

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

Значит, для определения IOPS надо знать скорость и размер блока при операции чтения / записи. Параметр IOPS равен скорости, деленной на размер блока при выполнении операции.
Читать полностью »

в 9:56, , рубрики: Amazon Web Services, AWS, ebs, IOPS, Блог компании EPAM Systems Ukraine, метки: , ,

Доброго времени суток!
AWS: Больше IOPS для EBSAWS: Больше IOPS для EBS

Сегодня стала известна ещё одна хорошая новость от Amazon Web Services: теперь каждый EBS-диск обеспечивает производительность в 2000 IOPS (это в два раза больше предыдущего лимита в 1000 IOPS).

AWS: Больше IOPS для EBS

Если производительности диска в 2000 IOPS Вам мало, то EBS-диски можно объединить в RAID-массив, получив тем самым необходимое количество операций ввода/вывода.

Читать полностью »

в 13:06, , рубрики: Amazon Web Services, AWS, cloudformation, ebs, IOPS, RDS, Блог компании EPAM Systems Ukraine, метки: , , , ,

Привет читатели! image

С сегодняшнего дня в описании шаблонов AWS CloudFormation появились параметры, позволяющие настраивать как последние новшества от Amazon, так и уже очень древние фичи, которые сообщество просило включить очень давно.

Параметр-группы RDS.

Все RDS серверы можно поднять со стандартными настройками. Но рут доступа к серверам нет, поэтому невозможно, например, включить возможность хранения процедур в RDS MySQL. Для этого и существуют параметр-группы, которые могут быть созданы и настроены через API или CLI.
Читать полностью »

в 10:10, , рубрики: disk performance, fio, hdd, IOPS, linux, NAS, performance tests, SAN, ssd, дисковая подсистема, Серверная оптимизация, системное администрирование, СХД, метки: , , , , , , , , , ,

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

  • научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
  • использование bonnie++
  • использование iozone
  • использование пачки cp с измерениема времени выполнения
  • использование iometer с dynamo на 64-битных системах

Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.

Читать полностью »

в 9:26, , рубрики: IOPS, raid, vdi, windows, Блог компании HP, виртуализация, виртуальная машина, индексация, оптимизация, сервер, Серверная оптимизация, система хранения данных, метки: , , , , , , , , ,

Это продолжение серии из двух постов, в которых я рассказываю о построении VDI-решения для крупной российской софтверной компании.

Немного математики

Опираясь на описанную в предыдущем посте теорию, проведем расчеты:

Одновременно от 6 до 9 пользователей VDI могут использовать одно физическое ядро CPU. Для упрощения возьмем среднюю цифру — 7 пользователей.

Согласно требованиям заказчика необходимо обеспечить работу 700 пользователей по VDI с расширением до 1000.
Читать полностью »

в 8:51, , рубрики: IOPS, raid, vdi, windows, Блог компании HP, виртуализация, виртуальная машина, индексация, оптимизация, сервер, Серверная оптимизация, система хранения данных, метки: , , , , , , , , ,

Представляю вам серию из двух постов, где я постараюсь рассказать о разработке довольно типового решения VDI для предприятия среднего размера. В первой части – подготовка к внедрению, планирование; во второй – реальные практически примеры.

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

Например, у одного из заказчиков, крупной отечественной софтверной компании, имеется довольно большой парк серверов и систем хранения. В том числе — несколько серверов HP ProLiant 6-го и 7-го поколения и система хранения HP EVA, которые были в резерве. Именно на их базе нужно было разработать решение.
Озвученными требованиями к решению VDI были:

  • Floating Desktops Pool (с сохранением изменений после окончания сессии);
  • Начальная конфигурация — 700 пользователей, с расширением до 1000.

Мне предстояло просчитать какое количество серверов и систем хранения в итоге перейдут из резерва в состав решения.
В качестве среды виртуализации выбрана VMware. Схема работы получилась примерно такая:
Читать полностью »

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js