Hiện tại tôi đang tìm cách chuyển hệ thống của chúng tôi từ RHEL 5 sang RHEL 6, nhưng tôi đã gặp phải một trở ngại với việc sử dụng CPU cao bất ngờ trên các máy của RHEL 6. Dường như điều này có thể là do ít nhất là một phần do việc sử dụng selectđể thực hiện một giấc ngủ gián đoạn. Đây là một ví dụ đơn giản cho thấy hành vi:
#include <sys/select.h>
int main()
{
timeval ts;
for (unsigned int ii=0; ii<10000; ++ii) {
ts.tv_sec = 0;
ts.tv_usec = 1000;
select(0, 0, 0, 0, &ts);
}
return 0;
}
Trên máy RHEL 5, nó sẽ giữ mức sử dụng CPU 0%, nhưng trên cùng một phần cứng với cài đặt RHEL 6, nó sẽ sử dụng khoảng 0,5% CPU, do đó, khi 30 đến 50 chương trình đang chạy selectđể thực hiện chế độ ngủ, nó sẽ ngốn số lượng lớn CPU không cần thiết.
Tôi đã mở một Bugzilla và tôi đã thử chạy OProfile và nó chỉ hiển thị chính 100% cho ứng dụng và chỉ hơn 99% trong poll_idle khi nhìn vào kernel (tôi có idle = poll set trong các tùy chọn grub của tôi để mọi thứ có thể được chụp).
Bất kỳ ý tưởng nào khác về những gì tôi có thể làm để thử và cô lập nguyên nhân của việc sử dụng CPU cao hơn là gì?
CẬP NHẬT: Tôi tìm thấy công cụ hoàn hảo và có đầu ra sau:
# Events: 23K cycles
#
# Overhead Command Shared Object Symbol
# ........ ....... ................... ....................................
#
13.11% test_select_sma [kernel.kallsyms] [k] find_busiest_group
5.88% test_select_sma [kernel.kallsyms] [k] schedule
5.00% test_select_sma [kernel.kallsyms] [k] system_call
3.77% test_select_sma [kernel.kallsyms] [k] copy_to_user
3.39% test_select_sma [kernel.kallsyms] [k] update_curr
3.22% test_select_sma ld-2.12.so [.] _dl_sysinfo_int80
2.83% test_select_sma [kernel.kallsyms] [k] native_sched_clock
2.72% test_select_sma [kernel.kallsyms] [k] find_next_bit
2.69% test_select_sma [kernel.kallsyms] [k] cpumask_next_and
2.58% test_select_sma [kernel.kallsyms] [k] native_write_msr_safe
2.47% test_select_sma [kernel.kallsyms] [k] sched_clock_local
2.39% test_select_sma [kernel.kallsyms] [k] read_tsc
2.26% test_select_sma [kernel.kallsyms] [k] do_select
2.13% test_select_sma [kernel.kallsyms] [k] restore_nocheck
Có vẻ như việc sử dụng CPU cao hơn là từ bộ lập lịch. Tôi cũng đã sử dụng tập lệnh bash sau đây để khởi động cùng lúc 100 tập lệnh này:
#!/bin/bash
for i in {1..100}
do
./test_select_small &
done
Trên RHEL 5, mức sử dụng CPU vẫn ở mức gần 0%, nhưng trên RHEL 6 có một lượng sử dụng CPU không hề nhỏ trong cả người dùng và hệ thống. Bất kỳ ý tưởng về làm thế nào để theo dõi nguồn gốc thực sự của điều này và hy vọng sửa chữa nó?
Tôi cũng đã thử nghiệm thử nghiệm này trên bản dựng Arch Linux hiện tại và Ubuntu 11.10 và thấy hành vi tương tự, vì vậy đây có vẻ là một số loại vấn đề hạt nhân và không chỉ là vấn đề của RHEL.
CẬP NHẬT2: Tôi ngần ngại một chút để đưa ra điều này vì tôi biết rằng đó là một cuộc tranh luận lớn, nhưng tôi đã thử một hạt nhân với các bản vá BFS trên Ubuntu 11.10 và nó không hiển thị cách sử dụng CPU hệ thống cao (dường như việc sử dụng cpu của người dùng giống nhau).
Có một số thử nghiệm tôi có thể chạy với từng người trong số họ để kiểm tra xem việc sử dụng CPU cao này chỉ là một sự khác biệt trong kế toán sử dụng CPU đang làm cho nó trông cao một cách giả tạo? Hoặc nếu chu kỳ CPU thực tế đang bị CFS đánh cắp?
CẬP NHẬT3: Phân tích được thực hiện liên quan đến câu hỏi này dường như chỉ ra rằng đó là một cái gì đó liên quan đến công cụ lên lịch, vì vậy tôi đã tạo một câu hỏi mới để thảo luận về kết quả.
CẬP NHẬT4: Tôi đã thêm một số thông tin cho câu hỏi khác .
CẬP NHẬT5: Tôi đã thêm một số kết quả cho câu hỏi khác từ một bài kiểm tra đơn giản hơn mà vẫn thể hiện vấn đề.
selectđó?