google / perfetto

Performance instrumentation and tracing for Android, Linux and Chrome (read-only mirror of https://android.googlesource.com/platform/external/perfetto/)
https://www.perfetto.dev
Apache License 2.0
2.83k stars 354 forks source link

Try to lower cpu cost in perfetto client #919

Closed ChunelFeng closed 3 hours ago

ChunelFeng commented 4 hours ago

HI, we use perfetto sdk to write track_event in our project, and we find cpu use more than before(no use).

experiments show, disable some track_event categories make our client's cpu lower, but you know, on other hand, this leads some useful info loss.

any other idea can help us lower the cpu use? for example, change or add some config?

duration_ms: 0

incremental_state_config: {
  clear_period_ms: 500
}

buffers {
  size_kb: 296605
  fill_policy: RING_BUFFER
}

data_sources {
  config {
    name: "linux.ftrace"
    target_buffer: 0
    ftrace_config {
      drain_period_ms: 120
      compact_sched: {
        enabled: true
      }
    ftrace_events: "sched/*"
    ftrace_events: "irq/*"
    ftrace_events: "task/task_newtask"
    ftrace_events: "task/task_rename"
    }
  }
}

# User-defined data source
data_sources: {
    config {
        name: "track_event"
         track_event_config {
           enabled_categories: "ros2"
           enabled_categories: "app"
         }
        target_buffer: 0
    }
}
LalitMaganti commented 3 hours ago

So a few suggestions: 1) tracing irqs is very very expensive. It's rarely useful unless you are debugging low level data. Perfetto also allows configuring which irqs to capture which is used to configure the kernel. 2) you can increase the drain period and the ftrace buffer size both of which will reduce the CPU use of ftrace tracing 3) you can increase the shmem sizes when configuring your producer for track event: see https://cs.android.com/android/platform/superproject/main/+/main:external/perfetto/include/perfetto/tracing/tracing.h;drc=5916ee589c4880e2d8a1a9ad6dc852108e4c44c1;l=88 4) figure out the spammy track events, put them in a new category and then disable it

In general though, you only have three options: 1) reduce how much you are tracing 2) increase the memory you are using 3) accept that tracing solves enough problems that it justifies the overhead :)

We tend to go with option 1) and 3) on our side but you can choose other combinations as well :)