Як обмежити введення / виведення диска під час резервного копіювання?


14

У мене є крон, який в основному роблять простий "tar zcf" вночі.

Сервер має:

  • 8 ядер - процесор Intel (R) Xeon (R) E5606 при 2,13 ГГц
  • 25 Гб оперативної пам’яті
  • Ubuntu 12.04.2 LTS
  • Апаратний RAID 1 (LSI Logic / Symbios Logic MegaRAID SAS SMC2108) з двома накопичувачами 2.728TB

Як ви бачите на екрані моніторингу:

http://clip2net.com/s/57YRKP

Протягом майже всього часу використання смоли дисковий введення / вивід переходить на> 90% і змушує всі інші програми (mysql, apache) значно сповільнюватися.

2 питання:

  • Чи нормально мати настільки високий диск вводу / виводу під час резервного копіювання?
  • Чи існує спосіб обмеження вводу / виводу диска, щоб інша програма могла продовжувати працювати правильно?

Дякую!

Відповіді:


11

Окрім досить загального підходу, ioniceіснує приємна ціль відображення пристроїв (ioband), яка дозволяє точно контролювати пропускну здатність до блоку пристрою (DM). На жаль, це не є частиною стандартного ядра.

Крім того, ви, ймовірно, можете пришвидшити смолу

  1. Читання імен файлів у кеш диска: find /source/path -printf ""
  2. Читання вкладок у кеш диска: find /source/path -perm 777 -printf ""
  3. Зробити тар для читання та запису великих блоків з та на диск, наприклад, використовуючи трубу з mbuffer або буфером (щонайменше 100 Мбайт оперативної пам’яті): tar ... | mbuffer -m 256M -P 100 -p 1 ...

Чому читання імен файлів / входів у кеш-пам'яті зменшує введення диска під час таргетування? Я б очікував, що це збільшить середній рівень введення, зменшивши загальний час лише незначно.
scai

3
@scai Це не допомагає для SSD-дисків; моя рекомендація стосується лише прядіння жорстких дисків. Те, що вбиває продуктивність, - це рух голови. Імена файлів зберігаються в безперервних блоках, вставки зберігаються в безперервних блоках, а вміст файлів зберігається в безперервних блоках. Якщо ви робите це так, то ви читаєте назви файлів (і підкаталогів) одного каталогу, отримуєте доступ до inode для одного файлу, потім до самого файлу, потім до вводу для наступного файлу, потім до самого наступного файлу ... Це викликає більший рух голови, ніж читання всіх імен та вкладів один за одним.
Хоуке Лагінг

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

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

@acemtp Це правильно. findбез (наприклад) -permне матиме доступу до файлу inode. Але це дозволяє оптимізувати використання двох findдзвінків. Якщо ви здійснюєте той самий findдзвінок двічі (з невеликим проміжком часу), другий, як правило, закінчується протягом декількох секунд (або менше). Залежно від кількості вільної пам'яті та кількості кешованих даних у певний момент дані викидаються з кеша. Читання занадто багато може, таким чином, просто уповільнити роботу. Якщо ви можете годувати програму резервного копіювання з іменами файлів через stdin, ви можете запобігти цьому, читаючи блоки, наприклад, 100 файлів.
Хоуке Лагінг

13

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


1

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

http://backuppc.sourceforge.net/


0

Як відповіли інші, так, це нормально, і ioniceце загальний загальний спосіб не допускати впливу на вашу систему.

Неодноразово я бачив, як люди tarналагоджують, коли їм це не потрібно. Якщо жоден відсоток даних, які ви копіюєте, не змінився з моменту останньої копії, тоді я б rsyncспробував спробувати.

Це зменшить IO, лише скопіювавши файли, які були змінені з моменту останньої копії. ви не зможете зменшити IO більш ніж вдвічі, оскільки всі дані все-таки потрібно буде прочитати, але ви значно зменшите кількість записаних даних (що залежно від вашого обладнання також може бути повільнішим).

Якщо ви хочете кожен раз виконувати окремі копії / резервні копії, найпотужнішим варіантом є –link-dest, який дозволяє жорстко пов’язати незмінені файли з попередньою резервною копією. Це економить величезну кількість місця на резервному сервері. Наприклад, я створюю резервну копію машини (Fred), Fred має 20 Гб HD, і я створюю резервну копію / копіювання всього диска, виключаючи / proc і / dev. Зараз у мене на резервному сервері є каталог із 20 ГБ. Наступного дня я знову створюю резервну копію Фреда і посилаюсь на вчорашнє резервне копіювання. Rsync порівнює віддалені файли з локальною копією, і якщо точно так само не буде перешкоджати їх передачі, але буде важко пов’язати новий файл з вчорашнім файлом. Будь-які файли, які були змінені, копіюються у свіжому вигляді (або частково скопіюються за допомогою вчорашнього резервного копіювання, якщо можливо). Якщо з вчорашнього дня було змінено лише 100 МБ файлів, я маю два каталоги, по 20 ГБ файлів, але лише 20.

Я сподіваюся, що це допоможе і все-таки відповість на ваше питання.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.