প্রশ্ন কিভাবে ব্যাকআপ সময় ডিস্ক I / O সীমিত করবেন?


আমি মূলত একটি সহজ "tar zcf" রাতে যে একটি cron আছে।

সার্ভার আছে:

  • 8 কোরে - ইন্টেল (আর) জিয়ন (আর) CPU E5606 @ 2.13GHz
  • 25 গিগাবাইট র্যাম
  • উবুন্টু 12.04.2 এলটিএস
  • হার্ডওয়্যার ২.0 (এলএসআই লজিক / সিম্বিওস লজিক মেগ্রেড এসএএস এসএমসি 2108) দুটি 2.728 টিবি হার্ডড্রাইভ সহ

আপনি পর্যবেক্ষণ স্ক্রিনশট দেখতে পারেন:

http://clip2net.com/s/57YRKP

প্রায় সব সময়, ডিস্ক I / O> 90% -এ যায় এবং অন্যান্য সমস্ত অ্যাপ্লিকেশন (MySQL, Apache) অনেক ধীর করে তোলে।

2 প্রশ্নঃ

  • ব্যাকআপের সময় এত উচ্চ ডিস্ক I / O থাকা স্বাভাবিক?
  • ডিস্ক I / O সীমাবদ্ধ করার একটি উপায় আছে তাই অন্য অ্যাপ্লিকেশন সঠিকভাবে কাজ চালিয়ে যেতে পারে?

ধন্যবাদ!


14
2018-05-27 08:54


উত্স




উত্তর:


সঙ্গে বরং সাধারণ পদ্ধতির পাশাপাশি ionice একটি চমৎকার ডিভাইস ম্যাপার টার্গেট (আইব্যান্ড) রয়েছে যা ব্যান্ডউইথের (ডিএম) ব্লক ডিভাইসে সুনির্দিষ্ট নিয়ন্ত্রণের অনুমতি দেয়। দুর্ভাগ্যবশত এটি স্ট্যান্ডার্ড কার্নেলের অংশ নয়।

উপরন্তু আপনি সম্ভবত দ্বারা আপ tar আপ করতে পারেন

  1. ডিস্ক ক্যাশে ফাইল নামগুলি পড়ছে: find /source/path -printf ""
  2. ডিস্ক ক্যাশে inodes পড়া: find /source/path -perm 777 -printf ""
  3. টরটি তৈরি করা এবং ডিস্ক থেকে বড় ব্লকগুলি পড়ুন এবং লিখুন। mbuffer বা বাফারের সাথে একটি পাইপ ব্যবহার করে (কমপক্ষে 100 MiB RAM সহ): tar ... | mbuffer -m 256M -P 100 -p 1 ...

11
2018-05-27 10:13



কেন ক্যাশে ফাইল নাম / ইনডোড পড়ার সময় ডিস্ক আইও কমে যায়? আমি কেবল গড় সামান্য সময় হ্রাস যখন এটি গড় আইও বৃদ্ধি করতে হবে। - scai
@ এসসিআই এটি এসএসডিগুলির সাথে সাহায্য করে না; আমার সুপারিশ শুধুমাত্র হার্ডডিস্ক কাটনা বোঝায়। কি তাদের সঙ্গে কর্মক্ষমতা হত্যা মাথা আন্দোলন। ফাইল নামগুলি ক্রমাগত ব্লকগুলিতে সংরক্ষণ করা হয়, ইনডোগুলি ক্রমাগত ব্লকগুলিতে সংরক্ষণ করা হয় এবং ফাইল সামগ্রী ক্রমাগত ব্লকগুলিতে সংরক্ষণ করা হয়। আপনি যদি tar tar way করেন তবে আপনি একটি ডিরেক্টরিের ফাইল (এবং সাবডিরেক্টরি) নামগুলি পড়তে, একটি ফাইলের জন্য ইনডোকে অ্যাক্সেস করতে পারেন, তারপর ফাইলটি নিজেই, তারপর পরবর্তী ফাইলের জন্য ইনডোড, তারপর পরবর্তী ফাইলটি নিজেই ... যে একে অপরের পর সব নাম এবং inodes পড়া চেয়ে আরো মাথা আন্দোলন কারণ। - Hauke Laging
@ এসসিআই কর্মক্ষমতা প্রভাব আপনি কি কি উপর নির্ভর করে। এটি সম্পূর্ণ ব্যাকআপগুলির জন্য ছোট (সম্ভবত ফাইল মাপের উপর নির্ভর করে) তবে আমি ডিফারেনশিয়াল ব্যাকআপগুলির জন্য একটি বড় পার্থক্য লক্ষ্য করেছি (যদিও এটির জন্য আমি এটি ব্যবহার করি না তবে এটি একটি সাধারণ প্রভাব হওয়া উচিত)। - Hauke Laging
শুধু সঠিকভাবে বুঝতে আমি নিশ্চিত। 1. এবং 2. এর জন্য, আমাদের কেবল অনুসন্ধান কমান্ডটি কল করতে হবে এবং লিনাক্স স্বয়ংক্রিয়ভাবে এটি ক্যাশে করবে? - acemtp
@ এএসএমটিপি যে সঠিক। find ছাড়া (উদাঃ) -perm যদিও, ফাইল inode প্রবেশ করবে না। কিন্তু যে অপ্টিমাইজেশান ব্যবহার করতে পারবেন find কল। যদি আপনি একই করা find দুইবার কল করুন (মাঝে মাঝে সামান্য সময়), দ্বিতীয়টি সাধারণত সেকেন্ডের মধ্যে (বা কম) শেষ হবে। বিনামূল্যে মেমরির পরিমাণ এবং নির্দিষ্ট পরিমাণে ক্যাশেকৃত ডেটা পরিমাণের উপর ভিত্তি করে তথ্য ক্যাশের বাইরে ফেলে দেওয়া হয়। খুব বেশী পড়া এইভাবে অপারেশন ধীর হতে পারে। যদি আপনি stdin এর মাধ্যমে ফাইলের নামের সাথে ব্যাকআপ প্রোগ্রামটি ফিড করতে পারেন তবে আপনি ব্লকগুলি পড়ার দ্বারা এটি আটকান করতে পারেন। 100 ফাইল। - Hauke Laging


