افزایش سرعت سرور مجازی: علت کندی را پیدا کنید، بعد درمان کنید

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

این راهنما برای سرورهای لینوکسی (AlmaLinux و Ubuntu) نوشته شده و ترتیبی را دنبال می کند که ما در بررسی های عملکرد استفاده می کنیم: اول نشانه ها، بعد منابع سخت افزاری، بعد لایه های نرم افزاری مثل دیتابیس و وب سرور.

علت کند شدن سرور چیست؟

کندی سرور تقریبا همیشه به یکی از این گروه ها برمی گردد. دانستن این دسته بندی کمک می کند بی هدف تنظیمات را تغییر ندهید.

• کمبود CPU: پردازش های سنگین PHP، کوئری های بدون ایندکس، کرون جاب های پرمصرف یا ربات هایی که صفحات را پشت سر هم باز می کنند.
• کمبود رم: وقتی رم پر شود سیستم عامل سراغ swap می رود و دیسک که چند برابر کندتر از رم است عملا جای حافظه را می گیرد.
• گلوگاه دیسک (IO): دیسک کند، دیسک پر، یا بکاپی که وسط روز کاری اجرا می شود.
• مشکل میزبان: در سرور مجازی منابع فیزیکی بین چند ماشین تقسیم شده است. اگر میزبان بیش از حد فروخته شده باشد، ماشین شما منتظر CPU یا دیسک می ماند.
• تنظیمات نرم افزار: دیتابیس با تنظیمات پیش فرض، PHP-FPM با تعداد پردازش نامناسب، نبودن کش.
• شبکه و فاصله: فاصله جغرافیایی سرور تا کاربران، فایل های حجیم بدون فشرده سازی، یا حمله و ترافیک ناخواسته.

قبل از هر تغییری: کندی را اندازه بگیرید

«سایت کند است» قابل بررسی نیست. مشخص کنید کدام صفحه، در چه ساعتی و برای چه کسانی کند است. زمان پاسخ اولیه سرور (TTFB) را با یک دستور ساده بسنجید:

curl -o /dev/null -s -w "connect: %{time_connect}s  ttfb: %{time_starttransfer}s  total: %{time_total}s\n" https://example.com/

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

بررسی CPU و load average

دستور uptime سه عدد load average را برای یک، پنج و پانزده دقیقه اخیر نشان می دهد. این عدد را باید با تعداد هسته ها مقایسه کنید که با nproc به دست می آید. اگر load به طور مداوم از تعداد هسته ها بیشتر باشد، پردازش ها در صف مانده اند.

nproc
uptime
top -o %CPU

در خروجی top به ردیف %Cpu(s) دقت کنید:

• us بالا یعنی برنامه ها (PHP، دیتابیس، جاوا) CPU را مصرف می کنند.
• wa بالا یعنی CPU بیکار است ولی منتظر دیسک مانده. در این حالت خرید CPU بیشتر فایده ای ندارد.
• st یا steal time یعنی میزبان مجازی سازی سهم CPU شما را به ماشین دیگری داده است. اگر این عدد به طور پایدار بالا باشد، مشکل از ارائه دهنده سرور است و با تنظیمات داخل سرور حل نمی شود.

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

# پرتکرارترین IPها در لاگ Nginx
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

بررسی رم و swap

ستون available در دستور free -h مهم تر از free است، چون لینوکس رم خالی را برای کش فایل ها استفاده می کند و این مصرف قابل آزاد شدن است. برای دیدن فعالیت swap از vmstat استفاده کنید:

free -h
vmstat 1 10
journalctl -k | grep -i "out of memory"

اگر ستون های si و so در vmstat به طور مداوم غیر صفر باشند، سرور در حال جابه جایی حافظه با دیسک است و کندی محسوس خواهد بود. پیام out of memory در لاگ کرنل هم یعنی سیستم عامل مجبور شده پردازشی را ببندد؛ اغلب قربانی این اتفاق MySQL یا MariaDB است.

بررسی دیسک و IO

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

df -h
df -i
# AlmaLinux: dnf install sysstat iotop   |   Ubuntu: apt install sysstat iotop
iostat -x 2 5
iotop -o

در خروجی iostat -x به %util و ستون های r_await و w_await نگاه کنید. استفاده نزدیک به صد درصد همراه با زمان انتظار بالا یعنی دیسک گلوگاه است. iotop نشان می دهد کدام پردازش بیشترین خواندن و نوشتن را دارد.

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

fio --name=randrw --rw=randrw --bs=4k --size=1G --iodepth=32 \
    --runtime=60 --time_based --direct=1 --ioengine=libaio --group_reporting

دیتابیس: جایی که بیشتر کندی ها پنهان است

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

