аннотация: разница между текущими показателями и теоретическими показателями; задержка и IOPS, концепция независимости от нагрузки на диск; подготовка тестирования; типичные параметры испытаний; практическое руководство по копипасту.
Внимание: много букв, долго читать.
Текст песни 
Очень распространенная проблема — попытка понять, «насколько быстр серверЭ» Среди всех тестов попытки оценить производительность дисковой подсистемы выглядят наиболее жалко.
Вот какие ужасы я видел в своей жизни:
- научная публикация, в которой скорость работы кластерной ФС оценивалась с помощью dd (и включенного файлового кэша, то есть без прямой опции)
- используя Бонни++
- использование иозона
- использование пакета cp с измерением времени выполнения
- использование iometer с динамо в 64-битных системах
Я расскажу о более тонких ошибках измерений позже, но все, что я могу сказать об этих тестах, — это выбросить их и не использовать.
bonnie++ и iozone измеряют скорость файловой системы.
Что зависит от кеша, продуманности ядра, удачного расположения ФС на диске и т.д. Косвенно можно сказать, что если в iozone получаются хорошие результаты, то это либо хороший кеш, либо дурацкий набор параметров , или действительно быстрый диск (угадайте, какой вариант вам достался).
bonnie++ обычно ориентирован на операции открытия/закрытия файлов.
те.
На самом деле он не проверяет производительность диска.
dd без опции Direct показывает только скорость кэша - не более того.
В некоторых конфигурациях без кэша можно получить более высокую скорость линии, чем с кэшем.
В некоторых вы получите сотни мегабайт в секунду с линейной производительностью в мегабайтах.
При использовании опции Direct (iflag=direct для чтения, oflag=direct для записи) dd проверяет только линейную скорость.
Что совершенно не равно ни максимальной скорости (если мы говорим о рейде на множество дисков, то рейд в несколько потоков может дать большую скорость, чем в один), ни реальной производительности.
IOmeter лучше всех вышеперечисленных, но у него проблемы с запуском в Linux. 64-битная версия неправильно рассчитывает тип нагрузки и показывает заниженные результаты (кто не верит, запустите на рамдиске).
Спойлер: правильная утилита для Linux — fio. Но это требует очень продуманной разработки теста и еще более вдумчивого анализа результатов.
Все что ниже — это лишь подготовка теории и практических заметок по работе с fio. Постановка задачи (текущая максимальная производительность по сравнению с максимальной производительностью) Теперь скучных букв будет еще больше.
Если кого-то интересует количество попугаев на его любимом SSD, диске ноутбука и т.п.
— рецепты смотрите в конце статьи.
Все современные носители, кроме виртуальных дисков, крайне негативно относятся к операциям случайной записи.
Для HDD нет разницы, пишет он или читает; важно то, что головки перемещаются по диску.
Для SSD операция случайного чтения — нонсенс, а запись небольшим блоком приводит к копированию при записи.
Минимальный размер записи 1-2 Мб, пишут 4кб.
Вам нужно прочитать 2МБ, заменить в них 4КБ и записать обратно.
В результате SSD принимает, например, 400 запросов в секунду на запись 4кб, которые превращаются в чтение 800 МБ/с (!!!!) и запись их обратно.
(Для рамдиска такая проблема тоже могла быть, но интрига в том, что размер «минимального блока» для DDR составляет около 128 байт, а блоки в тестах обычно 4кб, поэтому гранулярность DDR в тестах дисковой производительности ОЗУ равна не важно) .
Этот пост не о специфике разных медиа, поэтому вернемся к общей проблеме.
Мы не можем измерить запись в МБ/с.
Важно то, сколько было движений головы и сколько случайных блоков мы нарушили на SSD. Те.
Подсчет основан на объеме операций ввода-вывода, а значение ввода-вывода/с называется операций ввода-вывода в секунду .
Таким образом, когда мы измеряем случайную нагрузку, мы говорим о IOPS (иногда wIOPS, rIOPS, для записи и чтения соответственно).
В больших системах используется значение kIOPS, (внимание, всегда и везде, нет 1024) 1kIOPS = 1000 IOPS. И здесь многие попадают в ловушку первого типа.
Они хотят знать, «сколько IOPS» производит диск.
Или полка с дисками.
Или 200 серверных шкафов, доверху заполненных дисками.
Здесь важно различать количество выполненных операций (зафиксировано, что с 12:00:15 до 12:00:16 было выполнено 245 790 дисковых операций - т.е.
нагрузка составила 245kIOPS) и максимальное количество операций, которое может выполнить система.
выполнять.
Количество выполненных операций всегда известно и легко поддается измерению.
Но когда мы говорим о дисковой операции, мы говорим о ней в будущем времени.
«Сколько операций может выполнить системаЭ» - «Какие операцииЭ» Различные операции создают разную нагрузку на систему хранения.
Например, если кто-то пишет случайными блоками по 1 МБ, то он будет получать гораздо меньше iops, чем если бы он читал последовательно блоками по 4 КБ.
И если в случае входящей нагрузки мы говорим о том, сколько запросов было обслужено, «какие пришли, те и были обслужены», то в случае планирования мы хотим знать, какие iops там будут. Драма в том, что никто точно не знает, какие именно запросы поступят. Маленькие? Большие? Договор? В раздоре? Будут ли они читаться из кэша или придется идти в самое медленное место и выковыривать байты из разных половин диска? Я не буду развивать драму дальше, скажу только, что есть простой ответ:
- Тест диска (хранилища/массива) в лучшем случае (попадание в кэш, последовательные операции)
- Тест диска в худшем случае.
Чаще всего такие тесты планируются со знанием дискового устройства.
«Есть ли у него кэш 64 МБ? Что, если я сделаю область тестирования 2 ГБЭ» Жесткий диск читается быстрее снаружи? Что, если я помещу тестовую область на внутреннюю (ближайшую к шпинделю) область, чтобы путь, пройденный головками, был больше? Есть ли у него прогноз на будущее? А если прочитать в обратном порядке? И т. д.
Например: 15 000 IOPS и 150 IOPS. Какова будет фактическая производительность системы? Это определяется только тем, насколько близка нагрузка к хорошему и плохому концу.
(То есть банальное «жизнь покажет»).
Чаще всего ориентируются на следующие показатели:
- Что лучший случай все равно остается лучшим.
Потому что вы можете оптимизироваться до такой степени, что лучший вариант почти не будет отличаться от худшего.
Это плохо (или у нас такое офигенное худшее).
- В худшем случае.
Имея его, можно сказать, что СХД будет работать быстрее полученного показателя.
Те.
если мы получили 3000 IOPS, то можем смело использовать систему/диск с нагрузкой до 2000.
Традиционно тест проходит с размером блока 4 КБ.
Почему? Потому что это стандартный размер блока, который использует ОС при сохранении файла.
Это размер страницы памяти и вообще Очень Круглое Число Компьютера.
Нужно понимать, что если с блоком 4к система обрабатывает 100 IOPS (худшее), то с блоком 8k она будет обрабатывать меньше (минимум 50 IOPS, скорее всего около 70-80).
Ну а на блоке размером 1 МБ мы увидим совсем другие цифры.
Все? Нет, это было только вступление.
Все, что написано выше, более или менее общеизвестно.
Нетривиальные вещи начинаются ниже.
Сначала мы рассмотрим концепцию «зависимого IOPS».
Представим, что наше приложение работает следующим образом:
- прочитать запись
- изменить запись
- записать запись обратно
Если обработка каждого запроса на чтение и запись занимает 1 мс, сколько записей в секунду может обработать приложение? Правильно, 500. А что если рядом с ним запустить вторую копию приложения? В любой приличной системе мы получим 1000. Если мы получим значительно меньше 1000, мы достигли предела производительности системы.
Если нет, то это означает, что производительность приложения с зависимым IOPS ограничена не производительностью СХД, а двумя параметрами: задержкой и уровнем зависимости IOPS. Начнем с задержки.
Задержка — время выполнения запроса, задержка перед ответом.
Обычно используемым значением является «средняя задержка».
Более продвинутые используют медиана среди всех операций за определенный интервал (чаще всего за 1 с).
Задержку очень сложно измерить.
Это связано с тем, что на любой системе хранения некоторые запросы выполняются быстро, некоторые — медленно, а некоторые могут попасть в крайне неприятную ситуацию и обслуживаться в десятки раз дольше, чем другие.
Интригу усиливает наличие очереди запросов, внутри которой запросы могут переупорядочиваться и выполняться параллельно.
Типичный диск SATA имеет глубину очереди (NCQ) 31; в мощных системах хранения данных оно может достигать нескольких тысяч.
(обратите внимание, что фактическая длина очереди (количество ожидающих запросов) является достаточно отрицательным параметром; если в очереди много заявок, то они ждут дольше, т.е.
замедляются.
Любой человек, стоявший в супермаркете во время в час пик согласитесь, что чем длиннее очередь, тем хуже обслуживание.
Задержка напрямую влияет на производительность последовательного приложения, пример которого приведен выше.
Более высокая задержка означает более низкую производительность.
При 5мс максимальное количество запросов - 200 шт/с, при 20мс - 50. При этом если у нас 100 запросов обрабатываются за 1мс, а 9 запросов за 100мс, то в секунду мы получим всего 109 IOPS, при медиане 1мс.
и avg (среднее) при 10 мс.
Это приводит к довольно сложному для понимания выводу: тип рабочей нагрузки влияет на производительность не только тем, является ли она «последовательной» или «случайной», но и тем, как устроены приложения, использующие диск.
Пример: запуск приложения (типичная задача рабочего стола) практически на 100% последователен.
Читаем приложение, читаем список необходимых библиотек, читаем каждую библиотеку по очереди.
Вот почему так горячо любят SSD на десктопах - у них микроскопическая задержка (микросекунда) на чтение - конечно же любимый фотошоп или блендер начинается через десятые доли секунды.
Но, например, работа загруженного веб-сервера практически параллельна — каждый последующий клиент обслуживается независимо от соседнего, т.е.
задержка влияет только на время обслуживания каждого клиента, но не на «максимальное количество клиентов».
И, допустим, для веб-сервера 1 мс или 10 мс — одно и то же.
(Но не имеет значения, сколько параллельных запросов по 10 мс можно отправить).
Избиение .
Я думаю, что пользователи настольных компьютеров знакомы с этим явлением даже лучше, чем системные администраторы.
Жуткий хруст жесткого диска, неописуемые тормоза, «ничего не работает и все тормозит».
Когда мы начинаем заполнять дисковую очередь (или хранилище, повторюсь, в контексте статьи разницы между ними нет), наша латентность начинает резко увеличиваться.
Диск работает на максимальной мощности, но входящих запросов больше, чем скорость их обслуживания.
Задержка начинает стремительно расти, достигая ужасающих цифр в несколько секунд (и это при том, что приложению, например, для завершения своей работы необходимо совершить 100 операций, что при задержке в 5 мс означало полсекунды).
задерживать.
).
Это состояние называется подергиванием.
Вы будете удивлены, но любой диск или хранилище способны показывать БОЛЬШЕ IOPS в состоянии перегрузки, чем при нормальной нагрузке.
Причина проста: если в обычном режиме очередь чаще всего пуста и кассиру скучно ждать клиентов, то в мусорном состоянии происходит постоянное обслуживание.
(Кстати, вот объяснение, почему в супермаркетах любят очереди – в этом случае производительность кассиров максимальна).
Правда, клиентам это очень не нравится.
А в хороших супермаркетах складские помещения стараются избегать такого режима.
Если продолжать увеличивать глубину очереди, то производительность начнет падать из-за того, что очередь переполнена и запросы выстраиваются в очередь, чтобы попасть в очередь (да-да, и серийный номер с шариковой ручкой на твоя рука).
И здесь мы сталкиваемся со следующей распространенной (и очень трудно опровергаемой) ошибкой тех, кто измеряет производительность дисков.
Мониторинг задержки во время теста Говорят «мой диск выдает 180 IOPS, значит, если взять 10 дисков, то будет целых 1800 IOPS».
(Именно так думают плохие супермаркеты, нанимающие меньше кассиров, чем необходимо).
При этом латентность оказывается запредельной — и «так жить нельзя».
Реальный тест производительности требует контроля задержки, то есть подбора таких параметров тестирования, чтобы задержка оставалась ниже согласованного предела.
И здесь мы сталкиваемся со второй проблемой: каков предел? Теория не может ответить на этот вопрос – этот показатель является индикатором качество обслуживания .
Другими словами, каждый выбирает для себя.
Лично я для себя провожу тесты, чтобы задержка оставалась не более 10мс.
Для себя я считаю этот показатель потолком производительности хранилища.
(при этом мысленно для себя считаю, что предельный показатель после которого начинают ощущаться лаги - это 20мс, но помните про пример выше от 900 до 1мс и от 10 до 100мс, для которых avg стало 10мс? Это почему я оставляю +10мс для случайных всплесков).
Параллелизм Выше мы уже рассматривали вопрос зависимого и независимого IOPS. Производительность зависимых Iops точно контролируется задержкой, и мы уже обсуждали этот вопрос.
А вот производительность в независимых iops (т.е.
при параллельной нагрузке) от чего зависит? Ответ исходит из воображения человека, который изобрел диск или спроектировал хранилище.
Можно говорить о количестве головок, шпинделей и очередей параллельной записи в SSD, но все это предположения.
С точки зрения практического использования нас интересует один вопрос: СКОЛЬКО? Сколько потоков параллельной загрузки мы можем запустить? (Не забываем про латентность, ведь если мы позволим латентности отправляться в рай, то туда уйдет количество параллельных потоков, хоть и не с одинаковой скоростью).
Итак, вопрос: сколько параллельных потоков мы можем запустить с задержкой ниже заданного порога? Именно на этот вопрос должны ответить тесты.
САН и NAS Отдельно нужно поговорить о ситуации, когда хранилище подключено к хосту по сети по протоколу TCP. Про TCP нужно писать, писать, писать и еще раз писать.
Достаточно сказать, что в Linux существует 12 различных алгоритмов контроля перегрузки сети, которые рассчитаны на разные ситуации.
А параметров ядра около 20, каждый из которых может кардинально повлиять на вывод попугаев (извините, на результаты тестов).
С точки зрения оценки производительности следует просто принять такое правило: для сетевого хранилища тест должен проводиться с нескольких хостов (серверов) параллельно.
Тесты с одного сервера не будут тестом хранилища, а будут комплексным тестом сети, хранилища и правильности настройки самого сервера.
насыщение шины Последний вопрос – это вопрос затенения шин.
О чем мы говорим? Если наш SSD способен выдавать 400 МБ/с, и мы подключаем его через SATA/300, то очевидно, что всей производительности мы не увидим.
Причем с точки зрения задержки проблема начнет проявляться задолго до приближения к 300МБ/с, ведь каждому запросу (и ответу на него) придется ждать своей очереди, чтобы проскочить узкое место кабеля SATA. Но бывают ситуации и смешнее.
Например, если у вас есть полка дисков, подключенных по SAS/300x4 (т.е.
4 линии SAS по 300 МБ каждая).
Кажется, это очень много.
Что делать, если на полке 24 диска? 24*100=2400 МБ/с, а у нас всего 1200 (300х4).
Более того, тесты на некоторых (серверных!) материнских платах показали, что встроенные SATA-контроллеры зачастую подключаются через PCIx4, что не обеспечивает максимально возможную скорость всех 6-ти разъемов SATA. Повторюсь, основная проблема при насыщении шины — не потребление полосы пропускания, а увеличение задержки по мере загрузки шины.
Хитрости производителей Ну а прежде чем давать практические советы, расскажу об известных хитростях, которые можно встретить на промышленных складах.
Во-первых, если вы читаете пустой диск, вы будете читать его из ниоткуда.
Системы достаточно умны, чтобы скармливать вам нули из областей диска, куда вы никогда не записывали.
Во-вторых, во многих системах первая запись хуже последующих из-за всевозможных механизмов моментальных снимков, тонкого предоставления, дедупликации, сжатия, позднего распределения, разреженного размещения и т. д. Другими словами, тестирование должно проводиться после первичной записи.
В-третьих, кэш.
Если мы тестируем худший случай, то нам нужно знать, как поведет себя система, когда кеш не поможет. Для этого нам нужно взять такой размер теста, чтобы мы гарантированно могли читать/записывать «мимо кэша», то есть превышать объём кэша.
Кэш записей — это особая история.
Он может аккумулировать все запросы на запись (последовательные и случайные) и записывать их в удобной форме.
Единственный наихудший метод — это «перебор кеша», то есть отправка запросов на запись в таком объеме и так долго, что кеш записи перестает работать и вынужден записывать данные не в комфортном режиме (объединение соседних областей), а сбрасывать случайные данные, выполнение случайной записи.
Этого можно добиться только многократно превысив тестовую область размера кэша.
Вердикт - минимум х10 кэш (честно говоря, цифра взята из воздуха, механизма точного расчета у меня нет).
Локальный кеш ОС Разумеется, тест необходимо делать без участия локального кеша ОС, то есть нам нужно запустить тест в режиме, не использующем кеширование.
В Linux это опция O_DIRECT при открытии файла (или диска).
Описание теста Общий: 1) Тестируем худший случай — 100% размера диска, что в несколько раз превышает ожидаемый размер кэша на хранилище.
Для рабочего стола это просто «весь диск»; для промышленного хранилища — это LUN или диск виртуальной машины размером 1 ТБ и более.
(Хе-хе, если вы думаете, что 64 ГБ кэш-памяти — это много…).
2) Тест проводим в блоке размером 4кб.
3) Выбираем такую глубину параллелизма операций, чтобы латентность оставалась в разумных пределах.
На выходе нас интересуют следующие параметры: количество IOPS, задержка, глубина очереди.
Если тест запускался на нескольких хостах, то показатели суммируются (iops и глубина очереди), а для задержки берется либо avg, либо max из показателей для всех хостов.
фио Здесь мы переходим к практической части.
Есть утилита фио что позволяет нам добиться нужного нам результата.
Обычный режим fio предполагает использование т.н.
файл задания, то есть конфигурация, которая точно описывает, как выглядит тест. Примеры файлов заданий приведены ниже, а пока давайте обсудим, как работает fio. fio выполняет операции с указанным файлом/файлами.
Вместо файла можно указать устройство, т.е.
исключить файловую систему из рассмотрения.
Есть несколько режимов тестирования.
Нас интересуют randwrite, randread и randrw. К сожалению, randrw дает нам зависимые iops (чтение идет после записи), поэтому для получения полностью независимого теста нам придется выполнить две параллельные задачи — одну на чтение, вторую на запись (randread, randwrite).
И нам придется сказать fio выполнить «предварительное выделение».
(о хитростях производителей см.
выше).
Далее мы фиксируем размер блока (4 КБ).
Еще одним параметром является метод доступа к диску.
Самый быстрый — libaio, его мы и будем использовать.
Практичные рецепты Установите fio: apt-get install fio (debian/ubntu).
Во всяком случае, у Squeze его пока нет. Утилита очень хитро скрыта, поэтому у нее просто нет «домашней страницы», только Git-репозиторий.
Вот одно из зеркал: freecode.com/projects/fio
При тестировании диска необходимо запускать его от имени пользователя root.
чтение тестов
Запустите: fio read.ini Содержимое read.ini[readtest] blocksize=4k filename=/dev/sda rw=randread direct=1 buffered=0 ioengine=libaio iodepth=32Задача — выбрать такую глубину ввода-вывода, чтобы avg.latency была меньше 10 мс.
Запись тестов
(внимание! Если вы используете неправильную букву диска, вы останетесь без данных)[writetest] blocksize=4k filename=/dev/sdz rw=randwrite direct=1 buffered=0 ioengine=libaio iodepth=32
Гибридные тесты
лучшая часть: (внимание! Если вы используете неправильную букву диска, вы останетесь без данных)[readtest] blocksize=4k filename=/dev/sdz rw=randread direct=1 buffered=0 ioengine=libaio iodepth=32 [writetest] blocksize=4k filename=/dev/sdz rw=randwrite direct=1 buffered=0 ioengine=libaio iodepth=32Анализ результатов Во время теста мы видим что-то вроде этого:
Jobs: 2 (f=2): [rw] [2.8% done] [13312K/11001K /s] [3250/2686 iops] [eta 05m:12s]В квадратных скобках указаны значения IOPS. Но радоваться пока рано — ведь нас интересует латентность.
На выходе (по Ctrl-C, или в конце) получим что-то вроде этого: ^ С fio: завершение по сигналу 2
read: (groupid=0, jobs=1): err= 0: pid=11048
read : io=126480KB, bw=14107KB/s, iops=3526, runt= 8966msec
slat (usec): min=3, max=432, avg= 6.19, stdev= 6.72
clat (usec): min=387, max=208677, avg=9063.18, stdev=22736.45
bw (KB/s) : min=10416, max=18176, per=98.74%, avg=13928.29, stdev=2414.65
cpu : usr=1.56%, sys=3.17%, ctx=15636, majf=0, minf=57
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued r/w: total=31620/0, short=0/0
lat (usec): 500=0.07%, 750=0.99%, 1000=2.76%
lat (msec): 2=16.55%, 4=35.21%, 10=35.47%, 20=3.68%, 50=0.76%
lat (msec): 100=0.08%, 250=4.43%
write: (groupid=0, jobs=1): err= 0: pid=11050
write: io=95280KB, bw=10630KB/s, iops=2657, runt= 8963msec
slat (usec): min=3, max=907, avg= 7.60, stdev=11.68
clat (usec): min=589, max=162693, avg=12028.23, stdev=25166.31
bw (KB/s) : min= 6666, max=14304, per=100.47%, avg=10679.50, stdev=2141.46
cpu : usr=0.49%, sys=3.57%, ctx=12075, majf=0, minf=25
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued r/w: total=0/23820, short=0/0
lat (usec): 750=0.03%, 1000=0.37%
lat (msec): 2=9.04%, 4=24.53%, 10=49.72%, 20=9.56%, 50=0.82%
lat (msec): 100=0.07%, 250=5.87%
Отсюда нас интересует (в минимальном случае) следующее:
читаем: iops=3526 clat=9063,18 (усек), то есть 9мс.
напишите: iops=2657 clat=12028.23 Не путайте планку и клац.
slat — это время отправки запроса (т.е.
производительность дискового стека Linux), а clat — это полная задержка, то есть та задержка, о которой мы говорили.
Нетрудно заметить, что чтение явно продуктивнее письма, и я указал на чрезмерную глубину.
В том же примере я понижаю ioглубину до 16/16 и получаю: чтение 6548 операций ввода-вывода в секунду, 2432,79 мкс = 2,4 мс запись 5301 iops, 3005,13 мкс = 3 мс Очевидно, глубина 64 (32+32) оказалась слишком большой, причем настолько, что итоговая производительность даже упала.
Глубина 32 – гораздо более подходящий вариант для теста.
Рекомендации по производительности Конечно, все уже раскрыли своих пи.
попугаев.
Вот значения, которые я наблюдал:
- RAMDISK (rbd) — ~200kIOPS/0,1мс (ioглубина=2)
- SSD (серия Intel 320) — чтение 40 тыс.
операций ввода-вывода в секунду (0,8 мс); около 800 IOPS на запись (после длительного тестирования)
- Диск SAS (15 тыс.
об/мин) — 180 операций ввода-вывода в секунду, 9 мс
- SATA-диск (7.2, WD RE) — 100 IOPS, 12 мс
- SATA WD Raptor — 140 операций ввода-вывода в секунду, 12 мс
- SATA WD Green — 40 IOPS, и мне не удалось добиться задержки <20 even with iodepth=1
Если вы запустите это на виртуальных машинах, то а) если за IOPS будут брать деньги, то это будут очень значительные деньги.
б) Если у хостера плохое хранилище, которое опирается только на кеш в несколько десятков гигабайт, то тест с большим диском (> 1ТБ) приведет к.
проблемам хостера и соседей по хостингу.
Некоторые хостеры могут обидеться и попросить вас уйти.
в) Не забудьте обнулить диск перед тестом (т.е.
dd if=/dev/zero of=/dev/sdz bs=2M oflag=direct) Теги: #ssd #оптимизация сервера #системное администрирование #HDD #настройка Linux #система хранения #nas #бенчмаркинг #SAN #iops #тесты производительности #fio #производительность диска #дисковая подсистема
-
Изучите Ruby Трудным Путем
19 Oct, 24 -
Портрет Голливудского Хакера
19 Oct, 24 -
Пользовательская Мифология
19 Oct, 24
