سرور خوب ایران چه ویژگی‌هایی دارد؟ ۹ تست عملی سنجش کیفیت سرور

یک سرور خوب ایران را نمی‌شود از روی متن تبلیغ تشخیص داد؛ باید اندازه‌اش گرفت. در این راهنما ۹ تست عملی را با دستور واقعی مرور می‌کنیم — از steal time و نرخ واقعی دیسک NVMe تا کیفیت شبکه‌ی داخلی و سلامت آی‌پی — و برای هرکدام می‌گوییم عدد سالم چقدر است، تا اورسل را پیش از هر تعهد بلندمدت مستند کنید.

سرور خوب ایران یعنی چه؟ تعریفی که بشود اندازه گرفت

سرور خوب ایران سروری است که منابع فروخته‌شده را واقعاً در اختیار شما بگذارد، زیر بار همسایه‌ها افت نکند و مسیر شبکه‌اش تا کاربر داخلی کوتاه و پایدار بماند. هر سه بخش این تعریف با دستور قابل سنجش است؛ صفت‌هایی مثل «پرسرعت» و «حرفه‌ای» عدد ندارند و قابل راستی‌آزمایی نیستند.

ریشه‌ی تقریباً همه‌ی تجربه‌های بد اورسل است: ارائه‌دهنده روی یک سرور فیزیکی بیش از ظرفیتش مشتری نشانده و نتیجه‌اش «کندی‌های بی‌دلیل» است — کوئری‌ای که گاهی ۲۰ میلی‌ثانیه است و گاهی ۲ ثانیه.

هشت تست از نُه تست این مقاله در کمتر از دو ساعت انجام می‌شوند و فقط تست پایداری ۴۸ ساعت طول می‌کشد. با مدل صورتحساب ساعتی سرور ابری می‌توانید همین چند ساعت را بخرید و اگر سرور قبول نشد حذفش کنید؛ هزینه‌ی همین دوره‌ی ارزیابی و اینکه از چند ساعت به بعد دیگر به‌صرفه نیست، در راهنمای هزینه و نقطه‌ی سربه‌سر سرور ساعتی با فرمول آمده است.

برای تست سرور ایران چه ابزارهایی لازم است؟

به هفت ابزار استاندارد نیاز دارید: sysstat برای steal time، fio برای دیسک، sysbench برای پایداری پردازنده، iperf3 برای پهنای باند، mtr برای مسیر شبکه، dig برای rDNS و whois برای سابقه‌ی آی‌پی. همه در مخازن رسمی توزیع‌ها هستند و نصبشان کمتر از یک دقیقه طول می‌کشد.

# Ubuntu / Debian
sudo apt update
sudo apt install -y sysstat fio iperf3 mtr-tiny sysbench whois
sudo apt install -y bind9-dnsutils || sudo apt install -y dnsutils   # نام بسته در نسخه‌های قدیمی‌تر

# AlmaLinux / Rocky
sudo dnf install -y epel-release
sudo dnf install -y sysstat fio iperf3 mtr bind-utils sysbench whois

تست را روی سرور تازه‌تحویل و بدون بار انجام دهید و هر آزمون را دو بار تکرار کنید: ساعت خلوت و ساعت اوج. تفاوت این دو نوبت، مهم‌ترین عدد ماجراست.

تست ۱: پایداری CPU و steal time — فشار میزبان را اندازه بگیرید

steal time درصد زمانی است که پردازنده‌ی مجازی شما آماده‌ی اجرا بوده اما هایپروایزر آن را به ماشین دیگری داده است. مستقیم‌ترین شاخص اورسل CPU همین است و در ستون st خروجی vmstat دیده می‌شود. عدد سالم، صفر تا یک درصد است.

vmstat 5 120
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  1  0      0 1583220  61240 402188    0    0   509    77    6    4   3  2 95  0  0   <- این خط را نادیده بگیرید
#  0  0      0 1583688  61240 402196    0    0     0     0  312  598   2  1 97  0  0

