Skip to content
VDS · মনিটরিং ও পারফরম্যান্স

মেমোরি এবং swap: কখন উচ্চতর টিয়ারে যাওয়ার সময়

স্বাভাবিক মেমোরি ব্যবহার এবং ঘাটতির মধ্যে কীভাবে পার্থক্য করবেন, ছোট টিয়ারে swap কেন প্রয়োজন, এবং কোন লক্ষণে উচ্চতর প্ল্যানে যাওয়ার সিদ্ধান্ত নেবেন।

আপডেট: ২৩ আগস্ট, ২০২৬

“2 GB-এর মধ্যে 120 MB ফ্রি” — এই লেখা নতুনদের ভয় দেখায়, আর Linux-এ এর কোনো মানেই নেই: সিস্টেম সচেতনভাবেই ফাইল ক্যাশের জন্য ফ্রি মেমোরি ব্যবহার করে, কারণ খালি মেমোরি অকাজের। আসল চিত্র দেয় অন্য একটি কলাম।

free সঠিকভাবে পড়া

free -h
#               total  used   free  shared  buff/cache  available
# Mem:          1.9Gi  742Mi  102Mi    18Mi       1.1Gi      1.0Gi
# Swap:         1.0Gi  126Mi  898Mi

available দেখুন — ক্যাশ সরিয়ে একটি অ্যাপ্লিকেশন কত মেমোরি পেতে পারে। যতক্ষণ এই মান শূন্যের অনেক উপরে থাকে, মেশিন ঠিক আছে। এই অর্থে free অকাজের।

সতর্কতার লক্ষণ:

  • available মোট total-এর 10%-এর কম;
  • Swap used বাড়ছে এবং ছাড়া হচ্ছে না;
  • vmstat 2-এ si/so শূন্য নয় এবং স্থির — সিস্টেম অবিরাম ডিস্কে পেজিং করছে।

কী ঠিক কী মেমোরি খাচ্ছে:

ps aux --sort=-%mem | head -10
smem -tk -s uss 2>/dev/null | tail -10

Swap: দরকার কি না

যেকোনো টিয়ারে অল্প swap কাজে লাগে: এটি সিস্টেমকে অনেক দিন অব্যবহৃত পেজ সরানোর জায়গা দেয় এবং ছোট একটি স্পাইকের সময় প্রসেস সঙ্গে সঙ্গে মরে যাওয়া থেকে রক্ষা করে। এটি মেমোরির বিকল্প নয় — ডিস্ক শতগুণ ধীর।

2 GB-এর একটি swap ফাইল তৈরি করুন:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

swap করার সিস্টেমের আগ্রহ কমান:

sysctl -w vm.swappiness=10
echo 'vm.swappiness=10' > /etc/sysctl.d/99-swap.conf

মনে রাখুন, swap ফাইল টিয়ারের ডিস্কে জায়গা নেয় (VDS-1-এ 40 GB), আর এতে লেখা ডিস্ক স্পিডের ব্যান্ডউইথ খায়, দেখুন ডিস্ক লোড।

লিক, নাকি মেমোরি কম

প্যানেলের /hosting/vds/m/<id>-এ সাপ্তাহিক স্কেলে মেমোরি গ্রাফ একটিকে অন্যটি থেকে আলাদা করতে সাহায্য করে:

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

প্ল্যান বদলানোর আগে স্পষ্ট বিষয়গুলো ঠিক করুন: journal-এর জন্য SystemMaxUse সীমিত করুন, ডেটাবেসের জন্য যুক্তিসঙ্গত লিমিট দিন (MySQL ডিফল্টে বেশ অনেক চায়), অব্যবহৃত সার্ভিস সরান (systemctl list-units --type=service --state=running), এবং PHP-FPM ও Gunicorn-এর worker সংখ্যা কমান।

কখন আপগ্রেড করবেন

পরিষ্কারের পরও যদি available সপ্তাহের পর সপ্তাহ শূন্যের কাছে থাকে, swap অবিরাম ব্যবহৃত হয়, আর আপনার পুরো অ্যাপ্লিকেশনটাই দরকার হয়, তাহলে উঁচু টিয়ার নিন। মেমোরি সিরিজ ধরে বাড়ে 2, 4, 8, 16, 24, 32 GB। আপগ্রেড শুধু উপরের দিকে, বাকি দিনগুলোর জন্য অতিরিক্ত পেমেন্টসহ; ডাউনগ্রেড নেই: ডিস্ক ছোট হয় না। বিস্তারিত জানতে দেখুন প্ল্যান আপগ্রেড নিবন্ধটি।

সাধারণ ভুল

  • swap সম্পূর্ণ বন্ধ করা। স্পাইকের সময় সিস্টেম এক মিনিট টিকে থাকার বদলে প্রসেসটি মেরে ফেলবে।
  • ডিস্কের সমান swap বানানো। মেশিন মরবে না, কিন্তু ঘণ্টার পর ঘণ্টা হামাগুড়ি দেবে, যা দ্রুত ক্র্যাশের চেয়েও খারাপ।
  • htop-এ VIRT দেখা। JVM, PostgreSQL ও Node-এর ভার্চুয়াল সাইজ বিশাল এবং খরচ প্রতিফলিত করে না। RES দেখুন।

আউটেজের পরে নয়, আগে মেমোরি পরীক্ষা করুন। থ্রেশহোল্ড অ্যালার্ট সেট করুন — সহজ রেসিপি আছে সাইট ডাউনটাইম অ্যালার্ট নিবন্ধে।