دسته بندی:

علل کندی سرور مجازی و راهکارهای عملی در ویندوز و لینوکس

علل کندی سرور مجازی و راهکارهای عملی در ویندوز و لینوکس

حدود ۱۹ دقیقه مطالعه

اتصال به سرور مجازی برقرار است، اما تصویر ریموت دسکتاپ می‌پرد و کلیک‌ها با تاخیر جواب می‌دهند؛ یا در لینوکس نشست SSH چند ثانیه معطل می‌ماند و ساده‌ترین دستور دیر اجرا می‌شود. این «کندی» تقریبا همیشه یکی از چهار ریشه دارد: کیفیت مسیر شبکه بین شما و سرور، اشباع CPU، پر شدن RAM و افتادن سیستم روی swap، یا فشار I/O روی دیسک.

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

بررسی علل کندی سرور مجازی و راهکارهای بهبود عملکرد آن

گام اول: مشکل از شبکه است یا از خود سرور؟

ساده‌ترین آزمون، یک ping طولانی از سیستم خودتان به IP سرور است. در ویندوز:

ping -t IP-Server

سوییچ -t ping را به‌صورت پیوسته اجرا می‌کند تا با Ctrl+C متوقفش کنید. اگر می‌خواهید تعداد مشخصی بسته بفرستید، از ping -n 50 IP-Server استفاده کنید. در لینوکس و macOS معادل آن این است:

ping -c 50 IP-Server

خروجی را این‌طور بخوانید:

  • وجود Request timed out یا درصدی از packet loss یعنی بسته‌ها در مسیر گم می‌شوند.
  • نوسان شدید زمان پاسخ (مثلا رفت‌وبرگشت بین ۴۰ و ۴۰۰ میلی‌ثانیه) همان چیزی است که به آن jitter می‌گویند و بیشترین اثر را روی تجربه ریموت دسکتاپ دارد.
  • زمان پاسخ بالا اما یکنواخت، معمولا فقط به معنی فاصله جغرافیایی است و به‌تنهایی باعث کندی سرویس‌ها نمی‌شود.

اگر ping ناپایدار بود، مشکل از مسیر اینترنت شماست و هرچقدر هم منابع سرور را ارتقا دهید تغییری نمی‌کند. برای پیدا کردن اینکه کدام نقطه از مسیر مشکل دارد، در ویندوز pathping IP-Server و در لینوکس mtr IP-Server تصویر دقیق‌تری می‌دهند، چون درصد از دست رفتن بسته را برای تک‌تک هاپ‌های مسیر نشان می‌دهند.

اگر ping تمیز بود ولی سرور همچنان کند است، مشکل داخل سرور است و باید سراغ منابع بروید.

کندی در سرورهای ویندوزی: دلایل و راهکارها

سرورهای ویندوزی به دلیل داشتن رابط گرافیکی و استفاده گسترده از Remote Desktop بیشتر از سایر سیستم‌عامل‌ها در معرض کندی محسوس قرار دارند؛ چون هر بار که چیزی روی صفحه تغییر می‌کند، باید تصویر آن ناحیه از شبکه عبور کند. مهم‌ترین علل کندی در این سیستم‌ها شامل موارد زیر است.

مهم‌ترین علل کندی سرورهای مجازی ویندوز و مصرف بالای منابع

کیفیت پایین اینترنت و قطعی‌های لحظه‌ای

شایع‌ترین شکایت کاربران، کندی یا پرش تصویر هنگام کار با ریموت دسکتاپ است. حتی قطع کوتاه اینترنت به اندازه یک دهم ثانیه می‌تواند باعث تاخیر محسوس در تصویر شود؛ چون RDP روی TCP کار می‌کند و بسته گم‌شده باید دوباره ارسال شود، و تا رسیدن آن، بسته‌های بعدی هم پشت آن در صف می‌مانند. با آزمون ping بخش قبل می‌توانید این را تایید کنید.

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

پر شدن منابع سرور

اگر تعداد برنامه‌های باز در سرور زیاد باشد یا وب‌سایت شما بازدید بالایی داشته باشد، CPU و حافظه رم سرور به حد نهایی خود می‌رسند و باعث کندی سیستم می‌شوند. برای بررسی وضعیت منابع، Task Manager را باز کنید و در تب Processes ستون‌های CPU و Memory را مرتب کنید تا برنامه‌های پرمصرف را ببینید، سپس موارد غیرضروری را ببندید.

