2008-10-06 38 views
10

Chúng tôi chạy một trang web có kích thước trung bình nhận được vài trăm nghìn lượt xem trang mỗi ngày. Cho đến cuối tuần trước, chúng tôi chạy với tải thường dưới 0,2 trên một máy ảo. Hệ điều hành là Ubuntu.Apache sử dụng CPU quá mức

Khi triển khai phiên bản mới nhất của ứng dụng, chúng tôi cũng đã thực hiện nâng cấp apt-get trước khi triển khai. Sau khi chúng tôi đã triển khai, chúng tôi nhận thấy rằng tải trên CPU đã tăng đột biến (đôi khi đạt 10 và dừng để phản hồi yêu cầu trang).

Chúng tôi đã cố gắng đổ đầy một phút của dữ liệu lược tả Xdebug từ PHP, nhưng nhìn qua nó chỉ tiết lộ một vài phần hơi chậm, nhưng không có gì để giải thích bước nhảy lớn.

Chúng tôi hiện đang khá chắc chắn rằng không có gì trong phiên bản mới của trang web của chúng tôi đang kích hoạt sự cố, nhưng chúng tôi không có cách nào để đảm bảo. Chúng tôi đã khôi phục rất nhiều thay đổi, nhưng vấn đề vẫn tồn tại.

Khi xem xét quy trình, chúng tôi thấy rằng các quy trình Apache đơn sử dụng khá nhiều CPU trong một khoảng thời gian dài hơn mức cần thiết. Tuy nhiên, khi sử dụng strace về quá trình bị ảnh hưởng, chúng ta không bao giờ nhìn thấy bất cứ điều gì nhưng

accept(3, 

và nó được treo trong một thời gian trước khi nhận một kết nối mới, vì vậy chúng tôi không thể thực sự nhìn thấy những gì đang gây ra vấn đề.

Ngăn xếp là PHP 5, Apache 2 (prefork), MySQL 5.1. Hầu hết mọi thứ chạy qua Memcached. Chúng tôi đã thử APC và eAccelerator.

Vậy, bước tiếp theo của chúng ta là gì? Có bất kỳ phương pháp lược tả nào mà chúng tôi đã bỏ qua/không biết?

+0

Bạn đã nâng cấp hệ thống lên phiên bản nào? Tôi có nghĩa là a) PHP, b) Apache và c) memcached. – Georgi

+0

Tôi không có nhật ký về điều đó, thật không may. Theo như tôi biết, không có nhật ký apt-get/aptitude. –

Trả lời

11

Câu trả lời cuối cùng không liên quan đến Apache. Như đã đề cập, chúng tôi đã ở trên một máy ảo. Các phiên người dùng của chúng tôi khá lớn (nghĩ 500kB cho mỗi người dùng đang hoạt động), vì vậy chúng tôi có rất nhiều đĩa IO. Đĩa đã gần đầy, có nghĩa là Ubuntu đã dành rất nhiều thời gian di chuyển mọi thứ xung quanh (hoặc vì vậy chúng tôi nghĩ). Không có cách nào dễ dàng để mở rộng đĩa (vì nó không được thiết lập đúng cho VMWare). Điều này hoàn toàn bị giết hiệu suất, và Apache và MySQL đôi khi sẽ sử dụng CPU 100% (trong một thời gian rất ngắn), và hệ thống sẽ rất chậm để cập nhật các mét sử dụng CPU mà nó dường như bị mắc kẹt ở đó.

Chúng tôi đã thiết lập một máy ảo mới (cũng đã cho chúng tôi cơ hội ghi chép kỹ lưỡng mọi thứ trên máy chủ). Trên máy ảo mới, chúng tôi đã phân bổ nhiều không gian đĩa và chuyển các phiên sang bộ nhớ (sử dụng memcached). Tải của chúng tôi giảm xuống 0,2 khi sử dụng ngoài giờ cao điểm và khoảng 1 lần sử dụng gần nhất (trên máy ảo 2 CPU). Di chuyển các phiên vào memcached mất rất nhiều đĩa IO đi (chúng tôi đã liên tục sử dụng khoảng 2MB/s của đĩa IO, mà là rất xấu).

Kết luận; đôi khi bạn chỉ cần bắt đầu lại ... :)

1

Có lẽ bạn đang sử dụng MPM của nhân viên trước và bây giờ bạn không?

Tôi biết PHP5 không hoạt động với MPM của người lao động. Trên máy chủ Ubuntu của tôi, PHP5 chỉ có thể được cài đặt với MPM Prefork. Có vẻ như mô-đun PHP5 không tương thích với phiên bản đa luồng của Apache.

Tôi tìm thấy một liên kết ở đây sẽ cho bạn thấy làm thế nào để có được hiệu suất tốt hơn với mod_fcgid

Để xem những gì MPM công nhân là thấy here.

+0

Apache vẫn đang chạy bằng prefork. PHP đang hoạt động tốt. –

+0

Trong số các ý tưởng sau đó tôi sợ tôi nghĩ rằng bạn có thể đã sử dụng php4 trong phiên bản cũ của ứng dụng và bây giờ kể từ khi cập nhật lên php5 apapche đang chạy trong chế độ prefork. Phiên bản cũ của ứng dụng có sử dụng php4 không? –

+0

