Почему во время интенсивной записи снижается задержка диска?
Глядя на продукцию Мунина diskstats плагин (который читает из /proc/diskstats) Я замечаю то, что мне кажется необычным. Диск представляет собой SSD, и я бы предположил, магнитный или твердотельный, что задержка будет увеличиваться во время периодов интенсивной записи. Почему вместо этого он умирает?
Запись случайная или потоковая?
Я предполагаю, что это непрерывная потоковая «последовательная» запись, потому что задержка ввода-вывода всегда ниже при последовательном вводе-выводе. Задержка выше для случайного ввода-вывода, потому что твердотельные накопители все еще имеют некоторую задержку для пакетов ввода-вывода, кеши не так эффективны, и на SSD может быть фоновая сборка мусора, которую необходимо прервать, и т. Д.
Читать далее: https://www.seagate.com/tech-insights/lies-damn-lies-and-ssd-benchmark-master-ti/
SSD-накопители ведут себя странно при записи, которая может вызвать снижение задержки. Они будут хранить данные во внутреннем кэше записи в течение первых нескольких МБ, а затем записывать их. Это означает, что первые несколько операций записи будут иметь очень короткую задержку, поскольку запись подтверждается, когда данные попадают во внутреннюю SRAM, но еще не попали на флэш-носитель. Затем данные быстро записываются на носитель (обычно записываются параллельно на несколько флэш-кристаллов по нескольким каналам), а затем SSD готов к получению другой такой партии. Если у вас есть записи, которые генерируют большую очередь на SSD, вы увидите рост задержки, если ваши записи происходят короткими пакетами, у вас будет очень большое сокращение задержки, поскольку каждый пакет обрабатывается SRAM.
эта задержка будет увеличиваться в периоды интенсивной записи. Почему вместо этого он умирает?
Потому что у вас хейси не пишет. Похоже, ваши тяжелые записи БОЛЬШИЕ. В то время как в другие периоды ты делал много мелочей.
Видите, здесь не хватает счетчика IOPS. IOS обычно более ограничен IOPS. Если oyu odo несколько больших IOPS (копирование больших файлов), тогда это более эффективно, даже для SSD (замена содержимого ячейки быстрее, чем чтение ячейки, изменение некоторых байтов, запись всей ячейки).
Нам нужно было бы проанализировать то, что вы сделали, но похоже, что большая операция ввода-вывода переборщила с остальным. Возможно, у вас были виртуальные машины на сервере, которые вы даже отключили? Никто не может знать, не зная, что там произошло в это время.
Кстати, для оборудования и SSD задержка обычно УЖАСНАЯ. С такой пропускной способностью и твердотельным накопителем я ожидал, что задержка будет намного меньше 1 мс.
Я просто смотрю на меньшее устройство хранения, выполняющее около 1000 операций ввода-вывода в секунду на данный момент - менее 1 мегабайта, тонна небольших io, которые вы получаете, когда запускаете 40 или около того бездействующих виртуальных машин .... запись составляет 1,85 мс НАД СЕТЬ (! ), считайте при 5,25 мкс (не мс, мкс). Даже ваши минимальные значения чрезвычайно высоки. Ваши записи обычно находятся в той области, в которой я получил доступ к SSD через 1-гигабитную сеть.
В средний переместился на ваш график. Но будьте осторожны Что на самом деле означает "среднее". Распределение задержки почти наверняка имеет выбросы, не является нормальным и имеет несколько режимов.
Пытаться получение сырого времени отклика и отображение его в виде тепловой карты. Вероятно, будет небольшое количество выбросов и кластер около 2 мс, где среднее значение стабилизируется. Размер выборки - количество операций ввода-вывода - меняет степень влияния на среднее значение.
Также обратите внимание, что в зависимости от реализации запись может быть быстрее, чем чтение. Массив хранения или дисковый накопитель могут подтвердить запись в энергонезависимую кэш-память быстрее, чем это требуется для чтения с носителя.