Rough numbers for calls to open and openat (used to access files) on various configurations. Then compare summaries of both results and dive into the differences. On your own GitLab instance while performing the action performed by the customer, When nothing stands out in the results, a good way to get more context is to run strace In the example above, we can see which files took longer to open for PID 16815.

stats takes the same sorting and count options as summary. Processes using the -p/ -pid for a specific process, or -s/ -stats flags forĪ sorted list. strace-parser sidekiq_trace.txt summary -c15 -s =pid The number of results defaults to 25 processes, butĬan be changed using the -c/ -count option. You can also sort based on total time, # of system calls made, PID #, and # of child processes How to use the toolįirst run the tool with summary flag to get a summary of the top processes sorted by time spent actively performing tasks.

Or you can build it from source if you have the Rust compiler. It is similar to strace -C,īut provides much more detailed statistics. Provide a high level summary of the strace output. We have a series of GitLab Unfiltered videos on using strace to understand GitLab.Brendan Gregg has a more detailed explanation of how to use strace.See the strace zine for a quick walkthrough.Ps auwx | grep puma | awk '' | xargs strace -tt -T -f -y -yy -s 1024 -o /tmp/puma.txtīe aware that strace can have major impacts to system performance when it is running.

# -tt print timestamps with microsecond accuracy # -T print the time spent in each syscall # -f also trace any child processes that forked # -y print the path associated with file handles # -yy print socket and device file handle details # -s max string length to print for an event # -o output file # run strace on all puma processes

Linux command cheat sheet