اگر ترجیح می‌دهید از خط فرمان کار کنید، این دستور PowerShell ده فرایندی را فهرست می‌کند که از لحظه اجرا شدنشان بیشترین زمان CPU را مصرف کرده‌اند:

Get-Process | Sort-Object -Property CPU -Descending | Select-Object -First 10

یک نکته مهم درباره همین دستور: ستون CPU در Get-Process زمان تجمعی پردازنده بر حسب ثانیه است، نه مصرف لحظه‌ای. سرویسی که هفته‌هاست بالاست و الان کاملا بیکار است هم می‌تواند بالای این فهرست بیاید. برای دیدن مصرف همین لحظه، تب Processes در Task Manager معیار درستی است. برای پرمصرف‌ترین فرایندها از نظر حافظه هم:

Get-Process | Sort-Object -Property WS -Descending | Select-Object -First 10

یک نکته که معمولا از قلم می‌افتد: ویندوز هم دقیقا مثل لینوکس وقتی RAM کم بیاورد، صفحات حافظه را روی دیسک می‌نویسد؛ منتها اسمش pagefile است. در Task Manager به تب Performance و بخش Memory بروید و مقدار Committed را ببینید؛ اگر عدد سمت چپ به سقف نزدیک شده، سرور در حال صفحه‌بندی سنگین است و تنها راه واقعی، افزایش RAM یا کم کردن بار است. ابزار Resource Monitor (با اجرای resmon) در تب Memory ستون Hard Faults/sec را نشان می‌دهد که معیار دقیق‌تری برای همین فشار است.

نبود کارت گرافیک اختصاصی

سرورهای مجازی برخلاف کامپیوترهای خانگی معمولا کارت گرافیک اختصاصی ندارند و رندر تصویر روی CPU انجام می‌شود. این باعث می‌شود محیط دسکتاپ کمی کندتر اجرا شود. برای بهبود، در پنجره Remote Desktop Connection روی Show Options کلیک کنید، به تب Experience بروید و کیفیت را کاهش دهید:

  • در فهرست بالای تب (Choose your connection speed to optimize performance) گزینه‌ای متناسب با کیفیت واقعی اینترنت خود انتخاب کنید، نه Detect connection quality automatically؛ چون تشخیص خودکار روی خطوط پرنوسان مدام بین تنظیمات بالا و پایین می‌رود.
  • تیک Desktop background، Font smoothing، Desktop composition، Show contents of window while dragging، Menu and window animation و Visual styles را بردارید.
  • برخلاف بقیه، تیک Persistent bitmap caching را روشن بگذارید؛ این گزینه بخش‌های تکراری تصویر را روی سیستم شما کش می‌کند و ترافیک را کم می‌کند.
کاهش کیفیت تصویر در بخش Experience تنظیمات Remote Desktop برای بهبود سرعت اتصال

مشکلات نرم‌افزاری و سیستم‌عامل

گاهی برنامه‌های معیوب یا بدافزارها باعث مصرف غیرعادی منابع و کندی می‌شوند. اگر یک فرایند ناشناس دائم CPU را اشغال کرده، در Task Manager روی آن راست‌کلیک کنید و Open file location را بزنید تا ببینید از کجا اجرا می‌شود.

سرویس‌های در حال اجرا را هم می‌توانید در services.msc مرور کنید، اما اینجا محتاط باشید: غیرفعال کردن کورکورانه سرویس‌ها می‌تواند دسترسی ریموت شما به سرور را برای همیشه قطع کند. سرویس‌های Remote Desktop Services (نام داخلی TermService)، Remote Procedure Call (RPC)، DNS Client، DHCP Client، Server، Workstation و Windows Firewall را دست نزنید. هر سرویس مشکوک را جداگانه و یکی‌یکی خاموش کنید، به‌جای Disabled حالت Manual را انتخاب کنید، و این کار را فقط زمانی انجام دهید که دسترسی جایگزین (کنسول VNC یا KVM در پنل سرور) در اختیار دارید تا اگر ارتباط قطع شد بتوانید برگردید.

ریستارت دوره‌ای سرور هم می‌تواند اثر نشت حافظه برخی برنامه‌ها را موقتا خنثی کند، اما راه‌حل نیست؛ اگر سروری فقط با ریستارت روزانه قابل استفاده است، یک سرویس معیوب دارید که باید پیدایش کنید.

