Carica avg weirdness su Linux Ubuntu

In questi giorni ho cercato di capire la stranezza che sta accadendo nella nostra infrastruttura ma non sono stato in grado di capirlo, quindi mi rivolgo a voi ragazzi per darmi qualche suggerimento.

Ho notato in Graphite, picchi in load_avg che si verificano con regolarità mortale circa ogni 2 ore - non sono esattamente 2 ore ma è molto regolare. Allego uno screenshot di questo che ho preso da Graphite

Mi sono bloccato a indagare su questo - la regolarità di questo mi portava a pensare che fosse una sorta di cron job o qualcosa del genere ma non ci sono cronjob in esecuzione su questi server - in realtà si tratta di macchine virtuali in esecuzione nel cloud Rackspace. Quello che sto cercando è una sorta di indicazione che potrebbe causare questi problemi e come indagare ulteriormente.

I server sono abbastanza inattivi: si tratta di un ambiente di gestione temporanea, quindi non c'è quasi traffico in entrata / non dovrebbero esserci carichi. Queste sono tutte e 4 le VM con core virtuali. Quello che so per certo è che stiamo prendendo un sacco di campioni di grafite ogni 10 secondi circa, ma se questa è la causa del carico, mi aspetto che sia costantemente alto invece che ogni 2 ore a ondate su server diversi.

Qualsiasi aiuto su come investigare questo sarebbe molto apprezzato!

Ecco alcuni dati di sar per app01 - che è il primo picco blu nella foto sopra - Non sono stato in grado di trarre QUALSIASI conclusione dai dati. Inoltre, il fatto che i byte scrivano un picco che vedi accadere ogni mezz'ora (NON OGNI 2 ORE) è dovuto al fatto che lo chef-cliente corre ogni 30 minuti. Proverò a raccogliere più dati anche se l'ho già fatto ma non sono riuscito a trarre alcuna conclusione da quelli.

CARICARE

09:55:01 PM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
10:05:01 PM         0       125      1.28      1.26      0.86         0
10:15:01 PM         0       125      0.71      1.08      0.98         0
10:25:01 PM         0       125      4.10      3.59      2.23         0
10:35:01 PM         0       125      0.43      0.94      1.46         3
10:45:01 PM         0       125      0.25      0.45      0.96         0
10:55:01 PM         0       125      0.15      0.27      0.63         0
11:05:01 PM         0       125      0.48      0.33      0.47         0
11:15:01 PM         0       125      0.07      0.28      0.40         0
11:25:01 PM         0       125      0.46      0.32      0.34         0
11:35:01 PM         2       130      0.38      0.47      0.42         0
11:45:01 PM         2       131      0.29      0.40      0.38         0
11:55:01 PM         2       131      0.47      0.53      0.46         0
11:59:01 PM         2       131      0.66      0.70      0.55         0
12:00:01 AM         2       131      0.81      0.74      0.57         0

processore

09:55:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:05:01 PM     all      5.68      0.00      3.07      0.04      0.11     91.10
10:15:01 PM     all      5.01      0.00      1.70      0.01      0.07     93.21
10:25:01 PM     all      5.06      0.00      1.74      0.02      0.08     93.11
10:35:01 PM     all      5.74      0.00      2.95      0.06      0.13     91.12
10:45:01 PM     all      5.05      0.00      1.76      0.02      0.06     93.10
10:55:01 PM     all      5.02      0.00      1.73      0.02      0.09     93.13
11:05:01 PM     all      5.52      0.00      2.74      0.05      0.08     91.61
11:15:01 PM     all      4.98      0.00      1.76      0.01      0.08     93.17
11:25:01 PM     all      4.99      0.00      1.75      0.01      0.06     93.19
11:35:01 PM     all      5.45      0.00      2.70      0.04      0.05     91.76
11:45:01 PM     all      5.00      0.00      1.71      0.01      0.05     93.23
11:55:01 PM     all      5.02      0.00      1.72      0.01      0.06     93.19
11:59:01 PM     all      5.03      0.00      1.74      0.01      0.06     93.16
12:00:01 AM     all      4.91      0.00      1.68      0.01      0.08     93.33

