اگر وردپرس یا یک سایت PHP گاهی کند میشود اما در access log و error log سرنخ واضحی نمیبینید، PHP-FPM Slow Log یکی از دقیقترین ابزارها برای پیدا کردن اسکریپت یا تابعی است که اجرای درخواست را معطل کرده است. در این راهنما Slow Log را با آستانه کنترلشده فعال میکنیم، یک درخواست کند را بازتولید میکنیم، Stack Trace را میخوانیم، علت را اصلاح میکنیم و بعد تنظیمات را Verify یا Rollback میکنیم.
PHP-FPM Slow Log چه چیزی را نشان میدهد؟
PHP-FPM برای هر Pool میتواند درخواستهایی را که بیشتر از زمان تعیینشده طول میکشند ثبت کند. دو Directive اصلی request_slowlog_timeout و slowlog هستند. اولی مشخص میکند بعد از چند ثانیه از اجرای درخواست، Backtrace ثبت شود و دومی مسیر فایل لاگ را تعیین میکند. این ابزار با لاگ خطای PHP فرق دارد: هدفش پیدا کردن مسیر اجرای کند است، نه فقط خطاهای Fatal یا Warning.
چه زمانی Slow Log مفید است؟
- TTFB سایت بالا است ولی CPU همیشه 100٪ نیست.
- بعضی درخواستهای wp-admin، WooCommerce یا API تصادفی کند میشوند.
- یک افزونه یا Theme مشکوک است اما غیرفعالکردن تصادفی افزونهها روش مناسبی نیست.
- PHP-FPM Workerها مدت زیادی Busy میمانند و میخواهید محل توقف کد را پیدا کنید.
برای مشکلات عمومیتر عملکرد وردپرس، ابتدا راهنمای رفع کندی وردپرس را هم ببینید. اگر Site Health مشخصاً Autoload را گزارش میکند، مسیر عیبیابی Autoload و wp_options جدا است.
مرحله ۱: مطمئن شوید سایت واقعاً با PHP-FPM اجرا میشود
قبل از تغییر تنظیمات، سرویسها و Poolهای فعال را بررسی کنید. نام سرویس بسته به توزیع و نسخه PHP متفاوت است:
systemctl list-units --type=service | grep -E 'php.*fpm'
ps aux | grep '[p]hp-fpm'
روی Ubuntu ممکن است نامی مثل php8.3-fpm.service ببینید. در cPanel نیز ابتدا باید PHP-FPM برای دامنه موردنظر فعال باشد.
مرحله ۲: فایل Pool درست را پیدا کنید
در سرورهای معمولی، Poolها اغلب زیر یکی از مسیرهای /etc/php/*/fpm/pool.d/ قرار دارند. مسیر دقیق را حدس نزنید؛ Config فعال را از خود PHP-FPM بگیرید:
php-fpm -tt 2>&1 | less
# یا با باینری نسخه نصبشده، برای مثال:
php-fpm8.3 -tt 2>&1 | less
قبل از ویرایش، از فایل Pool بکاپ بگیرید:
cp /etc/php/8.3/fpm/pool.d/www.conf /etc/php/8.3/fpm/pool.d/www.conf.bak
مرحله ۳: Slow Log را فعال کنید
در Pool موردنظر این دو مقدار را تنظیم کنید:
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
آستانه ۵ ثانیه برای شروع محافظهکارانه است. مستند cPanel برای تست نمونهای با ۱ ثانیه ارائه میکند، اما هشدار میدهد که Timeout خیلی پایین میتواند لاگ بسیار بزرگی بسازد. در Production مقدار را متناسب با SLA و زمان طبیعی درخواستها انتخاب کنید.
دایرکتوری لاگ باید برای فرآیند FPM قابل استفاده باشد. اگر مسیر سفارشی میسازید، مالکیت و Permission را با مدل امنیتی سرور خود هماهنگ کنید و از chmod 777 استفاده نکنید.
مرحله ۴: قبل از Reload کانفیگ را تست کنید
php-fpm8.3 -t
اگر پیام موفقیتآمیز بودن تست Config را گرفتید، سرویس را Reload کنید:
systemctl reload php8.3-fpm
systemctl status php8.3-fpm --no-pager
اگر توزیع یا کنترلپنل شما Reload را پشتیبانی نمیکند، روش رسمی همان محیط را استفاده کنید. Restart بدون بررسی Config میتواند سایت را از دسترس خارج کند.
مرحله ۵: درخواست کند را بازتولید کنید
صفحه یا عملیاتی را که کند است چند بار اجرا کنید و همزمان Slow Log را دنبال کنید:
tail -f /var/log/php-fpm/www-slow.log
برای اندازهگیری سمت HTTP نیز میتوانید از curl استفاده کنید:
curl -o /dev/null -s -w 'TTFB=%{time_starttransfer} Total=%{time_total}n' https://example.com/
هدف این است که کندی را با یک Timestamp مشخص به Backtrace داخل Slow Log وصل کنید.
مرحله ۶: Stack Trace را چطور بخوانیم؟
به آخرین Frame اکتفا نکنید. چند Frame متوالی را بخوانید و دنبال مسیر فایل، Plugin، Theme یا Library تکرارشونده بگردید. مثال فرضی:
[0x00007f...] mysqli_query() /var/www/html/wp-includes/class-wpdb.php:...
[0x00007f...] get_option() /var/www/html/wp-content/plugins/example-plugin/...php:...
این خروجی بهتنهایی ثابت نمیکند افزونه مقصر قطعی است؛ ممکن است Query کند، API خارجی، قفل فایل، DNS یا منابع ناکافی باعث توقف شده باشد. Slow Log محل توقف را محدود میکند تا تست بعدی هدفمند شود.
سناریوهای رایج بعد از پیدا کردن نقطه کندی
Query دیتابیس یا wp_options
اگر Stack مرتباً به Optionها یا Queryهای دیتابیس میرسد، Query و حجم داده را بررسی کنید. برای Autoload بزرگ از آموزش سبککردن wp_options استفاده کنید؛ حذف تصادفی Optionها خطرناک است.
Plugin یا Theme
روی Staging یا در بازه نگهداری، همان درخواست را با غیرفعالسازی کنترلشده جزء مشکوک مقایسه کنید. قبل و بعد از تغییر، TTFB و Slow Log را ثبت کنید تا نتیجه قابل اندازهگیری باشد.
API خارجی یا DNS
اگر کد روی درخواست HTTP خارجی میایستد، Timeout، DNS resolution و دسترسی شبکه را جداگانه تست کنید. افزایش بیدلیل max_execution_time درمان علت نیست و فقط میتواند Worker را مدت بیشتری اشغال کند.
کمبود Worker
اگر همه Workerها Busy هستند، Slow Log کمک میکند بفهمید آیا Workerها روی یک مسیر کد مشابه گیر کردهاند. قبل از افزایش pm.max_children مصرف RAM هر Worker و ظرفیت واقعی سرور را اندازه بگیرید؛ افزایش کورکورانه میتواند OOM ایجاد کند.
Log Rotation را فراموش نکنید
Slow Log میتواند سریع رشد کند. cPanel نیز صریحاً توصیه میکند اگر قرار است آن را فعال نگه دارید، Log Rotation تنظیم شود. نمونه پایه:
/var/log/php-fpm/*-slow.log {
daily
rotate 7
compress
missingok
notifempty
copytruncate
}
مسیر و روش Rotation را با توزیع و شیوه بازکردن فایل توسط FPM هماهنگ کنید. بعد از اعمال، Config لاگروت را با حالت Debug بررسی کنید:
logrotate -d /etc/logrotate.conf
Verify: از کجا بفهمیم مشکل واقعاً حل شده؟
- همان URL یا عملیات قبلی را با شرایط مشابه دوباره اجرا کنید.
- TTFB و Total Time را با مقادیر قبل مقایسه کنید.
- بررسی کنید درخواست دیگر از آستانه Slow Log عبور نمیکند.
- وضعیت PHP-FPM و Error Log را برای خطای جدید چک کنید.
- اگر تغییر روی افزونه، Query یا API بوده، چند مسیر مهم سایت و Checkout/Login را نیز Smoke Test کنید.
systemctl status php8.3-fpm --no-pager
tail -n 50 /var/log/php-fpm/www-slow.log
Rollback و خاموشکردن Slow Log
اگر تغییر Config مشکل ایجاد کرد، فایل بکاپ Pool را برگردانید، Config را تست و سپس Reload کنید:
cp /etc/php/8.3/fpm/pool.d/www.conf.bak /etc/php/8.3/fpm/pool.d/www.conf
php-fpm8.3 -t && systemctl reload php8.3-fpm
بعد از پایان عیبیابی میتوانید request_slowlog_timeout را غیرفعال یا روی آستانه Production مناسب تنظیم کنید. فایل لاگ تشخیصی را بیدلیل و بدون Rotation با Timeout پایین رها نکنید.
جمعبندی
PHP-FPM Slow Log بهجای حدسزدن درباره علت کندی، یک Backtrace از درخواستهایی میدهد که از آستانه تعیینشده عبور کردهاند. مسیر درست این است: Pool فعال را پیدا کنید، Backup بگیرید، request_slowlog_timeout و slowlog را تنظیم کنید، Config را قبل از Reload تست کنید، کندی را بازتولید کنید، Stack را با لاگها و اندازهگیری HTTP تطبیق دهید و فقط علت واقعی را اصلاح کنید. اگر کندی سایت شما به محدودیت منابع هاست، پردازش PHP یا فشار همزمان درخواستها مربوط است، میتوانید پلنهای هاست وانسرور را متناسب با نیاز سایت بررسی کنید.
منابع فنی: PHP Manual — FPM Configuration و cPanel — PHP-FPM Slow Log.