এটি ব্যাকআপগুলির সময় উচ্চ I / O দেখতে প্রত্যাশিত কারণ তারা সাধারণত বড় ফাইলগুলির সাথে বড় ফাইলের গাছগুলি তৈরি করে। তুমি ব্যবহার করতে পার ionice ক্লাস এবং স্তরের সাথে লিনাক্সে I / O কাজের অগ্রাধিকার দিতে। আইআইআরসি, ক্লাস 2, লেভেল 7 সর্বনিম্ন, অ starving স্তর যা এটি অন্যান্য আই / ও লোড এবং ব্যবহারকারীদের কার্যত অদৃশ্য করতে হবে। দেখ man ionice ব্যবহারের জন্য এবং বিস্তারিত।


13
2018-05-27 08:58





আমি ditching tar এবং rsync সঙ্গে যেতে সুপারিশ করবে (Dogsbody দ্বারা উল্লিখিত)। আমি ব্যাকআপপিসিটি আমার উইন্ডোজ এবং লিনাক্স সিস্টেমে ব্যাকআপ ফাইলগুলির জন্য ব্যবহার করি এবং এটি tar এবং rsync ব্যবহার করে সমর্থন করে এবং স্বয়ংক্রিয়ভাবে আপনার জন্য হার্ড লিঙ্কিং যত্ন নেয় এবং সেইসাথে একটি চমৎকার ওয়েব ইন্টারফেস সরবরাহ করে।

http://backuppc.sourceforge.net/


1
2018-06-05 01:44





অন্যদের উত্তর দিয়েছেন, হ্যাঁ এটা স্বাভাবিক, এবং ionice এটি আপনার সিস্টেমকে প্রভাবিত করে না এমন একটি ভাল জেনেরিক উপায়।

আমি মানুষ দেখেছি কতবার tar তারা যদিও প্রয়োজন না যখন জিনিস আপ। যদি আপনি যে অনুলিপিটি অনুলিপি করছেন তার কোনও শতাংশ শেষ কপি থেকে পরিবর্তিত হয় না তবে আমি প্রস্তাব দেওয়ার প্রস্তাব দিই rsync একটি চেষ্টা.

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

আপনি এটি চালানোর জন্য প্রতিটি সময় পৃথক কপি / ব্যাকআপ চান তবে সবচেয়ে শক্তিশালী বিকল্প -link-dest যা আপনাকে পূর্ববর্তী ব্যাকআপে অপরিবর্তিত ফাইলগুলিকে হার্ড লিঙ্ক করার অনুমতি দেয়। এটি ব্যাকআপ সার্ভারে প্রচুর পরিমাণে স্থান সংরক্ষণ করে। উদাহরণস্বরূপ আমি ব্যাকআপ একটি মেশিন (ফ্রেড), ফ্রেড একটি 20 গিগাবাইট এইচডি আছে এবং আমি ব্যাক আপ / সম্পূর্ণ ড্রাইভ বাদ / proc এবং / dev। আমি এখন আমার ব্যাকআপ সার্ভারে একটি 20 গিগাবাইট ডিরেক্টরি আছে। পরের দিন আমি ব্যাকআপ ফ্রেড আবার এবং -link-dest গতকাল ব্যাকআপ। Rsync দূরবর্তী ফাইলগুলিকে স্থানীয় অনুলিপি দিয়ে তুলনা করে এবং যদি ঠিক একইভাবে তাদের স্থানান্তরিত করতে বিরত না হয় তবে নতুন ফাইলটি হার্ডওয়ার ফাইলটিকে Yesterdays ফাইলে লিঙ্ক করবে। পরিবর্তিত যে কোনও ফাইলগুলি একটি তাজা অনুলিপি করা হয় (অথবা সম্ভব হলে Yesterdays ব্যাকআপ ব্যবহার করে আংশিকভাবে অনুলিপি করা হয়েছে)। গতকাল থেকে কেবলমাত্র 100 এমবি ফাইল পরিবর্তিত হলে আমার কাছে ২0 গিগাবাইট ফাইলের সাথে দুটি ডিরেক্টরি রয়েছে কিন্তু ব্যাকআপ সার্ভারে কেবলমাত্র ২0.1 গিগাবাইট স্থান রয়েছে!

আমি সাহায্য এবং এখনও আপনার প্রশ্নের উত্তর আশা করি।


0
2018-05-29 09:14