خط اولِ خروجی vmstat میانگین از لحظه‌ی بوت است، نه وضعیت لحظه‌ای؛ آن را نادیده بگیرید. فاصله‌ی ۵ ثانیه و ۱۲۰ نمونه یعنی ۱۰ دقیقه رصد پیوسته — بازه‌ای که برای قضاوت درباره‌ی steal لازم است.

mpstat -P ALL 2 10
# 09:28:45 PM  CPU   %usr  %nice   %sys %iowait   %irq  %soft %steal %guest %gnice  %idle
# 09:28:47 PM  all   1.01   0.00   0.25    0.00   0.00   0.00   0.00   0.00   0.00  98.74
# 09:28:47 PM    0   0.00   0.00   0.00    0.00   0.00   0.00   0.00   0.00   0.00 100.00

mpstat همان عدد را هسته‌به‌هسته می‌شکند؛ ستون موردنظر %steal و ردیف all میانگین هسته‌هاست. تفسیر عملی: st پایدار زیر ۱ درصد یعنی میزبان جا دارد و جهش‌های کوتاه تا ۵ درصد نگران‌کننده نیستند؛ آنچه باید یادداشت کنید مدت ماندگاری عدد است، نه اوج لحظه‌ای. ستون r اگر پیوسته بزرگ‌تر از تعداد vCPUها باشد یعنی کارها منتظر پردازنده‌اند.

پراکندگی نتیجه‌ی sysbench مهم‌تر از عدد مطلق است

for i in 1 2 3 4 5; do
  sysbench cpu --cpu-max-prime=20000 --threads=1 run | grep "events per second"
done

عدد مطلق به نسل پردازنده بستگی دارد؛ چیزی که باید ببینید پراکندگی است. اگر پنج اجرا در محدوده‌ی چند درصد از هم باشند، سهم CPU شما واقعی است؛ اگر یکی ۳۰ درصد پایین‌تر بیفتد، همان لحظه هسته از دست شما گرفته شده. کرنل‌های جدید شاخص مکملی هم دارند:

cat /proc/pressure/cpu
# some avg10=0.12 avg60=0.18 avg300=0.15 total=94812733

some avg10 یعنی در ۱۰ ثانیه‌ی گذشته چند درصد زمان دست‌کم یک پروسه منتظر CPU مانده و زیر ۱۰ سالم است. PSI فشار را از دید زمان‌بند خودِ ماشین می‌سنجد و steal میزبان را نمی‌بیند: st بالا با PSI پایین یعنی فشار از میزبان است، و PSI بالا با st صفر یعنی بار خودتان بیش از ظرفیت vCPUهاست.

sudo grubby --update-kernel=ALL --args="psi=1"
sudo reboot

تست ۲: نرخ واقعی دیسک NVMe با fio — و چرا dd گمراه‌کننده است

مهم‌ترین عدد دیسک برای وب و دیتابیس، پهنای باند ترتیبی نیست؛ IOPS خواندن و نوشتن تصادفی ۴ کیلوبایتی و تأخیر آن است. دیتابیس شما هزاران بلاک کوچک پراکنده می‌خواند و همین‌جاست که NVMe واقعی از دیسک اشتراکیِ خسته جدا می‌شود. ابزار درست fio با پرچم --direct=1 است که کش صفحه‌ی سیستم‌عامل را دور می‌زند:

fio --name=randread --filename=/root/fiotest --rw=randread --bs=4k \
    --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
    --size=2G --runtime=60 --time_based --group_reporting

همان تست را برای نوشتن تکرار کنید، چون بسیاری از استوریج‌ها فقط در خواندن خوب‌اند:

fio --name=randwrite --filename=/root/fiotest --rw=randwrite --bs=4k \
    --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
    --size=2G --runtime=60 --time_based --group_reporting

# تأخیر تک‌درخواستی — نزدیک‌ترین عدد به حس واقعی دیتابیس
fio --name=lat --filename=/root/fiotest --rw=randread --bs=4k \
    --ioengine=libaio --direct=1 --iodepth=1 --size=2G --runtime=30 \
    --time_based --group_reporting

rm -f /root/fiotest

تفسیر خروجی fio: IOPS، تأخیر تک‌درخواستی و صدک ۹۹

