چگونه منابع VPS را بهینه کنیم؟

یکی از تلخ‌ترین تجربه‌های مدیریت سرور، وقتی است که مشتری روی VPS اختصاصی سرمایه‌گذاری کرده و باز هم سایتش کند است. وقتی وارد سرور می‌شوم، اغلب می‌بینم که هیچ تنظیمی روی PHP-FPM، MySQL یا هسته سیستم اعمال نشده؛ همه چیز با پیش‌فرض‌های لینوکس کار می‌کند. تجربه‌ام می‌گوید بهینه‌سازی منابع VPS (VPS resource optimization)، پیش از ارتقای پلن، یک فرآیند تنظیم دقیق است. در ادامه همان لایه‌هایی را می‌گویم که در پروژه‌های واقعی برای بهینه‌سازی VPS بازرسی می‌کنم.

پایه: اندازه VPS درست انتخاب شده؟

قبل از هر تنظیمی، بررسی کنید که پلن VPS شما با نیاز فعلی هم‌خوانی دارد. تفاوت VPS و هاست اشتراکی در VPS چیست و چه تفاوتی با هاست اشتراکی دارد آمده؛ اما برای انتخاب اندازه، مقایسه گزینه‌های فروشگاهی در بهترین VPS برای وردپرس آمده است. نشانه‌های پلن نامناسب: مصرف RAM در حالت عادی بالای ۸۰٪، swap فعال به‌طور دائمی، I/O wait بالای ۲۰٪. اگر این نشانه‌ها را دارید، پیش از هر تنظیمی به پلن بالاتر مهاجرت کنید.

VPS با پلن نامناسب، پایه تنظیمات غلط است؛ ابتدا اندازه درست، سپس بهینه‌سازی.

لایه PHP-FPM

PHP-FPM مخزن اجرای وردپرس است و تنظیم درست آن، تفاوت محسوسی در عملکرد می‌سازد. سه پارامتر کلیدی:

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500

مقدار pm.max_children را با فرمول زیر تعیین کنید:

max_children = (RAM اختصاصی به PHP) / (میانگین مصرف هر پروسه PHP)

اگر سایت شما متوسط مصرف هر پروسه PHP را حدود ۵۰ مگابایت باشد و ۱ گیگابایت RAM برای PHP اختصاص داده باشید، مقدار بهینه ۲۰ است. تنظیم بیش از این، به swap ختم می‌شود و کل سرور را کُند می‌کند. همچنین OPcache را با تنظیمات زیر فعال کنید:

opcache.enable=1
opcache.memory_consumption=192
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0

تنظیم validate_timestamps=0 فقط در محیط production مجاز است؛ چون در این حالت، تغییرات فایل PHP بدون restart سرور اعمال نمی‌شود. در محیط توسعه، مقدار ۱ لازم است.

لایه MySQL یا MariaDB

دیتابیس، بعد از PHP، دومین مصرف‌کننده RAM و I/O است. مهم‌ترین تنظیم، innodb_buffer_pool_size است که باید حدود ۶۰ تا ۷۰ درصد RAM اختصاصی دیتابیس باشد. اگر روی VPS با ۴ گیگابایت RAM کار می‌کنید و MySQL سهمش ۱.۵ گیگابایت است، این مقدار را روی حدود ۱ گیگابایت تنظیم کنید:

[mysqld]
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2
max_connections = 100

تنظیم innodb_flush_log_at_trx_commit = 2 تعادل بین سرعت و دوام داده را می‌سازد؛ در تجربه من برای سایت‌های غیرمالی، این تنظیم مجاز است و جهش محسوسی در سرعت درج و به‌روزرسانی می‌دهد. برای سایت‌های فروشگاهی حساس، مقدار ۱ امن‌تر است. اگر بهینه‌سازی کوئری نیاز دارید، مقایسه ابزارها و مفهوم ایندکس در ایندکس‌گذاری در MySQL آمده است.

لایه وب‌سرور (Nginx یا LiteSpeed)

روی VPS، انتخاب وب‌سرور مهم است. مقایسه کلی در هاست اشتراکی و اختصاصی آمده اما دو گزینه برای VPS معمول:

• Nginx: پایه‌ای سبک، مناسب برای سایت‌های پرمخاطب با تنظیم دستی.
• LiteSpeed: کارایی بالاتر برای وردپرس، با افزونه رایگان LSCache و کش سرور.

تنظیمات کلیدی Nginx در nginx.conf:

worker_processes auto;
worker_connections 2048;
keepalive_timeout 30;
gzip on;
gzip_types text/css application/javascript image/svg+xml;

