Tìm hiểu quá trình apache sử dụng CPU cao đang thực sự làm gì?

18

Hiện tại có một vài vấn đề với máy chủ của chúng tôi, trong đó, không liên tục, chúng tôi dường như nhận được các quy trình apache vừa chạy và chạy, chiếm 100% CPU.

Khi chạy hàng đầu, chúng ta thấy như sau:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20788 www-data  20   0  318m  18m 3984 R  100  0.0  40:29.21 /usr/sbin/apache2 -k start
23523 www-data  20   0  319m  20m 4684 R  100  0.0   4:12.36 /usr/sbin/apache2 -k start

Tôi muốn thử và tìm hiểu kịch bản nào (hoặc bất cứ kịch bản nào) đang gây ra điều này, vì vậy tôi đã thử:

 strace -p 20788

Nhưng điều đó hoàn toàn không hiển thị bất kỳ đầu ra nào (Tôi đã để nó trong khoảng 10 phút và nó không hiển thị gì cả). Theo hiểu biết của tôi, điều này có thể có nghĩa là nó bị mắc kẹt trong một vòng lặp vô hạn và không có bất kỳ "cuộc gọi hệ thống" nào để hiển thị.

Có điều gì khác tôi có thể làm để cho thấy những gì đang xảy ra?

Cảm ơn

Chỉnh sửa - Quên đề cập, đây là một máy chủ trực tiếp với vài trăm người dùng bất cứ lúc nào! Vì vậy, tôi thực sự không thể tự do thử thay đổi tùy chọn cấu hình và khởi động lại apache.

Chỉnh sửa 2 - Backtrace (bt) từ gdb dường như không hữu ích lắm khi PHP không được cấu hình với --enable-debug - nó chỉ hiển thị "exec ()", nhưng tôi cần biết đoạn script PHP là gì thực sự đang chạy .. có cách nào khác không?

#0  0x00007f6c143fb0c5 in ?? () from /usr/lib/apache2/modules/libphp5.so
#1  0x00007f6c143b040b in execute () from /usr/lib/apache2/modules/libphp5.so
#2  0x00007f6c1438b970 in zend_execute_scripts () from     /usr/lib/apache2/modules/libphp5.so
#3  0x00007f6c14337fe3 in php_execute_script () from     /usr/lib/apache2/modules/libphp5.so
#4  0x00007f6c1441ae7d in ?? () from /usr/lib/apache2/modules/libphp5.so
#5  0x00007f6c18912508 in ap_run_handler ()
#6  0x00007f6c1891297e in ap_invoke_handler ()
#7  0x00007f6c18922570 in ap_process_request ()
#8  0x00007f6c1891f398 in ?? ()
#9  0x00007f6c18918fa8 in ap_run_process_connection ()
#10 0x00007f6c189271d0 in ?? ()
#11 0x00007f6c1892793a in ?? ()
#12 0x00007f6c189284e7 in ap_mpm_run ()
#13 0x00007f6c188fd4a4 in main ()

— BT643
nguồn

1

Apache hỗ trợ khởi động lại "duyên dáng", vậy tại sao bạn lại không?

— poige

1

Tôi nghĩ rằng khi chúng tôi đã thử nó trước đây, nó không thể khởi động lại một cách duyên dáng vì các quá trình apache "bị kẹt" ... mặc dù điều đó có thể sai, nhưng cách đây một thời gian.

— BT643

Một mẹo khác là chạy một phiên bản apache khác trên cổng khác, chuyển hướng các kết nối mới đến nó.

— poige

9

Chà, trong trường hợp bạn cảm thấy dũng cảm:

gdb -p 20788

sau đó phát hành btđể xem khung stack, ví dụ:

Và BTW, cũng có ltraceđề cập đến - hãy thử nó.

CẬP NHẬT. : tốt, ok, vì bây giờ chúng ta có một ý tưởng rằng Apache đang thực sự chạy một cái gì đó, tại sao bạn không nhìn vào mod_statusđầu ra - Mở rộng ?

— sẵn sàng
nguồn

gdb chưa được cài đặt :( sẽ phải đợi cho đến khi tôi quay lại làm việc vào ngày mai để xem liệu tôi có thể cài đặt nó mà không gây ra bất kỳ sự cố nào ltracekhông .. không hiển thị bất kỳ đầu ra nào.

— BT643

Chỉ cần thêm kết quả từ gdb bt vào bài viết ban đầu .. thực sự không cho tôi biết nhiều!

— BT643

Ồ, rất vui khi thấy tôi đã đề xuất hướng đi đúng đắn. )

