Как ограничить дисковый ввод-вывод во время резервного копирования?

14

У меня есть cron, который в основном делает простой "tar zcf" ночью.

Сервер имеет:

8 ядер - процессор Intel® Xeon®® E5606 с частотой 2,13 ГГц
25 ГБ ОЗУ
Ubuntu 12.04.2 LTS
Аппаратный RAID 1 (LSI Logic / Symbios Logic MegaRAID SAS SMC2108) с двумя жесткими дисками по 2,728 ТБ

Как вы можете видеть на экране мониторинга:

В течение почти всего времени tar дисковый ввод-вывод достигает> 90% и заставляет все другие приложения (mysql, apache) сильно замедляться.

2 вопроса:

Нормально ли иметь такой высокий дисковый ввод / вывод во время резервного копирования?
Есть ли способ ограничить дисковый ввод-вывод, чтобы другие приложения могли продолжать работать правильно?

Спасибо!

— acemtp
источник

11

Помимо довольно общего подхода, ioniceесть хорошая цель отображения устройства (ioband), которая позволяет точно контролировать пропускную способность для блочного устройства (DM). К сожалению, оно не является частью стандартного ядра.

Кроме того, вы можете, вероятно, ускорить смолу

Чтение имен файлов в кэш диска: find /source/path -printf ""
Чтение inode в дисковый кеш: find /source/path -perm 777 -printf ""
Заставить tar читать и записывать большие блоки с диска и на диск, например, используя канал с mbuffer или буфером (с минимум 100 МБ ОЗУ): tar ... | mbuffer -m 256M -P 100 -p 1 ...

— Хауке Лагинг
источник

Почему чтение имен файлов / инодов в кеш сокращает дисковый ввод-вывод во время tar? Я ожидал бы, что это увеличит средний IO, уменьшая общее время только немного.

— Scai

3

@scai Это не помогает с твердотельными накопителями; моя рекомендация относится только к крутящимся жестким дискам. Что убивает производительность с этими движениями головы. Имена файлов хранятся в непрерывных блоках, иноды хранятся в непрерывных блоках, а содержимое файла хранится в непрерывных блоках. Если вы сделаете это tar-способом, то вы прочитаете имена файлов (и подкаталогов) одного каталога, получите доступ к inode для одного файла, затем к самому файлу, затем к inode для следующего файла, затем к самому следующему файлу ... вызывает больше движения головы, чем чтение всех имен и инодов друг за другом.

— Хауке Лагинг

@scai Влияние на производительность зависит от того, что вы делаете. Это довольно мало для полных резервных копий (вероятно, зависит от размеров файлов), но я заметил большую разницу для разностных резервных копий (правда, не для tar, поскольку я не использую это, но это должно быть общим эффектом).

— Хауке Лагинг

Просто чтобы убедиться, что я правильно понял. Для 1. и 2. нам просто нужно вызвать команду find, и Linux автоматически ее кеширует?

— acemtp

@acemtp Это правильно. findбез (например) -permне получит доступ к файлу inode, хотя. Но это позволяет для оптимизации использовать два findвызова. Если вы делаете один и тот же findвызов дважды (с небольшим промежутком времени), второй звонок обычно заканчивается в течение нескольких секунд (или меньше). В зависимости от объема свободной памяти и объема данных, кэшированных в определенный момент, данные выбрасываются из кэша. Чтение слишком много может, таким образом, просто замедлить работу. Если вы можете передать программе резервного копирования имена файлов через stdin, вы можете предотвратить это, прочитав блоки, например, из 100 файлов.

— Хауке Лагинг

13

Ожидается, что во время резервного копирования будет наблюдаться высокий уровень ввода-вывода, потому что они обычно создаются поверх больших файловых деревьев с большими файлами. Вы можете использовать ioniceдля приоритезации заданий ввода-вывода в Linux с классами и уровнями. IIRC, класс 2, уровень 7 - это самый низкий уровень, не подверженный голоданию, который сделает его практически невидимым для других нагрузок ввода-вывода и пользователей. Смотрите man ioniceдля использования и деталей.

— bayindirh
источник

1

Я бы порекомендовал отказаться от tar и использовать rsync (как упоминалось в Dogsbody). Я использую BackupPC для резервного копирования файлов в моих системах Windows и Linux, и он поддерживает использование tar, а также rsync и автоматически заботится о жестких ссылках для вас, а также предоставляет приятный веб-интерфейс.

http://backuppc.sourceforge.net/

— Atari911
источник

0

Как ответили другие, да, это нормально, и ioniceэто хороший общий способ не позволить этому повлиять на вашу систему.

Много раз я видел, как у людей tarвсе в порядке, хотя им это и не нужно. Если какой-либо процент копируемых данных не изменился со времени последней копии, я бы предложил rsyncпопробовать.

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

Если вы хотите, чтобы отдельные копии / резервные копии выполнялись при каждом запуске, тогда наиболее мощным параметром является –link-dest, который позволяет жестко связать неизмененные файлы с предыдущей резервной копией. Это экономит ОГРОМНОЕ количество места на сервере резервного копирования. Например, я создаю резервную копию компьютера (Fred), у Fred есть жесткий диск объемом 20 ГБ, и я копирую / копирую весь диск, кроме / proc и / dev. Теперь у меня есть каталог 20 ГБ на моем сервере резервного копирования. На следующий день я снова делаю резервную копию Fred и -link-dest для вчерашнего резервного копирования. Rsync сравнивает удаленные файлы с локальной копией и, если точно так же, не будет беспокоить их передачу, но будет жестко связывать новый файл с файлом вчерашнего дня. Любые файлы, которые были изменены, копируются заново (или частично, если возможно, с использованием резервной копии вчерашнего дня). Если со вчерашнего дня изменилось только 100 МБ файлов, то теперь у меня есть две директории, каждая из которых содержит 20 ГБ файлов, но занимает только 20.

Я надеюсь, что это помогает и все еще отвечает на ваш вопрос.

— работяга
источник