У меня есть ubuntu (серверное ядро) на amd x4, 4gb ram, 2x seagate sata 1 tb для тестирования виртуальных машин, и скорость записи очень медленная. Два диска находятся в программном массиве raid1, один небольшой загрузочный раздел ext3, системный раздел 10 ГБ, а остальное - раздел xfs (около 980 ГБ) для данных (виртуальных машин).
Если я копирую файлы с виртуальной машины на хост с помощью rsync или scp, копия часто останавливается или идет со скоростью около 1 МБ / с. В чем дело?
Я пробовал отключать барьеры на xfs, увеличивать logbufs, allocsize, но, похоже, ничего не помогает.
Странно то, что await (например, при копировании) для sda обычно меньше 100, а для sdb - около 400.
Есть идеи, что может быть не так / что я могу сделать, чтобы улучшить эту настройку?
Получаете ли вы аналогичные проблемы с производительностью при синхронизации файлов из одного места в файловой системе хоста в другое место в том же массиве? Если это так, то я подозреваю, что вы просто видите задержку движений головки диска при чтении из одной части диска и записи в другую часть того же диска (или в этом случае диски, так как любая запись должна выполняться на обоих в RAID1 массив). Производительность записи RAID1 практически такая же, как у самого медленного отдельного диска в массиве. Я бы не ожидал, что это будет так же медленно, как ~ 1 Мбайт / с, хотя с современными дисками, если вы не копируете много небольших файлов (в этом случае для каждого файла добавляется большая задержка, поскольку записи каталога создаются / обновляются, поэтому такой низкая скорость может не удивить).
Ваш выбор файловых систем и связанных параметров на хосте и виртуальных машинах также может иметь значение. Если вы включили ведение журнала на виртуальной машине, это увеличит накладные расходы, особенно если это полное ведение журнала, а не только ведение журнала метаданных. Я не уверен насчет XFS, но ext3 по умолчанию использует журналирование метаданных (обычно параметры журналирования отсутствуют, мета и полное). Если у вас есть полное ведение журнала в файловой системе на виртуальной машине и в файловой системе файлы виртуального диска виртуальной машины хранятся на хосте, тогда каждая операция записи в виртуальной машине станет как минимум четырьмя физическими операциями записи («запись в журнал» и «запись в основное хранилище» на виртуальной машине, обе операции становятся: запись в журнал »и« запись в область основного хранилища »в файловой системе ОС хоста).
Если это тестовая машина, и вас не волнует, что виртуальные машины умирают из-за сбоя диска, потому что вы можете легко воссоздать их (или полностью зарезервировать их в другом месте), тогда вы обнаружите, что RAID0 лучше для производительности, хотя, очевидно, обычный риск RAID0 применяется (если вы потеряете один диск, весь массив мертв). Вы также можете просто использовать два диска как отдельные тома - разумное распределение виртуальных машин (и задач в ОС хоста) по отдельным шпинделям может дать хороший прирост производительности, поскольку виртуальные машины (и задачи хоста) будут меньше конкурировать друг с другом за операции ввода-вывода. пропускная способность. Вы также можете использовать четыре диска и перейти к RAID10 (что по сути дает вам преимущества как RAID0, так и RAID1 в обмен на небольшое дополнительное усложнение и больше дисков). Однако, прежде чем думать о реорганизации вашей дисковой подсистемы, убедитесь, что проблема с производительностью, которую вы в настоящее время наблюдаете, не связана с чем-то еще, например, с одним из текущих дисков, развивающим проблему. Проверяли ли вы журналы SMART на дисках на предмет каких-либо предупреждающих знаков?