در خروجی دنبال سه چیز بگردید: IOPS، خط clat percentiles و صدک ۹۹. مقیاس قضاوت را همین‌جا ثابت کنید — این آستانه‌ها برای یک ماشین مجازیِ اشتراکی با --iodepth=32 نوشته شده‌اند، نه برای دیسک خام روی سخت‌افزار که ارقامش چند برابر است: زیر ۵ هزار IOPS مردود؛ ۵ تا ۲۰ هزار مشکوک و احتمالاً NVMe اشتراکیِ پرفشار یا سقف مصنوعی؛ بالای ۲۰ هزار قابل قبول؛ بالای ۵۰ هزار NVMe واقعیِ کم‌فشار. سقف‌گذاشتن روی IOPS هر ماشین خودش نشانه‌ی بدی نیست و تقریباً همه‌ی ارائه‌دهندگان جدی این کار را می‌کنند؛ آنچه باید ردش کنید سقفِ نامعلوم و متغیر است. پس همین تست را سه نوبت در ساعت‌های مختلف بگیرید: اگر هر سه بار عدد تکرار شد، سقف مهندسی‌شده است و اگر هر بار چیز دیگری داد، دارید با همسایه‌ها می‌جنگید.

تأخیر تک‌درخواستی هم باید چند صد میکروثانیه بماند؛ اگر به چند میلی‌ثانیه رسید، آنچه فروخته‌اند یا NVMe نیست یا چنان تقسیم شده که فرقی نمی‌کند. صدک ۹۹ خیلی بزرگ‌تر از میانه یعنی صف.

چهار لایه‌ی کیفیت یک سرور خوب ایران و ابزار سنجش هرکدام

کیفیت سرور یک عدد واحد نیست؛ چهار لایه‌ی مستقل است که هرکدام جداگانه خراب می‌شود: سخت‌افزار و سهم واقعی شما از آن، مجازی‌سازی، شبکه‌ی داخل کشور، و خودِ ارائه‌دهنده. جدول زیر از نشانه تا عدد سالم را جمع کرده است.

تست ۳: مجازی‌سازی واقعاً KVM است یا کانتینر؟

خیلی از سرویس‌هایی که «سرور مجازی» فروخته می‌شوند در واقع کانتینرند: کرنل مستقل ندارید و ماژول کرنل بارگذاری نمی‌شود. پاسخ سالم دقیقاً kvm است و تفاوتش با qemu را جدی بگیرید: دومی یعنی شتاب سخت‌افزاری فعال نیست.

systemd-detect-virt
# kvm   -> مجازی‌سازی کامل با شتاب سخت‌افزاری
# qemu  -> شبیه‌سازی نرم‌افزاری بدون KVM (کُند)
# lxc / openvz -> کانتینر، نه ماشین مجازی

ls /proc/user_beancounters 2>/dev/null && echo "OpenVZ container"
sudo modprobe dummy && lsmod | grep dummy && sudo modprobe -r dummy   # فقط روی KVM موفق می‌شود
grep -c -E "vmx|svm" /proc/cpuinfo    # صفر یعنی مجازی‌سازی تودرتو ندارید
rpm -q kernel 2>/dev/null || dpkg -l | grep -c '^ii  linux-image'   # آیا بسته‌ی کرنل نصب است؟

وجود /proc/user_beancounters امضای قطعی کانتینرهای OpenVZ است، اما آزمون قطعی‌تر بارگذاری ماژول کرنل است: اگر modprobe dummy با Operation not permitted برگشت، کرنل مال شما نیست و هرچه فروخته‌اند KVM نیست. uname -r چیزی ثابت نمی‌کند، چون در کانتینر هم کرنل میزبان را می‌بینید؛ نشانه‌ی گویاتر، نصب‌بودن بسته‌ی کرنل و ارتقاپذیری آن است. اجرای موفق داکر روی سرور ابری هم سند KVM بودن نیست؛ روی کانتینر تودرتو هم اجرا می‌شود. مفهوم KVM و NVMe را در مقاله‌ی KVM و NVMe به زبان ساده توضیح داده‌ایم؛ آنچه اینجا اضافه می‌شود، آستانه‌ی قبول یا رد است. و اگر قرار است روی همین سرور تونل لایه‌ی سه بالا بیاورید، آزمون ماژول را با modprobe ip_gre هم تکرار کنید — چرایی‌اش در راهنمای انتخاب سرور مناسب تانل آمده است.