Có thể khoảng một tháng tuổi. Chúng tôi nâng cấp trước mỗi lần triển khai. Chúng tôi có thể ngừng làm điều đó sau khi vấn đề này, mặc dù ... :) –

1

Tôi muốn sử dụng dTrace để giải quyết bí ẩn này ... nếu nó đang chạy trên Solaris hoặc Mac ... nhưng kể từ khi Linux không có nó, bạn có thể muốn thử Systemtap, tuy nhiên tôi không thể nói bất cứ điều gì về khả năng sử dụng của nó vì tôi chưa sử dụng nó.

Với DTrace bạn có thể dễ dàng sniff ra các thủ phạm trong một ngày, và hy vọng với Systemtap nó sẽ là tương tự

+0

Systemtap có vẻ hơi phức tạp một chút. –

0

Một tùy chọn khác mà tôi không thể đảm bảo với bạn sẽ làm bất cứ tốt, nhưng nó nhiều hơn giá trị cố gắng. Là để đọc các thay đổi chi tiết cho phiên bản mới, và xem xét những gì có thể đã thay đổi mà từ xa có thể ảnh hưởng đến bạn.

Đi qua các danh sách thay đổi đã lưu tôi nhiều lần. Đặc biệt là khi một số tùy chọn cấu hình đã thay đổi và khi một cái gì đó không được chấp nhận. Trường hợp xấu nhất là nó sẽ cung cấp cho bạn một số manh mối về nơi để xem tiếp theo

+0

Đối với trường hợp này, nó đã không thực sự giúp đỡ. Ban đầu, chúng tôi đã làm điều này và đã tìm thấy một số vấn đề về hiệu suất, nhưng không may là việc quay lại những thay đổi đó không giải quyết được vấn đề. –

5

Thấy một cuộc gọi accept() từ quá trình Apache của bạn không phải là bất thường - đó là máy chủ web đang chờ yêu cầu mới.

Trước hết, bạn muốn thiết lập thông số của tải là gì. Một cái gì đó như

vmstat 1 

sẽ cho bạn biết hệ thống của bạn đang làm gì. Tìm trong các cột 'hoán đổi' và 'io'. Nếu bạn thấy bất kỳ điều gì khác ngoài '0' trong cột 'si' và 'so', hệ thống của bạn sẽ hoán đổi vì điều kiện bộ nhớ thấp. Cân nhắc giảm số lượng con chạy Apache, hoặc ném thêm RAM vào máy chủ của bạn.

Nếu RAM không phải là vấn đề, hãy xem cột 'cpu'. Bạn quan tâm đến các cột 'chúng tôi' và 'sy'. Điều này cho bạn thấy tỷ lệ phần trăm thời gian CPU đã sử dụng trong các quy trình hoặc hệ thống của người dùng. Số 'số' cao của chúng tôi chỉ ngón tay vào Apache hoặc tập lệnh của bạn - hoặc có thể có thứ gì đó khác trên máy chủ.

Chạy

top 

sẽ cho bạn thấy những quy trình là tích cực nhất.

Bạn đã loại trừ cơ sở dữ liệu của mình chưa? Nguyên nhân phổ biến nhất của tải cao bất ngờ mà tôi đã thấy trên các ngăn xếp LAMP sản xuất là các truy vấn cơ sở dữ liệu. Bạn có thể đã triển khai mã mới với một truy vấn đắt tiền trong đó; hoặc đã đến mức có đủ hàng trong tập dữ liệu của bạn để khiến các truy vấn trước đây rẻ tiền trở nên đắt đỏ.

Trong giai đoạn tải cao, làm

echo "show full processlist" | mysql | grep -v Sleep 

để xem nếu có một trong hai truy vấn dài chạy, hoặc số lượng lớn các truy vấn cùng hoạt động cùng một lúc. Các công cụ mysql khác sẽ giúp bạn tối ưu hóa các công cụ này.

Bạn có thể thấy hữu ích khi định cấu hình và sử dụng mod_status cho Apache, điều này sẽ cho phép bạn xem yêu cầu mà mỗi đứa trẻ Apache đang phân phối và thời gian thực hiện nó.

Cuối cùng, hãy thiết lập một số thiết lập giám sát thống kê dài hạn. Một cái gì đó như zabbix là đơn giản để cấu hình, và sẽ cho phép bạn theo dõi việc sử dụng tài nguyên theo thời gian, như vậy nếu mọi thứ trở nên chậm chạp, bạn có các đường cơ sở lịch sử để so sánh và một ieda tốt hơn khi các vấn đề bắt đầu.

+0

Vấn đề là Apache sử dụng CPU. Có nhiều hơn RAM đủ (chúng tôi chạy trên 512MB trước khi nâng cấp, bây giờ chúng tôi có 2GB). Không có sự trao đổi đang xảy ra. MySQL báo cáo truy vấn chậm không có gì bất thường. Hiện tại chúng tôi đang thấy mức tăng tải là 40 khi sử dụng nhiều. –

+0

mod_status là đặt cược tốt nhất của bạn từ đây. Ngoài ra, để ngăn chặn tất cả các quy trình Apache của bạn, thay vì chỉ là phụ huynh, hãy thử: ps aux | grep h [t] tpd | awk '{print' -p '$ 2}' | xargs strace –

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