راهکارهای عملی در ویندوز

  • استفاده از اینترنت پایدار با سرعت مناسب و تایید پایداری آن با ping.
  • کاهش کیفیت نمایش و غیرفعال کردن جلوه‌های گرافیکی غیرضروری در Remote Desktop.
  • پایش Task Manager برای شناسایی برنامه‌های پرمصرف و بستن آن‌ها.
  • بررسی Committed Memory و Hard Faults برای تشخیص کمبود RAM.
  • ریستارت دوره‌ای سرور در صورت پر بودن منابع، به‌عنوان راه‌حل موقت.
  • ارتقای منابع یا پلن سرور برای افزایش CPU و RAM.

کندی در سرورهای لینوکسی

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

کمبود منابع سخت‌افزاری

اگر پردازش‌های سنگین یا تعداد سرویس‌ها زیاد باشد، RAM و CPU سرور پر می‌شوند. برای مشاهده مصرف منابع از این دستورها استفاده کنید:

top

یا نسخه خواناترش:

htop

اگر htop نصب نیست، در Ubuntu و Debian با apt install htop و در AlmaLinux و Rocky Linux با dnf install htop نصب می‌شود (در توزیع‌های خانواده RHEL ابتدا باید مخزن EPEL را با dnf install epel-release فعال کنید).

در خط اول خروجی top سه عدد load average دیده می‌شود که میانگین بار سیستم در ۱، ۵ و ۱۵ دقیقه گذشته است. این اعداد را باید نسبت به تعداد هسته‌های CPU بسنجید؛ تعداد هسته را با nproc ببینید. load برابر ۴ روی سروری با ۴ هسته یعنی سیستم دقیقا اشباع است، و همان عدد روی سرور تک‌هسته‌ای یعنی سرور به‌شدت تحت فشار است.

یک نکته که تشخیص را عوض می‌کند: load در لینوکس فقط پردازنده را نمی‌شمارد؛ فرایندهایی که در انتظار غیرقابل‌وقفه دیسک (حالت D) گیر کرده‌اند هم در آن حساب می‌شوند. پس اگر load بالاست ولی مقدار %id در سطر CPU خروجی top هنوز بزرگ است و در عوض %wa بالا رفته، مشکل شما دیسک است نه CPU و باید مستقیم سراغ بخش I/O همین مقاله بروید.

پر شدن RAM و افتادن سرور روی swap

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

نکته مهمی که در بیشتر آموزش‌ها گفته نمی‌شود: پر بودن swap به‌تنهایی مشکل نیست. کرنل عمدا صفحات بی‌استفاده را به swap می‌فرستد تا RAM را برای کش دیسک و فرایندهای فعال آزاد نگه دارد، و ممکن است آن صفحات هفته‌ها همان‌جا بمانند بدون اینکه ذره‌ای روی سرعت اثر بگذارند. چیزی که واقعا سرور را کند می‌کند، فعالیت مداوم swap است. برای دیدن هر دو وضعیت:

free -h
swapon --show
vmstat 1 5
  • free -h در سطر Swap مجموع فضای swap و مقدار استفاده‌شده را نشان می‌دهد.
  • swapon --show فهرست فضاهای swap فعال را با نوع (partition یا file)، اندازه و مقدار استفاده‌شده می‌دهد. معادل آن cat /proc/swaps است.
  • در خروجی vmstat دو ستون si و so (swap in و swap out) نرخ خواندن از swap و نوشتن در آن را نشان می‌دهند. اگر این دو ستون پیوسته عددی غیر صفر باشند، سرور در حال swap فعال است و مشکل واقعی کمبود RAM است، نه خود swap.

یک هشدار درباره خواندن vmstat: سطر اول خروجی آن میانگین از زمان بوت سرور است و وضعیت الان را نشان نمی‌دهد. به سطر اول نگاه نکنید و از سطر دوم به بعد را بخوانید. به همین دلیل هم vmstat را همیشه با بازه و تعداد اجرا کنید، نه به‌تنهایی.

اگر کار به کشته شدن فرایندها رسیده باشد، ردش در لاگ کرنل می‌ماند (روی بیشتر توزیع‌های امروزی خواندن این لاگ نیاز به دسترسی root دارد):

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k --since "24 hours ago" | grep -iE "out of memory|killed process"

پاکسازی swap و خطری که باید پیش از آن بدانید

