Even if stack trace is less than ideal, it seems now to be a Galera thing, so assigning to sysprg

oli, there is no promise or obligation that all process threads are always instrumented, there are 3rd party components that create threads, that have no slightest idea of what is PS.

Hi Vlad, OK got it.

But some of theses 3rd party components are registering in the PS correctly:

thread/sql/wsrep_rollbacker_thread FOREGROUND 150011
thread/sql/wsrep_applier_thread FOREGROUND 150012

Should that not be somehow a standard if you create a thread that one should also register in PS???

Just for curiosity, what has happened to all the other BACKGROUND threads? They disappeared somehow! Or are they only started on demand nowadays???

thread/innodb/io_ibuf_thread
thread/innodb/io_read_thread
thread/innodb/io_read_thread
thread/innodb/io_read_thread
thread/innodb/io_read_thread
thread/innodb/io_write_thread
thread/innodb/io_write_thread
thread/innodb/io_write_thread
thread/innodb/io_write_thread
thread/innodb/page_flush_coordinator_thread
thread/innodb/log_checkpointer_thread
thread/innodb/log_flush_notifier_thread
thread/innodb/log_flusher_thread
thread/innodb/log_write_notifier_thread
thread/innodb/log_writer_thread
thread/innodb/log_files_governor_thread
thread/innodb/srv_lock_timeout_thread
thread/innodb/srv_error_monitor_thread
thread/innodb/srv_monitor_thread
thread/innodb/buf_resize_thread
thread/innodb/srv_master_thread
thread/innodb/dict_stats_thread
thread/innodb/fts_optimize_thread
thread/innodb/buf_dump_thread
thread/innodb/clone_gtid_thread
thread/innodb/srv_purge_thread

There are no innodb threads anymore that only do 1 thing and wait 99.9% of the time. The only dedicated thread that remains if the page cleaner, because it was easier. Anything else is served by internal threadpool inside the Innodb, since 10.5 . Threads are created when needed, and go away when idle. There are mechanisms to cap number of specific "groups" those handling io completion, or purge workers.

Some of 3rd party instrument their threads, with performance schema, like this galera (which I think is part of the server). But some don't , like another part of Galera, which I think is not part of the server.

I realize that statement that you can't expect all threads to be instrumented, is overly generic. But here are couple of illustrations

1. If you look into rocksdb - the library, they also have their threadpool for background work, and it was written without perfschema instrumentation in mind
2. Sometimes you'll see threads internal to Linux uring, and those won't be the threads we create, but they are still part of mariadbd process.
3. If you start any process on Windows, including mariadbd.exe, there are already 4 threads in it, only one of them executing main function, and 3 others idle.

This is just to illustrate that server does not have control over all possible threads, in some cases number of instrumented threads is equal to number of all threads, in other cases it might not, and without looking at the stacktraces, it is impossible to know whether it is a bug or not.

Thanks Vlad for this information!