Puncte:0

Sesiunea Ubuntu VM SSH se blochează în timpul unei dezarhivari mari din cauza utilizării excesive a procesorului

drapel wf

Am probleme cu o mașină virtuală Ubuntu 18.08 pe Azure. Problema pare să apară atunci când dezarhiv un fișier mare cu dezarhivați. Sesiunea mea SSH se blochează cu trimite deconectare: conductă spartă, și nu mai pot SSH pe mașină până când nu o repornesc pe consola Azure.

Am verificat spațiul pe disc și pare să fie în regulă, cred că problema se datorează unei blocări a procesorului pe care am descoperit-o în jurnalele de diagnosticare:

[ 9574.275457] rcu: blocarea structurilor rcu_node:
[ 9581.022803] watchdog: BUG: blocare soft - CPU#1 blocat timp de 23 de secunde! [kauditd:22]
[ 9609.022802] watchdog: BUG: blocare soft - CPU#1 blocat timp de 23 de secunde! [kauditd:22]
[ 9614.067067] audit: limita rămasă depășită
[ 9614.072016] audit: limita rămasă depășită
[ 9614.076728] audit: limita rămasă depășită
[ 9637.022802] watchdog: BUG: blocare soft - CPU#1 blocat timp de 23 de secunde! [kauditd:22]
[ 9665.022801] watchdog: BUG: blocare soft - CPU#1 blocat timp de 23 de secunde! [kauditd:22]
[ 9674.339074] audit: limita rămasă depășită
[ 9674.344825] audit: limita rămasă depășită
[ 9674.351922] audit: limita rămasă depășită
[ 9693.022802] watchdog: BUG: blocare soft - CPU#1 blocat timp de 23 de secunde! [kauditd:22]
[ 9721.022802] watchdog: BUG: blocare soft - CPU#1 blocat timp de 22 de secunde! [kauditd:22]
[ 9734.182947] audit: limita rămasă depășită
[ 9734.188086] audit: limita rămasă depășită
[ 9734.194938] audit: limita rămasă depășită
[ 9736.682801] rcu: INFO: rcu_sched auto-detectat blocare pe CPU
[ 9736.684975] rcu: 1-....: (509855 bifează acest GP) idle=492/1/0x400000000000002 softirq=1049753/1049838 fqs=254454 
[ 9754.486826] rcu: INFO: rcu_sched a detectat blocaje accelerate pe CPU/sarcini: { 1-... } 511745 jiffies s: 525 root: 0x2/.
[ 9754.497787] rcu: blocarea structurilor rcu_node:
[ 9761.022802] watchdog: BUG: blocare soft - CPU#1 blocat timp de 22 de secunde! [kauditd:22]

În plus, am încercat să monitorizez top în timpul dezarhivării și chiar înainte de a fi scos, văd kauditd zboară de la mai puțin de 0% CPU la 70%-100% CPU:

sus - 12:00:01 până la 21 min, 1 utilizator, medie de încărcare: 1,34, 1,29, 0,98
sus - 12:02:53 până la 24 min, 2 utilizatori, medie de încărcare: 2,80, 1,87, 1,25
Sarcini: 168 total, 4 alergare, 95 dormit, 0 oprit, 0 zombi
%Cpu(e): 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 gratuit, 958672 folosit, 4753604 buff/cache
Schimb KiB: 0 total, 0 gratuit, 0 folosit. 6878804 disponibil Mem

  PID UTILIZATOR PR NI VIRT RES SHR S %CPU %MEM TIME+ COMANDA
  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

Ce ar putea face ca demonul de audit al nucleului să ocupe atât de mult CPU atât de brusc? Nu a fost o creștere treptată, ci o clipă de până la 100% și apoi o înghețare a VM.

A mai întâlnit cineva asta?

anx avatar
drapel fr
anx
Ce este `ds_am`? Executați ulei de șarpe anti-malware care utilizează în mod destul de intenționat cel puțin la fel de multe resurse (audit propriu și kernel) cât cheltuiți pentru operația de dezarhivare cu siguranță intensivă I/O?
x3nr0s avatar
drapel wf
Este trend micro, așa că răspunsul este da. Dar avem nevoie de el în scopuri de acreditare de securitate.
Puncte:0
drapel ge

Nu pot spune de ce. Dar v-aș sugera să utilizați SCREEN sau BYOB și să dezarhivați în fundal.

În timp ce dezarhivează fișierul, închideți sesiunea SSH, reveniți după câteva minute și VOILA!

x3nr0s avatar
drapel wf
Există vreun motiv pentru care un proces intens, cum ar fi zip, utilizează mult mai multe resurse atunci când un utilizator este activ SSH?
drapel ge
nu, cu excepția cazului în care îl rulați așa: ~#ssh user@host unzip bigFile.zip, deoarece ar putea returna rezultatul în sesiunea dvs. de throw ssh terminal..... Dar nu văd de ce ar provoca o astfel de „crash” ''.... Aș sugera să deschideți un bilet către Azure.
drapel ge
Sau ați putea limita timpul de proces care durează dezarhivarea. Dacă aveți un VM mic, este posibil să aveți o limitare în acest sens. Ex: sudo cpulimit --pid 17918 --limit 20. sau utilizați comanda ''nice''.
Puncte:0
drapel fr
anx

Cred că acest lucru este cauzat de o componentă a Trend Micro software. Rezultatul dvs. de top se afișează 1:40.58 timpul petrecut pe ds_am, o parte semnificativă din timpul de funcționare.

Software-ul de acest fel este, de asemenea, un candidat probabil (deși nu singurul) pentru configurarea facilităților de auditare a nucleului.

  1. Consultați documentația și/sau contactați furnizorul de software despre utilizarea directă a resurselor. Cu toate acestea, verificați mai întâi dacă vreo activitate regulată de întreținere sau upgrade pentru acel software este încă în așteptare.

  2. Determinați configurația cadrului de auditare a nucleului și identificați alt software care se interfață cu acesta. (încerca auditctl)

x3nr0s avatar
drapel wf
După investigații suplimentare, nu cred că acest lucru este legat de micro tendințe. După încă câteva teste, ieșirea `top` nu a arătat ds_agent cu CPU la fel de mare. De asemenea, am oprit temporar ds_agent. Cu toate acestea, kauditd a fost întotdeauna la 100% după o dezarhivare mare.
anx avatar
drapel fr
anx
@x3nr0s Dacă nu a fost acel software (oprirea componentelor runtime nu confirmă și nici nu o exclude), altcineva trebuie să fi instruit nucleul să colecteze informații de audit. Încercați să adune mai multe informații despre regulile de auditare încărcate în prezent în nucleu.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.