09:55:01 PM       tps      rtps      wtps   bread/s   bwrtn/s
10:05:01 PM      8.88      0.15      8.72      1.21    422.38
10:15:01 PM      1.49      0.00      1.49      0.00     28.48
10:25:01 PM      1.54      0.00      1.54      0.03     29.61
10:35:01 PM      8.35      0.04      8.31      0.32    411.71
10:45:01 PM      1.58      0.00      1.58      0.00     30.04
10:55:01 PM      1.52      0.00      1.52      0.00     28.36
11:05:01 PM      8.32      0.01      8.31      0.08    410.30
11:15:01 PM      1.54      0.01      1.52      0.43     29.07
11:25:01 PM      1.47      0.00      1.47      0.00     28.39
11:35:01 PM      8.28      0.00      8.28      0.00    410.97
11:45:01 PM      1.49      0.00      1.49      0.00     28.35
11:55:01 PM      1.46      0.00      1.46      0.00     27.93
11:59:01 PM      1.35      0.00      1.35      0.00     26.83
12:00:01 AM      1.60      0.00      1.60      0.00     29.87

RETE:

10:25:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
10:35:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
10:35:01 PM      eth1      7.07      4.77      5.24      2.42      0.00      0.00      0.00
10:35:01 PM      eth0      2.30      1.99      0.24      0.51      0.00      0.00      0.00
10:45:01 PM        lo      8.35      8.35      2.18      2.18      0.00      0.00      0.00
10:45:01 PM      eth1      3.69      3.45      0.65      2.22      0.00      0.00      0.00
10:45:01 PM      eth0      1.50      1.33      0.15      0.36      0.00      0.00      0.00
10:55:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
10:55:01 PM      eth1      3.66      3.40      0.64      2.19      0.00      0.00      0.00
10:55:01 PM      eth0      0.79      0.87      0.08      0.29      0.00      0.00      0.00
11:05:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
11:05:01 PM      eth1      7.29      4.73      5.25      2.41      0.00      0.00      0.00
11:05:01 PM      eth0      0.82      0.89      0.09      0.29      0.00      0.00      0.00
11:15:01 PM        lo      8.34      8.34      2.18      2.18      0.00      0.00      0.00
11:15:01 PM      eth1      3.67      3.30      0.64      2.19      0.00      0.00      0.00
11:15:01 PM      eth0      1.27      1.21      0.11      0.34      0.00      0.00      0.00
11:25:01 PM        lo      8.32      8.32      2.18      2.18      0.00      0.00      0.00
11:25:01 PM      eth1      3.43      3.35      0.63      2.20      0.00      0.00      0.00
11:25:01 PM      eth0      1.13      1.09      0.10      0.32      0.00      0.00      0.00
11:35:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
11:35:01 PM      eth1      7.16      4.68      5.25      2.40      0.00      0.00      0.00
11:35:01 PM      eth0      1.15      1.12      0.11      0.32      0.00      0.00      0.00
11:45:01 PM        lo      8.37      8.37      2.18      2.18      0.00      0.00      0.00
11:45:01 PM      eth1      3.71      3.51      0.65      2.20      0.00      0.00      0.00
11:45:01 PM      eth0      0.75      0.86      0.08      0.29      0.00      0.00      0.00
11:55:01 PM        lo      8.30      8.30      2.18      2.18      0.00      0.00      0.00
11:55:01 PM      eth1      3.65      3.37      0.64      2.20      0.00      0.00      0.00
11:55:01 PM      eth0      0.74      0.84      0.08      0.28      0.00      0.00      0.00

Per le persone curiose di cronjobs. Ecco il riepilogo di tutti i cronjobs configurati sul server (ho scelto app01 ma questo sta accadendo anche su alcuni altri server con gli stessi cronjobs impostati)

$ ls -ltr /etc/cron*
-rw-r--r-- 1 root root  722 Apr  2  2012 /etc/crontab

/etc/cron.monthly:
total 0

/etc/cron.hourly:
total 0

/etc/cron.weekly:
total 8
-rwxr-xr-x 1 root root 730 Dec 31  2011 apt-xapian-index
-rwxr-xr-x 1 root root 907 Mar 31  2012 man-db

