কয়েক মিলিয়ন ফাইল মুছে ফেলা হচ্ছে


38

আমার লক্ষ লক্ষ জিআইএফ ইমেজ রয়েছে এমন একটি দির ছিল। আরএম কমান্ডের জন্য অনেক বেশি।

আমি ফাইন্ড কমান্ডটি এভাবে চেষ্টা করে যাচ্ছি:

find . -name "*.gif" -print0 | xargs -0 rm

সমস্যাটি হ'ল এটি আমার মেশিনটিকে সত্যই খারাপ করে ফেলেছে এবং এটি সার্ভারের কারণে গ্রাহকদের জন্য সময়সীমা অতিক্রম করে।

মেশিনটি লক না করেই কোনও উপায় আছে যে এই সমস্ত ফাইল মুছে ফেলার জন্য দ্রুত ...


আমি নীচে "ভাল ফাইন্ড" কমান্ডটি ব্যবহার করে প্রায় 6 গিগাবাইট / ঘন্টা ডিলিটেশন রেটে রয়েছি all সম্ভবত সমস্ত ফাইল থেকে মুক্তি পেতে সরাসরি 48 ঘন্টা সময় লাগবে this আরএম কমান্ড সহ "ইভেন্ট দিগন্ত", তখন এটি পালিয়ে যায়

3
পুরো দির অপসারণ কি যথেষ্ট দ্রুত হবে না? বাকী ফাইলগুলি ঠিক করার আগে কেবল "ভাল" ফাইলগুলি বের করুন ...
tucuxi

ঠিক আছে, প্রতিটি ফাইল এখনই খারাপ, কারণ এটি / dir_old এ সরানো হয়েছিল এবং আমি / dir পুনর্নির্মাণ করেছি। কিন্তু আরএমডিয়ার আরএম * এর মতো সীমাবদ্ধতায় চলে যাবে না?

@ কোরপুঞ্চার: আমি প্রত্যাশা করব যে পুরো ডিরেক্টরিটি সরিয়ে ফেলা (পাশাপাশি rm -rfএটি আরও দ্রুত হবে a এটি একটি চেষ্টা করার মতো মূল্য।)
জেসন আর

আমি বর্তমানে দিরের উপর "আরএম-আরএফ" চালাচ্ছি। এটি এখন প্রায় 20 মিনিটেরও বেশি সময় ধরে চলছে ... ডিস্ক আকারে কোনও পরিবর্তন হয়নি। তবে এটি স্বয়ংক্রিয়ভাবে "তর্ক তালিকায় খুব দীর্ঘ" পরেও আসে নি। কেবল সমস্যাটি হ'ল এটি আমার মেশিনটিকে সত্যই হাতুড়ি দিয়ে অন্য জিনিসগুলি ধীর / ব্যর্থ করে তুলছে। কতক্ষণ যেতে দেওয়া যায় তা নিশ্চিত নয়।

উত্তর:


44

দ্রুত আপনি যা চান তা অগত্যা নয়। আপনি আসলে ধীর চালাতে চাইতে পারেন , সুতরাং মুছে ফেলাটি চলমান অবস্থায় কম সংস্থান গ্রহণ করে।

কমান্ডের অগ্রাধিকার কমিয়ে আনতে সুন্দর (1) ব্যবহার করুন ।

nice find . -name "*.gif" -delete

আই / ও-বাউন্ড প্রক্রিয়াগুলির জন্য দুর্দান্ত (1) পর্যাপ্ত নাও হতে পারে। লিনাক্সের শিডিয়ুলারটি কেবল সিপিইউ নয়, আই / ও-কে বিবেচনায় নেয়, তবে আপনি I / O অগ্রাধিকারের উপর আরও ভাল নিয়ন্ত্রণ পেতে চাইতে পারেন।

ionice -c 2 -n 7 find . -name "*.gif" -delete

যদি এটি না করে তবে আপনি এটি আস্তে আস্তে একটি ঘুমও যোগ করতে পারেন।

find . -name "*.gif" -exec sleep 0.01 \; -delete

3
বাহ ... কয়েক মিলিয়ন ফাইল .1 এস ঘুম সহ ... 864000 ফাইলের জন্য একটি দিনের প্রয়োজন।
glglgl

