sqlhist(1)

Från Wiki.linux.se -Linux wikipedia på Svenska.
Version från den 15 maj 2026 kl. 06.45 av Admin (diskussion | bidrag) (Skapade sidan med '= sqlhist(1) = == NAMN == sqlhist - verktyg som använder SQL-liknande språk för att skapa eller visa skapande av tracefs-histogram och syntetiska händelser == SYNOPSIS == <pre> sqlhist [ALTERNATIV] [SQL-select-kommando] </pre> == BESKRIVNING == sqlhist(1) tar ett SQL-liknande uttryck och använder det för att skapa tracefs-histogram och syntetiska händelser som kan utföra olika åtgärder för hantering av spårningsdata. Filsystemet tracefs utgör ett grä...')
(skillnad) ← Äldre version | Nuvarande version (skillnad) | Nyare version → (skillnad)
Hoppa till navigering Hoppa till sök

sqlhist(1)

NAMN

sqlhist - verktyg som använder SQL-liknande språk för att skapa eller visa skapande av tracefs-histogram och syntetiska händelser

SYNOPSIS

sqlhist [ALTERNATIV] [SQL-select-kommando]

BESKRIVNING

sqlhist(1) tar ett SQL-liknande uttryck och använder det för att skapa tracefs-histogram och syntetiska händelser som kan utföra olika åtgärder för hantering av spårningsdata.

Filsystemet tracefs utgör ett gränssnitt mot Linux spårningsinfrastruktur. Denna infrastruktur innehåller olika dynamiska och statiska händelser i kärnan. Varje sådan händelse kan ha ett histogram kopplat till sig, där händelsens fält definierar histogrammets grupper.

En syntetisk händelse är ett sätt att koppla samman två separata händelser och använda fält och tidsstämplar från dessa händelser för att skapa en ny dynamisk händelse. Denna nya dynamiska händelse kallas en syntetisk händelse.

Fälten från respektive händelse kan användas i enkla beräkningar. Exempelvis kan skillnaden mellan ett fält i den ena händelsen och ett fält i den andra händelsen beräknas. Detta fungerar även för händelsernas tidsstämplar, där tidsskillnaden mellan två händelser kan extraheras och placeras i den syntetiska händelsen.

Andra åtgärder kan också utföras utifrån händelsefält. En ögonblicksbild kan tas av kärnans ringbuffert när en variabel som används vid skapandet av den syntetiska händelsen når ett nytt maxvärde, eller helt enkelt ändras.

Kommandona för att skapa histogram och syntetiska händelser är komplexa och inte enkla att komma ihåg. sqlhist används för att konvertera SQL-syntax till de kommandon som behövs för att skapa histogrammet eller den syntetiska händelsen.

SQL-select-kommandot är en SQL-sträng enligt definitionen i tracefs_sql(3).

Observera att detta normalt måste köras som root, eller med sudo, eftersom interaktion med tracefs-katalogen kräver root-behörighet. Undantaget är när alternativet -t används med en kopia av tracefs-katalogen och dess händelser.

sqlhist är ett enkelt program vars kod faktiskt finns i manualsidan tracefs_sql(3).

ALTERNATIV

-n namn Namnet på den syntetiska händelse som ska skapas. Denna händelse kan sedan användas som vilken annan händelse som helst och aktiveras via trace-cmd(1).

-t tracefs-katalog För att testa programmet som en vanlig användare utan root-behörighet kan en kopia av tracefs-katalogen användas. Genom att ange denna katalog med alternativet -t kan programmet köras mot kopian.

Observera att -e naturligtvis inte fungerar som icke-root, eftersom kommandona då inte kan köras mot den riktiga tracefs-miljön.

# mkdir /tmp/tracing
# cp -r /sys/kernel/tracing/events /tmp/tracing
# exit
$ ./sqlhist -t /tmp/tracing ...

-e Visa inte bara kommandona som skapar histogrammet, utan kör dem också. Detta kräver root-behörighet.

-f fil Läs SQL-kommandona från fil i stället för från kommandoraden. Om fil är - läses kommandona från standard input.

-m var Utför den angivna åtgärden när variabeln var når ett nytt maxvärde. Detta kan inte användas tillsammans med -c.