/etc/cron.daily:
total 68
-rwxr-xr-x 1 root root  2417 Jul  1  2011 popularity-contest
-rwxr-xr-x 1 root root   606 Aug 17  2011 mlocate
-rwxr-xr-x 1 root root   372 Oct  4  2011 logrotate
-rwxr-xr-x 1 root root   469 Dec 16  2011 sysstat
-rwxr-xr-x 1 root root   314 Mar 30  2012 aptitude
-rwxr-xr-x 1 root root   502 Mar 31  2012 bsdmainutils
-rwxr-xr-x 1 root root  1365 Mar 31  2012 man-db
-rwxr-xr-x 1 root root  2947 Apr  2  2012 standard
-rwxr-xr-x 1 root root   249 Apr  9  2012 passwd
-rwxr-xr-x 1 root root   219 Apr 10  2012 apport
-rwxr-xr-x 1 root root   256 Apr 12  2012 dpkg
-rwxr-xr-x 1 root root   214 Apr 20  2012 update-notifier-common
-rwxr-xr-x 1 root root 15399 Apr 20  2012 apt
-rwxr-xr-x 1 root root  1154 Jun  5  2012 ntp

/etc/cron.d:
total 4
-rw-r--r-- 1 root root 395 Jan  6 18:27 sysstat
$ sudo ls -ltr /var/spool/cron/crontabs 
total 0
$

Come puoi vedere non ci sono cronjobs ORARI. Solo giornaliero / settimanale ecc.

Ho raccolto un sacco di statistiche (vmstat, mpstat, iostat) - per quanto ci stia provando, non riesco a vedere alcun indizio che possa suggerire un comportamento errato di un componente VM ... Sto iniziando a inclinarmi verso potenziali problemi all'hypervisor. Sentiti libero di dare un'occhiata alle statistiche. L'essenza inizia con l'output di sar -q attorno al tempo "offensivo" e quindi puoi vedere vm, mp e iostats ....

Fondamentalmente è ancora un mistero per me ...

— milosgajdos
fonte

Hai dei dati interattivi che puoi condividere per indagare ulteriormente (ad esempio, cosa visualizzano 'top', 'htop' e 'iotop' durante i picchi di carico ricorrenti)? Inoltre, hai controllato i registri delle applicazioni durante i periodi in questione per vedere se mostrano comportamenti strani? Inoltre, hai host con configurazioni simili non ospitati su un'infrastruttura di cloud pubblico e, in tal caso, presentano comportamenti simili?

— esquireofoz,

In termini di registri delle app, non succede nulla. Le uniche voci di registro che contiene sono i controlli del monitoraggio che avvengono ogni minuto - sostanzialmente il sistema di monitoraggio colpisce il sito principale e riporta il codice del risultato - a parte che i registri sono completamente vuoti. Inoltre, come puoi vedere, c'è una varietà di host sopra - questo sta accadendo su tutti loro (redis, app server, chef server ecc.)

— milosgajdos

Hai provato a usare psacct per restringerlo?

— HTTP500,

presumi la regolarità, ma i dati che mostri non mostrano picchi che si verificano regolarmente .. si prega di essere più specifici per quanto riguarda il periodo esatto in cui mostra regolarità (nell'arco di diversi giorni forse? nella foto, non c'è regolarità). esegui un "top -n 1" ogni 1 minuto circa e tienili in un file, e questo potrebbe aiutare a vedere quali altri processi competono per la cpu nello stesso momento in cui si verifica un picco. Se App1 è un'app che si affaccia su Internet, forse è solo qualcuno che può accedervi e forzare quel comportamento? aggiungere una registrazione "netstat -an" regolare (ogni minuto?)

— Olivier Dulac

Hai visto lo screenshot allegato? Se ciò non mostra regolarità, non so cosa. Ora ho aumentato il periodo di campionamento per sar, quindi sto campionando ogni 5 minuti. La regolarità nella foto è più che ovvia - succede ogni due ore. Questo è un ambiente di gestione temporanea senza traffico - come puoi sicuramente vedere dagli output sar sopra riportati per le statistiche di rete.

— milosgajdos,

Interessante.

In primo luogo, puoi aumentare la frequenza della registrazione sar. Al posto di 10 minuti, prova ad accedere ogni minuto. Il cronjob sysstat è configurabile.

Quindi, prova a scrivere i seguenti comandi.

ps auxf > /tmp/ps.out
vmstat 1 50 > /tmp/vm.out
mpstat -P ALL 1 50 > /tmp/mp.out
iostat -xdk 1 50 > /tmp/io.out
cat /proc/meminfo > /tmp/meminfo.out

