सर्वर को परेशान किए बिना लाखों फ़ाइलों को कैसे हटाएं

11

मैं एक nginx कैश निर्देशिका को हटाना चाहता हूं, जिसे मैंने जल्दी से शुद्ध कर लिया है:

mv cache cache.bak
mkdir cache
service nginx restart

अब मेरे पास एक cache.bakफ़ोल्डर है जिसमें 2 मिलियन फाइलें हैं। मैं सर्वर को परेशान किए बिना इसे हटाना चाहता हूं।

एक साधारण rm -rf cache.bakसर्वर को ट्रैश किया जाता है, यहां तक कि सबसे सरल HTTP प्रतिसाद को 16 सेकंड लगते हैं, जबकि rm चल रहा है, इसलिए मैं ऐसा नहीं कर सकता।

मैंने कोशिश की ionice -c3 rm -rf cache.bak, लेकिन यह मदद नहीं की। सर्वर में एक एचडीडी है, एसएसडी नहीं है, शायद एक एसएसडी पर ये समस्या नहीं हो सकती है।

मेरा मानना है कि सबसे अच्छा समाधान किसी प्रकार का थ्रॉटलिंग होगा, जैसे कि कैश मैनेजर में नगेंक्स कैसे बनाया जाता है।

आप इसे कैसे हल करेंगे? क्या कोई उपकरण है जो वास्तव में ऐसा कर सकता है?

ext4 Ubuntu 16.04 पर

— hyperknot
स्रोत

1

आपने "rm -rf cache.bak" से कैसे उबर लिया? ऐसा प्रतीत होता है कि जब आपने नाम बदला था तब नगनेक्स चल रहा था, इसलिए हो सकता है कि उसने फ़ाइल डिस्क्रिप्टर बनाए रखा हो और नई निर्देशिका में भी स्विच किया गया हो। मुझे लगता है कि आपको नगीन को पूरी तरह से बंद करना होगा, कैश को हटाना होगा, फिर से शुरू करना होगा।

— जनवरी स्टेनन

6

भविष्य में, कृपया अपना कैश एक अलग फाइल सिस्टम पर चिपका दें। इस तरह आप बस उस फाइलसिस्टम को न्यूड कर सकते हैं, जो लाखों फाइलों को डिलीट करने की कोशिश से बहुत तेज है। यह एक कठिन तरीका है कुछ साल पहले फ़ाइलों के zillions युक्त एक hylafax स्पूल निर्देशिका के साथ सीखा।

— डेनिस करसेमेकर

क्या आपने अच्छाrm उपयोग करके चलाने की कोशिश की है ?

— व्लादिस्लाव रैस्ट्रुसनी

तेजी से हटाने के लिए rsync का प्रयास करें - एक समान मामले के उत्तर - unix.stackexchange.com/questions/37329/…

— kawu

सभी टिप्पणियों के लिए धन्यवाद, मैंने अपने निष्कर्षों को संक्षेप में उत्तर देने के लिए लिखा है।

— हाइपरनोट

9

इस तरह से एक बैश स्क्रिप्ट बनाएं:

#!/bin/bash
rm -- "$*"
sleep 0.5

deleter.shउदाहरण के लिए नाम के साथ इसे सहेजें । chmod u+x deleter.shइसे निष्पादन योग्य बनाने के लिए चलाएं ।

यह स्क्रिप्ट तर्कों के रूप में इसे पास की गई सभी फ़ाइलों को हटा देती है, और फिर 0.5 सेकंड सोती है।

फिर, आप चला सकते हैं

find cache.bak -print0 | xargs -0 -n 5 deleter.sh

यह कमांड cache.bak में सभी फाइलों की सूची को पुनः प्राप्त करता है और डिलीट स्क्रिप्ट पर एक बार में पांच फाइलनामों को पास करता है।

तो, आप यह समायोजित कर सकते हैं कि कितनी फाइलें एक बार में हटा दी जाती हैं, और प्रत्येक ऑपरेशन को हटाने में कितनी देर होती है।

— तेरो किलकनें
स्रोत

इस समाधान के लिए धन्यवाद, मैंने इसे अपने समग्र लेखन में शामिल किया है। हालांकि एक सवाल यह है कि बड़े एन.एस. मुझे आमतौर पर त्रुटियों को देने वाली बड़ी निर्देशिकाओं में * चरित्र के साथ समस्या थी, क्या यह यहाँ नहीं है?

— हाइपरनोट

xargsएक कमांड लाइन के अधिकतम आकार को समझता है और डिफ़ॉल्ट रूप से इसे पार नहीं करने की कोशिश करता है। इस एक समय में 5 से अधिक रास्तों की अतिरिक्त सीमा नहीं है।

— बाउलऑफर्ड

1

बस इस बात का ध्यान रखें कि प्रति सेकंड 10 फ़ाइलों की दर से, 2 मिलियन फ़ाइलों को हटाने में 55 घंटे लगेंगे।

— एंड्रयू हेनले

4

आपको अपने कैश को एक अलग फाइल सिस्टम पर सहेजने पर विचार करना चाहिए जिसे आप टिप्पणियों में बताए गए अनुसार माउंट / अनमाउंट कर सकते हैं। जब तक आप ऐसा नहीं करते हैं, आप इस एक लाइनर का उपयोग कर सकते हैं /usr/bin/find /path/to/files/ -type f -print0 -exec sleep 0.2 \; -exec echo \; -deleteमान लें कि आपका बाइनरी अंडर / यूएसआर / बिन में स्थित है और आप स्क्रीन पर प्रगति देखना चाहते हैं। तदनुसार नींद को समायोजित करें, ताकि आप अपने एचडीडी पर जोर न दें।

