Azure의 Ubuntu 18.08 VM에 문제가 있습니다. 이 문제는 대용량 파일의 압축을 풀 때 발생하는 것 같습니다 unzip
. 내 SSH 세션이 와 충돌하고 send disconnect: Broken pipe
, Azure 콘솔에서 다시 시작할 때까지 더 이상 머신에 SSH를 연결할 수 없습니다.
디스크 공간을 확인한 결과 문제가 없는 것 같습니다. 진단 로그에서 발견한 CPU 잠금으로 인해 문제가 발생한 것 같습니다.
[ 9574.275457] rcu: blocking rcu_node structures:
[ 9581.022803] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9609.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9614.067067] audit: backlog limit exceeded
[ 9614.072016] audit: backlog limit exceeded
[ 9614.076728] audit: backlog limit exceeded
[ 9637.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9665.022801] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9674.339074] audit: backlog limit exceeded
[ 9674.344825] audit: backlog limit exceeded
[ 9674.351922] audit: backlog limit exceeded
[ 9693.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9721.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kauditd:22]
[ 9734.182947] audit: backlog limit exceeded
[ 9734.188086] audit: backlog limit exceeded
[ 9734.194938] audit: backlog limit exceeded
[ 9736.682801] rcu: INFO: rcu_sched self-detected stall on CPU
[ 9736.684975] rcu: 1-....: (509855 ticks this GP) idle=492/1/0x4000000000000002 softirq=1049753/1049838 fqs=254454
[ 9754.486826] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 1-... } 511745 jiffies s: 525 root: 0x2/.
[ 9754.497787] rcu: blocking rcu_node structures:
[ 9761.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kauditd:22]
또한 압축을 푸는 동안 모니터링을 시도했는데 top
부팅하기 직전에 kauditd
CPU가 0% 미만에서 70%-100% CPU로 올라가는 것을 볼 수 있습니다.
top - 12:00:01 up 21 min, 1 user, load average: 1.34, 1.29, 0.98
top - 12:02:53 up 24 min, 2 users, load average: 2.80, 1.87, 1.25
Tasks: 168 total, 4 running, 95 sleeping, 0 stopped, 0 zombie
%Cpu(s): 31.8 us, 48.8 sy, 0.0 ni, 0.0 id, 19.3 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8149152 total, 2436876 free, 958672 used, 4753604 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 6878804 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22 root 20 0 0 0 0 R 79.3 0.0 0:02.92 kauditd
299 root 20 0 1563540 153316 35416 S 73.4 1.9 1:40.58 ds_am
29619 root 20 0 11528 5252 2088 S 3.6 0.1 0:14.03 unzip
466 root 19 -1 144180 58788 57688 S 1.3 0.7 0:03.89 systemd-journal
21596 root 20 0 0 0 0 I 0.7 0.0 0:00.65 kworker/u4:1-ev
커널 감사 데몬이 갑자기 그렇게 많은 CPU를 차지하는 원인은 무엇입니까? 점진적인 증가가 아니라 100%까지 급격하게 증가한 다음 VM이 정지되었습니다.
전에 이런 일을 겪은 사람이 있나요?
답변1
이유를 알 수 없습니다. 하지만 SCREEN 또는 BYOB를 사용하고 백그라운드에서 압축을 푸는 것이 좋습니다.
파일의 압축을 푸는 동안 SSH 세션을 닫고 몇 분 후에 다시 돌아오면 짜잔!
답변2
나는 이것이 다음의 일부 구성 요소로 인해 발생한다고 생각합니다.트렌드마이크로소프트웨어. 상위 출력에는 가동 시간의 상당 부분인 에 1:40.58
소요된 시간이 표시됩니다.ds_am
이러한 종류의 소프트웨어는 커널 감사 기능을 설정하는 데에도 유력한 후보입니다(유일한 것은 아니지만).
설명서 및/또는 참조소프트웨어 공급업체에 문의직접적인 자원 사용에 대해. 그러나 먼저 해당 소프트웨어에 대한 정기 유지 관리 또는 업그레이드 작업이 아직 보류 중인지 확인하세요.
커널 감사 프레임워크의 구성을 결정하고 이와 인터페이스하는 다른 소프트웨어를 식별합니다. (노력하다
auditctl
)