Linux VPS: পরিবেশ যাচাই, তারপর লোড মাপুন
Linux VPS বেছে নেওয়ার আগে অ্যাপের চাহিদা লিখুন, তারপর একই কাজ দিয়ে সম্ভাব্য কনফিগারেশন পরীক্ষা করুন। এখানে সামঞ্জস্য, রিসোর্স ব্যবহার ও খরচ যাচাইয়ের পদ্ধতি আছে; কোনো প্রদানকারীর র্যাঙ্কিং বা বানানো benchmark নেই।
VPSuntu · হালনাগাদ · পড়তে প্রায় 4 মিনিট
এই নির্দেশনায়
একটি নির্দিষ্ট workload ঠিক করুন
ওয়েব সার্ভার, runtime, database, cache এবং background worker এক VM-এর CPU ও RAM ভাগ করে। ডেটা import, ছবি প্রক্রিয়াকরণ ও ব্যাকআপ একসঙ্গে চললে সাধারণ browsing-এর চেয়ে বেশি চাপ পড়তে পারে। এটি শেখার, staging নাকি গ্রাহকের পরিবেশ এবং কতক্ষণ বন্ধ থাকা গ্রহণযোগ্য, লিখে রাখুন।
Ubuntu ব্যবহার করলে image ও প্যাকেজের সামঞ্জস্য যাচাই করুন। অ্যাপ ছাড়াও extension, container image, monitoring ও backup agent-এর আর্কিটেকচার সমর্থন দরকার। শুধু হোমপেজ খোলা পুরো অ্যাপের পরীক্ষা নয়।
একটি ছোট dynamic catalogue-এ Nginx, একটি app service, PostgreSQL ও নির্ধারিত import থাকলে 2 vCPU এবং 4 GB RAM দিয়ে পরীক্ষা শুরু করা যায়। এটি পরীক্ষিত visitor capacity নয়। Staging-এ প্রতিনিধিত্বমূলক ডেটা ব্যবহার করুন, অপ্রয়োজনীয় ব্যক্তিগত গ্রাহক-তথ্য নয়।
একই শর্তে Linux VPS সার্ভার তুলনা করুন
প্রতিটি প্রার্থী VM-এ একই app build, database copy, cache settings ও worker count রাখুন। Region, OS release এবং architecture লিখুন। কাছের database বা ভিন্ন সফটওয়্যারের সুবিধাকে যেন হার্ডওয়্যারের সুবিধা মনে না হয়।
ছোট পর্দায় সব কলাম দেখতে টেবিলটি পাশে স্ক্রল করুন।
| যা লিখবেন | কেন দরকার |
|---|---|
| CPU allocation ও fair-use | Shared, dedicated এবং burstable CPU-এর সীমা এক নয় |
| RAM ও swap | সব service একই memory budget ব্যবহার করে |
| Disk capacity ও I/O | ফাঁকা জায়গা এবং দ্রুত response আলাদা বিষয় |
| Region ও dependency | দূরের database request ধীর করতে পারে |
| Resize ও restore | পরিবর্তনে downtime লাগতে পারে; disk ছোট করা নাও যেতে পারে |
| Billing unit ও add-on | এক VM price হলেও মোট বিল আলাদা হতে পারে |
দীর্ঘ সময়ের workload অনুমোদিত কি না নিশ্চিত করুন। vCPU সংখ্যা sustained performance প্রমাণ করে না; NVMe লেখা I/O quota বলে না। সাময়িক upgrade-এর আগে আবার ছোট configuration-এ ফেরা যায় কি না দেখুন।
লোড চলার সময় রিসোর্স মাপুন
Ubuntu-তে iostat-এর জন্য sysstat ব্যবহার হয়। App workload চলার সময় sampling command আলাদা terminal-এ চালান। Idle অবস্থায় ছোট নমুনা শুধু শুরুর reference।
free -h
df -h /
sudo apt update
sudo apt install sysstat
vmstat 1 11
iostat -xz -y 1 10vmstat-এর প্রথম activity report boot থেকে গড় দেখায়; পরের এক সেকেন্ডের sample ব্যবহার করুন। iostat-এর -y প্রথম cumulative report বাদ দেয়। free-তে available দেখুন: Linux cache-এর কিছু অংশ ছাড়তে পারে, তাই কম free মানেই RAM শেষ নয়।
এই static সাইটের origin-এ 24 September 2026-এর একটি পর্যবেক্ষণে এক logical CPU ও 957 MiB memory দেখা যায়। Free ছিল 59 MiB, available 358 MiB; control panel ও অন্য service-ও এতে ছিল। এটি দুই memory মানের পার্থক্যের উদাহরণ, load test নয়।
সময় ও scenario-সহ ফল রাখুন। Import এবং backup-এর সময় disk বৃদ্ধি দেখুন। Database অন্য volume-এ থাকলে সেটিও মাপুন; df -h / শুধু root filesystem দেখায়।
ব্যবহারকারীর আসল কাজ পরীক্ষা করুন
নিজের staging-এ browsing, search, login ও একটি স্বাভাবিক write operation চালান। Cache থাকা ও না থাকা request এবং background job অন্তর্ভুক্ত করুন। ফল দেখার আগেই গ্রহণযোগ্য response time ও error rate ঠিক করুন।
ব্যবহারকারীদের কাছাকাছি একটি client থেকে HTTP status, প্রথম byte আসার সময় ও মোট সময় সেকেন্ডে মাপতে পারেন। নিজের staging hostname ও path বসান।
curl -sS -o /dev/null --max-time 30 -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://app.example.com/catalogueএকটি curl request concurrent load মাপে না। আলাদা client দিয়ে একই workflow পুনরাবৃত্তি করুন; request rate, concurrency, duration, dataset ও cache state লিখুন। Error এবং 95th-percentile response time তুলনা করুন—যে সময়ের নিচে 95% মাপা request শেষ হয়। একই সময়ে VM-এর ব্যবহার দেখুন।
Upgrade-এর আগে bottleneck খুঁজুন
ছোট পর্দায় সব কলাম দেখতে টেবিলটি পাশে স্ক্রল করুন।
| একই workload-এ লক্ষণ | যা পরীক্ষা করবেন |
|---|---|
| Available কম, swap-in/out চলমান | Worker count, database memory এবং RAM |
| CPU ব্যস্ত, runnable queue বাড়ছে | ব্যয়বহুল code path, concurrency ও CPU allocation |
| বারবার বেশি steal time | Host scheduling বা plan limit |
| Disk await ও request time বাড়ছে | Database query, I/O queue ও storage allowance |
| Local দ্রুত, বাইরে ধীর | Region, DNS, TLS এবং network path |
এগুলো তদন্তের সূত্র, স্বয়ংক্রিয় upgrade rule নয়। Swap-এ পুরোনো নিষ্ক্রিয় page থাকতে পারে; চলমান activity বেশি গুরুত্বপূর্ণ। Await-এর মধ্যে queue ও service time দুটোই থাকে। Database lock CPU বা RAM শেষ না করেও request আটকে দেয়। App log-এর সঙ্গে মিলিয়ে একবারে একটি বড় পরিবর্তন পরীক্ষা করুন।
সম্পূর্ণ খরচ ও recovery বিবেচনা করুন
Linux VPS হোস্টিং তুলনায় VM-এর সঙ্গে IP, traffic, backup storage ও administration ধরুন। মাসিক খরচের উদাহরণ অঙ্ক বোঝায়, চলতি quote নয়। Email পাঠালে provider-এর SMTP restriction দেখুন; guest firewall খোলা provider-level block সরায় না।
Recovery console খুঁজুন এবং স্বাধীন কপি রিস্টোর করুন। Update ও incident-এর দায়িত্ব ঠিক করুন। সবচেয়ে কম খরচের সেই candidate নিন, যা আপনার workload, growth ও recovery পরীক্ষায় উত্তীর্ণ। শেখার কাজে ফ্রি Linux VPS-এর কোটা মিলিয়ে দেখতে পারেন; সেখানেও architecture, region ও memory-এর সীমা আছে।
প্রশ্ন ও উত্তর
2 vCPU-তে কত visitor চলবে?
অ্যাপ ও workload না জেনে নির্ভরযোগ্য সংখ্যা বলা যায় না। Cached static response এবং database write-এর খরচ আলাদা। নিজের workflow ও concurrency মেপে সিদ্ধান্ত নিন।
Managed hosting কি দরকার?
অন্তর্ভুক্ত কাজের সঙ্গে আপনার দলের সক্ষমতা তুলনা করুন। Security update, app troubleshooting, backup ও restore সহায়তার পরিধি আলাদা করে জেনে নিন।