Bagaimana mencegah subtree removal (`rm -rf`) agar tidak kelaparan proses lain untuk Disk I / O?


8

Kami memiliki direktori cache Nginx (multi-GB) yang sangat besar untuk situs yang sibuk, yang terkadang perlu kami hapus sekaligus. Saya telah memecahkan ini di masa lalu dengan memindahkan folder cache ke jalur baru, membuat folder cache baru di jalur lama, dan kemudian rm -rfmemasukkan folder cache lama.

Namun belakangan ini, ketika saya perlu menghapus cache pada suatu pagi yang sibuk, I / O dari rm -rfmembuat server saya kelaparan proses akses disk, karena baik Nginx dan server yang dihadapinya bersifat membaca-intensif. Saya bisa menyaksikan rata-rata beban naik sementara CPU diam dan rm -rfmengambil 98-99% dari Disk IO iotop.

Saya sudah mencoba ionice -c 3ketika memohon rm, tetapi tampaknya tidak memiliki efek yang cukup pada perilaku yang diamati.

Apakah ada cara untuk menjinakkan rm -rfuntuk berbagi disk lebih banyak? Apakah saya perlu menggunakan teknik berbeda yang akan mengambil isyarat dari ionice?

Memperbarui:

Sistem file yang dimaksud adalah penyimpanan instance AWS EC2 (disk utama adalah EBS). The /etc/fstabentri terlihat seperti ini:

/dev/xvdb       /mnt    auto    defaults,nobootwait,comment=cloudconfig 0       2

Anda mungkin juga harus menyebutkan sistem file yang Anda gunakan dan caranya (opsi mount).
Cristian Ciupitu

Diperbarui. Juga, jika itu penting, ini ada di Ubuntu 12.04.
David Eyk

Perhatikan bahwa kinerja IO di Amazon EBS bisa sangat buruk. Lihat perfcap.blogspot.com/2011/03/... yang merekomendasikan maksimum 100 jangka panjang, dengan jangka pendek (1 menit) meledak hingga 1000. Kedengarannya kasus Anda jauh lebih tinggi daripada yang terjadi dalam satu menit, karenanya masalahnya.
Moshe Katz

Benar, itu sebabnya kami menggunakan toko contoh, bukan EBS, untuk cache. Lihat komentar pembaruan saya. Maaf kalau itu tidak jelas.
David Eyk

Maaf saya terlambat, tetapi Anda bisa menyelidiki cgroup dan pengontrol blkio: kernel.org/doc/Documentation/cgroups/blkio-controller.txt
AndreasM

Jawaban:


3

Semua data dikumpulkan dari halaman ini. Di bawah ini adalah beberapa opsi untuk menghapus direktori file yang besar. Lihat langganan untuk rincian bagaimana ini diproduksi.

Waktu Sistem Perintah Berlalu% CPU cs1 * (Vol / Invol)
rsync -a –delete kosong / a 10,60 1,31 95% 106/22
temukan b / -tipe f -hapus 28.51 14.46 52% 14849/11
temukan c / -type f | xargs -L 100 rm 41,69 20.60 54% 37048/15074
temukan d / -type f | xargs -L 100 -P 100 rm 34,32 27,82 89% 929897/21720
rm -rf f 31,29 14.80 47% 15134/11

* cs1 adalah saklar konteks sukarela dan tidak sukarela


Sementara ini secara teoritis dapat menjawab pertanyaan, akan lebih baik untuk memasukkan bagian-bagian penting dari jawaban di sini, dan menyediakan tautan untuk referensi.
Tom O'Connor

Menarik! Saya akan mencobanya.
David Eyk

rsyncsedang berjalan sekarang. Mungkin terlalu dini untuk mengatakannya, dan ini bisa membantu saya tidak menjalankannya di tengah pagi yang sibuk, tetapi server masih responsif dan rata-rata beban dapat dikelola.
David Eyk

Doa yang tepat saya gunakan:ionice -c 3 nice -19 rsync -a --delete /mnt/empty/ /mnt/nginx-cache-old
David Eyk

