Beberapa poin yang tidak terkait:
80K adalah banyak file.
80.000 file dalam satu direktori? Tidak ada sistem operasi atau aplikasi yang menangani situasi itu dengan sangat baik secara default. Anda baru saja menyadari masalah ini dengan rsync.
Periksa versi rsync Anda
Rsync modern menangani direktori besar jauh lebih baik daripada sebelumnya. Pastikan Anda menggunakan versi terbaru.
Bahkan rsync lama menangani direktori besar dengan cukup baik melalui tautan latensi tinggi ... tapi file 80k tidak besar ... besar sekali!
Yang mengatakan, penggunaan memori rsync berbanding lurus dengan jumlah file dalam pohon. Direktori besar membutuhkan RAM dalam jumlah besar. Kelambatan mungkin karena kurangnya RAM di kedua sisi. Lakukan uji coba sambil menonton penggunaan memori. Linux menggunakan RAM sisa sebagai cache disk, jadi jika Anda kehabisan RAM, ada lebih sedikit caching disk. Jika Anda kehabisan RAM dan sistem mulai menggunakan swap, kinerjanya akan sangat buruk.
Pastikan --checksum tidak digunakan
--checksum(atau -c) mengharuskan membaca setiap dan setiap blok dari setiap file. Anda mungkin dapat bertahan dengan perilaku default hanya dengan membaca waktu modifikasi (disimpan dalam inode).
Bagi pekerjaan menjadi beberapa kelompok kecil.
Ada beberapa proyek seperti Gigasync yang akan "Memotong beban kerja dengan menggunakan perl untuk recurse pohon direktori, membangun daftar file yang lebih kecil untuk ditransfer dengan rsync."
Pemindaian direktori tambahan akan menjadi jumlah besar overhead, tapi mungkin itu akan menjadi kemenangan bersih.
Default OS tidak dibuat untuk situasi ini.
Jika Anda menggunakan Linux / FreeBSD / etc dengan semua defaultnya, kinerja akan mengerikan untuk semua aplikasi Anda. Default mengasumsikan direktori yang lebih kecil agar tidak membuang RAM pada cache yang terlalu besar.
Tune sistem file Anda untuk menangani direktori besar dengan lebih baik: Apakah ukuran folder besar memperlambat kinerja IO?
Lihatlah "namei cache"
Sistem operasi mirip BSD memiliki cache yang mempercepat pencarian nama ke inode ("namei" cache "). Ada cache namei untuk setiap direktori. Jika terlalu kecil, itu adalah penghalang lebih dari optimasi. Karena rsync melakukan lstat () pada setiap file, inode sedang diakses untuk setiap satu dari file 80k. Itu mungkin meniup cache Anda. Meneliti bagaimana mengatur kinerja direktori file pada sistem Anda.
Pertimbangkan sistem file yang berbeda
XFS dirancang untuk menangani direktori yang lebih besar. Lihat Filesystem sejumlah besar file dalam satu direktori
Mungkin 5 menit adalah yang terbaik yang bisa Anda lakukan.
Pertimbangkan menghitung berapa banyak blok disk yang sedang dibaca, dan hitung seberapa cepat Anda seharusnya mengharapkan perangkat keras dapat membaca banyak blok itu.
Mungkin harapan Anda terlalu tinggi. Pertimbangkan berapa banyak blok disk yang harus dibaca untuk melakukan rsync tanpa file yang diubah: setiap server harus membaca direktori dan membaca satu inode per file. Mari kita asumsikan tidak ada yang di-cache karena, well, 80 ribu file mungkin telah menghancurkan cache Anda. Katakanlah itu 80k blok untuk menjaga matematika sederhana. Itu sekitar 40 juta data, yang seharusnya bisa dibaca dalam beberapa detik. Namun jika perlu ada pencarian disk antara setiap blok, itu bisa memakan waktu lebih lama.
Jadi, Anda perlu membaca sekitar 80.000 blok disk. Seberapa cepat hard drive Anda dapat melakukannya? Menimbang bahwa ini adalah I / O acak, bukan bacaan linear panjang, 5 menit mungkin cukup bagus. Itu 1 / (80000/600), atau disk membaca setiap 7,5ms. Apakah itu cepat atau lambat untuk hard drive Anda? Tergantung modelnya.
Tolak ukur terhadap sesuatu yang serupa
Cara lain untuk memikirkannya adalah ini. Jika tidak ada file yang berubah, ls -Llrlakukan aktivitas disk dalam jumlah yang sama tetapi tidak pernah membaca data file apa pun (hanya metadata). Waktu yang ls -Llrdiperlukan untuk berlari adalah batas atas Anda.
Apakah rsync (tanpa file berubah) secara signifikan lebih lambat daripada ls -Llr? Maka opsi yang Anda gunakan untuk rsync dapat ditingkatkan. Mungkin -cdiaktifkan atau flag lain yang membaca lebih dari sekadar direktori dan metadata (data inode).
Apakah rsync (tanpa file berubah) hampir secepat ls -Llr? Kemudian Anda telah menyetel rsync sebaik mungkin. Anda harus menyetel OS, menambah RAM, mendapatkan drive yang lebih cepat, mengubah sistem file, dll.
Bicaralah dengan devs Anda
File 80k hanya desain yang buruk. Sangat sedikit sistem file dan alat sistem yang menangani direktori besar dengan sangat baik. Jika nama file abcdefg.txt, pertimbangkan untuk menyimpannya di abdc / abcdefg.txt (perhatikan pengulangannya). Ini memecah direktori menjadi lebih kecil, tetapi tidak memerlukan perubahan besar pada kode.
Juga .... pertimbangkan untuk menggunakan basis data. Jika Anda memiliki 80 ribu file dalam suatu direktori, mungkin pengembang Anda mengatasi kenyataan bahwa apa yang sebenarnya mereka inginkan adalah database. MariaDB atau MySQL atau PostgreSQL akan menjadi pilihan yang jauh lebih baik untuk menyimpan sejumlah besar data.
Hei, ada apa dengan 5 menit?
Terakhir, apakah 5 menit benar-benar buruk? Jika Anda menjalankan cadangan ini sekali sehari, 5 menit bukanlah waktu yang banyak. Ya, saya suka kecepatan. Namun jika 5 menit "cukup baik" untuk pelanggan Anda, maka itu cukup baik untuk Anda. Jika Anda tidak memiliki SLA tertulis, bagaimana dengan diskusi informal dengan pengguna Anda untuk mengetahui seberapa cepat mereka mengharapkan pencadangan.
Saya berasumsi Anda tidak mengajukan pertanyaan ini jika tidak ada kebutuhan untuk meningkatkan kinerja. Namun, jika pelanggan Anda senang dengan 5 menit, nyatakan kemenangan dan beralih ke proyek lain yang membutuhkan upaya Anda.
Pembaruan: Setelah beberapa diskusi, kami menentukan bahwa bottleneck adalah jaringan. Saya akan merekomendasikan 2 hal sebelum saya menyerah :-).
- Cobalah untuk memeras lebih banyak bandwidth dari pipa dengan kompresi. Namun kompresi membutuhkan lebih banyak CPU, jadi jika CPU Anda kelebihan beban, itu dapat membuat kinerja lebih buruk. Coba rsync dengan dan tanpa
-z, dan konfigurasikan ssh Anda dengan dan tanpa kompresi. Atur waktu semua 4 kombinasi untuk melihat apakah ada di antaranya yang berperforma lebih baik daripada yang lain.
- Tonton lalu lintas jaringan untuk melihat apakah ada jeda. Jika ada jeda, Anda dapat menemukan apa yang menyebabkannya dan mengoptimalkannya. Jika rsync selalu mengirim, maka Anda benar-benar berada di batas Anda. Pilihan Anda adalah:
- jaringan yang lebih cepat
- sesuatu selain rsync
- pindahkan sumber dan tujuan lebih dekat bersama. Jika Anda tidak bisa melakukan itu, bisakah Anda rsync ke mesin lokal kemudian rsync ke tujuan sebenarnya? Mungkin ada manfaat untuk melakukan ini jika sistem harus turun selama rsync awal.