Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better thread labels? #197

Open
tmm1 opened this issue Oct 18, 2024 · 0 comments
Open

Better thread labels? #197

tmm1 opened this issue Oct 18, 2024 · 0 comments

Comments

@tmm1
Copy link

tmm1 commented Oct 18, 2024

Currently all the built-in threads are just called 'node' which is not useful in debugging. For instance, with lldb:

thread #4, name = 'node', stop reason = signal SIGSTOP
    frame #0: 0x00000000011cda71 nsolid`v8::internal::ConcurrentMarking::RunMajor(v8::JobDelegate*, v8::base::EnumSet<v8::internal::CodeFlushMode, int>, unsigned int, bool) + 1217
nsolid`v8::internal::ConcurrentMarking::RunMajor:
thread #5, name = 'node', stop reason = signal SIGSTOP
    frame #0: 0x00000000011cc5ee nsolid`void v8::internal::MarkingVisitorBase<v8::internal::ConcurrentMarkingVisitor, v8::internal::ConcurrentMarkingState>::ProcessStrongHeapObject<v8::internal::FullHeapObjectSlot>(v8::internal::HeapObject, v8::internal::FullHeapObjectSlot, v8::internal::HeapObject) + 30
nsolid`v8::internal::MarkingVisitorBase<v8::internal::ConcurrentMarkingVisitor, v8::internal::ConcurrentMarkingState>::ProcessStrongHeapObject<v8::internal::FullHeapObjectSlot>:

these are clearly GC threads, and marking them as such would make it much easier to see that GC was the cause of CPU usage when looking at htop (with thread names enabled in settings):

Screenshot 2024-10-18 at 1 10 43 PM

it looks like there may be some precedent already inside v8, as using the built-in profiler shows up as a thread named v8:ProfEvntProc

thread #32, name = 'v8:ProfEvntProc', stop reason = signal SIGSTOP
    frame #0: 0x00007f348069ce96 libc.so.6`___lldb_unnamed_symbol3485 + 198
    frame #1: 0x00007f348069f83c libc.so.6`pthread_cond_timedwait + 540
    frame #2: 0x00000000024fc6c1 nsolid`v8::base::ConditionVariable::WaitFor(v8::base::Mutex*, v8::base::TimeDelta const&) + 97
    frame #3: 0x0000000001583e19 nsolid`v8::internal::SamplingEventsProcessor::Run() + 249

note that on linux there is generally a 16 character limit on thread names

i propose major-gc and minor-gc labels for the threads above. there are also many others that could use unique labels:

thread #2, name = 'node', stop reason = signal SIGSTOP
    frame #0: 0x00007f348071fb9e libc.so.6`epoll_pwait + 110
    frame #1: 0x0000000001985f73 nsolid`___lldb_unnamed_symbol90679 + 595
    frame #2: 0x0000000001971617 nsolid`uv_run + 327
    frame #3: 0x0000000000db579b nsolid`node::WorkerThreadsTaskRunner::DelayedTaskScheduler::Start()::'lambda'(void*)::_FUN(void*) + 123
thread #7, name = 'node', stop reason = signal SIGSTOP
    frame #0: 0x00007f348071fb9e libc.so.6`epoll_pwait + 110
    frame #1: 0x0000000001985f73 nsolid`___lldb_unnamed_symbol90679 + 595
    frame #2: 0x0000000001971617 nsolid`uv_run + 327
    frame #3: 0x0000000000f19f41 nsolid`node::nsolid::EnvList::env_list_routine_(nsuv::ns_thread*, node::nsolid::EnvList*) + 305
    frame #4: 0x00007f34806a0144 libc.so.6`___lldb_unnamed_symbol3515 + 724
    frame #5: 0x00007f348071fa40 libc.so.6`__clone + 64
thread #13, name = 'node', stop reason = signal SIGSTOP
    frame #0: 0x00007f348071fb9e libc.so.6`epoll_pwait + 110
    frame #1: 0x0000000001985f73 nsolid`___lldb_unnamed_symbol90679 + 595
    frame #2: 0x0000000001971617 nsolid`uv_run + 327
    frame #3: 0x0000000000ec9372 nsolid`node::nsolid::statsd::StatsDAgent::run_(nsuv::ns_thread*, std::weak_ptr<node::nsolid::statsd::StatsDAgent>) + 82
    frame #4: 0x0000000000ed5fad nsolid`void nsuv::ns_thread::create_proxy_wp_<void (*)(nsuv::ns_thread*, std::weak_ptr<node::nsolid::statsd::StatsDAgent>), node::nsolid::statsd::StatsDAgent>(void*) + 93

in addition to labeling the obvious nodejs/v8 and nsolid threads, it would be also be useful to provide better instrumentation of js-created worker_threads

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant