Có một vài cách có thể bạn có thể làm điều này. Lưu ý rằng nó hoàn toàn có thể có nhiều quá trình trong một kịch bản chạy trốn gây ra điều này, không chỉ một.
Cách đầu tiên là thiết lập pidstat để chạy trong nền và tạo dữ liệu.
pidstat -u 600 >/var/log/pidstats.log & disown $!
Điều này sẽ cung cấp cho bạn một triển vọng khá chi tiết về hoạt động của hệ thống trong khoảng thời gian mười phút. Tôi sẽ đề nghị đây là cổng gọi đầu tiên của bạn vì nó tạo ra dữ liệu đáng tin cậy / đáng tin cậy nhất để làm việc.
Có một vấn đề với điều này, chủ yếu là nếu hộp đi vào vòng lặp cpu chạy trốn và tạo ra tải rất lớn - bạn không đảm bảo rằng quy trình thực tế của bạn sẽ thực hiện kịp thời trong quá trình tải (nếu có) để bạn thực sự có thể bỏ lỡ đầu ra !
Cách thứ hai để tìm kiếm điều này là cho phép kế toán quy trình. Có thể nhiều hơn của một lựa chọn dài hạn.
accton on
Điều này sẽ cho phép kế toán quá trình (nếu chưa được thêm). Nếu nó không chạy trước thì sẽ cần thời gian để chạy.
Đã được chạy, trong 24 giờ - bạn có thể chạy một lệnh như vậy (sẽ tạo ra kết quả như thế này)
# sa --percentages --separate-times
108 100.00% 7.84re 100.00% 0.00u 100.00% 0.00s 100.00% 0avio 19803k
2 1.85% 0.00re 0.05% 0.00u 75.00% 0.00s 0.00% 0avio 29328k troff
2 1.85% 0.37re 4.73% 0.00u 25.00% 0.00s 44.44% 0avio 29632k man
7 6.48% 0.00re 0.01% 0.00u 0.00% 0.00s 44.44% 0avio 28400k ps
4 3.70% 0.00re 0.02% 0.00u 0.00% 0.00s 11.11% 0avio 9753k ***other*
26 24.07% 0.08re 1.01% 0.00u 0.00% 0.00s 0.00% 0avio 1130k sa
14 12.96% 0.00re 0.01% 0.00u 0.00% 0.00s 0.00% 0avio 28544k ksmtuned*
14 12.96% 0.00re 0.01% 0.00u 0.00% 0.00s 0.00% 0avio 28096k awk
14 12.96% 0.00re 0.01% 0.00u 0.00% 0.00s 0.00% 0avio 29623k man*
7 6.48% 7.00re 89.26% 0.00u 0.00% 0.00s
Các cột được sắp xếp như vậy:
- Số lượng cuộc gọi
- Tỷ lệ cuộc gọi
- Lượng thời gian thực dành cho tất cả các quy trình thuộc loại này.
- Tỷ lệ phần trăm.
- Thời gian CPU của người dùng
- Tỷ lệ phần trăm
- Thời gian CPU hệ thống.
- Các cuộc gọi IO trung bình.
- Tỷ lệ phần trăm
- Tên lệnh
Những gì bạn sẽ tìm kiếm là các loại quy trình tạo ra thời gian CPU Người dùng / Hệ thống nhiều nhất.
Điều này phá vỡ dữ liệu dưới dạng tổng thời gian CPU (hàng trên cùng) và sau đó cách thức thời gian CPU đó được phân chia. Kế toán quy trình chỉ hạch toán đúng khi nó khởi động khi quá trình sinh sản, vì vậy có lẽ tốt nhất là khởi động lại hệ thống sau khi cho phép nó đảm bảo tất cả các dịch vụ đang được hạch toán.
Điều này, không có nghĩa là thực sự mang đến cho bạn một ý tưởng nhất định quá trình có thể là nguyên nhân của vấn đề này, nhưng có thể mang lại cho bạn cảm giác tốt. Vì nó có thể là một ảnh chụp nhanh 24 giờ có khả năng cho kết quả sai lệch, vì vậy hãy ghi nhớ điều đó. Nó cũng phải luôn luôn đăng nhập vì tính năng kernel của nó và không giống như pidstat sẽ luôn tạo ra đầu ra ngay cả khi tải nặng.
Tùy chọn cuối cùng khả dụng cũng sử dụng kế toán quy trình để bạn có thể bật nó như trên, nhưng sau đó sử dụng chương trình "Lastcomm" để tạo một số thống kê về các quy trình được thực hiện trong khoảng thời gian xảy ra sự cố cùng với thống kê cpu cho từng quy trình.
lastcomm | grep "May 8 22:[01234]"
kworker/1:0 F root __ 0.00 secs Tue May 8 22:20
sleep root __ 0.00 secs Tue May 8 22:49
sa root pts/0 0.00 secs Tue May 8 22:49
sa root pts/0 0.00 secs Tue May 8 22:49
sa X root pts/0 0.00 secs Tue May 8 22:49
ksmtuned F root __ 0.00 secs Tue May 8 22:49
awk root __ 0.00 secs Tue May 8 22:49
Điều này có thể cung cấp cho bạn một số gợi ý về những gì có thể gây ra vấn đề.