فعال‌سازی HTTP/2 و در صورت امکان HTTP/3، روی VPS پرترافیک، تأخیر هر درخواست را کم می‌کند.

لایه کش: OPcache، Redis و کش صفحه

سه لایه کش روی VPS که در تجربه من بیشترین اثر را دارند:

1. OPcache: کش کامپایل PHP، که در لایه PHP-FPM توضیح داده شد.
2. Redis یا Memcached: کش آبجکت که نتایج کوئری‌های سنگین دیتابیس را نگه می‌دارد. روی وردپرس، ترکیب Redis با افزونه‌ای مثل Redis Object Cache یا پشتیبانی قالب از این کش، محسوس است.
3. کش صفحه: از سمت وب‌سرور (FastCGI Cache در Nginx یا LSCache در LiteSpeed) یا از افزونه وردپرس.

ترکیب هر سه، در تجربه من روی سایت‌های وردپرسی متوسط، بین ۴۰ تا ۷۰ درصد بهبود TTFB می‌سازد. سنجش با ابزارهای تست سرعت سایت انجام دهید.

تنظیمات هسته لینوکس

چند تنظیم کلیدی هسته که روی VPS به‌طور محسوس اثر می‌گذارند:

# /etc/sysctl.d/99-vps.conf
net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 2048
vm.swappiness = 10
net.core.netdev_max_backlog = 4096
net.ipv4.tcp_fin_timeout = 15

تنظیم vm.swappiness به مقدار پایین (مثل ۱۰) باعث می‌شود هسته تا جای ممکن از swap استفاده نکند. این تنظیم برای VPS روی SSD، به‌خصوص در بارهای تصادفی، تفاوت محسوسی می‌سازد.

مانیتورینگ و آلارم

بدون مانیتورینگ، نمی‌دانید بهینه‌سازی جواب داده یا نه. سه سطح:

• لحظه‌ای: ابزارهای top، htop، iostat برای دیدن وضعیت فعلی.
• تاریخی: Netdata یا Prometheus + Grafana برای ثبت متریک‌ها.
• خارجی: مانیتور uptime و پاسخ‌دهی از بیرون سرور با ابزارهایی مثل UptimeRobot.

آستانه‌های هشدار پیشنهادی: مصرف RAM بالای ۸۵٪ برای بیش از ۵ دقیقه، I/O wait بالای ۲۰٪، load average بالای تعداد هسته. مدیریت کامل سرور در چگونه سرور را مدیریت و نگهداری کنیم آمده است.

جدول مرجع

پرسش‌های کوتاه

آیا روی VPS باید خودم همه چیز را نصب کنم؟ اگر VPS مدیریت نشده (unmanaged) است، بله. اگر مدیریت شده (managed) است، بخشی از این تنظیمات توسط سرویس‌دهنده اعمال می‌شود. تفاوت این دو در VPS مدیریت شده یا مدیریت نشده آمده است.

چقدر طول می‌کشد تا بهینه‌سازی اعمال شود؟ بسته به لایه، بین چند دقیقه تا چند ساعت. تغییرات PHP-FPM و MySQL بلافاصله اثر می‌کنند؛ تغییرات کش سرور باید پس از فعال‌سازی، در چند ساعت اول پایش شوند.

آیا این تنظیمات برای VPS کوچک هم لازم است؟ بله، اما با دوز کوچک‌تر. روی VPS با ۱ گیگابایت RAM، تعداد children کمتر و buffer pool کوچک‌تر است. تنظیمات دقیق برای پلن‌های کوچک در مزایا و معایب VPS آمده است.

سخن آخر

بهینه‌سازی منابع VPS، یک کار یک‌باره نیست؛ یک چرخه تنظیم و اندازه‌گیری است. تجربه من می‌گوید بیشترین بازده از سه لایه اول (PHP-FPM، MySQL و کش آبجکت) می‌آید و لایه‌های بعدی، جزئیات تکمیلی‌اند. اگر امروز فقط سه تنظیم بکنید، این‌ها بیشترین سود را دارند: تنظیم pm.max_children متناسب با RAM، فعال‌سازی OPcache و تنظیم innodb_buffer_pool_size روی دیتابیس. باقی مسیر، تکرار همین چرخه با اندازه‌گیری دقیق است. اگر تجربه‌ای از تنظیمی دارید که روی VPS شما جهش محسوسی ساخت، در دیدگاه‌ها بنویسید؛ همان جزئیات، برای نفر بعدی ارزشمندتر از هر راهنمای عمومی است. ⚙️