perf top Linux: individuare i punti caldi della CPU nel kernel

Con perf top Su Linux riesco a individuare in pochi secondi quali funzioni del kernel stanno attualmente occupando la maggior parte del tempo di CPU e dove si formano i colli di bottiglia. In questa guida vi mostrerò, seguendo passaggi chiari, come individuare i punti critici in tempo reale, interpretare correttamente i risultati e ricavarne rapide ottimizzazioni per lo scheduler, la rete e la memoria.

Punti centrali

Ritengo che la visualizzazione in tempo reale di perf È l'ideale come punto di partenza, perché mette subito in evidenza le attività che richiedono più tempo. Le percentuali associate a ciascun simbolo mi indicano se il collo di bottiglia si trova nel Kernel oppure si trova nello spazio utente. Dai modelli ricorrenti deduco se prevalgono i blocchi, gli IRQ, la rete o la memoria. Successivamente, individuo il punto critico con strumenti più approfonditi e verifico le modifiche direttamente sotto carico. In questo modo miglioro passo dopo passo la CPU-Ottimizzare l'utilizzo delle risorse e ridurre le latenze in modo sostenibile.

• Punti di accesso live identificare e dare priorità
• percentuali interpretare correttamente in base alla funzione
• Obiettivo principale impostare: IRQ, blocchi, memoria
• Flusso di lavoro: in alto → record → report
• Ottimizzazioni verificare in modo mirato

Che cos'è Perf Top e a cosa serve?

Uso perf top, per vedere immediatamente, mentre il carico è in esecuzione, quali simboli consumano la maggior parte del tempo di CPU. Lo strumento accede ai contatori di prestazioni hardware e mi mostra, a brevi intervalli, una classifica aggiornata delle funzioni più dispendiose. Secondo Linux-Magazin, perf è in grado di gestire sia il profiling che il tracing, il che rende la Vista in diretta si integra perfettamente con analisi più approfondite. Nel mio flusso di lavoro abituale, integro l’istantanea con perf record e perf report per esaminare i callgraph e i percorsi esatti. In questo modo rispondo alla domanda fondamentale: dove trascorre il CPU proprio in quel momento – nello stack di rete, nel sottosistema di memoria, nello scheduler o in un driver?

Installare e avviare Perf Top

Dopo l'installazione tramite il pacchetto di distribuzione, eseguo il comando perf top viene solitamente eseguito con privilegi avanzati, in modo che siano visibili i simboli del kernel e gli eventi di sistema. È sufficiente un semplice comando „perf top“ per ottenere una prima visualizzazione in tempo reale e individuare le funzioni predominanti. Se ho bisogno di concentrarmi su singoli processi, aggiungo il PID con l'opzione -p; per CPU specifiche utilizzo l'opzione -C con un elenco o un intervallo. Definisco gli eventi con l'opzione -e, ad esempio cpu-cycles, instructions o branch-misses, a seconda della questione che intendo chiarire. Per ottenere risultati riproducibili, avvio la misurazione durante un carico di lavoro reale, in modo che Hotspot risaltare chiaramente e non essere sovrastati dal rumore di fondo.

Ecco come leggo correttamente questo numero

Nell'elenco valuto innanzitutto il Valori percentuali per ogni simbolo, poiché rappresentano le percentuali di tempo relative. Percentuali elevate nelle funzioni di sistema indicano un collo di bottiglia nel kernel, mentre i simboli dominanti nello spazio utente rimandano piuttosto alla logica dell’applicazione. Se vedo molte routine dello scheduler, penso a un numero eccessivo di thread attivi, affinità sfavorevoli o priorità inadeguate. Se compaiono funzioni di memoria nelle prime posizioni, controllo i modelli di allocazione, i page fault, la località NUMA e le cache. Per i percorsi di rete, esamino la distribuzione degli IRQ, le impostazioni Gro/TSO e il comportamento dei driver, poiché tali dettagli sono Latenza influenzare notevolmente.

Cause tipiche degli hotspot del kernel