تست ۴: رم واقعی، swap و ردّ پای OOM

رم دومین جایی است که اورسل خودش را نشان می‌دهد، اما نه با کندی — با کشته‌شدن ناگهانی سرویس‌ها. اول ببینید چقدر رم تحویل گرفته‌اید و بعد سراغ تاریخچه بروید؛ اگر کرنل پروسه‌ای را برای نجات سیستم کشته باشد، ردش در لاگ مانده است.

free -m
swapon --show
grep -E "MemTotal|MemAvailable" /proc/meminfo
lsmod | grep -i balloon

journalctl -k | grep -iE "out of memory|oom-killer|killed process"
cat /proc/pressure/memory

MemTotal همیشه کمتر از عدد خریداری‌شده است و این طبیعی است: تفاوت گیگابایت با گیبی‌بایت، رزرو کرنل، و روی آلمالینوکس و راکی رزرو crashkernel. روی یک ماشین ۸ گیگابایتی free -m حدود ۷۵۰۰ نشان می‌دهد و جای نگرانی نیست. غیرعادی، اختلاف بیش از ده درصد است — یا تغییر MemTotal در طول روز، یعنی ballooning میزبان.

روی سرور تازه‌تحویل، خروجی جست‌وجوی OOM باید خالی باشد (اگر /proc/pressure/memory نبود، همان نکته‌ی PSI برقرار است). رکورد OOM روی سرور نو یعنی رم واقعی کمتر از فروخته‌شده یا سرور دست‌دوم و پاک‌نشده است. تشخیص کمبود رم از کش را در راهنمای مانیتورینگ سرور لینوکس توضیح داده‌ایم.

تست ۵: کیفیت شبکه‌ی داخل ایران را از هر سه اپراتور بسنجید

سرور ایران را به خاطر شبکه‌اش می‌خرید، پس شبکه را جدی‌تر از همه بسنجید. قاعده‌ی طلایی: تست را از هر سه اپراتور بگیرید — همراه اول، ایرانسل و مخابرات — چون کیفیت پیرینگ هر دیتاسنتر با هر اپراتور متفاوت است و کاربران شما از هر سه می‌آیند.

دستورهای زیر را روی سرور اجرا نکنید؛ باید از سمت کاربر به‌سمت سرور اجرا شوند. ساده‌ترین راه، اتصال لپ‌تاپ به هات‌اسپات گوشی است: یک‌بار با همراه اول، یک‌بار با ایرانسل و یک‌بار روی خط ثابت.

ping -c 100 SERVER_IP | tail -3
# --- 203.0.113.10 ping statistics ---
# 100 packets transmitted, 100 received, 0% packet loss, time 99143ms
# rtt min/avg/max/mdev = 11.4/14.8/38.1/3.2 ms

mtr -rwzc 100 SERVER_IP

سه عدد را ثبت کنید: گم‌شدن بسته باید صفر باشد (حتی ۱ درصدِ پایدار برای TCP گران تمام می‌شود)، mdev روی مسیر داخلی زیر ۱۰ میلی‌ثانیه بماند، و max چند برابر min نشود. همین سه عدد را ساعت ۶ صبح و ساعت ۲۳ بگیرید؛ اختلاف دو نوبت، سند اورسل شبکه است. ریشه‌های تأخیر را در راهنمای کاهش پینگ سرور جدا بررسی کرده‌ایم.

خواندن درست mtr: کدام گم‌شدن بسته واقعی است؟

mtr مسیر را هاپ‌به‌هاپ می‌شکند و نشان می‌دهد پرش تأخیر کجا شروع شده. هشدار مهم: بعضی روترهای میانی به ICMP کم‌اهمیت جواب نمی‌دهند و ستون Loss آن‌ها را قرمز نشان می‌دهد؛ فقط وقتی نگران شوید که گم‌شدن از یک هاپ به بعد تا هاپ آخر ادامه پیدا کند.