گاهی بعد از اینکه یک فرایند سنگین تمام می‌شود، صفحات آن همچنان در swap باقی می‌مانند و سرور بی‌دلیل سنگین به نظر می‌رسد. راه استاندارد خالی کردن swap این است که آن را خاموش و دوباره روشن کنید؛ در لحظه خاموش شدن، کرنل هرچه در swap است را به RAM برمی‌گرداند.

پیش از اجرای این دستور حتما یک چیز را بررسی کنید: مقدار swap استفاده‌شده باید کمتر از RAM آزاد باشد. اگر ۳ گیگابایت داده در swap باشد و فقط ۵۰۰ مگابایت RAM آزاد داشته باشید، swapoff یا سرور را برای دقایق طولانی قفل می‌کند یا OOM killer را فعال می‌کند و سرویسی مثل MySQL کشته می‌شود. بنابراین اول:

free -h

عدد ستون available در سطر Mem باید از عدد used در سطر Swap بزرگ‌تر باشد. اگر بود، همه فضاهای swap را خاموش و دوباره روشن کنید (این کار را در ساعت کم‌ترافیک و ترجیحا با یک بکاپ تازه از دیتابیس انجام دهید):

sudo swapoff -a
sudo swapon -a

اگر بیش از یک فضای swap دارید و فقط یکی را می‌خواهید پاک کنید، اول با swapon --show مسیر دقیق آن را پیدا کنید و سپس همان را خاموش و روشن کنید. مثلا اگر swap روی پارتیشن /dev/sda5 باشد:

sudo swapoff /dev/sda5
sudo swapon /dev/sda5

در راهنماهای قدیمی برای پیدا کردن پارتیشن swap از blkid استفاده می‌شد. این دستور هنوز کار می‌کند و اگر بدون پارامتر اجرا شود مشخصات همه پارتیشن‌ها را با نوعشان فهرست می‌کند، اما دو ایراد دارد: خروجی‌اش شلوغ است و مهم‌تر اینکه امروز روی بسیاری از سرورهای مجازی، swap به‌جای پارتیشن یک فایل است (معمولا /swapfile) و blkid اصلا آن را نشان نمی‌دهد. swapon --show همان چیزی را نشان می‌دهد که واقعا در همان لحظه فعال است.

یک اصلاح اصطلاحی هم لازم است: آنچه معمولا «پاکسازی swap cache» نامیده می‌شود، در عمل خالی کردن کل فضای swap است. اصطلاح SwapCached در /proc/meminfo چیز دیگری است و به صفحاتی اشاره دارد که هم‌زمان در RAM و در swap موجودند تا اگر دوباره لازم شدند بدون خواندن از دیسک در دسترس باشند؛ بالا بودن این عدد به‌خودی‌خود نشانه مشکل نیست.

دو محدودیت مهم را هم در نظر داشته باشید. روی سرورهای مجازی مبتنی بر کانتینر (مثل OpenVZ و LXC) ممکن است اصلا swap در اختیار شما نباشد یا swapoff با خطای مجوز رد شود؛ در این حالت تنها راه، افزایش RAM یا سبک کردن سرویس‌هاست. ضمنا این کار یک اقدام موقت است: اگر ظرف چند ساعت swap دوباره پر شد، مشکل اصلی کمبود RAM یا نشت حافظه در یکی از سرویس‌هاست و باید همان را حل کنید.

اگر سرور RAM کافی دارد اما زودتر از انتظار سراغ swap می‌رود، پارامتر vm.swappiness تمایل کرنل به استفاده از swap را تعیین می‌کند. مقدار پیش‌فرض در بیشتر توزیع‌ها ۶۰ است و عدد کمتر یعنی کرنل دیرتر به swap متوسل شود:

sysctl vm.swappiness
sudo sysctl -w vm.swappiness=10

این تغییر با ریستارت از بین می‌رود. برای دائمی کردن آن یک فایل در /etc/sysctl.d/ بسازید:

echo "vm.swappiness=10" | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

(از شکل sudo echo ... > /etc/sysctl.d/... استفاده نکنید؛ در آن حالت تغییرمسیر > را پوسته با کاربر عادی انجام می‌دهد و خطای Permission denied می‌گیرید. به همین دلیل بالا از tee استفاده شده است.)

مقدار صفر را انتخاب نکنید؛ در کرنل‌های امروزی صفر عملا استفاده از swap را تا لحظه بحران متوقف می‌کند و احتمال ورود OOM killer را بالا می‌برد.