Raccogliere questo insieme di dati ad ogni iterazione quando la media del carico aumenta manualmente o tramite cron. Sarebbe bene avere i dati di almeno un giorno lavorativo completo.

Ora capisco che i server sono inattivi ma alcune applicazioni devono essere in esecuzione. Quali sono?

È possibile eseguire uno strumento di profilazione, come perf o oprofile.

Qualche componente hardware del server è stato modificato? Anche qualcosa di innocuo come un aggiornamento del firmware o un aggiornamento del software.

Ehi, una domanda. Qual è lo scheduler che stai eseguendo. Credo che sia cfq, ogni possibilità che tu possa cambiarlo in noop. Inserire elevator=noopil parametro della riga di comando del kernel e riavviare il sistema e vedere se lo migliora.

— Soham Chakraborty
fonte

Ho aggiunto una piccola modifica sullo scheduler. si prega di vedere il risultato.

— Soham Chakraborty,

Registra i processi principali

Poiché la ricorrenza è molto regolare, impostare cron job per monitorare i processi principali durante quel periodo

#app01
20-59 0/2 * * * root /usr/bin/top -b -n 1 | /usr/bin/head -n 15 >> /var/log/top.log

Passa 20-59a *registrerà l'intera ora per ogni numero pari di ore. Il processo Cron verrà eseguito una volta al minuto in entrambi i casi.

È possibile che si desideri aggiungere il file top.log alla rotazione del registro in modo che non occupi tutto lo spazio nel caso in cui si dimentichi di disabilitarlo.

Controlla il file di registro

Cerca le voci del file di registro durante il periodo di caricamento elevato

Prendi la seguente voce di caricamento come esempio

10:25:01 PM         0       125      4.10      3.59      2.23         0

Fare

grep ' 22:2' /var/log/*
grep ' 22:2' /var/log/apache2/*

Questo mostrerà tutte le voci di registro per 22:2x:xx. Potrebbe essere necessario includere altre directory di registro.

Dom 6 gennaio 21:00:07 2013: xvda w_await spike

Grafico xvda - Il picco di w_await è al Sun 6 gennaio 21:00:07 2013 inserisci qui la descrizione dell'immagine

— John Siu
fonte

Una cosa che vorrei sicuramente verificare:

grafici vSphere per lo stesso modello, forse un'altra VM sullo stesso host sta consumando le CPU (quindi il carico sulla VM aumenta poiché ci vuole più tempo per elaborare la stessa quantità di dati con un flusso costante a causa della minore disponibilità della CPU per la tua macchina virtuale).

Modifica: non l'ho capito la prima volta :) Stai eseguendo su Rackspace, quindi nessun controllo sull'hypervisor, ma potrebbe valere la pena chiedere a rackspace se potevano verificare se questo schema è comune su altre VM sullo stesso host .

— Martino Dino
fonte

Anch'io sospetto di questo - non sarebbe la prima volta che la nuvola di Rackspace provocherà una sorta di follia. Dubito che monitorino tutti i loro server hypervisor, intendo in termini di comportamento errato delle VM, tuttavia vorrei escludere qualsiasi possibilità "interna" prima di passare all'ultima risorsa: il supporto di Rackspace.

— milosgajdos,

Le prestazioni dell'hypervisor influiranno sulla media del carico apparente di una VM? Questo mi porta a pensare a come viene calcolata la media del carico. Questo potrebbe forse essere un effetto della funzionalità di risparmio energia / verde che sposta periodicamente il lavoro su un numero inferiore di core all'insaputa del sistema operativo? O che ne dici di cambiare dinamicamente la frequenza di clock in base, ad esempio, a input ambientali?

— trp,

La media del carico viene calcolata dall'algoritmo di pianificazione, in parole semplici, se nella coda di elaborazione sono presenti 100 attività e l'hypervisor è efficiente al 100% nell'esecuzione di 10 attività per 1 secondo, quindi sono necessari 10 secondi per eseguire 100 attività, se l'hypervisor è efficiente solo al 50% (forse overcrovisioning della CPU) ci vorranno 20 secondi per eseguire la stessa quantità di attività, portando quindi a un carico maggiore. Spiegazione completa: blog.scoutapp.com/articles/2009/07/31/…

— Martino Dino,