2013-08-02 24 views
8

Tôi đã gặp phải lỗi ngẫu nhiên 500 Internal Server trên các trang web dựa trên PHP/MySQL của tôi trên các máy chủ chia sẻ khác nhau. Tôi đang sử dụng PHP 5.2.17 thông qua CGI/FastCGI trên một máy chủ Linux được chia sẻ. Khi tôi nhìn vào nhật ký, tôi thấy điều này:Ngẫu nhiên PHP FastCGI/Kết nối được đặt lại theo tiêu đề ngang hàng/không đầy đủ

[error] [client 75.71.176.224] (104)Connection reset by peer: FastCGI: comm with server "/dev/shm/blackmou-php.fcgi" aborted: read failed, referer: ... 
[error] [client 75.71.176.224] FastCGI: incomplete headers (0 bytes) received from server "/dev/shm/blackmou-php.fcgi", referer: ... 
[error] [client 75.71.176.224] (104)Connection reset by peer: FastCGI: comm with server "/dev/shm/blackmou-php.fcgi" aborted: read failed, referer: ... 
[error] [client 75.71.176.224] FastCGI: incomplete headers (0 bytes) received from server "/dev/shm/blackmou-php.fcgi", referer: ... 

Bất kỳ ai biết cách giải quyết vấn đề này?

+0

Bất kỳ ai biết cách giải quyết vấn đề này? –

+0

Bạn có cơ hội gặp GoDaddy không? Chúng tôi đã gặp sự cố tương tự với một trang web mà chúng tôi đã lưu trữ ở đó. – andrewsi

+0

Chúng tôi đã gặp lỗi với 1 & 1 và Nexcess. Chúng tôi đã dành rất nhiều thời gian để xem xét điều này. Chúng tôi không tìm thấy vấn đề chính xác, nhưng nghĩ rằng đó là một vấn đề liên quan đến bộ nhớ. Chúng tôi đã đăng toàn bộ trang web lên một máy chủ khác và không có vấn đề gì. –

Trả lời

11

Vấn đề này thường không chỉ là máy chủ cụ thể, mà còn là nhà phát triển có liên quan, tùy thuộc vào cấu hình. Tuy nhiên một số máy chủ khá nghiêm ngặt với FastCGI và sẽ giới hạn khả năng của bạn. Nói chung dễ dàng hơn khi chạy mà không cần sử dụng FastCGI và chỉ sử dụng mod_php trừ khi bạn có nhu cầu cụ thể để sử dụng FastCGI trong ứng dụng của mình.

Chúng tôi sẽ cần xem trình bao bọc fcgi của bạn (có gì trong /dev/shm/blackmou-php.fcgi) hoặc .htaccess để sinh ra FastCGI, để hỗ trợ bạn tốt hơn mà không biết tệp nào và mã trên các tệp đó vấn đề xảy ra với. Máy chủ của bạn có sử dụng Apache, LightHttpd hoặc Nginx (hoặc kết hợp) không? Vào thời điểm đó, tôi khuyên bạn nên cập nhật để sử dụng PHP 5.3.9+

Vì điều này có thể gây ra bởi bất kỳ vấn đề nào, FastCGI ngăn chặn trang web/tập lệnh của bạn khỏi bị tấn công bởi Dịch vụ từ chối hoặc bị lỗi do bộ nhớ rò rỉ, vv (EG: cố gắng xử lý 80.000 kết nối đơn giản bằng cách thả và giới hạn số lượng yêu cầu hoặc bị kẹt trong vòng lặp vô tận bằng cách định thời gian và chấm dứt quá trình)

Lỗi này nói chung là do idle_timeout (30 giây theo mặc định) hoặc giới hạn tối đa cho trẻ em. Nó cũng có thể được gây ra bởi một người nào đó bắt đầu một tập lệnh chạy dài và đóng trình duyệt/kết nối của họ trước khi tập lệnh hoàn tất.

FastCGI khởi chạy trình bao bọc quy trình của nó, thực hiện lệnh, hết thời gian trước khi hoàn tất quá trình, kết nối được xem là đặt lại bởi đồng đẳng.

Ví dụ khác là số trẻ em tối đa (maxProcesses) đạt được (EG: nhiều trang web hiển thị 2 hoặc 4 làm ví dụ khi thực tế bạn có thể cần 20 hoặc 50 tùy thuộc vào lưu lượng truy cập trung bình) Nếu tất cả trẻ em hiện đang hoạt động và yêu cầu/kết nối bổ sung được thực hiện, trẻ em được giới hạn ở maxProcesses, mà FastCGI sẽ không chia sẻ các trẻ đang hoạt động, vì vậy trước tiên phải chấm dứt quá trình và bắt đầu quá trình mới hoặc yêu cầu tùy thuộc vào cấu hình của bạn .

Dưới đây là một số chi tiết thông tin về các thiết lập:

http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html

http://www.fastcgi.com/drupal/node/10

Wrapper Ví dụ

PHP_FCGI_CHILDREN=0 #no limit 
export PHP_FCGI_CHILDREN 
PHP_FCGI_MAX_REQUESTS=10000 
export PHP_FCGI_MAX_REQUESTS 

CẬP NHẬT

Để thêm vào điều này, điều này cũng có thể được gây ra bởi giới hạn bộ nhớ php

Nếu ở trên không giải quyết được vấn đề của bạn, hãy cập nhật php của bạn.ini để tăng memory_limit

+1

Đây chính xác là nó. Đó là một sự kết hợp của quá nhiều quá trình và các chức năng giết chết memory_limit trên trang web. –

+0

Đây là thông tin tuyệt vời, cảm ơn bạn! – workflow

0

cho bất cứ ai tìm kiếm để biết thêm:

trong trường hợp của tôi, có một vấn đề mã. Trên một yêu cầu http đến, một cuộc gọi đến một URL nội bộ đã được thực hiện từ bên trong mã do đó tạo ra một loại bế tắc của tình huống.

Điều này dẫn đến treo các quy trình PHP và đưa máy chủ xuống. chúng tôi đã sử dụng file_get_contents ('URL') hoặc cURL() trong hàm gọi lại của chúng tôi. Sau đó chúng tôi thay thế nó bằng một hàm drupal đơn giản cung cấp cho chúng ta các giá trị từ DB.

Công cụ NewRelic đã giúp tôi xác định hàm đã mất rất nhiều thời gian để trả lời.

Một cách khác để xác định điều này sẽ là thực hiện drupal_watchdog trên hàm gọi lại của chúng tôi và xác minh nhật ký khi máy chủ gặp sự cố.

hy vọng điều này sẽ hữu ích.

+1

Một công cụ miễn phí tuyệt vời khác để sử dụng là cấu hình Xdebug và chức năng theo dõi. Họ có thể đánh giá ứng dụng của bạn, cho bạn biết tất cả các yêu cầu và chuyển hướng xảy ra và chỉ định các hàm nào mất nhiều thời gian nhất để thực thi. Nó chạy khi bạn chạy tập lệnh của bạn, đổ các bản ghi mà bạn đã chỉ định và bạn có thể sử dụng trình xem nhật ký xdebug để vẽ ra các kết quả. Ngoài ra hầu hết các IDE có thể được tích hợp để sử dụng nó, thậm chí từ các máy chủ từ xa và trình duyệt của bạn. – fyrye

+0

cảm ơn thông tin. Hãy thử xem. –

Các vấn đề liên quan