تست ۶: پهنای باند واقعی سرور چقدر است؟

پهنای باند واقعی را فقط با iperf3 بین دو نقطه‌ی تحت کنترل خودتان بسنجید، نه با عبارت تبلیغاتی «پورت یک گیگ». یک جریان تکی به سقف پورت نمی‌رسد، پس چند جریان موازی بگیرید و تست را در هر دو جهت تکرار کنید تا سقف نامتقارن آپلود و دانلود معلوم شود.

# پورت 5201 باید باز باشد — Ubuntu/Debian:
sudo ufw allow 5201/tcp
# AlmaLinux/Rocky:
sudo firewall-cmd --add-port=5201/tcp

# روی سرور
iperf3 -s

# از سمت کلاینت یا سرور دوم
iperf3 -c SERVER_IP -t 30 -P 4        # آپلود به سرور
iperf3 -c SERVER_IP -t 30 -P 4 -R     # دانلود از سرور

اگر تست را از اینترنت خانگی می‌گیرید، گلوگاه احتمالاً خط خودتان است. بعد از کار iperf3 -s را با Ctrl+C و پورت را هم ببندید. کلاینت رسمی Ookla (که در مخازن پیش‌فرض نیست) عدد تقریبی می‌دهد ولی جای iperf3 را نمی‌گیرد، چون گلوگاه می‌تواند سرور مقصدِ اسپیدتست باشد. حجم ترافیک ماهانه موضوع راهنمای پهنای باند سرور مجازی است.

تست ۷: سلامت و سابقه‌ی آی‌پی

آی‌پی هم بخشی از چیزی است که یک سرور خوب ایران را می‌سازد و می‌تواند دست‌دوم و سوخته باشد. اگر آی‌پی شما قبلاً برای ارسال هرزنامه استفاده شده، ایمیل‌هایتان به اسپم می‌روند و بعضی سرویس‌ها بلاک‌تان می‌کنند — بدون اینکه تست‌های قبلی چیزی نشان بدهند.

dig -x 203.0.113.10 +short          # رکورد PTR یا همان rDNS
whois 203.0.113.10 | grep -iE "netname|descr|country|org"

سه چیز را چک کنید. اول rDNS: آی‌پی باید PTR داشته باشد و ارائه‌دهنده امکان تغییرش را بدهد؛ بدون آن، ارسال ایمیل از سرور بی‌فایده است. دوم ثبت رنج: خروجی whois باید netname و orgِ روشنی داشته باشد، نه یک بلوک بی‌نام. فیلد country در رکورد RIPE اداری است و محل واقعی سرور را ثابت نمی‌کند؛ آنچه سرویس‌ها می‌بینند پایگاه‌های ژئولوکیشن تجاری است، پس مکان‌یابی آی‌پی را جداگانه چک کنید — اگر با محل دیتاسنتر نخواند، سرویس‌های داخلی دسترسی را رد می‌کنند و آمار سایت کاربر ایرانی را خارجی می‌شمارد. سوم بلاک‌لیست: اگر آی‌پی در فهرست سیاه بود، همان روز اول درخواست تعویض بدهید.

تست ۸: پایداری در طول زمان — سرور بی‌خبر ری‌بوت می‌شود؟

هیچ اسنپ‌شاتی از یک لحظه، پایداری را ثابت نمی‌کند. سرور را دست‌کم ۴۸ ساعت روشن نگه دارید و بعد سراغ تاریخچه‌ی بوت و لاگ کرنل بروید. معیار قبولی ساده است: هر ری‌بوت ثبت‌شده باید کار خودتان باشد و هیچ خطای دیسک یا وقفه‌ی طولانی I/O در dmesg نمانده باشد.

پیش‌نیازش ژورنال ماندگار است؛ وگرنه با هر ری‌بوت لاگ‌ها پاک می‌شوند. روی آلمالینوکس و راکی ساعت اول فعالش کنید:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

uptime -p
journalctl --list-boots | tail -5
last -x reboot | head
journalctl -k -p err -b -1 | tail -20
dmesg -T | grep -iE "I/O error|hung task|clocksource|blk_update_request"

