Project

General

Profile

Actions

Feature #10602

closed

Support multithreaded profiling

Added by mperham (Mike Perham) almost 10 years ago. Updated about 1 year ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:66863]

Description

The current rb_profile_frames captures the frame for whatever thread is current. This makes profiling a multithreaded system impossible. I'd like a rb_thread_profile_frames which captures a given thread. It seems like it would be a very simple change, something like this:

int
rb_profile_frames(int start, int limit, VALUE *buff, int *lines)
{
    rb_profile_frames(start, limit, buff, lines, GET_THREAD())
}

int
rb_thread_profile_frames(int start, int limit, VALUE *buff, int *lines, rb_thread_t *th)
{
    int i;
    rb_control_frame_t *cfp = th->cfp, *end_cfp = RUBY_VM_END_CONTROL_FRAME(th);
    ...

This way profiling gems could lock to a specific thread.

Updated by mperham (Mike Perham) almost 10 years ago

To be clear, I want to profile a single thread within a running multithreaded Ruby app. This is useful for profiling individual Sidekiq jobs executing in production. Right now the profile frames capture data from other threads which makes the output useless.

Actions #2

Updated by jeremyevans0 (Jeremy Evans) over 5 years ago

  • Tracker changed from Bug to Feature
  • ruby -v deleted (2.1.5)
  • Backport deleted (2.0.0: UNKNOWN, 2.1: UNKNOWN)

Updated by ivoanjo (Ivo Anjo) over 1 year ago

PR to implement this being discussed in https://github.com/ruby/ruby/pull/7784

Actions #4

Updated by Anonymous about 1 year ago

  • Status changed from Open to Closed

Applied in changeset git|4adf418be963b3554962b2f27057be81486c57d9.


[Feature #10602] Add new API rb_profile_thread_frames()

Add a new API rb_profile_thread_frames(), which is essentialy a
per-thread version of rb_profile_frames().

While the original rb_profile_frames() always returns results about the
current active thread obtained by GET_EC(), this new API takes a Thread
to be profiled as an argument.

This should come in handy when profiling I/O-bound programs such as
webapps, since this new API allows us to learn about Threads performing
I/O (which do not have the GVL).

Profiling worker threads (such as Sidekiq workers) may be another
application.

Implements [Feature #10602]

Co-authored-by: Mike Perham

Actions

Also available in: Atom PDF

Like2
Like0Like0Like0Like0