تشخیص کندی سرور اختصاصی و روش‌های رفع آن

در این مقاله هدف این است که علت‌های فنی کند شدن سرور اختصاصی به شکل دقیق بررسی شود و روش‌های عملی برای تشخیص محل فشار و رفع آن ارائه شود. تمرکز مقاله روی نکاتی است که معمولاً در بررسی‌های روزمره فراموش می‌شوند اما نقش مهمی در افت کارایی دارند.

مرحله اول: تشخیص نوع سایت و حدس اولیه محل فشار

اگر سایت شما وردپرس باشد فشار معمولاً روی دیتابیس PHP و تعداد درخواست‌های هم‌زمان قرار می‌گیرد. افزونه‌های زیاد کوئری‌های تکراری کران‌های داخلی وردپرس و صفحه‌سازها باعث می‌شوند پردازش‌ها پشت صف باقی بمانند. در این حالت مدیر سرور باید قبل از هر اقدامی مشخص کند وب‌سرور PHP و دیتابیس دقیقاً چه سرویس‌هایی هستند و هرکدام روی چه پورتی کار می‌کنند.

# تشخیص وب‌سرور
ps -eo comm,args | egrep -i 'nginx|apache2|httpd' | head

# تشخیص PHP-FPM
ps -eo comm,args | egrep -i 'php-fpm' | head

# تشخیص دیتابیس
ps -eo comm,args | egrep -i 'mysqld|mariadbd|postgres' | head
ss -lntp | egrep -i ':(80|443|3306|5432)\b'

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

# دیدن پردازش‌هایی که بیشترین عملیات دیسک دارند
sudo apt-get update && sudo apt-get install -y iotop
sudo iotop -oPa

مرحله دوم: مشخص کردن اینکه کندی دقیقاً از دید کاربر چیست

قبل از هر تحلیل فنی باید مشخص شود کندی به چه شکلی دیده می‌شود. آیا زمان بارگذاری صفحات افزایش یافته است یا خطاهای 502 و 504 دیده می‌شود یا درخواست‌ها دیر پاسخ می‌گیرند. این مرحله کمک می‌کند مسیر بررسی کوتاه‌تر شود.

# نصب ابزارهای پایه بررسی وضعیت
sudo apt-get update
sudo apt-get install -y sysstat atop htop lsof

# بررسی سریع وضعیت کلی سیستم
uptime
vmstat 1 5
iostat -xz 1 5

اگر مشکل فقط در بازه‌های زمانی خاص رخ می‌دهد باید داده‌های عملکردی ذخیره شوند تا بعداً بررسی شوند. ابزار sar که در بسته sysstat وجود دارد دقیقاً برای همین کار طراحی شده است اما در بسیاری از سرورها غیرفعال می‌ماند.

# فعال‌سازی ثبت خودکار داده‌های sar
sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat

# مشاهده داده‌های ثبت‌شده
sar -u 1 3
sar -r 1 3
sar -n DEV 1 3

مرحله سوم: بررسی CPU با تمرکز روی زمان انتظار

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

# بررسی جزئیات مصرف CPU
mpstat -P ALL 1 5
vmstat 1 10

# دیدن پردازش‌هایی با مصرف بالاتر
ps -eo pid,cmd,%cpu,%mem --sort=-%cpu | head -n 15

در برنامه‌های اختصاصی گاهی یک تابع یا عملیات خاص سهم زیادی از زمان پردازش را به خود اختصاص می‌دهد. ابزار perf کمک می‌کند این نقاط پرهزینه شناسایی شوند.

sudo apt-get install -y linux-tools-common linux-tools-generic
sudo perf top

مرحله چهارم: بررسی حافظه و swap که اغلب دست‌کم گرفته می‌شود

حتی استفاده محدود از swap می‌تواند باعث افزایش شدید زمان پاسخ شود. در این شرایط سیستم به جای استفاده از RAM به دیسک مراجعه می‌کند و همین موضوع سرعت کلی را کاهش می‌دهد.

