Tại sao Apache chạy hoang dã và giết chết MySQL?

Apache đã vượt khỏi tầm kiểm soát trong vài ngày qua và khiến MySQL bị sập hai lần. Tất cả bắt đầu khi tôi di chuyển một trang web WordPress cũng chứa một diễn đàn phpBB.

Tôi không có nhiều kinh nghiệm trong quản trị máy chủ nên tôi rất khó xác định chính xác nguyên nhân gây ra sự cố. Khi tôi nhận thấy rằng MySQL bị hỏng, tôi đã chạy TOP và thấy mức tăng tải hệ thống của tôi lên 98,00. Máy chủ chạy 10 V-HOSTS tất cả đều nhận được lưu lượng truy cập tốt, vì vậy tôi rõ ràng đã thấy nhiều quá trình apache-2 đang chạy.

Tải máy chủ cao tiếp tục trong 10 phút và sau đó nó trở lại trạng thái bình thường. Tôi đã không thấy lưu lượng truy cập mạng tăng đột biến vào thời điểm này.

Thật không may, ghi nhật ký lỗi MySQL đã bị vô hiệu hóa (hiện đã được bật lại) nên không có manh mối nào ở đó. Nhưng tôi khá chắc chắn rằng đó là do Apache đã tiêu thụ tất cả các tài nguyên, vì vậy ID tiến trình MySQL đã bị giết.

Câu hỏi của tôi là:

Lần tiếp theo điều này xảy ra - làm thế nào tôi có thể xác định được nguyên nhân gây ra tải hệ thống tăng đột biến? Nó có thể là một kịch bản php đã phát điên? Nó có thể là một cuộc tấn công DDOS?

Có cách nào tự động khởi động lại MySQL khi nó gặp sự cố không?

Tôi đã cài đặt htop. Điều này có thể hữu ích hơn top?

Đây là số liệu thống kê máy chủ của tôi:

m1.xlarge (8 ECUs, 4 vCPUs, 15 GiB memory, 4 x 420 GiB Storage Capacity)
Ubuntu Server 12.04.3 LTS 

MySQL vẫn có thể không đăng nhập bất cứ điều gì, bởi vì những gì có thể xảy ra là nó đang bị hệ thống giết chết một cách kỳ lạ do áp lực bộ nhớ hệ thống từ những đứa trẻ của apache. Cần có một dấu vết của điều này trong / var / log / syslog.

MySQL nên cố gắng tự khởi động lại trong một sự cố hoặc chấm dứt cưỡng bức, nhưng trừ khi có đủ bộ nhớ, nó không thể làm điều đó ... và thất bại thứ hai này không được mysqld_safe xem là "sự cố" mà là "từ chối" bắt đầu, "vì vậy nó sẽ không tiếp tục cố gắng. Nỗ lực khởi động lại thất bại thường bị các quản trị viên hiểu sai là "sự cố", vì bản chất của lỗi ban đầu được ẩn sau một thông báo dễ bị bỏ qua trong nhật ký lỗi của MySQL:

mysqld_safe Number of processes running now: 0

Xem InnoDB Crash Post Mortem cho một tình huống mà tôi nghi ngờ là tương tự như của bạn.

Câu trả lời có vẻ đơn giản cho "tại sao" là giữa Apache và MySQL, tải bạn có và các cấu hình hiện tại của bạn, bạn không có đủ bộ nhớ trên máy và có một số điểm bùng phát liên quan đến tải lưu lượng mang đến điều kiện này .

Apache phục vụ mỗi yêu cầu trình duyệt đồng thời từ một tiến trình con, do đó, số lượng kết nối đồng thời tăng lên, số lượng trẻ em sẽ tăng lên. Trước tiên, bạn sẽ cần giới hạn giá trị này trong cấu hình apache để bạn có thể hiểu những gì thực sự gây ra sự gia tăng các kết nối đồng thời ... nó chỉ đơn giản là một lưu lượng truy cập lớn nhưng hợp pháp? Một số loại từ chối dịch vụ? Truy vấn DB trì hoãn yêu cầu vì chúng chạy quá lâu? Một cái gì đó cần tối ưu hóa?

http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclents

Hạn chế các quy trình đồng thời của Apache sẽ giúp ngăn chặn điều này, nhưng rõ ràng, thật ngây thơ khi nghĩ rằng đây là giải pháp đầy đủ, vì vậy tôi không muốn ám chỉ điều đó. Khi các quy trình được giới hạn ở mức hợp lý hoặc ít nhất là an toàn hơn, bạn có thể tiến hành xác định những gì đang thực sự xảy ra. (Có các điều khiển hạn chế khác trên Apache, nhưng đó không phải là lĩnh vực chuyên môn của tôi.)

Tất nhiên, "cách tốt nhất" là chạy cơ sở dữ liệu của bạn trên các phần cứng khác nhau để ứng dụng không thể tắt nó. Mặc dù có vẻ hiệu quả hơn, nhưng trên bề mặt, để "tối đa hóa việc sử dụng" một máy bằng cách chia sẻ nó, đây là một nền kinh tế sai lầm. Phần lớn bộ nhớ được sử dụng bởi MySQL, trong một khối lượng công việc thông thường, được phân bổ vào thời điểm khởi động và được giữ miễn là MySQL Server đang chạy. Các yêu cầu đối với CPU có thể chia sẻ thời gian cao điểm cho MySQL và Apache, vì cuối cùng chúng đang phục vụ cùng một tải. Bạn thực sự có thể tốt hơn với hai máy m1.lund thay vì m1.xlarge duy nhất và chi phí sẽ bằng nhau vì máy nhỏ hơn chính xác bằng một nửa so với máy lớn hơn ... ngay cả khi bạn đã trả trước đối với giảm giá bổ sung, thay đổi này có thể được thực hiện .

Bạn có một số điểm cần kiểm tra:

-Kiểm tra / var / log / message: oomkiller có thể giết tiến trình mysql nếu không còn bộ nhớ để sử dụng. Kiểm tra ram với -lm miễn phí (không có bộ đệm)

-Nếu bạn sử dụng apache với prefork mpm: kiểm tra số lượng quá trình. Nếu apache xếp một số lượng quá trình quan trọng (trong một khối lượng công việc lớn) với một liên kết đến mysql, thì độ trễ và bộ nhớ được sử dụng có thể tăng lên nhanh chóng.

-Kiểm tra số lượng luồng được khởi chạy bởi mysql với trạng thái hiển thị toàn cục : thread_cached, thread_created và thread_rucky rất quan trọng để kiểm tra (thread_created phải ở gần 0).

-Kiểm tra ram được sử dụng bởi Mysql.

Bạn cũng có thể xem xét việc triển khai cpusets và dự trữ tài nguyên cho mysql. Đó là cách gần nhất để chạy các dịch vụ này trên các phần cứng khác nhau, nhưng vẫn mang lại cho bạn những lợi ích của việc duy trì một máy chủ.