Liên tục phải tải lại PHP-FPM


27

Chúng tôi có một máy chủ được tải khá nhiều chạy nginx và PHP-FPM. Chúng tôi có 6 trang web trên máy chủ này, chạy PHP-FPM và nginx. Phần mềm là tất cả các phiên bản 3,8 và WordPress. Cơ sở dữ liệu trên một máy chủ riêng biệt.

Bây giờ, vì đây là những trang web rất phổ biến, chúng tôi thường có 7-8.000 khách truy cập trực tuyến cùng một lúc, với mỗi trang chiếm phần lớn cơ sở dữ liệu. Tôi tin rằng đây là nguyên nhân của các vấn đề của chúng tôi.

Bởi vì chúng tôi có rất nhiều cơ sở dữ liệu lớn trên máy chủ MySQL và vì thực tế, các truy vấn có thể tốt hơn rất nhiều trong phần mềm, tôi nghĩ rằng thỉnh thoảng MySQL sẽ không trả lại kết quả cho PHP một cách kịp thời, tạo ra hiệu ứng xếp tầng cuối cùng khiến mọi thứ chỉ dừng lại cho đến khi chúng ta tải lại PHP-FPM. Sau khi chúng tôi làm điều đó, mọi thứ bắt đầu hoạt động tốt trở lại.

Lý do tôi gặp sự cố khi khắc phục sự cố này là vì tôi thực sự không thể nhận ra bất cứ điều gì từ nhật ký. Trong nhật ký truy vấn chậm của MySQL, tôi thấy không có gì đáng quan tâm khi thời gian chết xảy ra. Trong nhật ký nginx, tôi thấy hàng ngàn mục nhập nói rằng yêu cầu đọc đã hết thời gian hoặc kết nối đã hết thời gian (Tới PHP-FPM). Và trong nhật ký PHP-FPM, tôi thấy rất nhiều dòng có nội dung "hết thời gian thực hiện (31 giây), chấm dứt

Vì vậy, tại thời điểm này tôi hoàn toàn không biết tìm kiếm vấn đề ở đâu. Rõ ràng, bất cứ điều gì đang xảy ra đang xảy ra bởi vì các tập lệnh này đôi khi không thực thi đủ nhanh (Thông thường chúng tải trong một giây, nhưng điều gì đó xảy ra khiến thời gian tải tăng vọt). Điều này xảy ra nhiều lần trong ngày và đã trở thành một vấn đề đối với chúng tôi.

Bây giờ tôi chỉ cần có một crontab để phục vụ tải lại php5-fpm cứ sau 10 phút, điều này sẽ giải quyết vấn đề sự cố. Tất nhiên, khi PHP tải lại, nginx sẽ gây ra lỗi cổng 502, vì vậy đó không phải là một giải pháp.

PHP đang chạy bộ đệm APC, nếu vấn đề đó. Tôi đã đọc ở một vài điểm rằng APC có thể gây treo trong những trường hợp nhất định.

Bất kỳ con trỏ sẽ hữu ích. Tôi thực sự không muốn phải lo lắng về chiếc máy này mọi lúc.

Thêm thông tin có thể được cung cấp tất nhiên. Chỉ cần cho tôi biết những gì bạn cần.

Cập nhật: Tôi vừa sao chép qua apc.php vào một web root và truy cập nó để xem số liệu thống kê của chúng tôi. Mọi thứ có vẻ tốt. Sau đó, tôi nhấp vào liên kết để đi đến Thống kê người dùng và BÙM máy chủ ngay lập tức bị treo. Tôi đã tải lại php-fpm và sau đó tải lại trang thống kê người dùng và nó đã hoạt động tốt. Đợi một phút, tải lại, máy chủ lại treo.

Vì vậy, điều này chắc chắn có liên quan đến APC. Câu hỏi là - Làm thế nào để chúng tôi sửa chữa nó?

Cấu hình APC:

[apc]
apc.enabled="1"
apc.stat = "1"
apc.max_file_size = "2M"
apc.localcache = "1"
apc.localcache.size = "256"
apc.shm_segments = "1"
apc.ttl = "3600"
apc.user_ttl = "7200"
apc.gc_ttl = "3600"
apc.cache_by_default = "1"
apc.filters = ""
apc.write_lock = "1"
apc.num_files_hint= "10000"
apc.user_entries_hint="10000"
apc.shm_size = "1G"
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.include_once_override = "0"
apc.file_update_protection="2"
apc.canonicalize = "1"
apc.report_autofilter="0"
apc.stat_ctime="0"