7
@glglgl ঠিক আছে, স্মার্ট গাধা। আমি সময়সীমা পরিবর্তন করেছি। :
জন কুগেলম্যান

28
ঘুম ভাল পছন্দ হতে পারে, তবে দুর্দান্ত করবে না, যেহেতু এখানে কাজটি আইও আবদ্ধ, সিপিইউ আবদ্ধ নয়; পরিবর্তে আপনি আয়নিস চেষ্টা করতে পারেন। খেয়াল করুন যে ঘুম যদি খুব ছোট হয় তবে এটি অকেজো হবে।
মাত্তেও ইতালি

3
@glglgl: মূল কথাটি হ'ল আপনি যদি সার্ভারে পরিষেবা বিঘ্ন সৃষ্টি করতে না চান তবে আপনাকে আস্তে আস্তে যেতে হবে, এই কোডটি যে সময় ঘুমায় সেই সময়টি সার্ভারকে ডিস্কের সাহায্যে কার্যকরভাবে কাজ করতে দেয়।
মাত্তেও ইতালি

1
sleepসংযোজনের জন্য +1 - ব্যবহার করা সত্ত্বেও সার্ভারগুলিতে আইওতে দম বন্ধ করতে সমস্যা হচ্ছে ionice -c 3। ফাইলগুলি সাফ করার জন্য এটি অবশ্যই সময়ের সাথে যুক্ত হয় (অবশ্যই) তবে আমি অ্যাপ্লিকেশনটি নামিয়ে আনার চেয়ে অপেক্ষা করব ...
ওলা টুভসন

22

যেহেতু আপনি লিনাক্স চালাচ্ছেন এবং এই টাস্কটি সম্ভবত I / O- বাউন্ডেড তাই আমি আপনার আদেশটি নিষ্ক্রিয় I / O সময়সূচীটিকে অগ্রাধিকার দেওয়ার পরামর্শ দিচ্ছি ionice(1):

ionice -c3 find . -name '*.gif' -delete

আপনার আসল কমান্ডের সাথে তুলনা করে, আমি অনুমান করি এটি পাইপটি এড়িয়ে কিছু সিপিইউ চক্রকে এড়াতে পারে xargs


@ ব্রাইম আপনার অর্থ কি? এটি এমন কোনও জায়গা নয় find ... -execযেখানে তা বোঝা যাবে।

ওহ, হ্যাঁ, দুঃখিত। আমার খারাপ। আপনি নিশ্চিত যে দক্ষ, তাই না?
ব্রায়াম

1
ঠিক আছে, find(1)ডকুমেন্টেশন তাই দাবি। :) এবং এটি সুস্পষ্ট হওয়া উচিত যে এর জন্য findএকটি rmআদেশ কমানোর চেয়ে নিজেকে ফাইল সরিয়ে দেওয়া আরও কার্যকর ।

1
আমি একটি ফোল্ডারে একটি প্রোডাকশন সার্ভারে 4 মিলিয়ন ফাইল সহ বেশ কয়েকটি প্রস্তাবিত সংস্করণ চেষ্টা করেছি এবং এটি হ'ল একমাত্র এটি যা সিস্টেমে চট করে না। ionice -c3আইও নিষ্ক্রিয় থাকে যখন প্রিওটিকে কেবল চালনার জন্য হ্রাস করে অন্যথায় এটি নিখুঁত। নোট করুন যেহেতু সন্ধানের -deleteজন্য আদর্শ নয়, আপনি এই কমান্ডটি ব্যবহার করে একই কাজ করতে পারেন (এটির প্রতিক্রিয়া সহ): ionice -c 3 find . -name '*.gif' -exec echo {} \; -exec rm {} \;- ধীরে হলেও গুরুত্বপূর্ণ প্রক্রিয়াগুলির কোনও আইওয়েট নেই।
ক্রিস্টোফার লারকেন

13

না।

এর থেকে দ্রুততর কোনও উপায় নেই, ডিস্কের নরম বিন্যাস থেকে সংযুক্ত করুন। ফাইলগুলি একবারে আরএমকে দেওয়া হয় (কমান্ড লাইনের সীমা অবধি, এটিতেও সেট করা যেতে পারে xargs) যা প্রতিটি ফাইলে আরএম কল করার চেয়ে অনেক ভাল। সুতরাং না, অবশ্যই কোনও দ্রুততর উপায় নেই।

