Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Not a Bug
    • 10.6.14
    • N/A
    • None
    • RHEL 8

    Description

      I have a server where the history length keeps growing. At first we had them in shared system space but we moved them with using innodb_undo_tablespaces. This did not helped us either.

      Right now the length is 124355327 and the server is not making transactions right now (for 1 hour) just to see if the purge starts. It's pretty idle.

      Ihave the following parameters, most of them are extreme just to trigger some purge actions.

      {{MariaDB [(none)]> show global variables like "innodb%purge%";

      innodb_max_purge_lag 50000
      innodb_max_purge_lag_delay 0
      innodb_max_purge_lag_wait 4294967295
      innodb_purge_batch_size 300
      innodb_purge_rseg_truncate_frequency 1
      innodb_purge_threads 32
      innodb_undo_log_truncate 1

      innodb status:

      Purge done for trx's n:o < 258032014 undo n:o < 5633661 state: running
      History list length 124560317
      

      Looks a little bit like #MDEV-29401 but that one should be fixed by the version we are already using.

      Attachments

        Issue Links

          Activity

            rodehoed Gerwin added a comment -

            Sorry this isn't a bug. I made a miscalculation in de undo logsizes where I triggered lazy purging.

            rodehoed Gerwin added a comment - Sorry this isn't a bug. I made a miscalculation in de undo logsizes where I triggered lazy purging.

            This could still be a genuine problem, or at least I believe that this is related to the open ticket MDEV-30628.

            What was done in MDEV-29601 was that the existing throttling mechanism was improved slightly.

            Based on the configuration parameters that you posted, the throttling should not be activated at all, because innodb_max_purge_lag_delay=0.

            MDEV-31382 is one more bug in this area: Even if the history list length reached 0, the undo tablespaces might not be truncated despite innodb_undo_log_truncate=ON.

            marko Marko Mäkelä added a comment - This could still be a genuine problem, or at least I believe that this is related to the open ticket MDEV-30628 . What was done in MDEV-29601 was that the existing throttling mechanism was improved slightly. Based on the configuration parameters that you posted, the throttling should not be activated at all, because innodb_max_purge_lag_delay=0 . MDEV-31382 is one more bug in this area: Even if the history list length reached 0, the undo tablespaces might not be truncated despite innodb_undo_log_truncate=ON .

            MDEV-32050 in MariaDB Server 10.6.16 removed several performance bottlenecks from the purge subsystem.

            marko Marko Mäkelä added a comment - MDEV-32050 in MariaDB Server 10.6.16 removed several performance bottlenecks from the purge subsystem.

            MDEV-33213 was a further fix in this area. While MDEV-32050 made the purge faster, MDEV-33213 fixes a starvation problem and ensures that newly started transactions will not prevent already processed undo logs for older transactions from being freed.

            marko Marko Mäkelä added a comment - MDEV-33213 was a further fix in this area. While MDEV-32050 made the purge faster, MDEV-33213 fixes a starvation problem and ensures that newly started transactions will not prevent already processed undo logs for older transactions from being freed.

            People

              Unassigned Unassigned
              rodehoed Gerwin
              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.