Деякі непов'язані моменти:
80K - це багато файлів.
80 000 файлів в одному каталозі? За замовчуванням жодна операційна система чи додаток не справляються із цією ситуацією. Ви просто помітили цю проблему з rsync.
Перевірте свою версію rsync
Сучасна rsync обробляє великі каталоги набагато краще, ніж раніше. Обов’язково використовуйте останню версію.
Навіть старий rsync досить добре обробляє великі каталоги через великі латентні посилання ... але файли 80k не великі ... він величезний!
Однак, використання пам'яті rsync прямо пропорційно кількості файлів у дереві. Великі каталоги займають велику кількість оперативної пам’яті. Повільність може бути пов'язана з відсутністю оперативної пам’яті з будь-якої сторони. Зробіть пробний запуск під час перегляду використання пам'яті. Linux використовує будь-яку залишену оперативну пам’ять як кеш диска, тому якщо у вас мало оперативної пам'яті, менше кешування диска. Якщо у вас закінчилася оперативна пам’ять, і система почне використовувати swap, продуктивність буде дуже поганою.
Переконайтесь, що контрольна сума не використовується
--checksum(або -c) вимагає читання кожного блоку кожного файлу. Ви, мабуть, зможете обійтись за поведінкою за замовчуванням просто зчитуванням часових змін (збережених у inode).
Роботу розділіть на невеликі партії.
Є такі проекти, як Gigasync, які " Зробіть навантаження робочим навантаженням, використовуючи perl для повторення дерева каталогів, створивши невеликі списки файлів для передачі з rsync."
Додаткове сканування каталогу буде великою накладними витратами, але, можливо, це буде чистий виграш.
За замовчуванням в ОС для цієї ситуації не робиться.
Якщо ви використовуєте Linux / FreeBSD / тощо з усіма типовими настройками, продуктивність буде жахливою для всіх ваших програм. За замовчуванням передбачаються менші каталоги, щоб не витрачати оперативну пам’ять на негабаритні кеші.
Налаштуйте свою файлову систему, щоб краще обробляти великі каталоги: Чи великі розміри папок сповільнюють продуктивність IO?
Подивіться на "кеш імені"
BSD-подібні операційні системи мають кеш, який прискорює пошук імені до inode ("cache namei"). Для кожного каталогу є кеш namei. Якщо він занадто малий, це перешкода, ніж оптимізація. Оскільки rsync робить lstat () для кожного файлу, доступ до inode є доступним для кожного з файлів 80k, що може дути ваш кеш.
Розглянемо іншу файлову систему
XFS був розроблений для роботи з більшими каталогами. Дивіться велику кількість файлів у одній директорії Filesystem
Можливо, 5 хвилин - це найкраще, що ти можеш зробити.
Подумайте про обчислення кількості блоків дисків, які читаються, і обчисліть, наскільки швидко ви повинні розраховувати, що апаратне забезпечення зможе прочитати стільки блоків.
Можливо, ваші очікування занадто високі. Поміркуйте, скільки дискових блоків потрібно прочитати, щоб зробити rsync без змінених файлів: кожному серверу потрібно буде прочитати каталог і прочитати одну вкладку на файл. Припустимо, що нічого не кешовано, тому що, мабуть, 80k файли, ймовірно, підірвали ваш кеш. Скажімо, що це 80k блоків, щоб зберегти математику просто. Це приблизно 40 мільйонів даних, які слід прочитати за кілька секунд. Однак якщо між кожним блоком потрібно шукати диск, це може зайняти набагато більше часу.
Тож вам потрібно буде прочитати близько 80 000 блоків дисків. Як швидко ваш жорсткий диск може це зробити? Враховуючи, що це випадковий ввід / вивід, не довгий лінійний зчитування, 5 хвилин може бути досить відмінним. Це 1 / (80000/600), або диск читається кожні 7,5 мс. Це швидко чи повільно для вашого жорсткого диска? Це залежить від моделі.
Орієнтир проти чогось подібного
Ще один спосіб задуматися над цим - це такий. Якщо жоден файл не змінився, ls -Llrвиконує однакову кількість активності на диску, але ніколи не читає жодних файлових даних (лише метадані). Час, який ls -Llrпотрібно запустити, - ваша верхня межа.
Чи rsync (без файлів змінено) значно повільніше, ніж ls -Llr? Тоді параметри, які ви використовуєте для rsync, можна вдосконалити. Можливо -c, увімкнено чи інший прапор, який читає більше, ніж просто каталоги та метадані (дані inode).
Чи rsync (без файлів змінено) майже так само швидко ls -Llr? Тоді ви налаштували rsync якнайкраще. Вам доведеться налаштувати ОС, додати оперативну пам’ять, отримати швидші диски, змінити файлові системи тощо.
Поговоріть зі своїми дияволами
Файли 80k - це просто поганий дизайн. Дуже мало файлових систем та системних інструментів дуже добре обробляють такі великі каталоги. Якщо імена файлів abcdefg.txt, розгляньте їх збереження у abdc / abcdefg.txt (зверніть увагу на повторення). Це розбиває каталоги на більш дрібні, але не потребує великих змін у коді.
Також .... розглянути можливість використання бази даних. Якщо у вас в каталозі є 80k файлів, можливо, ваші розробники працюють над тим, що вони дійсно хочуть - це база даних. MariaDB або MySQL або PostgreSQL були б набагато кращим варіантом для зберігання великої кількості даних.
Гей, що не так з 5 хвилин?
Нарешті, чи справді 5 хвилин так погано? Якщо ви запускаєте цю резервну копію раз на день, 5 хвилин - це не багато часу. Так, я люблю швидкість. Однак якщо 5 хвилин "достатньо хороші" для ваших клієнтів, то це досить добре для вас. Якщо у вас немає письмового договору про домовленість, як щодо неофіційної дискусії з вашими користувачами, щоб дізнатися, наскільки швидко вони очікують на резервне копіювання.
Я припускаю, що ви не задавали це питання, якщо не було потреби в покращенні продуктивності. Однак якщо ваші клієнти задоволені 5 хвилин, оголосіть перемогу та перейдіть до інших проектів, які потребують ваших зусиль.
Оновлення: Після деякої дискусії ми визначили, що вузьким місцем є мережа. Я порекомендую дві речі, перш ніж відмовитись :-).
- Спробуйте стиснути більше пропускної здатності з труби при стисненні. Однак для стиснення потрібно більше процесора, тому якщо ваш процесор перевантажений, це може погіршити продуктивність. Спробуйте rsync з і без
-z, і налаштуйте свій ssh за допомогою та без стиснення. Надайте всі 4 комбінації, щоб побачити, чи якась із них працює значно краще, ніж інші.
- Перегляньте мережевий трафік, щоб побачити, чи немає пауз. Якщо є паузи, ви можете знайти те, що викликає їх, і оптимізувати там. Якщо rsync завжди надсилає, то ви дійсно на вашій межі. Ваш вибір:
- швидша мережа
- щось інше, ніж rsync
- перемістити джерело та місце призначення ближче один до одного. Якщо ви не можете цього зробити, чи можете ви rsync до локальної машини, а потім rsync до реального місця призначення? Це може бути корисно для цього, якщо система має бути вимкненою під час початкової rsync.