Cập nhật 2: Chúng tôi đã thực hiện một số tiến bộ về điều này ở đây. Hóa ra plugin bộ nhớ đệm WordPress (W3 Total Cache) là nguyên nhân gây ra sự cố. Chúng tôi vẫn không biết tại sao, nhưng với nó bị vô hiệu hóa, chúng tôi đã chạy PHP gần 4 giờ rồi mà không tải lại, không bị chậm, không gặp sự cố. Chúng tôi vẫn đang sử dụng APC trên các diễn đàn của Diễn đàn và không có vấn đề gì cả. Có cách nào chúng ta có thể xác định TẠI SAO APC bị sập không? Tôi muốn sử dụng nó trên các bản cài đặt WordPress của chúng tôi, nhưng không phải trả giá cho một hệ thống dễ vỡ.


Bạn có thể đăng bất kỳ cài đặt liên quan đến APC bạn có?
Kyle

Vâng, y hay. Làm xong.
Kevin

Bạn có bao nhiêu ram và trao đổi trên máy này? Bao nhiêu được sử dụng khi nó bắt đầu chết?
Kyle

2
APC là một cơn ác mộng khủng khiếp và là nguồn gây ra sự cố như thế này trên một trong những trang web của tôi trong nhiều năm . Cuối cùng tôi đã thoát khỏi nó hoàn toàn; và PHP là vững chắc. Nếu bạn muốn lưu vào bộ đệm, hãy thử Zend Opcache, đây cũng là bộ đệm mặc định từ PHP 5.5.
Michael Hampton

1
Vâng, cuối cùng nó đã trở thành APC đã làm sập PHP. Khi chúng tôi vô hiệu hóa APC, chúng tôi đã ngừng phải khởi động lại PHP liên tục.
Kevin

Câu trả lời:


27

Bạn đang sử dụng php-fpm, vì vậy tôi khuyên bạn nên tích cực hơn với thời gian trẻ em của php-fpm được phép sống. Bạn cần tìm ra điểm ngọt ngào giữa những chủ đề / trẻ em sống ngắn và sự ổn định. Mặc định php-fpm là cách để hào phóng cho bất kỳ hệ thống sản xuất nào, IMHO.

Tôi sẽ giảm số lượng pm.max_Vquests cho nhóm sản xuất của bạn. Tôi nghĩ mặc định là 200. Tôi sẽ bắt đầu từ 50 và xem nơi sẽ đưa bạn đến.

Không / bổ sung cho điều đó, bạn cũng có thể thử các tùy chọn toàn cầu này (AFAIK tất cả chúng đều bị tắt theo mặc định):

emergency_restart_threshold=3
emergency_restart_interval=1m
process_control_timeout=5s

Điều đó có nghĩa là gì? Nếu 3 con PHP-FPM xử lý thoát với SIGSEGV hoặc SIGBUS (tức là sự cố) trong vòng 1 phút thì PHP-FPM có nghĩa vụ tự động khởi động lại. Các tiến trình con chờ 5s cho một phản ứng về tín hiệu từ chủ.

Điều này sẽ giữ cho nhóm các luồng công nhân PHP của bạn đẹp, mới và sạch sẽ. Công nhân càng lâu được phép cung cấp các yêu cầu, nó sẽ càng không ổn định. Cũng có nguy cơ rò rỉ bộ nhớ cao hơn.

Đây là một tổng quan đẹp về tất cả các tùy chọn cấu hình tôi đã đề cập ở đây, cũng như các tùy chọn khác: http://myjeeva.com/php-fpm-configuration-101.html

Hy vọng những lời khuyên này sẽ giúp bạn! Hãy nhớ điều chỉnh và quan sát, thật không may, dường như không có quy tắc nào cho tất cả điều này, có quá nhiều biến số ảnh hưởng đến hành vi và sự ổn định của PHP.


1
Ý kiến ​​của bạn về việc chỉ sử dụng cron để khởi động lại php5-fpm mỗi giờ?
CMCDragonkai

2
Đó là một cách khá đơn giản để làm điều đó, và nó có thể không hoạt động. PHP-FPM có một số tinh chỉnh được tích hợp sẵn, vì vậy tốt hơn là sử dụng khả năng điều chỉnh đó.
Rouben

1
Câu trả lời này chỉ cho tôi đi đúng hướng. Tôi thấy một vấn đề tương tự như thế này bản thân mình, các giải pháp đối với tôi là thay đổi pmtừ dynamicđến ondemandvà tất cả dường như được làm việc lớn bây giờ với tất cả các giá trị mặc định khác.
llanato

(trong php-fpm.conf) nó phải là '=' thay vì '' tách khóa và giá trị. khẩn
cấp_restart_thr Ngưỡng

Tôi đang nhận đượcERROR: [/etc/php/7.0/fpm/pool.d/www.conf:135] unknown entry 'emergency_restart_threshold'
deweydb
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.