مصرف بالای I/O دیسک

برخی سرویس‌ها و برنامه‌ها بار زیادی روی دیسک ایجاد می‌کنند و نتیجه‌اش سروری است که CPU و RAM آزاد دارد ولی همه‌چیز در آن کند است. برای بررسی I/O:

iostat -xm 5 5

این دستور میزان استفاده از دیسک را در بازه‌های زمانی ۵ ثانیه‌ای نمایش می‌دهد. اجزای آن:

  • iostat ابزاری برای نمایش آمار استفاده از دیسک و CPU است. اگر نصب نبود، بسته sysstat را نصب کنید: dnf install sysstat در AlmaLinux و Rocky، یا apt install sysstat در Ubuntu و Debian.
  • -x آمار تفصیلی (Extended statistics) را نشان می‌دهد؛ یعنی جزئیاتی مثل درصد مشغول بودن دیسک، زمان انتظار و طول صف.
  • -m واحد نرخ انتقال را مگابایت بر ثانیه می‌کند. اگر این سوییچ را نگذارید، ستون‌ها به‌صورت rkB/s و wkB/s (کیلوبایت بر ثانیه) نمایش داده می‌شوند.
  • 5 5 یعنی هر ۵ ثانیه یک بار و مجموعا ۵ بار آمار گرفته شود. نمونه اول همیشه میانگین از زمان بوت سرور است، پس آن را نادیده بگیرید و از نمونه دوم به بعد را بخوانید.

خروجی چیزی شبیه این است (ستون‌ها را برای خوانایی خلاصه کرده‌ایم):

Device r/s w/s rMB/s wMB/s r_await w_await aqu-sz %util
sda ۱۰ ۵ ۰٫۱۰ ۰٫۰۵ ۸ ۱۲ ۰٫۱۵ ۲۰
sdb ۸ ۲ ۰٫۰۸ ۰٫۰۲ ۶ ۹ ۰٫۰۸ ۱۰
sdc ۰ ۰ ۰ ۰ ۰ ۰ ۰ ۰

توضیح ستون‌ها:

  • Device: نام دیسک یا پارتیشن
  • r/s: تعداد درخواست‌های خواندن در هر ثانیه
  • w/s: تعداد درخواست‌های نوشتن در هر ثانیه
  • rMB/s: سرعت خواندن بر حسب مگابایت بر ثانیه
  • wMB/s: سرعت نوشتن بر حسب مگابایت بر ثانیه
  • r_await و w_await: میانگین زمان پاسخ هر درخواست خواندن و نوشتن به میلی‌ثانیه؛ عدد بالاتر یعنی تاخیر بیشتر
  • aqu-sz: میانگین طول صف درخواست‌ها؛ عددی که پیوسته بالای ۱ بماند یعنی درخواست‌ها پشت هم صف کشیده‌اند
  • %util: درصد زمانی که دیسک مشغول بوده است

اگر روی سرور شما به‌جای r_await و w_await یک ستون واحد await و ستونی به نام svctm دیده می‌شود، نسخه sysstat نصب‌شده قدیمی‌تر از ۱۲ است؛ svctm از نسخه ۱۲ حذف شد چون روی دیسک‌های چندصفی دیگر قابل محاسبه نبود.

روی دیسک‌های مکانیکی، %util نزدیک ۱۰۰ یعنی دیسک اشباع شده و همان عامل کندی است. اما روی SSD و به‌ویژه NVMe که ده‌ها درخواست را هم‌زمان سرویس می‌دهند این عدد گمراه‌کننده است و ممکن است بدون اشباع واقعی به ۱۰۰ برسد؛ در آن حالت به aqu-sz و r_await/w_await اعتماد کنید. روی NVMe سالم، await در حد کسری از میلی‌ثانیه است؛ چند ده میلی‌ثانیه یعنی واقعا مشکل دارید. برای اینکه بفهمید کدام فرایند بار را می‌سازد، از iotop -o با کاربر root استفاده کنید.

یک بررسی ساده اما فراموش‌شده هم لازم است: دیسک پر نباشد. با df -h فضای آزاد پارتیشن‌ها و با df -i میزان مصرف inode را ببینید؛ پر شدن هرکدام می‌تواند سرویس‌ها را از کار بیندازد.

مشکلات شبکه و پکت لاس