-c var Utför den angivna åtgärden när variabeln var ändrar värde. Detta kan inte användas tillsammans med -m.

-s Utför en ögonblicksbild i stället för att anropa den syntetiska händelsen.

-T Utför både en ögonblicksbild och spåra den syntetiska händelsen.

-S fält[,fält] Spara de angivna fälten. Fälten måste vara fält från den avslutande händelsen, "end"-händelsen, i SQL-select-kommandot.

-B instans För enkla uttryck som endast skapar ett histogram anger detta den instans där histogrammet ska skapas.

Detta ignoreras vid fullständig skapelse av syntetiska händelser, eftersom syntetiska händelser har global effekt på alla spårningsinstanser, medan histogram endast påverkar en enskild instans.

EXEMPEL

Skapa den körbara filen sqlhist:

man tracefs_sql | sed -ne '/^EXAMPLE/,/FILES/ { /EXAMPLE/d ; /FILES/d ; p}' > sqlhist.c
gcc -o sqlhist sqlhist.c `pkg-config --cflags --libs libtracefs`

Som beskrivits ovan kan man för teständamål skapa en kopia av händelsekatalogen:

$ mkdir /tmp/tracing
$ sudo cp -r /sys/kernel/tracing/events /tmp/tracing/
$ sudo chmod -R 0644 /tmp/tracing/

Exempel på enkel histogramutdata med en kopia av tracefs-katalogen:

$ ./sqlhist -t /tmp/tracing/ 'SELECT CAST(call_site as SYM-OFFSET), bytes_req, CAST(bytes_alloc AS _COUNTER_) FROM kmalloc'

Detta ger följande utdata:

echo 'hist:keys=call_site.sym-offset,bytes_req:vals=bytes_alloc' > /sys/kernel/tracing/events/kmem/kmalloc/trigger

Detta kan användas av root:

# echo 'hist:keys=call_site.sym-offset,bytes_req:vals=bytes_alloc' > /sys/kernel/tracing/events/kmem/kmalloc/trigger
# cat /sys/kernel/tracing/events/kmem/kmalloc/hist

Exempel på histogramutdata:

# event histogram
#
# trigger info: hist:keys=call_site.sym-offset,bytes_req:vals=hitcount,bytes_alloc:sort=hitcount:size=2048 [active]
#