free -h
swapon --show
vmstat 1 10

برای کاهش رفتار تهاجمی swap می‌توان مقدار swappiness را تنظیم کرد تا سیستم تا حد ممکن از حافظه اصلی استفاده کند.

cat /proc/sys/vm/swappiness
echo "vm.swappiness=10" | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl -p /etc/sysctl.d/99-swappiness.conf

مرحله پنجم: بررسی دیسک و زمان پاسخ عملیات خواندن و نوشتن

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

iostat -xz 1 10
sudo iotop -oPa

بررسی سلامت دیسک نیز مهم است زیرا خطاهای سخت‌افزاری معمولاً ابتدا به شکل کاهش سرعت ظاهر می‌شوند.

sudo apt-get install -y smartmontools
sudo smartctl -H /dev/sda

مرحله ششم: بررسی شبکه و صف اتصال‌ها

مشکلات شبکه همیشه با قطع ارتباط دیده نمی‌شوند. گاهی بسته‌ها دوباره ارسال می‌شوند یا صف اتصال‌ها پر می‌شود و همین موضوع باعث تأخیر در پاسخ می‌گردد.

ip -s link
ss -s

بررسی تعداد اتصال‌های هم‌زمان کمک می‌کند مشخص شود آیا فشار غیرعادی از سمت کاربران یا ربات‌ها وجود دارد یا خیر.

sudo ss -ant | awk '{print $1}' | sort | uniq -c | sort -nr | head

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

در وب‌سرورها معمولاً کندی با خطاهای upstream یا افزایش زمان پاسخ مشخص می‌شود. بررسی لاگ‌ها در این مرحله اهمیت زیادی دارد.

sudo tail -n 200 /var/log/nginx/error.log

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

log_format main_ext '$remote_addr [$time_local] "$request" $status rt=$request_time urt=$upstream_response_time';
access_log /var/log/nginx/access.log main_ext;

مرحله هشتم: بررسی PHP-FPM و صف پردازش‌ها

اگر تعداد پردازش‌های هم‌زمان PHP کمتر از نیاز واقعی باشد درخواست‌ها منتظر آزاد شدن پردازش می‌مانند و سایت کند می‌شود حتی اگر مصرف CPU پایین باشد.

ps -ylC php-fpm* --sort=rss | head
sudo journalctl -u php*-fpm -n 100 --no-pager

مرحله نهم: بررسی دیتابیس و کوئری‌های زمان‌بر

کوئری‌هایی که بدون ایندکس مناسب اجرا می‌شوند یا حجم زیادی از داده را بررسی می‌کنند به مرور باعث افت کارایی می‌شوند. فعال کردن لاگ کوئری‌های کند یکی از مؤثرترین روش‌ها برای شناسایی این موارد است.

sudo mysql -e "SHOW FULL PROCESSLIST\G"

[mysqld]
slow_query_log=1
slow_query_log_file=/var/log/mysql/slow.log
long_query_time=1

مرحله دهم: بررسی فضای دیسک و inode

پر شدن inode یا رشد غیرعادی فایل‌های ریز می‌تواند باعث رفتار غیرمنتظره و کاهش سرعت شود حتی اگر فضای دیسک خالی باشد.

df -h
df -i

مرحله یازدهم: بررسی کران‌جاب‌ها و پردازش‌های زمان‌بندی‌شده

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

sudo crontab -l
systemctl list-timers --all --no-pager | head

مرحله دوازدهم: بررسی محدودیت‌های سیستم عامل

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

ulimit -n
cat /proc/sys/fs/file-max

جمع‌بندی
با بررسی مرحله‌به‌مرحله مصرف منابع تنظیمات سرویس‌ها و رفتار واقعی سیستم می‌توان علت اصلی کند شدن سرور اختصاصی را شناسایی کرد و بدون ارتقاء بی‌دلیل سخت‌افزار کارایی سرور را به شکل قابل توجهی بهبود داد.