— एलेक्स
स्रोत

-print0यहां आपको किसी की जरूरत नहीं है, क्योंकि आप findकहीं भी आउटपुट नहीं दे रहे हैं ।

— तेरो किल्केन

तुम सिर्फ rm- आईएनजी में रुचि हो सकती है इसे व्यामोह कहें, लेकिन मैं हमेशा यह सुनिश्चित करना चाहता हूं कि मैं सही फाइलें हटा रहा हूं।

— एलेक्स

यह सच है, मैं सही ढंग से कमांड को डिकोड नहीं कर रहा था, मेरा बुरा।

— तेरो किलकेनेन

3

तुम एक स्क्रिप्ट पर आयनिस की कोशिश करना चाहते हो सकता है एक खोज आदेश के उत्पादन का उपभोग। कुछ इस तरह है:

ionice -c3 $(
for file in find cache.bak -type f; do
    rm $file
done
for dir in find cache.bak -depthe -type d -empty; do
    rmdir $dir
done
)

फाइलसिस्टम के आधार पर प्रत्येक फ़ाइल को हटाने से उस संपूर्ण निर्देशिका को फिर से लिखा जा सकता है। बड़ी निर्देशिकाओं के लिए जो काफी हिट हो सकती हैं। इनोड टेबल के लिए अतिरिक्त अपडेट की आवश्यकता होती है, और संभवतः एक खाली स्थान सूची भी होती है।

यदि फ़ाइल सिस्टम में एक जर्नल है, तो परिवर्तन जर्नल को लिखा जाता है; लागू; और पत्रिका से हटा दिया गया। यह गहन गतिविधि लिखने के लिए I / O आवश्यकताओं को बढ़ाता है।

आप कैश के लिए जर्नल के बिना एक फाइल सिस्टम का उपयोग करना चाह सकते हैं।

आयनों के बजाय, आप कार्यों को सीमित करने के लिए एक नींद आदेश का उपयोग कर सकते हैं। यह काम करेगा भले ही आयनिस न हो, लेकिन आपकी सभी फ़ाइलों को हटाने में लंबा समय लगेगा।

— BillThor
स्रोत

2

मुझे यहां कई उपयोगी उत्तर / टिप्पणियां मिलीं, जिन्हें मैं समाप्त करने के साथ-साथ अपना समाधान भी बताना चाहता हूं।

हां, इस तरह की चीज को रोकने का सबसे अच्छा तरीका कैश फाइल को एक अलग फाइल सिस्टम पर रखना है। फ़ाइल सिस्टम को Nuking / क्विक फॉर्मेट करना हमेशा कुछ सेकंड (शायद मिनट) को अधिक से अधिक लेता है, यह असंबंधित है कि उस पर कितनी फाइलें / डायर मौजूद थे।
ionice/ niceसमाधान, कुछ भी नहीं किया क्योंकि हटाने प्रक्रिया वास्तव में लगभग कोई आई / ओ का कारण बना। आई / ओ के कारण मुझे विश्वास हुआ कि कर्नेल / फाइल सिस्टम स्तर की कतारें / बफ़र्स तब भरते हैं जब फाइलें डिलीट प्रक्रिया द्वारा बहुत जल्दी डिलीट हो जाती हैं।
जिस तरह से मैंने इसे हल किया वह टेरो किलकेन के समाधान के समान है, लेकिन शेल स्क्रिप्ट को कॉल करने की आवश्यकता नहीं है। मैंने --bwlimitहटाने की गति को सीमित करने के लिए स्विच में निर्मित rsync का उपयोग किया ।

पूर्ण आदेश था:

mkdir empty_dir
rsync -v -a --delete --bwlimit=1 empty_dir/ cache.bak/

अब bwlimit किलोबाइट में बैंडविड्थ को निर्दिष्ट करता है, जो इस मामले में फाइल के फ़ाइलनाम या पथ पर लागू होता है। इसे 1 केबीपीएस पर सेट करके, यह प्रति घंटे लगभग 100,000 फ़ाइलों को हटा रहा था, या प्रति सेकंड 27 फाइलें। फ़ाइलों के सापेक्ष पथ थे cache.bak/e/c1/db98339573acc5c76bdac4a601f9ec1e, जो 47 वर्ण लंबा है, इसलिए यह प्रति सेकंड 1000/47 ~ = 21 फ़ाइलें देगा, इसलिए प्रति घंटे 100,000 फ़ाइलों के मेरे अनुमान के समान है।

अब क्यों --bwlimit=1? मैंने विभिन्न मूल्यों की कोशिश की:

10000, 1000, 100 -> सिस्टम पहले की तरह धीमा
10 -> सिस्टम कुछ समय के लिए काफी अच्छा काम करता है, लेकिन एक-एक मिनट में आंशिक मंदी पैदा करता है। HTTP प्रतिक्रिया समय अभी भी <1 सेकंड।
1 -> कोई प्रणाली मंदी बिल्कुल नहीं। मैं जल्दी में नहीं हूं और 2 मिलियन फाइलें इस तरह से <1 दिन में हटाई जा सकती हैं, इसलिए मैं इसे चुनता हूं।

मुझे rsync की अंतर्निहित विधि की सादगी पसंद है, लेकिन यह समाधान रिश्तेदार पथ की लंबाई पर निर्भर करता है। नहीं एक बड़ी समस्या के रूप में ज्यादातर लोगों को परीक्षण और त्रुटि के माध्यम से सही मूल्य मिलेगा।

— hyperknot
स्रोत

और अब मैं उत्सुक हूं कि डिस्क प्रभाव क्या होगा यदि आपने "mv cache.dir-old / dev / null" जैसा कुछ किया है

— ivanivan