nice(বা reniceচলমান প্রক্রিয়াধীন) ব্যবহার করা কেবল আংশিকভাবে সহায়তা করে, কারণ এটি সিপিইউ সংস্থান নির্ধারণের জন্য , ডিস্কের জন্য নয়! এবং সিপিইউ ব্যবহার খুব কম হবে। এটি একটি লিনাক্স দুর্বলতা - যদি কোনও প্রক্রিয়া ডিস্ককে "খায়" (যেমন এটি দিয়ে অনেক কাজ করে), পুরো মেশিনটি আটকে যায়। রিয়েল টাইম ব্যবহারের জন্য পরিবর্তিত কার্নেল একটি সমাধান হতে পারে।

আমি সার্ভারে যা করব তা হ'ল ম্যানুয়ালি অন্য প্রক্রিয়াগুলি তাদের কাজটি করতে দিন - সার্ভারকে "শ্বাস ফেলা" রাখতে বিরতি অন্তর্ভুক্ত করুন:

find . -name "*.gif" > files
split -l 100 files files.
for F in files.* do
    cat $F | xargs rm
    sleep 5 
done

এটি প্রতি 100 ফাইলের পরে 5 সেকেন্ড অপেক্ষা করবে। এটি অনেক বেশি সময় নেবে তবে আপনার গ্রাহকদের কোনও বিলম্ব লক্ষ্য করা উচিত নয়।


"ফাইলগুলি একবারে আরএমকে দেওয়া হয় (কমান্ড লাইনের সীমা অবধি") শেলটি আদেশ করা হলে rm *, এটি *ফাইলের সমস্ত নামের সাথে লাইনে প্রসারিত হয় এবং এটিতে প্রেরণ করে rm? এটি অবিশ্বাস্যভাবে বোকা কেন? কেন শেল হবে? ওয়াইল্ডকার্ডগুলি প্রসারিত করবেন?

:-D @ জোকার_ভিডি, আপনার নাম অনুসারে আপনি কি রসিকতা করছেন? :-)
টমাস

2
@ জোকার_ভিডি: ১৯ 1970০ বা তার পরের ইউনিক্সের সিদ্ধান্তের সাথে সামঞ্জস্যতা। উইন্ডোজ এটি করে না। সেখানে, প্রোগ্রামগুলি ফাইন্ডনেক্সটফিল / ফাইন্ডনেক্সটফাইলে ওয়াইল্ডকার্ডগুলি পাস করতে পারে, যাতে তারা একবারে ফলাফলগুলি পায়।
এমসাল্টার

