Add MySQL Active Sessions #11709
Add MySQL Active Sessions #11709
Conversation
ghost
added
the
|
The |
There's currently a weird flaky issue that causes test_minimal_config to break if the activity tests run first. Need to investigate later.
| COALESCE( | ||
| IF(thread_a.processlist_state = 'User sleep', 'User sleep', | ||
| IF(waits_a.event_id = waits_a.end_event_id, 'CPU', waits_a.event_name)), 'CPU') AS wait_event, |
There was a problem hiding this comment.
Shouldn't we do this on the backend?
There was a problem hiding this comment.
Think it makes sense to do it in the SQL so what we are doing is more exposed as opposed to being more hidden in the code. We can do both. We can do the coalesce in the SQL and redo in the code if we want to control it there.
| LEFT JOIN performance_schema.events_waits_current AS waits_a ON waits_a.thread_id = thread_a.thread_id AND | ||
| waits_a.event_id IN( | ||
| SELECT | ||
| MAX(waits_b.EVENT_ID) |
There was a problem hiding this comment.
What is this doing exactly?
There was a problem hiding this comment.
the view events_waits_current can have multiple rows per thread (despite the documentation that states otherwise), thus we use EVENT_ID to identify the row we want to use. We want the row with the highest EVENT_ID value as the most recent and reflects the current wait
There was a problem hiding this comment.
Very interesting! That might be worth documenting for future generations of maintainers...
| WHERE | ||
| thread_a.processlist_state IS NOT NULL AND | ||
| thread_a.processlist_command != 'Sleep' AND | ||
| thread_a.processlist_command != 'Daemon' AND |
There was a problem hiding this comment.
filtering out idle threads. If the thread is sleeping or state is NULL then it is idle.
The filter on Daemon is questionable. We want to show background, i.e. non-user / non-application waits and activity, but in my testing Daemon entries looked idle. Would be worth investigating more.
There was a problem hiding this comment.
here is output with "daemon"
+-----------+--------+------------------------+----------+
| thread_id | cmd | PROCESSLIST_STATE | EVENT_ID |
+-----------+--------+------------------------+----------+
| 42 | Daemon | Waiting on empty queue | NULL |
| 46 | Daemon | Suspending | NULL |
Guess we could try filtering on COMMMAND and PROCESSLIST_STATE but I don't have a list of PROCESSLIST_STATE values go filter. We could collect them and fitler on the backend.
There was a problem hiding this comment.
We could collect them and fitler on the backend.
+1, we should submit everything we think we might need because we can always adjust things later in our back-end.
There was a problem hiding this comment.
I would bias towards collecting fewer rows until we need them. But in this case it doesn't seem that we're confident daemon threads are truly idle.
Daemon
This thread is internal to the server, not a thread that services a client connection.
https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html
COMMAND
The type of command the thread is executing on behalf of the client, or Sleep if the session is idle.
https://dev.mysql.com/doc/refman/8.0/en/performance-schema-processlist-table.html
It's hard to say but the language seems to suggest Daemon is non-idle.
What does this PR do?
Adds a new feature which collects query activity and includes information like wait events, when the event started, who/what/where was the query executed, etc.
Query author: @kyle-hailey
Motivation
Additional Notes
Agent health
Core metrics
Database health
Review checklist (to be filled by reviewers)
changelog/andintegration/labels attached