Hi,
The INNODB_METRICS are partly duplicating global status variables. I
would actually like to remove them eventually; see
https://jira.mariadb.org/browse/MDEV-15706. This interface was
designed in MySQL before performance_schema was developed. I do not
know if the author considered using status variables.
The regressions that you found were not intentional; we should avoid
changing interfaces within GA releases such as 10.6. The only
intentional change was to remove some "double bookkeeping" and let
some INNODB_METRICS counters reflect counters that are already being
maintained for other reasons, instead of duplicating them.
Some indirection for the counter Innodb_buffer_pool_read_requests was
removed in MDEV-26827: the duplicate global variable
export_vars.innodb_buffer_pool_read_requests was removed and the
status variable should reflect buf_pool.stat.n_page_gets directly.
When diagnosing https://jira.mariadb.org/browse/MDEV-29967 I did see
that counter being incremented. The statement that I used was:
show global status like 'innodb_buffer_pool_read%';
Can you please file a bug with exact steps on how to reproduce this?
Marko
On Fri, May 12, 2023 at 10:12 AM
Figured out trx_rseg_history_len; it's just disabled by default now. But still stumped on Innodb_buffer_pool_read_requests.
On 5/12/2023 2:40 AM, mariadb@biblestuph.com wrote:
I've also noticed that my transaction history length is always zero; that's true on all my 10.6.13 instances (not just Bullseye). Is that information no longer stored here?
SELECT `count` FROM information_schema.INNODB_METRICS WHERE name = 'trx_rseg_history_len';
On 5/11/2023 11:55 PM, mariadb@biblestuph.com wrote:
Just upgraded from 10.6.12 to 10.6.13 on a Debian Bullseye system, and seeing this oddity. Innodb_buffer_pool_read_requests is zero, and seems to remain at zero no matter what I do (I even tried selecting all the data from a small table several times in a row with no change). It's been running a couple hours now; I've restarted it a couple times. I have 10.6.13 on a few other platforms as well (including Buster), and I'm not seeing the same issue on them. What would cause this? I have no other Bullseye systems running 10.6.13 yet, and the same system has been running 10.6.12 for over a week now without showing this issue.
The system _seems_ to be running fine, it's a replica system that is being fed actively from the master (data comes in to it very regularly).
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_%'; +-----------------------------------------+--------------------------------------------------+ | Variable_name | Value | +-----------------------------------------+--------------------------------------------------+ | Innodb_buffer_pool_dump_status | | | Innodb_buffer_pool_load_status | Buffer pool(s) load completed at 230511 23:21:26 | | Innodb_buffer_pool_resize_status | | | Innodb_buffer_pool_load_incomplete | OFF | | Innodb_buffer_pool_pages_data | 609103 | | Innodb_buffer_pool_bytes_data | 9979543552 | | Innodb_buffer_pool_pages_dirty | 19465 | | Innodb_buffer_pool_bytes_dirty | 318914560 | | Innodb_buffer_pool_pages_flushed | 0 | | Innodb_buffer_pool_pages_free | 299441 | | Innodb_buffer_pool_pages_made_not_young | 0 | | Innodb_buffer_pool_pages_made_young | 107 | | Innodb_buffer_pool_pages_misc | 0 | | Innodb_buffer_pool_pages_old | 224824 | | Innodb_buffer_pool_pages_total | 908544 | | Innodb_buffer_pool_pages_lru_flushed | 0 | | Innodb_buffer_pool_pages_lru_freed | 0 | | Innodb_buffer_pool_pages_split | 726 | | Innodb_buffer_pool_read_ahead_rnd | 0 | | Innodb_buffer_pool_read_ahead | 3 | | Innodb_buffer_pool_read_ahead_evicted | 0 | | Innodb_buffer_pool_read_requests | 0 | | Innodb_buffer_pool_reads | 604346 | | Innodb_buffer_pool_wait_free | 0 | | Innodb_buffer_pool_write_requests | 3639341 | +-----------------------------------------+--------------------------------------------------+ 25 rows in set (0.000 sec)
MariaDB [(none)]> SHOW VARIABLES LIKE 'innodb_buffer_pool%'; +-------------------------------------+----------------+ | Variable_name | Value | +-------------------------------------+----------------+ | innodb_buffer_pool_chunk_size | 134217728 | | innodb_buffer_pool_dump_at_shutdown | ON | | innodb_buffer_pool_dump_now | OFF | | innodb_buffer_pool_dump_pct | 80 | | innodb_buffer_pool_filename | ib_buffer_pool | | innodb_buffer_pool_load_abort | OFF | | innodb_buffer_pool_load_at_startup | ON | | innodb_buffer_pool_load_now | OFF | | innodb_buffer_pool_size | 15032385536 | +-------------------------------------+----------------+ 9 rows in set (0.000 sec)
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
-- Marko Mäkelä, Lead Developer InnoDB MariaDB plc