{ call_site: [ffffffff813f8d8a] load_elf_phdrs+0x4a/0xb0                               , bytes_req:        728 } hitcount:          1  bytes_alloc:       1024
{ call_site: [ffffffffc0c69e74] nf_ct_ext_add+0xd4/0x1d0 [nf_conntrack]                , bytes_req:        128 } hitcount:          1  bytes_alloc:        128
{ call_site: [ffffffff818355e6] dma_resv_get_fences+0xf6/0x440                         , bytes_req:          8 } hitcount:          1  bytes_alloc:          8
{ call_site: [ffffffffc06dc73f] intel_gt_get_buffer_pool+0x15f/0x290 [i915]            , bytes_req:        424 } hitcount:          1  bytes_alloc:        512
{ call_site: [ffffffff813f8d8a] load_elf_phdrs+0x4a/0xb0                               , bytes_req:        616 } hitcount:          1  bytes_alloc:       1024
{ call_site: [ffffffff8161a44c] __sg_alloc_table+0x11c/0x180                           , bytes_req:         32 } hitcount:          1  bytes_alloc:         32
{ call_site: [ffffffffc070749d] shmem_get_pages+0xad/0x5d0 [i915]                      , bytes_req:         16 } hitcount:          1  bytes_alloc:         16
{ call_site: [ffffffffc07507f5] intel_framebuffer_create+0x25/0x60 [i915]              , bytes_req:        408 } hitcount:          1  bytes_alloc:        512
{ call_site: [ffffffffc06fc20f] eb_parse+0x34f/0x910 [i915]                            , bytes_req:        408 } hitcount:          1  bytes_alloc:        512
{ call_site: [ffffffffc0700ebd] i915_gem_object_get_pages_internal+0x5d/0x270 [i915]   , bytes_req:         16 } hitcount:          1  bytes_alloc:         16
{ call_site: [ffffffffc0771188] intel_frontbuffer_get+0x38/0x220 [i915]                , bytes_req:        400 } hitcount:          1  bytes_alloc:        512
{ call_site: [ffffffff8161a44c] __sg_alloc_table+0x11c/0x180                           , bytes_req:        128 } hitcount:          1  bytes_alloc:        128
{ call_site: [ffffffff813f8f45] load_elf_binary+0x155/0x1680                           , bytes_req:         28 } hitcount:          1  bytes_alloc:         32
{ call_site: [ffffffffc07038c8] __assign_mmap_offset+0x208/0x3d0 [i915]                , bytes_req:        288 } hitcount:          1  bytes_alloc:        512
{ call_site: [ffffffff813737b2] alloc_bprm+0x32/0x2f0                                  , bytes_req:        416 } hitcount:          1  bytes_alloc:        512
{ call_site: [ffffffff813f9027] load_elf_binary+0x237/0x1680                           , bytes_req:         64 } hitcount:          1  bytes_alloc:         64
{ call_site: [ffffffff8161a44c] __sg_alloc_table+0x11c/0x180                           , bytes_req:         64 } hitcount:          1  bytes_alloc:         64
{ call_site: [ffffffffc040ffe7] drm_vma_node_allow+0x27/0xe0 [drm]                     , bytes_req:         40 } hitcount:          2  bytes_alloc:        128
{ call_site: [ffffffff813cda98] __do_sys_timerfd_create+0x58/0x1c0                     , bytes_req:        336 } hitcount:          2  bytes_alloc:       1024
{ call_site: [ffffffff818355e6] dma_resv_get_fences+0xf6/0x440                         , bytes_req:         40 } hitcount:          2  bytes_alloc:        128
{ call_site: [ffffffff8139b75a] single_open+0x2a/0xa0                                  , bytes_req:         32 } hitcount:          2  bytes_alloc:         64
{ call_site: [ffffffff815df715] bio_kmalloc+0x25/0x80                                  , bytes_req:        136 } hitcount:          2  bytes_alloc:        384
{ call_site: [ffffffffc071e5cd] i915_vma_work+0x1d/0x50 [i915]                         , bytes_req:        416 } hitcount:          3  bytes_alloc:       1536
{ call_site: [ffffffff81390d0d] alloc_fdtable+0x4d/0x100                               , bytes_req:         56 } hitcount:          3  bytes_alloc:        192
{ call_site: [ffffffffc06ff65f] i915_gem_do_execbuffer+0x158f/0x2440 [i915]            , bytes_req:         16 } hitcount:          4  bytes_alloc:         64
{ call_site: [ffffffff8137713c] alloc_pipe_info+0x5c/0x230                             , bytes_req:        384 } hitcount:          5  bytes_alloc:       2560
{ call_site: [ffffffff813771b4] alloc_pipe_info+0xd4/0x230                             , bytes_req:        640 } hitcount:          5  bytes_alloc:       5120
{ call_site: [ffffffff81834cdb] dma_resv_list_alloc+0x1b/0x40                          , bytes_req:         40 } hitcount:          6  bytes_alloc:        384
{ call_site: [ffffffff81834cdb] dma_resv_list_alloc+0x1b/0x40                          , bytes_req:         56 } hitcount:          9  bytes_alloc:        576
{ call_site: [ffffffff8120086e] tracing_map_sort_entries+0x9e/0x3e0                    , bytes_req:         24 } hitcount:         60  bytes_alloc:       1920

Totals:
    Hits: 122
    Entries: 30
    Dropped: 0

Observera att även om exemplen använder versaler för SQL-nyckelorden behöver de inte skrivas så. SELECT kan även skrivas som select eller till och med sElEcT.

Genom att använda hela SQL-språket kan syntetiska händelser skapas och bearbetas. Exempelvis kan uppvakningslatens registreras genom att använda sqlhist tillsammans med trace-cmd(1). Detta görs genom att skapa en syntetisk händelse som kopplar samman händelserna sched_waking och sched_switch.

