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

MariaDB 10.5 does not do idle checkpoint (regression). Marked as fixed on 10.5.13 but it is not

Details

    Description

      Hi!

      I upgraded to 10.5.13 to fix MDEV-26860 but it is still not fixed.

      To reproduce, start a server with the defaults and check "show engine innodb status;" i.e get the following outputs:

      Log sequence number 1851090
      Log flushed up to 1851090
      Pages flushed up to 1851090
      Last checkpoint at 1851078

      Then do some inserts on any table and check SEIS again:

      Log sequence number 1852662
      Log flushed up to 1852662
      Pages flushed up to 1851090
      Last checkpoint at 1851078

      it can be seen that checkpoint is yet not moving forward. If monitoring with PMM, the graphs looks like a "saw tool" like on the bug report from MDEV-26860

      Attachments

        Issue Links

          Activity

            @Carlos,

            Idle flushing is enabled only if early flushing behavior is enabled (innodb_max_dirty_pages_pct_lwm != 0).
            [Default innodb_max_dirty_pages_pct_lwm == 0 so the issue].

            Documentation could be updated to make a note of this.

            krunalbauskar Krunal Bauskar added a comment - @Carlos, Idle flushing is enabled only if early flushing behavior is enabled (innodb_max_dirty_pages_pct_lwm != 0). [Default innodb_max_dirty_pages_pct_lwm == 0 so the issue] . Documentation could be updated to make a note of this.

            ctutte, did you test krunalbauskar’s suggestion?

            Note: In the MariaDB Server 10.5.7 and 10.5.8 releases, the parameter value innodb_max_dirty_pages_pct_lwm=0 (which is the default) meant that the page cleaner thread would always run in the background, as long as dirty pages exist in the buffer pool.

            In MDEV-24537, the original meaning of the default value was restored: it means that there will be no separate background flushing, and nothing will be written out as long as:

            • the share of dirty pages will not exceed innodb_max_dirty_pages_pct
            • the last checkpoint age (LSN difference since the latest checkpoint) does not exceed innodb_log_file_size (minus some safety margin)
            • we are not running out of space in the buffer pool, which could trigger eviction flushing

            If you want background flushing to be as eager as it was in 10.5.7 and 10.5.8, I believe that the following should come close:

            SET GLOBAL innodb_max_dirty_pages_pct_lwm=0.001;
            

            marko Marko Mäkelä added a comment - ctutte , did you test krunalbauskar ’s suggestion? Note: In the MariaDB Server 10.5.7 and 10.5.8 releases, the parameter value innodb_max_dirty_pages_pct_lwm=0 (which is the default) meant that the page cleaner thread would always run in the background, as long as dirty pages exist in the buffer pool. In MDEV-24537 , the original meaning of the default value was restored: it means that there will be no separate background flushing, and nothing will be written out as long as: the share of dirty pages will not exceed innodb_max_dirty_pages_pct the last checkpoint age (LSN difference since the latest checkpoint) does not exceed innodb_log_file_size (minus some safety margin) we are not running out of space in the buffer pool, which could trigger eviction flushing If you want background flushing to be as eager as it was in 10.5.7 and 10.5.8, I believe that the following should come close: SET GLOBAL innodb_max_dirty_pages_pct_lwm=0.001;
            greenman Ian Gilfillan added a comment - Documentation updated at https://mariadb.com/kb/en/innodb-page-flushing/

            People

              greenman Ian Gilfillan
              ctutte carlos tutte
              Votes:
              0 Vote for this issue
              Watchers:
              7 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.