2012-02-14 33 views
7

Chạy WordPress trên IIS 7 (Windows Server 2008) với WP-Supercache theo IIS.net's guide.WordPress trên IIS 7 php-cgi hogging CPU

Được chạy rất tốt nhưng gần đây chúng tôi đã thay đổi các điều khoản trên một số thư mục và mật khẩu quản trị và chúng tôi đang nhận được rất nhiều đột biến trong việc sử dụng CPU của chúng tôi là kết quả của quá trình PHP-cgi.exe.

cpu usage

php-cgi.exe processes

Điều này dẫn tôi để tin rằng nó không phải bộ nhớ đệm tuy nhiên các trang mình có "Cached với WP-Supercache" ý kiến ​​ở phía dưới, và bộ nhớ đệm dường như được làm việc một cách chính xác.

Còn vấn đề nào khác có thể xảy ra ở đây?

+1

Bạn có thể thêm bất kỳ thông tin bổ sung nào như nhật ký, thời gian hiển thị trang, cho dù bạn đã bật xdebug, v.v ... không? Đối với một, Wordpress sử dụng rất nhiều bộ nhớ (6MB +).Hai, wordpress plugins sử dụng rất nhiều bộ nhớ (cài đặt bất cứ điều gì thêm gần đây?). Ba, Windows server sử dụng rất nhiều bộ nhớ so với một hộp debian chạy nginx (chỉ có 40MB). – Xeoncross

Trả lời

1

Nhìn vào nhiệm vụ đó mgr trông giống như thiếu bộ nhớ cache trên mọi yêu cầu. Thêm vào đó bài báo có từ năm 2008 rất khó để nói liệu các hướng dẫn được viết có còn hiệu quả hay không. Một cái gì đó với WP-SuperCache có thể đã thay đổi.

Tôi khuyên bạn nên sử dụng W3 Total Cache. Tôi đã thử nghiệm rộng rãi với nó trên Windows Server 2008 và IIS 7 và nó hoạt động rất tốt. Nó cũng tương thích và tận dụng phần mở rộng WinCache cho PHP. Có một số tính năng tuyệt vời khác nữa nếu bạn quan tâm, giảm thiểu, hỗ trợ CDN, v.v. Đó là một plugin hiệu suất thực sự tuyệt vời cho WordPress. Bạn có thể nhận các plugin ở đây, http://wordpress.org/extend/plugins/w3-total-cache/

một số thứ khác để kiểm tra ...

kích thước là gì hồ bơi ứng dụng? (# of processes?) Đảm bảo bạn đang sử dụng PHP 5.3. Đảm bảo bạn đang sử dụng WinCache. Đảm bảo đặt MaxInstanceRequests thành một cái gì đó nhỏ hơn PHP_FCGI_MAX_REQUESTS. Chắc chắn không cho phép PHP xử lý việc tái tạo nhóm ứng dụng. Mặc định là 10K yêu cầu. Nếu bạn thấy các kết quả này trong quá trình kiểm tra tải thì đây có thể là nguyên nhân. Tăng MaxInstanceRequests và giữ nó nhỏ hơn PHP_FCGI_MAX_REQUESTS.

Hy vọng điều đó sẽ hữu ích.

8

Tôi nghĩ rằng tôi có thể đã tìm ra giải pháp hoặc ít nhất một vòng làm việc cho vấn đề này, ít nhất nó dường như đang làm việc cho tôi một cách đáng tin cậy.

Hãy thử thiết lập các Instances Max thiết lập, dưới IIS Server -> Cài đặt FastCGI, để 1.

Dường như với tôi rằng chỉ các yêu cầu nhất định đã gây ra một quá trình php-cgi.exe đi rogue và hog cpu, thường là khi cập nhật bài đăng. Khi đọc các bài viết khác về vấn đề này, một trong số họ đã đề cập đến thiết lập Max Instances và nó được thiết lập mặc định là 0 hoặc tự động. Tôi tự hỏi liệu điều này có thể không có tác dụng tốt hay không khi mọi thứ không như vậy. Tôi đoán (nhưng đây không phải là lĩnh vực chuyên môn của tôi) nếu một yêu cầu nhất định đang gây ra quá trình khóa, vì vậy FastCGI chỉ tạo ra một yêu cầu khác, trong khi rời khỏi vị trí đầu tiên tại chỗ. Bằng cách nào đó có vẻ như chỉ có một ví dụ duy nhất cho phép PHP chuyển từ khóa và CPU vẫn được kiểm soát.

Đối với các máy chủ có yêu cầu cao cấp, hãy đặt FastCGI thành một phiên bản duy nhất có thể không lý tưởng, nhưng chắc chắn sẽ đánh bại sự chậm trễ mà tôi đã nhận được trước đây. Được sử dụng kết hợp với WP-SuperCache và WinCache, mọi thứ dường như đã được tung ra một cách độc đáo.

+1

Tôi upvoting câu trả lời này bởi vì trong khi nó không giải quyết gốc của vấn đề, nó không mua thời gian để sắp xếp ra gốc. –

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