@ টমাস এই ক্ষেত্রে নয় Not সত্যি বলতে, আমি তত্ক্ষণাত এই জাতীয় নকশায় 2 টি সমস্যা দেখতে পাচ্ছি: প্রথমত, কমান্ড লাইনটি রাবার নয়; দ্বিতীয়, প্রোগ্রাম বলতে পারে না যদি এটা দিয়ে বলা হয় *বা /*এবং ব্যবহারকারী ধরনের সিদ্ধান্ত একটি সন্দেহ দেব।

1
@ জোকার_ভিডি শেল ওয়াইল্ডকার্ড প্রসারণ সম্পর্কে অনেক ভাল জিনিস রয়েছে। এটি উইন্ডোজ থেকে পৃথক, তবে এই সিদ্ধান্তে উঠবেন না যে এটি অবিশ্বাস্যভাবে বোকা কারণ এটি আপনার ব্যবহারের চেয়ে আলাদা you're আপনি যদি আরও জানতে চান তবে আমি আপনাকে এটি গুগলে উত্সাহিত করব বা প্রাসঙ্গিক স্ট্যাক এক্সচেঞ্জ সাইটে একটি প্রশ্ন পোস্ট করব। এই মন্তব্য অঞ্চলের জন্য এটি একটি বিশাল লেনদেন।
জন কুগেলম্যান মনিকা

5

যদি মুছতে হবে এমন ফাইলগুলির সংখ্যা যদি পিছনে ফেলে রাখা ফাইলগুলির তুলনায় খুব বেশি পরিমাণে থাকে, তবে মুছে ফেলার জন্য ফাইলের বৃক্ষের পদক্ষেপে চলে যাওয়া এবং সেই সমস্ত ফাইল সিস্টেম আপডেট করা সবচেয়ে কার্যকর পদ্ধতির নাও হতে পারে। (আনাড়ি রেফারেন্স-গণনা করা মেমরি পরিচালনা করা সমান, বড় গাছের প্রতিটি বস্তুকে তার রেফারেন্সটি বাদ দেওয়ার জন্য, সমস্ত পদক্ষেপে অযাচিতভাবে আবর্জনায় পরিণত করার পরিবর্তে এবং পরিষ্কার করা যায় এমন জিনিসগুলি দিয়ে ঝাড়ফুঁক করা))

এর অর্থ, গাছের যে অংশগুলি অন্য খণ্ডে রাখতে হবে তা ক্লোন করুন। আসল ভলিউমের একটি নতুন, ফাঁকা ফাইল সিস্টেম পুনরায় তৈরি করুন। ধরে রাখা ফাইলগুলি তাদের মূল পথে ফিরে অনুলিপি করুন। এই অস্পষ্টভাবে অনুরূপ গার্বেজ কালেকশন অনুলিপি

কিছু ডাউনটাইম থাকবে, তবে ক্রমাগত খারাপ কার্য সম্পাদন এবং পরিষেবা ব্যাহত হওয়ার চেয়ে এটি আরও ভাল।

এটি আপনার সিস্টেম এবং পরিস্থিতিটিতে অযৌক্তিক হতে পারে তবে স্পষ্ট ঘটনাগুলি কল্পনা করা সহজ যেখানে এটি যাওয়ার উপায়।

উদাহরণস্বরূপ, ধরুন আপনি একটি ফাইল সিস্টেমে সমস্ত ফাইল মুছতে চেয়েছিলেন । একের পর এক পুনরাবৃত্তি এবং মুছতে মুছতে কী হবে? খালি ফাইল সিস্টেম তৈরি করতে পার্টিশনের শীর্ষে একটি "এমকেএফএস" করুন Just

অথবা ধরুন আপনি অর্ধ ডজন গুরুত্বপূর্ণ ফাইল বাদে সমস্ত ফাইল মুছতে চান? সেখান থেকে আধা ডজন পান এবং উপরে "এমকেএফএস" পান।

অবশেষে কিছু বিরতি-এমনকি পয়েন্ট থাকে যখন পর্যাপ্ত ফাইল থাকতে হয় যেগুলি যে কোনও ডাউনটাইমের মতো অন্যান্য ব্যয়কে বিবেচনায় রেখে পুনরাবৃত্ত মোছার কাজটি সস্তার হয়ে যায়।


4

আপনি চেষ্টা করেছেন:

find . -name "*.gif" -exec rm {} +

শেষে + চিহ্নটি সিঙ্গেল আরএম কমান্ড কার্যকর করার জন্য আরও ফাইল অন্তর্ভুক্ত করার সন্ধান করবে। আরও তথ্যের জন্য এই প্রশ্নটি পরীক্ষা করুন।


এটি প্রিন্ট 0-এর চেয়ে অনেক দ্রুত চালিত করে xargs সমাধান কারণ rm প্রক্রিয়া প্রতিটি ফাইলের জন্য নয় তবে সেগুলির বড় সংখ্যার জন্য আহ্বান করা হয় এবং তাই এটি কম লোডের কারণ হয়।

@JohnKugelman তুমি সঠিক, কিন্তু এটা একটা গনুহ এক্সটেনশন সবসময় নেটিভ সাথে উপলব্ধ হয় খোঁজ কমান্ড।
কোডনোম

ঠিক আছে, আকর্ষণীয়, তবে এটি বেশ নতুন জিনিস (পাশাপাশি -delete) যা সর্বদা সেখানে থাকার দরকার নেই ..
টমাস

তবে এটি অবশ্যই ওপি'র সমাধানের তুলনায় আরও ভাল কিছু এনেছে।
টমাস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.