Molti punti critici sorgono perché tante piccole spese si sommano fino a diventare una grande Carico si sommano. Spesso i cambi di contesto eccessivi, la concorrenza sui lock e gli IRQ distribuiti in modo diseguale aumentano il tempo di CPU. Allo stesso modo, le strutture di memoria frammentate, l’uso inefficiente degli slab o il paging costante causano cicli superflui. Se noto un determinato driver, lo metto in relazione con il carico di lavoro, l’hardware e la versione per circoscrivere gli effetti collaterali. Nei sistemi multicore, verifico inoltre la presenza di false sharing, poiché, secondo la documentazione del kernel, le linee di cache condivise possono rapidamente causare un costoso Spese generali possono causare.

Analisi esemplificativa di un hotspot

Se il grafico mi mostra percentuali elevate e costanti nel tempo relative alle funzioni di rete, per prima cosa distinguo i tipi di carico: pacchetti piccoli vs. pacchetti grandi, TLS vs. testo in chiaro, molte connessioni vs. poche sessioni di lunga durata, al fine di Causa restringere il campo. Successivamente approfondisco l'analisi con `perf record` e `perf report`, attivo i callgraph (-g) e confronto i percorsi su più esecuzioni. Se invece il problema riguarda la gestione della memoria, controllo l’allocatore, le Huge Pages, le impostazioni THP e l’affinità NUMA, poiché in questi casi si generano rapidamente percorsi superflui. Spesso interpreto gli hotspot dello scheduler come un segno di un numero eccessivo di thread runnable o di un'assegnazione inadeguata delle risorse CPU. Modifico sempre e solo un Parametri per ogni ciclo, in modo da poter attribuire correttamente l'effetto.

Il massimo in termini di prestazioni negli ambienti di hosting

Negli scenari di hosting noto spesso come i costi minimi del kernel influenzino la Latenza di numerosi servizi. I container, le VM e le istanze di database in esecuzione parallela spostano nettamente il profilo verso la rete, lo storage e lo scheduler. Con perf top riesco a individuare se i colli di bottiglia risiedono piuttosto nella gestione degli IRQ, nell’elaborazione degli SoftIRQ o nei percorsi di blocco. Successivamente, includo nell’analisi la versione del kernel, il layout NUMA, le affinità IRQ e le profondità delle code, poiché questi fattori interagiscono tra loro. Chi desidera approfondire l’argomento troverà in questa guida a Analizzare i colli di bottiglia della CPU altri spunti pratici che utilizzo regolarmente nella mia attività professionale.

Guida pratica all'analisi

Comincio con uno scenario di carico riproducibile, in modo che le misurazioni rimangano comparabili e Hotspot compaiono in modo stabile. Successivamente avvio perf top e prendo nota dei simboli dominanti nel corso di diversi aggiornamenti. Con perf record/report sintetizzo questa istantanea in un quadro chiaro dei callgraph, in modo da individuare il percorso che porta al punto più costoso. Successivamente modifico in modo mirato un solo parametro, ad esempio un’affinità IRQ o la profondità di una coda, e ripeto la misurazione. Solo quando l’effetto è chiaro, passo al successivo Passo e documento i risultati in vista delle future finestre di manutenzione.

Quando è opportuno utilizzare altri strumenti

Per una prospettiva storica, callgraph più dettagliati o catene di eventi specifiche, ricorro a perf record/report, ftrace o eBPF. I tracepoint mi aiutano a mettere in luce percorsi specifici, mentre con i programmi BPF ottengo metriche flessibili. Se desidero approfondire i percorsi del kernel, questi strumenti forniscono Strumenti di analisi eBPF segnali preziosi direttamente sul posto. Per i problemi di cache e di condivisione, perf-c2c e pahole sono utili non appena viene identificato chiaramente il punto critico. In questo modo passo dall'analisi della visualizzazione in tempo reale all'individuazione della causa, senza perdermi in dettagli irrilevanti dettagli perdere.

Opzioni di campionamento e filtri nella pratica

