-
Marc Alff authored
Bug#17504345 - PERFORMANCE OVERHEAD, THREAD AGGREGATE ON DISCONNECT Before this fix, 1) On thread connect, the performance schema needs to evaluate if the thread is instrumented or not. The logic used did look up the content of performance_schema.setup_actors for the connecting account, every time. 2) On thread disconnect, the performance schema needs to aggregate statistics for parent users / account / hosts or globally, based on statistics collected by the disconnecting thread. The logic did perform this aggregation all the time, even when nothing was collected during the thread life time, for example when the performance schema is disabled. With this fix, 1) A new attribute PFS_account::m_enabled is created, that saves the result of the setup_actors look up. Whenever the content of the setup_actors table is changed, the code re evaluates PFS_acount::m_enabled for every account, to reflect new rules in setup_actors. When a thread connects, the corresponding PFS_account::m_enabled flag is used to decide if the thread is to be instrumented, if found. This avoids looking up setup_actors on every connection, the look up only happen the first time a given account connects. This flag is internal, there are no visible end user changes. 2) A new attribute PFS_thread::m_aggregate_on_disconnect is created, that indicates if aggregation during disconnect is needed. When the performance schema is disabled, this flag is always false. When the performance schema is enabled, and in particular: - when the 'global_instrumentation' consumer is enabled - when the 'thread_instrumentation' consumer is enabled - when the 'instrumented' column in table thread is enabled this flag PFS_thread::m_aggregate_on_disconnect is re evaluated, for every running thread if necessary. The m_aggregate_on_disconnect flag is only set when a thread can collect per thread statistics. During disconnect, aggregation is done only when the flag is set. The net effect of this change is that aggregation on disconnect only happens when necessary, saving CPU when no per thread stats are ever collected. This flag is internal, there are no visible end user changes.
Marc Alff authoredBug#17504345 - PERFORMANCE OVERHEAD, THREAD AGGREGATE ON DISCONNECT Before this fix, 1) On thread connect, the performance schema needs to evaluate if the thread is instrumented or not. The logic used did look up the content of performance_schema.setup_actors for the connecting account, every time. 2) On thread disconnect, the performance schema needs to aggregate statistics for parent users / account / hosts or globally, based on statistics collected by the disconnecting thread. The logic did perform this aggregation all the time, even when nothing was collected during the thread life time, for example when the performance schema is disabled. With this fix, 1) A new attribute PFS_account::m_enabled is created, that saves the result of the setup_actors look up. Whenever the content of the setup_actors table is changed, the code re evaluates PFS_acount::m_enabled for every account, to reflect new rules in setup_actors. When a thread connects, the corresponding PFS_account::m_enabled flag is used to decide if the thread is to be instrumented, if found. This avoids looking up setup_actors on every connection, the look up only happen the first time a given account connects. This flag is internal, there are no visible end user changes. 2) A new attribute PFS_thread::m_aggregate_on_disconnect is created, that indicates if aggregation during disconnect is needed. When the performance schema is disabled, this flag is always false. When the performance schema is enabled, and in particular: - when the 'global_instrumentation' consumer is enabled - when the 'thread_instrumentation' consumer is enabled - when the 'instrumented' column in table thread is enabled this flag PFS_thread::m_aggregate_on_disconnect is re evaluated, for every running thread if necessary. The m_aggregate_on_disconnect flag is only set when a thread can collect per thread statistics. During disconnect, aggregation is done only when the flag is set. The net effect of this change is that aggregation on disconnect only happens when necessary, saving CPU when no per thread stats are ever collected. This flag is internal, there are no visible end user changes.
Loading