— poige

@ BT643, xem CẬP NHẬT.

— poige

4

Mod_status đã được kích hoạt đã được bật theo mặc định, nó chỉ bị giới hạn truy cập từ 127.0.0.1. Tôi vừa đăng nhập qua SSH và chuyển đầu ra thành một tệp curl domain.com/server-status > randomfile.html- sau đó xem tệp. Hóa ra đó là một mã nhà phát triển cũ bị mắc kẹt trong một vòng lặp (tệp PHP)! Tất cả được sắp xếp ngay bây giờ. Cảm ơn sự giúp đỡ :)

— BT643

2

Một cách tiếp cận rất dễ dàng là sử dụng htop. Bạn có thể sắp xếp cho các quá trình CPU cao và sau đó sử dụng

s cho stracemột quá trình
Tôi lsofđể xem các tập tin đang mở của một quá trình
L đến ltrace.

Tôi thấy rằng ít nhất một trong các tùy chọn đó tìm thấy tập lệnh tạo tải và tất nhiên bạn có thể sử dụng tập lệnh này trên máy chủ web sản xuất để gỡ lỗi.

— bỏ rơi
nguồn

1

Bạn có thể thử:

iotop (hiển thị I / O trên hệ thống)
netstat -t (hiển thị kết nối)
Hãy xem các logfiles apache và tìm hiểu những gì máy chủ đã làm cuối cùng
thiết lập một số RLimits cho quá trình apache. Khi đạt đến những giới hạn này, quy trình sẽ bị hủy, cung cấp cho bạn thêm thông tin

— Kai Bojens
nguồn

0

Lệnh của bạn sẽ hoạt động với điều kiện bạn thực hiện một yêu cầu HTTP kích hoạt PID đó.

Có lẽ bạn muốn cấu hình lại tạm thời Apache chỉ với một tiến trình con?

— Harry tàn sát
nguồn

Hãy nhớ rằng chỉ có một tiến trình con có nghĩa là Apache chỉ có thể phục vụ một yêu cầu duy nhất và nếu một đứa trẻ đó bị mắc kẹt, Apache sẽ không thể phục vụ bất kỳ yêu cầu nào.

— Stefan Lasiewski

Không thể làm điều đó vì nó là một máy chủ trực tiếp với hàng trăm người dùng đồng thời (đã thêm nó vào OP vì nó không rõ ràng trước đó)

— BT643

0

PID của cá thể apache đó thấp, nó có thể là cha đẻ của tất cả. Điều đó chắc chắn sẽ giải thích việc sử dụng CPU cao (nó vẫn ở xung quanh, những người khác được sinh ra và thu hồi theo tải). Thời gian CPU tích lũy nhiều có thể chỉ có nghĩa là nó đã chạy trong một thời gian dài. Không có đầu ra từ strace(1)chỉ có nghĩa là nó đã không gọi hệ thống. Vâng, nó có thể nằm trong một vòng lặp chặt chẽ, nhưng apache về cơ bản là I / O trên mạng, vì vậy tôi nghĩ rằng nó không làm gì hữu ích. Lạ 100% của một CPU, trong mọi trường hợp.

— vonbrand
nguồn

PID thấp không nhất thiết có nghĩa là nó là một quá trình cũ. Các PID có giá trị tối đa và bao bọc xung quanh để các quy trình mới có thể được tạo bằng cách sử dụng các PID thấp.

— austinian 7/07/2015

0

Thử đi:

1) Bắt đầu nhật ký với ngày / giờ, tập lệnh PHP và bộ vi xử lý bằng cách sử dụng getmypid()

2) Sau đó xem máy chủ của bạn với top

3) Khi bạn thấy quá trình apache tăng cao, hãy tìm kiếm cùng ngày / giờ và PID trong nhật ký của bạn. Bạn sẽ có thể tìm thấy các kịch bản có vấn đề.

— Phượng Hoàng
nguồn

Đây là một giải pháp thú vị nhưng tôi có thể thấy nó chiếm nhiều tài nguyên hơn giá trị của nó, với điều đó là mod_statuscông việc của nó khá tốt.

— austinian