نوسان زیاد در زمان پاسخ یا از دست رفتن بسته‌ها، هم اتصال SSH و هم اجرای دستورها را کند نشان می‌دهد؛ در واقع سرور سریع پاسخ داده اما پاسخ دیر به شما رسیده است. آزمون ping و mtr بخش اول مقاله دقیقا برای تفکیک همین حالت است.

یک حالت اختصاصی لینوکس هم هست: اگر خودِ لحظه ورود به SSH چند ثانیه طول می‌کشد ولی بعد از ورود همه‌چیز روان است، اول ببینید مکث دقیقا کجا می‌افتد:

ssh -vvv user@IP-Server

دو مظنون رایج برای این مکث وجود دارد:

  • resolve معکوس DNS آدرس شما توسط سرور. توجه کنید که در OpenSSH نسخه ۶.۸ به بعد مقدار پیش‌فرض UseDNS خودش no است، پس این علت روی سرورهای امروزی کمتر از چیزی است که در آموزش‌های قدیمی گفته می‌شود. اول مقدار موثر فعلی را ببینید: sudo sshd -T | grep -i usedns و فقط اگر yes بود آن را در /etc/ssh/sshd_config به UseDNS no تغییر دهید.
  • احراز هویت GSSAPI. اگر GSSAPIAuthentication روشن باشد ولی Kerberos پیکربندی نشده باشد، کلاینت و سرور چند ثانیه منتظر تایم‌اوت می‌مانند. مقدار GSSAPIAuthentication no در همان فایل این تاخیر را برمی‌دارد.

هشدار مهم: هر تغییر اشتباه در /etc/ssh/sshd_config می‌تواند شما را برای همیشه از سرور بیرون بیندازد. سه قاعده را رعایت کنید: نشست SSH فعلی خود را تا پایان کار باز نگه دارید، پیش از ریستارت فایل را اعتبارسنجی کنید، و بعد از ریستارت با یک نشست جدید ورود را تست کنید و تنها پس از موفقیت نشست قدیمی را ببندید. نام سرویس در AlmaLinux و Rocky برابر sshd و در Ubuntu و Debian برابر ssh است:

sudo sshd -t
sudo systemctl restart sshd    # AlmaLinux / Rocky Linux
sudo systemctl restart ssh     # Ubuntu / Debian

اگر sshd -t چیزی چاپ کرد یعنی فایل ایراد دارد؛ در آن صورت ریستارت نکنید و اول خطا را برطرف کنید.

پردازش‌های سنگین یا سرویس‌های معیوب

گاهی یک سرویس اشتباه پیکربندی‌شده یا پردازش غیرعادی همه منابع را می‌بلعد. برای دیدن پرمصرف‌ترین فرایندها از نظر CPU:

ps aux --sort=-%cpu | head -n 10

و برای پرمصرف‌ترین‌ها از نظر حافظه:

ps aux --sort=-%mem | head -n 10

برای دیدن اینکه آیا سرویسی در حالت خطاست:

systemctl list-units --failed
systemctl status nginx
journalctl -u nginx -n 100 --no-pager

در توزیع‌های امروزی (AlmaLinux، Rocky Linux، CentOS 7 به بعد، Ubuntu 16.04 به بعد و Debian 8 به بعد) مدیریت سرویس‌ها با systemctl انجام می‌شود. اگر در آموزش‌های قدیمی به دستورهایی مثل service nginx restart یا /etc/init.d/nginx restart برخوردید، بدانید که این‌ها روش SysVinit هستند؛ روی سیستم‌های systemd هنوز به‌عنوان لایه سازگاری کار می‌کنند و درخواست را به systemd می‌سپارند، اما شکل درست و قابل اتکا امروز این است:

sudo systemctl restart nginx
sudo systemctl enable nginx

برای سرویس‌های وب، پیش از restart پیکربندی را تست کنید (مثلا nginx -t) تا سرویس بعد از ریستارت بالا نیاید و سایت را از دسترس خارج نکند.

راهکارهای عملی در لینوکس

  • بررسی و بهینه‌سازی سرویس‌های سنگین و غیرفعال کردن سرویس‌هایی که استفاده نمی‌شوند.
  • استفاده از top یا htop برای پایش لحظه‌ای CPU و RAM و مقایسه load average با تعداد هسته‌ها.
  • بررسی وضعیت swap با free -h و vmstat؛ اگر ستون‌های si و so پیوسته غیرصفرند، ریشه مشکل کمبود RAM است.
  • بررسی فضای دیسک با df -h و inode با df -i.
  • پایش I/O با iostat -xm یا vmstat و شناسایی فرایند مقصر با iotop -o.
  • بررسی لاگ سرویس‌ها با journalctl پیش از هر ریستارت کورکورانه.
  • ارتقای منابع در صورت نیاز.