روی ژورنال موقتی، -b -1 همیشه خالی است و خالی‌بودنش نشانه‌ی سلامت نیست؛ در آن حالت به last -x reboot تکیه کنید که از wtmp می‌خواند. ری‌بوت ثبت‌نشده یعنی میزبان کرش کرده یا سرور مهاجرت داده شده. پیام‌های I/O error و blk_update_request ردّ پای استوریج بیمارند، و hung task یعنی یک پروسه دست‌کم ۱۲۰ ثانیه — پیش‌فرض kernel.hung_task_timeout_secs — در خواب غیرقابل‌وقفه گیر کرده؛ یعنی درخواست I/O برنگشته است.

تست ۹: کیفیت خودِ ارائه‌دهنده را هم بسنجید

لایه‌ی چهارم انسانی است و هیچ دستوری آن را اندازه نمی‌گیرد، پس باید عمداً امتحانش کنید.

چهار چیزی که باید قبل از تعهد بلندمدت از ارائه‌دهنده بخواهید

• زمان پاسخ تیکت را عدد کنید، نه حس. دو تیکت فنیِ واقعی بفرستید — مثلاً درخواست تغییر rDNS برای همین آی‌پی — یکی وسط روز کاری و یکی بعد از نیمه‌شب، و فاصله‌ی هرکدام تا اولین پاسخ انسانی را ثبت کنید. عددی که به کارتان می‌آید دومی است؛ خرابی سرور ساعت اداری را انتخاب نمی‌کند.
• شفافیت صورتحساب. باید ریز کسر از کیف پول را ببینید و بفهمید هر مبلغ بابت چه ساعتی و چه منبعی بوده.
• کنسول VNC. این را قبل از نیاز تست کنید: اگر روزی کانفیگ SSH یا فایروال را خراب کنید، کنسول تنها راه بازگشت است.
• بازسازی سیستم‌عامل. یک‌بار نصب مجدد کنید و زمانش را بگیرید؛ نصب چنددقیقه‌ای یعنی هر آزمایش خطرناکی برگشت‌پذیر است.

سابقه‌ی فعالیت هم مهم است؛ مجموعه‌ای که سال‌ها در میزبانی وب اشتراکی کار کرده، معمولاً فرایند پشتیبانی جاافتاده‌تری دارد.

چک‌لیست سنجش سرور خوب ایران: هشت مرحله در یک ساعت، مرحله‌ی نهم در ۴۸ ساعت

ترتیب مراحل عمداً با شماره‌ی تست‌ها یکی نیست و بر پایه‌ی «سریع‌ترین اول» چیده شده است:

1. مجازی‌سازی — تست ۳ (۱ دقیقه): systemd-detect-virt باید kvm بدهد؛ هر خروجی دیگری یعنی همین‌جا تمام است.
2. منابع و رم — تست ۴ (۳ دقیقه): lscpu، free -m و df -h با خریدتان بخواند و journalctl -k | grep -i oom خالی باشد.
3. steal time — تست ۱ (۱۰ دقیقه): vmstat 5 120 و mpstat -P ALL 2 10؛ st زیر ۱٪.
4. پایداری CPU — تست ۱ (۵ دقیقه): پنج اجرای sysbench با پراکندگی چند درصد.
5. دیسک — تست ۲ (۵ دقیقه): سه اجرای fio: خواندن تصادفی، نوشتن تصادفی و تأخیر تک‌درخواستی.
6. شبکه — تست ۵ (۱۰ دقیقه): ping و mtr از سه اپراتور، بدون گم‌شدن بسته.
7. پهنای باند — تست ۶ (۵ دقیقه): iperf3 در هر دو جهت با چند جریان موازی.
8. سلامت آی‌پی — تست ۷ (۵ دقیقه): PTR، whois و فهرست سیاه.
9. پایداری و ارائه‌دهنده — تست ۸ و ۹ (۴۸ ساعت): سرور را روشن بگذارید، تیکت بفرستید، کنسول VNC و نصب مجدد را تست کنید و آخر journalctl --list-boots را ببینید.