Passo la Campionamento-Adotto una strategia mirata alla questione, invece di misurare tutto in modo indiscriminato. In caso di picchi sporadici, aumento la frequenza di campionamento e accorcio gli intervalli di visualizzazione per catturare i picchi transitori. Per concentrarmi su un processo, imposto -p sul PID pertinente; per concentrarmi sulla CPU, imposto -C sui core più sollecitati. Con -e controllo l’evento, ad esempio cpu-cycles per un profiling ampio o cache-misses se sospetto un problema di gestione della memoria. Utilizzo i callgraph (-g) non appena ho localizzato approssimativamente un hotspot e il Causa che vuole trovare nello stack.

La tabella seguente mostra combinazioni pratiche di tasti che utilizzo spesso nella vita di tutti i giorni, insieme agli usi tipici di ciascuna opzione:

Opzione	Effetto	Utilizzo
-p PID	Limita la misurazione a un processo	Specifiche dell'app Hotspot restringere
-C Elenco delle CPU	Attenzione su alcuni settori chiave	Verifica della distribuzione NUMA/IRQ
-e Evento	Seleziona evento hardware o software	cicli, istruzioni, mancati accessi alla cache
-g	Attiva il campionamento del call graph	Percorsi costosi nel Pila Riconoscere
–kernel/–user	Filtra a livello di kernel o di spazio utente	Separare la fonte del tempo CPU
–ordinare	Ordinati per simbolo, DSO, dso:symbol	Leggibilità della Classifica aumento

Provo sempre brevemente le configurazioni prima di avviare misurazioni più lunghe, in modo che le Visualizzare rimanga stabile e non si verifichino effetti collaterali. Soprattutto in caso di frequenza di campionamento elevata, prendo in considerazione l’overhead per non sovraccaricare inutilmente il sistema. Nel caso degli host container, verifico inoltre se i limiti dei namespace e dei cgroup limitino la visibilità. Per ottenere benchmark riproducibili, documento tutti i parametri, comprese le versioni del kernel e dei driver. Questa disciplina mi fa risparmiare molto tempo in seguito Tempo nell'interpretazione dei cambiamenti.

Interpretazione dei sottosistemi: rete, memoria, scheduler

Quando i percorsi di rete sono in cima alla lista, controllo innanzitutto le affinità IRQ, l’RSS (Receive-Side-Scaling) e gli offload come GRO/TSO, poiché questi parametri di regolazione influenzano la Produttività-Modificare il bilanciamento della latenza. In caso di anomalie nelle prestazioni della memoria, analizzo i modelli di allocazione, le Huge Pages, le statistiche dello slab e i tassi di page fault. Spesso attribuisco il carico dello scheduler a un numero eccessivo di thread, alla mancanza di affinità della CPU o a una prioritizzazione non equa. Per eventi mirati del kernel, imposto inoltre dei tracepoint oppure utilizzo bpftrace nell'hosting, per confermare le ipotesi. In questo modo, incrocio i dati di osservazione in tempo reale provenienti da perf top con quelli di punti di misurazione più profondi e arrivo più rapidamente al vero e proprio Causa.

Requisiti e visibilità dei simboli

Così che perf top Quando risolvo tutti i simboli rilevanti del kernel, faccio attenzione a due aspetti: i permessi corretti e la disponibilità delle informazioni sui simboli. Sui sistemi di produzione, kernel.perf_event_paranoid spesso impostato su un valore elevato. Per analisi approfondite del kernel, riduco temporaneamente questo valore oppure opero come root con i privilegi necessari (CAP_PERFMON/CAP_SYS_ADMIN). Se gli indirizzi del kernel sono mascherati (kptr_restrict), di solito vedo comunque i nomi, ma non gli indirizzi grezzi: mi basta questo per stabilire le priorità. Per lo spazio utente installo i pacchetti di debuginfo corrispondenti, in modo che perf top mostri i nomi delle funzioni invece degli offset. Questo riduce le congetture e accelera l'individuazione della causa.

