2015-06-17 19 views
5

Sto cercando una spiegazione semplice di come funziona gperftools. Finora, questo è quello che ho imparato:Come funzionano i gperftools?

  • Gestisce un campionatore stop-the-world. In altre parole, interrompe periodicamente la profilazione del programma per raccogliere informazioni.
  • La libreria pprof di Golang utilizza gperftools al di sotto.

Oltre ad una panoramica generale, qui ci sono alcune domande specifiche che vorrei risposto:

  • È gperftools un "event based profiler" o "instrumentation profiler". Da quanto ho capito, questi profiler modificano il modo in cui un programma viene eseguito e raccolgono campioni tramite tali modifiche
  • A quale 'livello' nel sistema operativo è presente il profilo gperftools? Ha il profilo del kernel come SystemTap o perf?
  • gperftools è sicuro per essere eseguito su un server di produzione con traffico elevato?

Sto ponendo questa domanda alla ragione sull'overhead introdotto usando pprof su un server Go.

risposta

4

È un profiler di campionamento.

Fondamentalmente, ci sono due tipi di profiling: o si tiene traccia di tutto ciò che fa il programma (tenendo conto di ogni chiamata, avvolgendo ogni funzione in un timer, in altre parole, permeando il codice con i propri strumenti) oppure lascia che si ritorca da solo, ma controllalo brevemente ogni tanto (prendendo i campioni).

Il problema con la strumentazione è che cambia il modo in cui il programma esegue. Rallenta il programma, in un modo che distorce anche i risultati. (Ad esempio, il codice di produzione potrebbe spendere troppo tempo in attesa di IO, ma il codice strumentato potrebbe non esibire questo.) Raccoglie anche molti più dati di quanto sia statisticamente necessario (se alla fine tutto ciò che ti interessa è identificare la maggior parte del tempo) speso).

Eseguendo strace, è possibile vedere che Google-perftools funziona utilizzando i segnali SIGPROF (così come HPCToolkit e Open | SpeedShop). Presumibilmente si limita a configurare un gestore di eventi, quindi rimane in memoria, senza consumare alcun ciclo della CPU, fino a quando l'hardware/OS non interrompe il programma (che può essere infrequente come preferisci), quindi presumibilmente salva solo una copia dello stack di chiamate (e pianifica il successivo interrupt) prima di lasciare che il controllo ritorni al programma. Lo stack di chiamate elenca la funzione del programma fino a (e quale funzione genitore l'ha invocata, e così, qual è il modo in cui funzionano le dichiarazioni di "ritorno" ..).

+0

+1 Non è molto ben compreso come siano effettivamente i campioni di stack informativi, specialmente se vengono esaminati quelli individuali. Purtroppo, questa mancanza di comprensione porta all'assunzione generale che un gran numero di essi è necessario, e quindi devono essere riassunti (in tempo di auto-tempo, cumulativo, grafici delle chiamate, grafici di fiamma, ecc.) È molto facile per i grandi aumenti di velocità da nascondere in quei riepiloghi, ma non possono nascondersi da un programmatore solo esaminando un piccolo numero di campioni. [* Esempi. *] (Http://stackoverflow.com/a/25870103/23771) –

+0

E SIGPROF è generato dal timer di intervallo, il ['setitimer()'] (http://man7.org/linux/man -pages/man2/setitimer.2.html) - https://github.com/gperftools/gperftools/blob/7822b5b0b9fa7e016e1f6b46ea86f26f4691a457/src/profile-handler.cc#L482 'setitimer (timer_type_, & timer, 0);' – osgx