Ubuntu - несовместимая производительность с программным обеспечением raid-1


0

Я устанавливаю новую систему, используя soft-raid 1 с двумя физическими дисками. Во время выполнения нескольких тестов (после ожидания завершения начальной синхронизации) я обнаружил, что скорость жесткого диска была крайне непоследовательной.

Мой тест был очень прост: скопировать около jpegs с помощью cp -r, а затем удалить их и проверить, сколько времени это заняло.

for i in {1..5} ; do
  echo ".. start run $i"
  time cp -r public public2

  echo "... deleting duplicate"
  time rm -rf public2

  sleep 1
done

Иногда на протяжении всего теста процесс, кажется, кратковременно «зависает», не реагирует на ^ C и (как видно из результатов ниже) вызывает задержку в десятки секунд, а верхние отчеты «Ожидание ввода-вывода» в любом месте от 20 % до 70% в это время, и консоль становится вялой, даже не отвечает.

Это были результаты с 1 гигабайтом изображений jpg:

        copy       delete
run 1   1.336s     35.929s
run 2   2.300s     50.737s
run 3   2.358s     26.562s
run 4   0.971s     23.717s
run 5   17.485s    27.074s

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

Еще одна попытка, через некоторое время с меньшим набором данных (~ 600 МБ):

        copy       delete
run 1   11.614s    36.403s
run 2   0.630s     0.208s
run 3   0.652s     14.891s
run 4   0.676s     0.192s
run 5   0.640s     0.213s

При меньшем наборе задержки происходят гораздо реже, часто проходя все 5 прогонов без какой-либо задержки.

Еще одна попытка с большим набором данных, около 1,5 ГБ:

        copy       delete
run 1   26.687s    22.336s
run 2   38.336s    22.466s
run 3   44.711s    20.473s
run 4   41.269s    22.721s
run 5   41.592s    26.499s

Здесь задержка происходит почти каждый раз.

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

Любые мысли будут оценены, потому что я в растерянности.

Ответы:


3

У вас 2 ГБ оперативной памяти? 600 МБ в .6s - это 1 ГБ / с, что является очень быстрым диском. Система использует обратную запись для более быстрого возврата управления пользовательскому процессу, но когда в системе отсутствуют буферы, пользовательский процесс должен ждать записи данных.

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


1
Кроме того, время будет в значительной степени зависеть от того, насколько «далеки друг от друга» находятся два файла на диске. Когда вы копируете данные с одного и того же диска и на него, головки должны перемещаться назад и вперед из одного файла в другой. Это просто удача, как далеко друг от друга на диске они. (Кроме того, вы можете частично отменить коэффициент очистки буфера, выполнив syncперед тестом и выполнив syncпосле, включая время синхронизации после теста во время выполнения теста.)
Дэвид Шварц

Я пытался сбросить дисковый кэш между каждым запуском (синхронизация; echo 3> / proc / sys / vm / drop_caches), и это сделало операции удаления почти полностью согласованными (20s@1.6G). Операция копирования все еще колеблется (~ 30-60 с), но это может быть геометрия. Спасибо за объяснение обоих!
PeterD
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.