Valori percentuali e insidie del campionamento

Interpreto le percentuali riportate nell'elenco come quote relative dei campioni misurati, non come carico esatto della CPU nel dominio del tempo. Se seleziono più eventi, è possibile Multiplexing agire: Perf distribuisce i contatori nel tempo e normalizzato il grafico. Per ottenere un quadro chiaro, inizio misurando in modo ampio i cicli di CPU o le istruzioni, per poi aggiungere in un secondo momento gli eventi specifici. I picchi di breve durata li rilevo con una frequenza più alta (-F) e intervalli più brevi; nei sistemi con attività ridotta è sufficiente la frequenza standard. Inoltre, tengo presente che Inattivo-Le fasi e i cambiamenti di frequenza (Turbo, Governor) possono distorcere la percezione. Per effettuare misurazioni comparative, uniformo quindi le impostazioni di clock e di potenza.

I callgraphs approfonditi

Una volta individuato un hotspot, ne approfondisco l'analisi tramite i callgraph. Con -g e, con un metodo di unwinding adeguato, ottengo il percorso che porta al punto più costoso. I puntatori di frame o l’unwinding DWARF mi forniscono stack stabili; ove disponibili, utilizzo i buffer di ritorno supportati dall’hardware (LBR) per ottenere catene molto precise. Aumento i buffer mmap solo nella misura necessaria per mantenere basso l’overhead. Se lo stack mostra molte funzioni di supporto, faccio attenzione a inclusivo vs. esclusivo Costi: ciò che conta è se la funzione in sé è costosa o se incide solo in quanto percorso di transito. Questa distinzione mi fa spesso risparmiare ore nella ricerca delle cause.

Lavorare in container e macchine virtuali

Negli ambienti containerizzati verifico se la mia vista su cgroups e che gli spazi dei nomi siano corretti. Concentro le misurazioni sui PID e sulle CPU rilevanti, in modo che i “vicini rumorosi” non distorcano il quadro. Per le VM, verifico che la PMU virtuale sia abilitata; in caso contrario, mi mancano eventi hardware precisi e vedo principalmente segnali software. Spesso riconosco gli host KVM dai simboli che circondano kvm_vcpu oppure vmx/svm. In scenari di questo tipo, separo nettamente le analisi dell'host e quelle del guest, in modo da non confondere causa ed effetto.

Modelli riconoscibili e ipotesi rapide

Nella vita di tutti i giorni si sono rivelati efficaci alcuni schemi che verifico immediatamente:

• Concorrenza di Lock: Immersioni queued_spin_lock_slowpath oppure mutex_spin_on_owner A livello superiore, le strutture dei dati sono troppo generiche o le code di lavoro troppo ristrette. Riduco la contesa tramite lo sharding, una granularità dei blocchi più fine o la modifica delle dimensioni dei batch.
• Stampa dallo scheduler: Si stanno moltiplicando schedule(), pick_next_task_fair oppure i percorsi di wake-up, regolo il numero di thread, le affinità e le priorità. Spesso basta calmare i thread “loquaci” o definire con precisione le impostazioni della CPU.
• Softirq di rete: Picchi a net_rx_action, napi_poll oppure gli offload delle checksum indicano picchi di traffico o una distribuzione non ottimale di RSS e IRQ. Assegno gli IRQ ai nuclei appropriati e regolo GRO/TSO in base al profilo di throughput/latenza desiderato.
• Percorsi di archiviazione: Molto tempo a do_page_fault, copy_user_* oppure le funzioni Slab mi consentono di verificare i modelli di allocazione, THP/Huge Pages e la località NUMA. In questo caso, un posizionamento errato comporta una perdita di cicli che passa inosservata.
• RCU e timer: Dominare rcu_core oppure i callback del timer, sto rivalutando le strategie di polling e di elaborazione in batch dei miei servizi, al fine di garantire un funzionamento più fluido del sistema.

Approfondire la precisione di misura e la riproducibilità

