ফাইল স্থানান্তরের সময় ডিস্ক I/O-এর কারণে OOM কিলার

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

কী ঘটেছিল

আমার বর্তমান পরিবেশটি কিছুটা বিশেষ, বা বরং, মেমরির ক্ষমতা 16GB + 8GB, যা একটি অদ্ভুত সমন্বয়, তবে অনুগ্রহ করে বুঝবেন যে আমি এটি অবশিষ্ট অংশ দিয়ে তৈরি করেছি।

ব্যাপারটি হল, 24GB RAM সহ, যা এখন সাধারণ হতে পারে, তবে ব্যক্তিগতভাবে এটি বেশ সমৃদ্ধ একটি অবস্থা, তাই আমি ভেবেছিলাম OOM ঘটবে না, কিন্তু লিনাক্স কার্নেল থেকে তিরস্কারের মতো একটি OOM ঘটেছে।

অ্যাপ্লিকেশন যেমন Apache, php-fpm, Redis ইত্যাদি, তাদের প্রত্যেকের দ্বারা বরাদ্দকৃত মেমরি নগণ্য, কিন্তু...

ফাইল স্থানান্তর নিয়ে সমস্যা

এটি ঘটেছিল যখন আমি আমার বাবা-মায়ের বাড়িতে থাকা হোম সার্ভার থেকে scp ব্যবহার করে ফাইল আনার চেষ্টা করছিলাম, অথবা যখন আমি aria2c ব্যবহার করে 2TB HDD-তে একবারে ছবি সংরক্ষণ করছিলাম।
এখন, কেন শুধুমাত্র এই লেখার প্রক্রিয়াতেই OOM ঘটে? কারণ ফাইলগুলি প্রথমে মেমরিতে গ্রহণ করা হয় এবং তারপরে স্টোরেজ এলাকায় লেখা হয়। দ্রুত প্রক্রিয়াকরণের জন্য, সেগুলিকে ক্যাশে হিসাবে মেমরি দ্বারা সাময়িকভাবে গ্রহণ করা প্রয়োজন।

মনে হচ্ছে scp -r ব্যবহার করে শত শত GB আকারের ফাইল, বিশেষ করে যদি সেই ফাইলগুলিতে এলোমেলো I/O অপারেশন জড়িত থাকে, তবে তা সত্যিই প্রচুর সংস্থান ব্যবহার করে।
এবং যেহেতু এটি প্রতি-প্রক্রিয়া মেমরি ব্যবহার হিসাবে গণ্য হয় না, তাই top দিয়ে পরীক্ষা করেও একটি একক প্রক্রিয়ায় এটি নিশ্চিত করা যায় না; এটি সম্পূর্ণরূপে লিনাক্স কার্নেল-সম্পর্কিত একটি সমস্যা, যা চিহ্নিত করা বেশ কঠিন করে তোলে।

সহজ কথায়, মনে হচ্ছে I/O অপেক্ষার কারণে মেমরিতে সাময়িকভাবে সংরক্ষিত ডেটার পরিমাণ লেখার প্রক্রিয়ার সাথে তাল মেলাতে পারে না, যার ফলে ধীরে ধীরে সংস্থান ফুরিয়ে যায়।

পরিবর্তনযোগ্য কার্নেল প্যারামিটার

কার্নেল যা করতে পারে তার মধ্যে, কতটুকু ক্যাশে করতে হবে তা কনফিগার করা সম্ভব বলে মনে হয়, এবং আমি এটি সামঞ্জস্য করার চেষ্টা করেছি, তবে খুব বেশি প্রভাব অনুভব করিনি।
2.2. VFS টিউনিং বিকল্প: গবেষণা এবং পরীক্ষা Red Hat Product Documentation
লিনাক্স পেজ ক্যাশে সেটিংস পরিবর্তন করে রাইট I/O টিউনিংয়ের নোট- YOMON8.NET

ঘটনাটি এই ব্যক্তির অভিজ্ঞতার অনুরূপ।
OOM Killer invoked due to slow disk I/O - #17 by Whis-key - troubleshooting - Storj Community Forum (official)
অনেক দিন পর Storj শব্দটি দেখলাম... যদিও আমার ফ্রি টিয়ার আমার অজান্তেই মুছে ফেলা হয়েছিল...

শুধুমাত্র একটি HDD-তে লেখার কারণে মেমরি ফুরিয়ে যাওয়া নিয়ে আমাকে ভাবতে হবে, এটা অপ্রত্যাশিত ছিল...
মেমরি সম্পর্কে একটি সাধারণ উক্তি আছে: "লিনাক্স RAM সম্পর্কে আশাবাদী, উইন্ডোজ হতাশাবাদী।" এই অংশটিও এর সাথে সম্পর্কিত। তবে, মেমরির সম্পূর্ণ ব্যবহার করে আরও কার্যকর কর্মক্ষমতা অর্জনের উদ্দেশ্যটি আমি বুঝতে পারি, কিন্তু I/O অপেক্ষার কারণে সৃষ্ট এই সমস্যাটি সমাধান করতে আমি সত্যিই কিছু করতে চাই।