Việc sử dụng CPU dưới dạng % đơn giản không thể chuyển tải độ phức tạp của một CPU nhiều lõi, nhiều luồng, nhiều đơn vị thực thi và bộ nhớ. Gần như chắc chắn CPU thực sự bị đình trệ trên bộ nhớ hoặc bộ đệm. Và các quy trình có dữ liệu của chúng sẽ tranh giành các đơn vị thực thi.
CPU này chỉ có 16 nhân. Đối xử với nó như thể nó có 32 tại một số điểm sẽ làm giảm hiệu suất nghiêm trọng, như bạn đã phát hiện ra. Ngay cả với SMT 2. Có thể bạn có thể nhận được số lượng luồng lên tới 125% số lõi (20) nhưng 175% (28) đang đẩy nó lên. Đặc biệt là với những thứ khác đang chạy. Quay lại các chủ đề.
Đảm bảo tính toán công việc hữu ích được thực hiện trên mỗi luồng trên giây. Thử nghiệm, thay đổi một biến tại một thời điểm. Có thể thử các bộ xử lý có cấu hình bộ đệm và số lượng lõi khác nhau, nếu bạn có quyền truy cập vào các cấu hình đó.
Đo mức độ đình trệ của bạn với bộ đếm theo dõi hiệu suất. Không hoạt động trong máy ảo, nhưng đáng để thử trên Linux. Từ Gregg mà tôi đã liên kết trước đó:
perf stat -a -- ngủ 10
Tốc độ tối đa trên lý thuyết trên Xeons là 4 hoặc 5 lệnh mỗi chu kỳ. Bạn sẽ không nhận được điều đó, nhưng <1.0 IPC bị đình trệ thêm trên bộ nhớ.
Chắc chắn hiểu được mã của ứng dụng và các điểm nóng. Chức năng nào dành phần lớn thời gian cho CPU? Mã lắp ráp nào bị ảnh hưởng nặng nề nhất? Đơn vị thực thi nào trên CPU của bạn nói riêng đang làm việc chăm chỉ nhất để xử lý các uop này?
đồ thị ngọn lửa rất tốt để trực quan hóa các chức năng của CPU. Bạn đã đề cập đến EL 8, trong đó có công cụ biểu đồ ngọn lửa đóng gói.
yum cài đặt hoàn hảo js-d3-đồ thị ngọn lửa
# toàn hệ thống, 99 Hz, trong 60 giây
tập lệnh perf flamegraph -a -F 99 ngủ 60
Cần có sự hiểu biết ở cấp độ nhà phát triển về chương trình để giải thích đầy đủ các kết quả. Với các ký hiệu hoặc mã nguồn, báo cáo hoàn hảo có thể được chú thích trong một trình gỡ lỗi như trải nghiệm.