1. فعال کردن slow query log

در MariaDB روی AlmaLinux فایل تنظیمات معمولا /etc/my.cnf.d/mariadb-server.cnf است و در MySQL روی Ubuntu فایل /etc/mysql/mysql.conf.d/mysqld.cnf. این خطوط را در بخش [mysqld] اضافه کنید و سرویس را ری استارت کنید:

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

مسیر لاگ باید وجود داشته باشد و کاربر mysql اجازه نوشتن در آن را داشته باشد. بعد از چند ساعت، با mysqldumpslow -s t /var/log/mysql/slow.log | head کندترین کوئری ها را ببینید. اغلب راه حل یک ایندکس درست یا حذف یک افزونه ناکارآمد است.

2. بررسی کوئری های در حال اجرا

mysql -e "SHOW FULL PROCESSLIST;"

اگر ده ها کوئری در وضعیت Locked یا Sending data مانده اند، یک جدول یا یک کوئری کل سیستم را معطل کرده است.

3. اندازه buffer pool

پارامتر innodb_buffer_pool_size تعیین می کند چه مقدار از داده و ایندکس در رم نگهداری شود. مقدار پیش فرض برای سرورهای امروزی کوچک است. روی سروری که فقط دیتابیس دارد می توان سهم زیادی از رم را به آن داد، ولی روی سروری که وب سرور و PHP هم دارد باید برای آنها جا گذاشت. ابزار MySQLTuner پیشنهادهای اولیه خوبی می دهد، به شرط اینکه سرور مدتی بدون ری استارت کار کرده باشد تا آمار معنادار جمع شود.

وب سرور و PHP-FPM

یک خطای رایج در سرورهای PHP این است که تعداد پردازش های PHP-FPM بدون محاسبه تعیین می شود. اگر pm.max_children کم باشد، درخواست ها در صف می مانند. اگر زیاد باشد، رم تمام می شود و سرور به swap می افتد. نشانه حالت اول این پیام در لاگ است:

grep -i "max_children" /var/log/php-fpm/*.log      # AlmaLinux
grep -i "max_children" /var/log/php8.3-fpm.log      # Ubuntu 24.04

برای محاسبه تقریبی، میانگین مصرف رم هر پردازش را اندازه بگیرید و رم در دسترس برای PHP را بر آن تقسیم کنید:

ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=$1; n++} END {print s/n/1024 " MB"}'

روی AlmaLinux نام پردازش php-fpm است. چند نکته دیگر در این لایه:

• OPcache را فعال نگه دارید (opcache.enable=1) و opcache.memory_consumption را متناسب با حجم کد تنظیم کنید.
• نسخه PHP را به نسخه پشتیبانی شده به روز کنید؛ نسخه های قدیمی هم کندترند و هم وصله امنیتی نمی گیرند.
• برای سایت های محتوایی از کش صفحه استفاده کنید تا بیشتر درخواست ها اصلا به PHP و دیتابیس نرسند.
• فشرده سازی gzip یا brotli و HTTP/2 را در Nginx یا LiteSpeed فعال کنید.
• فایل های استاتیک را با هدر کش طولانی سرو کنید و در صورت نیاز از CDN کمک بگیرید.

عوامل خارج از سرور

گاهی سرور سالم است و کندی از جای دیگری می آید. اگر کاربران شما در ایران هستند و سرور در دیتاسنتر خارجی است، تاخیر شبکه بخشی از زمان پاسخ را تشکیل می دهد. با mtr مسیر و تاخیر را از دید کاربر بسنجید. ترافیک ربات ها و اسکنرها هم می تواند منابع را بگیرد؛ محدود کردن نرخ درخواست در وب سرور یا فایروال و بستن مسیرهایی مثل xmlrpc.php در وردپرس، اگر استفاده نمی شوند، کمک می کند. در نهایت، اگر مصرف CPU بدون دلیل روشن بالاست، احتمال آلودگی سرور به ماینر یا بدافزار را هم در نظر بگیرید.

چک لیست افزایش سرعت سرور مجازی

کی ارتقای سرور منطقی است؟

وقتی بررسی ها نشان دهد نرم افزار درست تنظیم شده، کوئری های کند رفع شده اند و با این حال منابع در ساعات اوج به سقف می رسند، ارتقا تصمیم درستی است. اگر steal time بالاست یا دیسک از حد انتظار کندتر است، جابه جایی به ارائه دهنده یا پلن دیگری با منابع اختصاصی تر مفیدتر از افزودن رم است. و اگر رشد ترافیک ادامه دارد، جدا کردن دیتابیس از وب سرور معمولا قدم بعدی منطقی است.

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

بررسی عملکرد سرور توسط تیم ما

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