نکات عمومی برای بهبود عملکرد VPS

  • همیشه سیستم‌عامل و بسته‌های نرم‌افزاری خود را به‌روز نگه دارید.
  • از نصب برنامه‌های غیرضروری خودداری کنید؛ هر سرویس اضافه، هم RAM مصرف می‌کند و هم سطح حمله را بزرگ‌تر می‌کند.
  • منابع سرور را متناسب با بار کاری انتخاب کنید.
  • پیش از رسیدن به اشباع منابع، پلن سرور خود را ارتقا دهید؛ سروری که همیشه روی ۹۵ درصد RAM کار می‌کند، با کوچک‌ترین افزایش بار متوقف می‌شود.
  • استفاده از SSD نسبت به هاردهای معمولی باعث کاهش تاخیر در I/O می‌شود.
  • swap را کاملا حذف نکنید؛ وجود مقداری swap به کرنل اجازه می‌دهد صفحات بی‌استفاده را کنار بگذارد و از توقف ناگهانی سرویس جلوگیری کند. اما swap هرگز جایگزین RAM کافی نیست.
  • مصرف منابع را در طول زمان ثبت کنید. ابزار sar (از همان بسته sysstat، پس از فعال کردن جمع‌آوری دوره‌ای آمار) به شما اجازه می‌دهد بفهمید کندی دیروز ساعت ۳ بعدازظهر از کجا آمده است.

سرورهای افسانه‌ای: پایان محدودیت منابع

حتی با رعایت تمام راهکارهای فوق، سرورهای مجازی معمولی به‌دلیل محدودیت‌های سخت‌افزاری تنها تا حد مشخصی امکان ارتقای منابع را در اختیار شما قرار می‌دهند. در چنین شرایطی هرچقدر هم پلن خود را ارتقا دهید، پس از رسیدن به سقف منابع دیگر امکان افزایش CPU یا RAM فراهم نیست و همین موضوع عملکرد سرویس‌ها را در بلندمدت تحت تاثیر قرار می‌دهد.

اما سرورهای افسانه‌ای این محدودیت را از میان برداشته‌اند. شما می‌توانید از همان ابتدا یا در هر زمان، منابعی به‌مراتب بالاتر را انتخاب یا بدون قطعی سرویس به پلن‌های قوی‌تر ارتقا دهید. این انعطاف‌پذیری باعث می‌شود پروژه‌های پربازدید، نرم‌افزارهای مالی یا سازمانی و وب‌سایت‌های پرترافیک حتی در شرایط اوج مصرف، بدون افت سرعت یا ناپایداری ادامه فعالیت دهند.

مزایای فنی سرور افسانه‌ای

  • امکان انتخاب پلن‌هایی با RAM و CPU بالاتر.
  • استفاده از SSD برای بهبود عملکرد I/O.
  • پهنای باند و پورت پایدارتر برای اتصال بدون قطعی.
  • امکان نصب سیستم‌عامل‌های ویندوز، AlmaLinux و Ubuntu.
  • ارتقای منابع بدون تغییر IP و بدون قطعی سرویس.

مناسب چه کاربردهایی است

  • وب‌سایت‌های پربازدید و نرم‌افزارهای مالی و سازمانی.
  • اجرای چند سرویس هم‌زمان بدون کاهش سرعت.
  • تجربه روان در ریموت دسکتاپ و کاهش لگ.
  • پشتیبانی مستقیم برای بهینه‌سازی منابع و عیب‌یابی.

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

جمع‌بندی عملی: پیش از هر ارتقایی، با ping مسیر شبکه را تایید کنید، با top یا Task Manager وضعیت CPU را ببینید، با free -h و vmstat بررسی کنید که سرور روی swap نیفتاده باشد و با iostat -xm دیسک را بسنجید. اگر بعد از این چهار بررسی معلوم شد منابع سرور واقعا کم است، دیگر تنظیمات نرم‌افزاری نجاتتان نمی‌دهد و باید منابع را بالا ببرید.

آموزش‌های مرتبط

خدمات مرتبط آنلاین سرور

ارسال نظر