LGI: khóa mềm - CPU # bị kẹt trong x giây


33

Tôi đã thấy một vài báo cáo lỗi và câu hỏi (trên stackexchange và các nơi khác) liên quan đến một lời cằn nhằn "BUG: soft lockup - CPU#<n> stuck for <dt>s!". Cho đến nay, tôi không tìm thấy bất kỳ manh mối nào về việc phải làm hoặc thử (thay vào đó, các manh mối tôi đã tìm thấy và theo dõi đã không ngăn chặn điều này xảy ra). Tôi quan tâm hơn về điều này bởi vì:

  1. tần suất của những sự kiện này dường như đã tăng chậm trong thời gian gần đây (hơn 700 mỗi tháng),
  2. yum update và khởi động lại đã làm nó chậm lại một chút nhưng tôi đã thấy một số lần khóa bắt đầu xảy ra lần nữa,
  3. một số quy trình (nếu không phải là toàn bộ máy chủ, thật khó để nói), chắc chắn bao gồm tất cả các vỏ tương tác của tôi bị đóng băng trong một khoảng thời gian khi nó xảy ra,
  4. Tôi không chắc liệu nó có liên quan hay không, nhưng tôi thấy rất nhiều nhật ký / tin nhắn liên quan đến ntpd không thể cập nhật đồng hồ.

Sau đây là một đoạn trích về $(grep 'soft lockup' /var/log/messages*):

Mar 22 10:02:35 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [kjournald:1048]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:40 localhost kernel: BUG: soft lockup - CPU#15 stuck for 25s! [swapper:0]
Mar 22 15:42:16 localhost kernel: BUG: soft lockup - CPU#8 stuck for 25s! [kjournald:1048]
Mar 22 18:22:13 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [postgres:21356]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#7 stuck for 10s! [java:8653]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#8 stuck for 72s! [kjournald:1048]
Mar 22 21:21:37 localhost kernel: BUG: soft lockup - CPU#12 stuck for 29s! [kjournald:1048]
Mar 22 21:22:07 localhost kernel: BUG: soft lockup - CPU#12 stuck for 27s! [kjournald:1048]
Mar 23 02:01:47 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [kblockd/8:276]
Mar 23 02:02:22 localhost kernel: BUG: soft lockup - CPU#8 stuck for 34s! [kblockd/8:276]

Điều này xảy ra với các quá trình ngẫu nhiên và dường như được phân phối khá tốt trên 16 "lõi" của máy chủ ảo đó.

Máy chủ lưu trữ là phiên bản AWS EC2 "cc1.4xlarge", với AMI có tên "EC2 CentOS 5.5 GPU HVM AMI (Driver 260.19,29) (ami-42a2532b)". Nó dường như được ảo hóa với Xen.

cat /etc/redhat-releasenăng suất CentOS release 5.9 (Final). 'free'báo cáo 21G RAM.

Người đứng đầu dmesglà:

Linux version 2.6.18-348.3.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Mon Mar 11 19:39:25 EDT 2013
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000010000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 00000005dd800000 (usable)
DMI 2.4 present.
DMI: Xen HVM domU, BIOS 3.4.3-2.6.18 08/29/2012
ACPI: RSDP (v002    Xen                                ) @ 0x00000000000ea020
ACPI: XSDT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0062b0
ACPI: FADT (v004    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005ee0
ACPI: MADT (v002    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005fe0
ACPI: SRAT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0060c0
ACPI: SLIT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006240
ACPI: HPET (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006270
ACPI: DSDT (v002    Xen      HVM 0x00000000 INTL 0x20090220) @ 0x(null)

Phần sau đây cho thấy số tích lũy của các "khóa mềm" này trong thời gian gần đây (đường dây đỏ là khi tôi thực hiện lần cuối yum updatetheo sau reboot) : số lượng tích lũy của khóa mềm.

Sau đây cho thấy biểu đồ thời lượng (máy chủ bị kẹt trong bao lâu) : biểu đồ thời lượng.


1
Tấn lý do có thể. Tôi đã có nó một lần trong một ví dụ KVM. Nguyên nhân là do trình điều khiển mạng máy chủ (realtek), sẽ làm điều gì đó trên mạng tải cao mà ảo hóa không mong đợi và voila bạn bị kẹt CPU trong máy ảo. Vì vậy, về cơ bản là một lỗi trong trình điều khiển mạng đã kích hoạt các lỗi khác ở xa hơn. Giải pháp là chuyển sang một phiên bản kernel khác (trên máy chủ) không kích hoạt hành vi cụ thể đó.
frostschutz

1
Chúng tôi đã nhận được thông báo lỗi này, vì một số máy ảo có cấu hình vcpus nhiều hơn so với CPU vật lý trong máy chủ mới, chúng tôi đã chuyển máy chủ Xen của chúng tôi sang.
Jörg Ludwig

Câu trả lời:


11

Tôi cũng gặp vấn đề này trên Xen 4.2 với 3.6 và 3.8 Kernel (AlpineLinux).

Tôi đã tìm kiếm xung quanh và bằng cách thêm clockource = jiffies vào kernel của tôi, tôi đã sửa nó. Thay vì jiffies bạn cũng có thể thử "hố".

Cũng có báo cáo về việc vô hiệu hóa trạng thái C trong BIOS .


4
Những tham số kernel đó làm gì?
Burhan Ali

2
Clocksource có vẻ khá rõ ràng đối với tôi và trạng thái c là trạng thái sức mạnh của CPU.
Franz Bettag

+1. Vô hiệu hóa c-state làm việc cho tôi.
Andrew Oblley

2

Tôi gặp vấn đề tương tự với Thinkpad T520 của tôi. Nhưng thay vì hack đi kernel, tôi đã làm một cái gì đó đơn giản hơn. Trước hết tôi đang sử dụng Centos7 Tôi đã cài đặt hệ thống cơ sở đều hoạt động tốt. Sau đó tôi đã thêm GUI Gnome, đó là khi tôi bắt đầu gặp các vấn đề được đề cập ở trên. Tôi nhận thấy rằng rất nhiều nhà sản xuất thiết lập cho các bản cài đặt Windows. Card đồ họa được thiết lập thường cho Win7 (NVIDIA OPTIMUS) Tôi đặt lại nó về chế độ đồ họa tích hợp và không còn bị treo / lỗi. Làm thế nào để làm nó? Khởi động lại Thinkpad của bạn nhấn nút F1 hoặc màu xanh lam để vào BIOS. Đi đến đồ họa chọn đồ họa tích hợp sau đó F10 để lưu và thoát. Có 3 cài đặt cho thẻ này: Tích hợp, rời rạc và NVIDIA OPTIMUS (chỉ dành cho Win7?) Hy vọng điều này sẽ giúp ai đó tiết kiệm thời gian?


Thở dài, giống như hầu hết mọi thứ khác, cài đặt các công cụ riêng biệt là không có. Quay lại phiên bản máy tính để bàn cồng kềnh với Office và những thứ nhảm nhí khác :(
killjoy
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.