Yah, itu hanya butuh 4 jam. ;) Saya akan menerima jawaban ini (maaf @aferber) karena saya suka doa langsung dan tampaknya rentan terhadap nicedan ionice, atau setidaknya itu tidak menghancurkan server seperti rm -rfsebelumnya.
David Eyk

9

Menghapus file hanya menjalankan operasi metadata pada sistem file, yang tidak dipengaruhi oleh ionice.

Cara paling sederhana adalah, jika Anda tidak memerlukan ruang disk sekarang, untuk melakukan rmselama jam-jam di luar jam sibuk.

Cara yang lebih kompleks yang BISA bekerja adalah untuk menyebarkan penghapusan dari waktu ke waktu. Anda dapat mencoba sesuatu seperti yang berikut ini (perhatikan bahwa ini mengasumsikan jalur dan nama file Anda TIDAK mengandung spasi!):

while find dir -type f | head -n 100 | xargs rm; do sleep 2; done
while find dir -type d -depth | head -n 100 | xargs rmdir; do sleep 2; done

Perhatikan juga bahwa Anda tidak dapat menggunakan rm -fdalam perintah pertama karena loop tidak akan berhenti (itu tergantung pada kode keluar kesalahan rmketika tidak ada argumen).

Anda dapat mengubahnya dengan memodifikasi jumlah penghapusan per siklus (100 dalam contoh) dan durasi tidur. Namun itu mungkin tidak benar-benar berfungsi karena sistem file mungkin masih mengelompokkan pembaruan metadata sedemikian rupa sehingga Anda mendapat masalah dengan muatan IO Anda. Anda hanya harus mencoba.


Menghapus banyak file membutuhkan waktu yang lama, jadi tidak ada periode "di luar puncak" yang akan mencakupnya. :(
David Eyk

The whileLoop tampaknya melakukan trik ketika head -n 50. 100 masih perlahan-lahan menaikkan rata-rata beban di atas kritis, yang memberitahu saya terlalu banyak pertengkaran sumber daya sedang terjadi.
David Eyk

Sobat, itu butuh waktu lama untuk berlari!
David Eyk

Temuan ini masih akan mencantumkan semua file dalam direktori dan semua subdirektori untuk setiap iterasi dari loop sementara. Anda mungkin bisa melakukan yang lebih baik dengan sesuatu seperti
Randy Orrison

1
Temuan ini masih akan mencantumkan semua file dalam direktori dan semua subdirektori untuk setiap iterasi dari loop sementara. Anda mungkin bisa melakukan yang lebih baik dengan sesuatu seperti find dir -type f -print0 | xargs -l50 -0 rmwait di mana rmwait adalah skrip yang melakukan rm "$ @"; sleep 2. Perhatikan penggunaan -print0 dan -0 untuk menangani nama file dengan spasi. -l50 memberitahu xargs untuk hanya melakukan 50 sekaligus.
Randy Orrison

-1

Anda dapat memasangkannya dengan perintah "bagus". ionice -c 3 nice -19 rm -rf /some/folder

Ini mengubah prioritas proses pada mesin.


Sayangnya, nicetampaknya memiliki efek sebanyak ionice, yaitu, tidak ada yang cukup.
David Eyk

@ DavidEyk. Jika nice dan ionice tidak memiliki efek "nyata", itu berarti tidak ada hal lain yang bersaing untuk sumber daya dengan cara apa pun, atau Anda tidak memperhatikan efeknya dengan mata telanjang. Anda benar-benar harus membandingkannya menggunakan iostat dan vmstat untuk melihat efek nyata.
Michael Martinez

Saya percaya @aferber menjawab pertanyaan ini dalam jawabannya: "Menghapus file hanya menjalankan operasi metadata pada sistem file, yang tidak dipengaruhi oleh ionice." Saya telah melihat pertengkaran - proses server saya kelaparan untuk waktu membaca sementara CPU dihancurkan dan rm -rfmemiliki 99% aktif iotop.
David Eyk
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.