سؤالات پرتکرار

سریع‌ترین راه تشخیص یک سرور خوب ایران چیست؟

سه دستور در ده دقیقه: systemd-detect-virt باید kvm برگرداند، vmstat 5 120 باید ستون st را زیر یک درصد نشان بدهد، و یک اجرای fio با --direct=1 باید در خواندن تصادفی ۴ کیلوبایتی از ۲۰ هزار IOPS رد شود. اگر هر سه قبول شدند، لایه‌ی سخت‌افزار و مجازی‌سازی سالم است و تست‌های شبکه و پایداری می‌ارزند.

steal time چقدر باشد یعنی سرور اورسل شده است؟

روی یک سرور سالم، ستون st در vmstat بین صفر تا یک درصد می‌ماند و جهش‌های کوتاه تا پنج درصد طبیعی است. اگر این عدد ده دقیقه‌ی پیوسته بالای پنج درصد بماند یعنی برای در اختیار گرفتن هسته با ماشین‌های همسایه رقابت می‌کنید، و بالای ده درصد یعنی میزبان بیش از ظرفیتش فروخته شده. تست را در ساعت اوج شب هم تکرار کنید.

چرا با dd نمی‌شود سرعت واقعی دیسک NVMe را سنجید؟

چون dd نوشتن ترتیبی را می‌سنجد، نه بار واقعی وب و دیتابیس که خواندن و نوشتن تصادفی بلاک‌های کوچک است. تا وقتی oflag=direct یا conv=fdatasync ندهید عملاً سرعت کش رم را اندازه می‌گیرید، و چون داده‌ی ورودی صفر خالص است، استوریج فشرده‌ساز ممکن است چیزی روی دیسک ننویسد. ابزار درست fio با --direct=1 است.

چرا رم سرور کمتر از مقداری است که خریده‌ام؟

بخشی از این اختلاف طبیعی است: تفاوت گیگابایت با گیبی‌بایت، رزرو کرنل و ساختارهای مدیریت حافظه، و روی خانواده‌ی RHEL رزرو crashkernel. روی یک ماشین ۸ گیگابایتی، free -m حدود ۷۵۰۰ نشان می‌دهد و جای نگرانی نیست؛ اختلاف بیش از ده درصد طبیعی نیست. اگر MemTotal در طول روز تغییر کرد، virtio_balloon دارد رم را پس می‌گیرد. رکورد oom-killer روی سرور نو هم یعنی رم واقعی کمتر از فروخته‌شده است.

پینگ ۶۰ میلی‌ثانیه از اینترنت همراه یعنی سرور بد است؟

لزوماً نه. بخش زیادی از تأخیر روی موبایل در شبکه‌ی رادیویی ساخته می‌شود و ۳۰ تا ۷۰ میلی‌ثانیه برای سرور داخل کشور طبیعی است؛ از خط ثابت همان سرور معمولاً ۵ تا ۳۰ میلی‌ثانیه می‌دهد. آنچه باید نگران‌تان کند گم‌شدن بسته و نوسان بالاست، نه عدد میانگین. اگر mtr نشان داد گم‌شدن از یک هاپ به بعد تا مقصد ادامه دارد، مشکل مسیر است.

قدم بعدی

هیچ متن تبلیغی جای این نُه عدد را نمی‌گیرد. سرور خوب ایران چیزی نیست که از روی جدول مقایسه انتخابش کنید؛ چیزی است که از یک غربال عددی بیرون می‌آید — و ساختن آن غربال یک بعدازظهر وقت می‌برد. پیشنهاد ما ساده است: یک سرور ابری ساعتی در مهران هاست بسازید — تحویل معمولاً زیر ۶۰ ثانیه است — چک‌لیست بالا را اجرا کنید و نتیجه را با هر سرور دیگری که دارید مقایسه کنید. اگر اعداد قانع‌تان کرد نگهش دارید؛ اگر نه، حذفش کنید و فقط هزینه‌ی چند ساعت را داده‌اید. معیارهای انتخاب پیش از خرید را در راهنمای خرید سرور مجازی جمع کرده‌ایم.