Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-26043

Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.

Details

    Description

      Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.

      How to reproduce:
      1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
      2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
      3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
      4. Verity the bug:

      • All counters are zero in the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
      • The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';

      Root cause:
      The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).

      How to fix:
      Put PSI_register before thread_group_init. I've created a patch in this pull request.

      Attachments

        Activity

          Zheng Zheng created issue -
          Zheng Zheng made changes -
          Field Original Value New Value
          Description Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.


          How to reproduce:
          1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
          2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
          3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
          4. Verity the bug:
          * All counters are zero as the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
          * The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';


          Root cause:
          The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).


          How to fix:
          Put PSI_register before thread_group_init.
          Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.


          How to reproduce:
          1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
          2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
          3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
          4. Verity the bug:
          * All counters are zero as the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
          * The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(\*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';


          Root cause:
          The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).


          How to fix:
          Put PSI_register before thread_group_init.
          Zheng Zheng made changes -
          Description Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.


          How to reproduce:
          1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
          2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
          3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
          4. Verity the bug:
          * All counters are zero as the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
          * The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(\*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';


          Root cause:
          The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).


          How to fix:
          Put PSI_register before thread_group_init.
          Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.


          How to reproduce:
          1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
          2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
          3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
          4. Verity the bug:
          * All counters are zero as the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
          * The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(\*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';


          Root cause:
          The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).


          How to fix:
          Put PSI_register before thread_group_init. I've created a [PR|https://github.com/MariaDB/server/pull/1867]
          Zheng Zheng made changes -
          Description Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.


          How to reproduce:
          1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
          2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
          3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
          4. Verity the bug:
          * All counters are zero as the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
          * The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(\*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';


          Root cause:
          The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).


          How to fix:
          Put PSI_register before thread_group_init. I've created a [PR|https://github.com/MariaDB/server/pull/1867]
          Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.


          How to reproduce:
          1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
          2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
          3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
          4. Verity the bug:
          * All counters are zero as the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
          * The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(\*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';


          Root cause:
          The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).


          How to fix:
          Put PSI_register before thread_group_init. I've created a [patch in this pull request|https://github.com/MariaDB/server/pull/1867]
          Zheng Zheng made changes -
          Description Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.


          How to reproduce:
          1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
          2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
          3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
          4. Verity the bug:
          * All counters are zero as the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
          * The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(\*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';


          Root cause:
          The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).


          How to fix:
          Put PSI_register before thread_group_init. I've created a [patch in this pull request|https://github.com/MariaDB/server/pull/1867]
          Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.


          How to reproduce:
          1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
          2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
          3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
          4. Verity the bug:
          * All counters are zero as the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
          * The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(\*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';


          Root cause:
          The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).


          How to fix:
          Put PSI_register before thread_group_init. I've created a [patch in this pull request|https://github.com/MariaDB/server/pull/1867].
          Zheng Zheng made changes -
          Description Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.


          How to reproduce:
          1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
          2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
          3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
          4. Verity the bug:
          * All counters are zero as the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
          * The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(\*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';


          Root cause:
          The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).


          How to fix:
          Put PSI_register before thread_group_init. I've created a [patch in this pull request|https://github.com/MariaDB/server/pull/1867].
          Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.


          How to reproduce:
          1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
          2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
          3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
          4. Verity the bug:
          * All counters are zero in the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
          * The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(\*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';


          Root cause:
          The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).


          How to fix:
          Put PSI_register before thread_group_init. I've created a [patch in this pull request|https://github.com/MariaDB/server/pull/1867].
          serg Sergei Golubchik made changes -
          Assignee Vladislav Vaintroub [ wlad ]
          serg Sergei Golubchik made changes -
          Fix Version/s 10.5 [ 23123 ]
          Fix Version/s 10.6 [ 24028 ]
          serg Sergei Golubchik made changes -
          Priority Minor [ 4 ] Major [ 3 ]
          wlad Vladislav Vaintroub made changes -
          Status Open [ 1 ] Confirmed [ 10101 ]
          wlad Vladislav Vaintroub made changes -
          Fix Version/s 10.5.12 [ 26025 ]
          Fix Version/s 10.6.4 [ 26033 ]
          Fix Version/s 10.5 [ 23123 ]
          Fix Version/s 10.6 [ 24028 ]
          Resolution Fixed [ 1 ]
          Status Confirmed [ 10101 ] Closed [ 6 ]
          serg Sergei Golubchik made changes -
          Workflow MariaDB v3 [ 123102 ] MariaDB v4 [ 159459 ]

          People

            wlad Vladislav Vaintroub
            Zheng Zheng
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.