# sqlhist -n wakeup_lat -e -T -m lat 'SELECT end.next_comm AS comm, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat FROM ' \
  'sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250  -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -30
        <idle>-0       [002] dNh4 23454.902246: sched_wakeup: comm=cyclictest pid=12272 prio=120 target_cpu=002
        <idle>-0       [005] ...1 23454.902246: cpu_idle: state=4294967295 cpu_id=5
        <idle>-0       [007] d..1 23454.902246: cpu_idle: state=0 cpu_id=7
        <idle>-0       [002] dNh1 23454.902247: hrtimer_expire_exit: hrtimer=0000000037956dc2
        <idle>-0       [005] d..1 23454.902248: cpu_idle: state=0 cpu_id=5
        <idle>-0       [002] dNh1 23454.902248: write_msr: 6e0, value 4866ce957272
        <idle>-0       [006] ...1 23454.902248: cpu_idle: state=4294967295 cpu_id=6
        <idle>-0       [002] dNh1 23454.902249: local_timer_exit: vector=236
        <idle>-0       [006] d..1 23454.902250: cpu_idle: state=0 cpu_id=6
        <idle>-0       [002] .N.1 23454.902250: cpu_idle: state=4294967295 cpu_id=2
        <idle>-0       [002] dN.1 23454.902251: rcu_utilization: Start context switch
        <idle>-0       [002] dN.1 23454.902252: rcu_utilization: End context switch
        <idle>-0       [001] ...1 23454.902252: cpu_idle: state=4294967295 cpu_id=1
        <idle>-0       [002] dN.3 23454.902253: prandom_u32: ret=3692516021
        <idle>-0       [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
        <idle>-0       [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
        <idle>-0       [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
        <idle>-0       [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify

Här är alternativen för sqlhist förklarade:

-n wakeup_lat Namnge den syntetiska händelsen som ska användas: wakeup_lat.

-e Kör de kommandon som skrivs ut.

-T Utför både en spårningsåtgärd och därefter en ögonblicksbild. Bufferten växlas då över till den statiska snapshot-bufferten.

-m lat Utlös åtgärderna varje gång lat når ett nytt maxvärde.

Uppdelning av SQL-uttrycket:

'SELECT end.next_comm AS comm, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat FROM ' \
   'sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'

end.next_comm AS comm Spara fältet next_comm från sched_switch och placera det i fältet comm i den syntetiska händelsen wakeup_lat.

(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat Beräkna skillnaden mellan tidsstämplarna från händelsen sched_switch och händelsen sched_waking.

Eftersom tidsstämplar normalt registreras i nanosekunder skulle TIMESTAMP ge hela tidsstämpeln i nanosekunder. Här används i stället TIMESTAMP_USECS, vilket trunkerar värdet till mikrosekunder. Värdet sparas i variabeln lat, som också registreras i den syntetiska händelsen.

FROM sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid Skapa den syntetiska händelsen genom att koppla sched_waking till sched_switch, där fältet pid i sched_waking matchas mot fältet next_pid i sched_switch.

Aliaset start används för sched_waking och aliaset end används för sched_switch. Dessa alias kan sedan användas i resten av SQL-uttrycket.

WHERE end.next_prio < 100 && end.next_comm == "cyclictest" Filtrera logiken så att den endast körs om fältet next_prio är mindre än 100.

Observera att prioriteringar i kärnan är omvända: realtidsprioriteter representeras från 0 till 100, där 0 är högsta prioritet.

Dessutom spåras endast händelser där next_comm, alltså processen som schemaläggs in i sched_switch, har namnet "cyclictest".

För kommandot trace-cmd:

trace-cmd start -e all -e wakeup_lat -R stacktrace

trace-cmd start Aktiverar spårning. Det spelar inte in till en fil.

-e all Aktivera alla händelser.

-e wakeup_lat -R stacktrace Låt händelsen "wakeup_lat", alltså den syntetiska händelsen, aktivera triggern stacktrace. För varje förekomst av händelsen "wakeup_lat" registreras då en kärnstackspårning i ringbufferten.

Efter att cyclictest har körts, vilket är ett realtidsverktyg för att mäta uppvakningslatens, kan snapshot-bufferten läsas.

trace-cmd show -s trace-cmd show läser kärnans ringbuffert. Alternativet -s gör att snapshot-bufferten läses i stället för den vanliga bufferten.

<idle>-0       [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17

Här ser vi att händelsen "wakeup_lat" inträffade på CPU 2, med en uppvakningslatens på 17 mikrosekunder.

Detta kan extraheras till en trace.dat-fil som trace-cmd(1) kan läsa för vidare analys, liksom kernelshark.

# trace-cmd extract -s
# trace-cmd report --cpu 2 | tail -30
        <idle>-0     [002] 23454.902238: prandom_u32:          ret=1633425088
        <idle>-0     [002] 23454.902239: sched_wakeup:         cyclictest:12275 [19] CPU:002
        <idle>-0     [002] 23454.902241: hrtimer_expire_exit:  hrtimer=0xffffbbd68286fe60
        <idle>-0     [002] 23454.902241: hrtimer_cancel:       hrtimer=0xffffbbd6826efe70
        <idle>-0     [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70 now=23455294430750 function=hrtimer_wakeup/0x0
        <idle>-0     [002] 23454.902243: sched_waking:         comm=cyclictest pid=12272 prio=120 target_cpu=002
        <idle>-0     [002] 23454.902244: prandom_u32:          ret=1102749734
        <idle>-0     [002] 23454.902246: sched_wakeup:         cyclictest:12272 [120] CPU:002
        <idle>-0     [002] 23454.902247: hrtimer_expire_exit:  hrtimer=0xffffbbd6826efe70
        <idle>-0     [002] 23454.902248: write_msr:            6e0, value 4866ce957272
        <idle>-0     [002] 23454.902249: local_timer_exit:     vector=236
        <idle>-0     [002] 23454.902250: cpu_idle:             state=4294967295 cpu_id=2
        <idle>-0     [002] 23454.902251: rcu_utilization:      Start context switch
        <idle>-0     [002] 23454.902252: rcu_utilization:      End context switch
        <idle>-0     [002] 23454.902253: prandom_u32:          ret=3692516021
        <idle>-0     [002] 23454.902254: sched_switch:         swapper/2:0 [120] R ==> cyclictest:12275 [19]
        <idle>-0     [002] 23454.902256: wakeup_lat:           next_comm=cyclictest lat=17
        <idle>-0     [002] 23454.902258: kernel_stack:         <stack trace >
=> trace_event_raw_event_synth (ffffffff8121a0db)
=> action_trace (ffffffff8121e9fb)
=> event_hist_trigger (ffffffff8121ca8d)
=> event_triggers_call (ffffffff81216c72)
=> trace_event_buffer_commit (ffffffff811f7618)
=> trace_event_raw_event_sched_switch (ffffffff8110fda4)
=> __traceiter_sched_switch (ffffffff8110d449)
=> __schedule (ffffffff81c02002)
=> schedule_idle (ffffffff81c02c86)
=> do_idle (ffffffff8111e898)
=> cpu_startup_entry (ffffffff8111eba9)
=> secondary_startup_64_no_verify (ffffffff81000107)

FEL

Eftersom sqlhist bara är exempelkod från en manualsida är det garanterat att programmet innehåller många fel. Bland annat hanteras inte alla felvägar korrekt.

SE ÄVEN

trace-cmd(1), tracefs_sql(3)

FÖRFATTARE

Skriven av Steven Rostedt, <rostedt@goodmis.org>.

RESURSER

https://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git/

KOPIERING

Copyright (C) 2021, Inc.

Fri användning av denna programvara ges enligt villkoren i GNU Public License, GPL.

NOTERINGAR

1. rostedt@goodmis.org mailto:rostedt@goodmis.org

KOLOFON

Denna sida är en del av projektet libtracefs, Linuxkärnans bibliotek för trace-filsystemet.

Information om projektet finns på:

https://www.trace-cmd.org/

Om du har en felrapport för denna manualsida, se:

https://www.trace-cmd.org/

Denna sida hämtades från projektets uppströms Git-arkiv:

https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git

Sidan hämtades den 16 januari 2026. Vid den tidpunkten var datumet för den senaste commit som hittades i arkivet den 2 januari 2026.

Om du upptäcker renderingsproblem i HTML-versionen av sidan, eller anser att det finns en bättre eller mer uppdaterad källa för sidan, eller har korrigeringar eller förbättringar av informationen i denna KOLOFON, som inte är en del av den ursprungliga manualsidan, skicka e-post till man-pages@man7.org.

SIDOR SOM HÄNVISAR TILL DENNA SIDA