PHP-FPM và OPcache: xử lý worker cạn, deploy code mới và cache opcode thế nào để production ổn định?

Chào bạn Thành Hải, PHP-FPM tuning cần bắt đầu từ workload và giới hạn máy chủ, không phải một con số max_children phổ biến. Mỗi worker có memory footprint khác nhau tùy framework, extension, request path và dữ liệu xử lý; đặt quá cao có thể làm host swap, còn quá thấp tạo queue khiến latency tăng. Quy trình nên là: 1. Đo request rate, latency percentile, queue/active process, CPU, RSS của worker, lỗi timeout và memory của host trong giờ cao điểm. 2. Ước lượng max_children từ memory budget thật sau khi chừa phần cho OS, MySQL/Redis/nginx và spike; sau đó load-test/đo lại thay vì tin một phép chia duy nhất. 3. Chọn process manager theo loại tải, đặt timeout để worker kẹt không tồn tại mãi và cấu hình recycle theo request/memory khi có dấu hiệu leak. Nhưng đừng dùng recycle để che một endpoint có bug hoặc I/O chậm. 4. Với OPcache, theo dõi hit rate, memory, interned strings, số script và invalidation. Deploy nên bất biến/atomic: release mới ở đường dẫn mới, switch symlink/nginx upstream có kiểm soát và reload nhẹ PHP-FPM khi cần theo quy trình của bạn. 5. Không dùng reset OPcache tùy tiện trên mọi request. Hãy kiểm thử deploy/rollback dưới tải, gồm cả worker background và cron. Một dashboard chỉ có CPU không đủ. Cần liên kết saturation của FPM, time ở upstream/database, memory pressure và tốc độ lỗi để tìm đúng nút thắt.

Chào bạn Hải, tôi cũng từng gặp tình trạng này khi traffic tăng đột biến. Đối với PHP‑FPM, bạn nên theo dõi các chỉ số như pm.max_children, pm.start_servers, pm.min/max_spare_servers thông qua trang trạng thái php‑fpm hoặc lệnh `ps aux | grep php`. Điều chỉnh max_children dựa trên số request đồng thời bạn mong muốn xử lý (ví dụ bắt đầu với 50–100) và thiết lập pm=dynamic để có thể mở rộng khi cần. Với OPcache, kích hoạt `opcache.validate_timestamps=0` và sử dụng `opcache.revalidate_freq=60` để cân bằng giữa hiệu năng và tính mới của code. Khi deploy, hãy restart worker

Khi lượng truy cập tăng đột biến, CPU và bộ nhớ thường là nguyên nhân chính khiến request chậm lại. Bắt đầu với việc đo lường cơ bản: theo dõi số process của php-fpm (`pm.max_children`), thời gian xử lý trung bình của mỗi worker và mức sử dụng bộ nhớ thông qua `ps aux` hoặc công cụ giám sát. Thiết lập `pm.mode = dynamic` với `pm.max_children` ban đầu bằng tổng số request có thể xử lý đồng thời (ví dụ: CPU cores × hệ số an toàn 2–3). Sử dụng `pm.max_requests = 1000` để buộc cycle worker, tránh rò rỉ bộ nhớ. Đối với OPcache, hãy bật `opcache.validate_timestamps = 0` trong production và thiết lập `opcache.revalidate_freq = 60` (hoặc cao hơn) để cân bằng giữa tính mới và hiệu

Mình đồng ý hướng đo trước rồi mới chỉnh. Với chuyện worker cạn, nên tách metric theo