Per garantire test comparabili in modo attendibile, mantengo costanti i fattori ambientali: governor della CPU, stati Turbo, processi in background e persino la temperatura ambiente nei nodi ad alta densità. Assegno i carichi di test a core definiti e, se necessario, isolo le CPU più sollecitate, in modo che le decisioni dello scheduler rimangano stabili. Documento tutte le modifiche, comprese le versioni del kernel, dei driver e del firmware. In caso di modifiche più rischiose, prevedo dei punti di ripristino ed effettuo una nuova misurazione immediatamente dopo l’intervento. In questo modo ottengo un risultato affidabile Prima/Dopo-Una storia che riesco a comprendere anche a distanza di mesi.

Consigli pratici: comandi che uso spesso

A seconda della domanda, utilizzo ricette concise:

• Ampia analisi preliminare sotto carico: perf top -e cpu-cycles –kernel –user
  Una rapida panoramica per capire se è il kernel o lo spazio utente a dettare le regole.
• Analisi del flusso di esecuzione con Callgraph: perf top -p PID -g –kernel –user
  Mostrami i percorsi in tempo reale dell'applicazione in questione, senza rumore di sistema.
• Focus sulla CPU: perf top -C 2-5 -e cpu-cycles -g
  È utile in caso di hotspot NUMA o IRQ, quando solo pochi core sono “sovraccarichi”.
• Sospetto di archiviazione: perf top -e cache-misses -e cycles -g –kernel
  Mostra i percorsi di memoria in relazione ai cicli.
• Fissare i picchi volanti: perf top -F 999 -I 1000 -e cicli
  Una frequenza più elevata e intervalli di visualizzazione più brevi consentono di rilevare i picchi di breve durata.

Indicazioni interpretative per sottosistemi specifici

All'indirizzo Rete Oltre a NAPI e ai percorsi RX/TX, monitoro anche le componenti TLS/crypto, che possono diventare predominanti in caso di elevato volume di handshake. Verifico se lo zero-copy o il coalescing funzionano in modo efficace e se i segmenti di grandi dimensioni (TSO/GSO) superano i miei limiti di latenza. Nel Memoria- In questo ambito, mi affido a THP: è d'aiuto per il mio carico di lavoro, oppure gli eventi di split/merge causano interferenze? Nel caso di Immagazzinamento lo interpreto blk_mq-Simboli e percorsi io_uring come indicatori della profondità delle code e delle strategie di unione. Nel caso del scheduler Colleghio le valanghe di wakeup alle catene Lock o IO e ottimizzo i percorsi tramite backpressure anziché “più thread”.

I limiti di Perf Top e quando cambio strategia

Perché perf top Poiché si basa sul campionamento, preferisco le immagini medie piuttosto che i singoli eventi. Per le sequenze deterministiche, passo a tracepoint, ftrace o eBPF per dimostrare con precisione le causalità. Se ho bisogno di una quantificazione esatta (ad es. istruzioni per richiesta), combino questi strumenti con stat perf oppure analisi offline da perf record/report. Se mi imbatto in stack poco chiari (simboli mancanti, unwinding errato), per prima cosa ne risolvo la visibilità: fare altro sarebbe come brancolare nel buio.

Riassumendo brevemente

Con perf top Riesco a individuare in tempo reale dove la CPU perde tempo nel kernel e quali simboli dovrei esaminare per primi. Sulla base delle percentuali, dei modelli ricorrenti e della separazione tra kernel e spazio utente, deduco le prossime azioni mirate da intraprendere. Successivamente, sintetizzo i risultati con perf record/report, verifico i cambiamenti sotto carico e documento la mia catena di misurazione. Negli ambienti di hosting questo approccio si rivela particolarmente vantaggioso, poiché molti servizi e container traggono beneficio l’uno dall’altro non appena i percorsi del kernel funzionano in modo più efficiente. Chi interiorizza questo processo risparmia giorni di diagnostica e riduce Latenze e garantisce tempi di risposta sensibilmente più stabili sotto carico reale.