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

Opening all .ibd files on InnoDB startup can be slow

Details

    Description

      2023-08-14 9:13:29 0 [Note] InnoDB: Uses event mutexes
      2023-08-14 9:13:29 0 [Note] InnoDB: Compressed tables use zlib 1.2.12
      2023-08-14 9:13:29 0 [Note] InnoDB: Number of pools: 1
      2023-08-14 9:13:29 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
      2023-08-14 9:13:29 0 [Note] InnoDB: Initializing buffer pool, total size = 5368709120, chunk size = 134217728
      2023-08-14 9:13:29 0 [Note] InnoDB: Completed initialization of buffer pool
      2023-08-14 9:13:31 0 [Note] InnoDB: 128 rollback segments are active.
      2023-08-14 9:17:50 0 [Note] InnoDB: Creating shared tablespace for temporary tables
      2023-08-14 9:17:50 0 [Note] InnoDB: Setting file '.\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
      2023-08-14 9:17:50 0 [Note] InnoDB: File '.\ibtmp1' size is now 12 MB.
      2023-08-14 9:17:50 0 [Note] InnoDB: 10.5.22 started; log sequence number 197013855628; transaction id 455278971

      2023-08-14 9:13:31 0 [Note] InnoDB: 128 rollback segments are active.
      2023-08-14 9:17:50 0 [Note] InnoDB: Creating shared tablespace for temporary tables.

      MySQL starts slowly, rollback segments and Creating shared tablespace with an interval of over 4 minutes.

      Attachments

        1. my.ini
          2 kB
        2. dump50.sql.gz
          1.13 MB
        3. Capture.PNG
          Capture.PNG
          317 kB
        4. 3.jpg
          3.jpg
          156 kB
        5. 2.jpg
          2.jpg
          489 kB
        6. 1.jpg
          1.jpg
          414 kB

        Issue Links

          Activity

            If I make dict_check_tablespaces_and_store_max_id() open all files when encryption_key_id_exists(FIL_DEFAULT_ENCRYPTION_KEY) (or !ibuf.empty), then all encryption tests except encryption.innodb-remove-encryption will pass. That still leaves some non-encryption test failures. The trickiest is the following:

            10.6 04477bd9364e7a753918c730b89e7012b1926e6a with patch

            CURRENT_TEST: sys_vars.innodb_buffer_pool_dump_abort_loads
            mysqltest: At line 143: Can't initialize replace from 'replace_result $fulldump Previously_dumped'
            

            This would be fixed by making buf_load() invoke another SYS_TABLES scan and open all data files for those missing tablespaces that are mentioned in the file identified by innodb_buffer_pool_filename.

            marko Marko Mäkelä added a comment - If I make dict_check_tablespaces_and_store_max_id() open all files when encryption_key_id_exists(FIL_DEFAULT_ENCRYPTION_KEY) (or !ibuf.empty ), then all encryption tests except encryption.innodb-remove-encryption will pass. That still leaves some non-encryption test failures. The trickiest is the following: 10.6 04477bd9364e7a753918c730b89e7012b1926e6a with patch CURRENT_TEST: sys_vars.innodb_buffer_pool_dump_abort_loads mysqltest: At line 143: Can't initialize replace from 'replace_result $fulldump Previously_dumped' This would be fixed by making buf_load() invoke another SYS_TABLES scan and open all data files for those missing tablespaces that are mentioned in the file identified by innodb_buffer_pool_filename .

            Before I implemented the tweak to buf_load(), I had tweaked the following tests:

            encryption.innodb-remove-encryption
            innodb.row_format_redundant
            innodb.table_flags
            innodb_zip.restart
            

            It turns out that my changes to these tests can be omitted, because the ib_buffer_pool file would ensure that the tablespaces of interest be loaded.

            If the ib_buffer_pool file were removed, these tests would fail. To make these failures deterministic, I would have created all tables with STATS_PERSISTENT=0 and run a slow shutdown (innodb_fast_shutdown=0) so that no background tasks would cause the tables to be loaded and data files to be opened.

            marko Marko Mäkelä added a comment - Before I implemented the tweak to buf_load() , I had tweaked the following tests: encryption.innodb-remove-encryption innodb.row_format_redundant innodb.table_flags innodb_zip.restart It turns out that my changes to these tests can be omitted, because the ib_buffer_pool file would ensure that the tablespaces of interest be loaded. If the ib_buffer_pool file were removed, these tests would fail. To make these failures deterministic, I would have created all tables with STATS_PERSISTENT=0 and run a slow shutdown ( innodb_fast_shutdown=0 ) so that no background tasks would cause the tables to be loaded and data files to be opened.

            I can imagine that opening the files can be slow also in other environments than Microsoft Windows, such as when the data directory resides on network attached storage or NFS.

            marko Marko Mäkelä added a comment - I can imagine that opening the files can be slow also in other environments than Microsoft Windows, such as when the data directory resides on network attached storage or NFS.

            origin/10.6-MDEV-32027 bddd1da9e939835dbbf61ea3c90638789db86733 2023-11-13T16:27:37+02:00
            behaved well in RQG testing.

            mleich Matthias Leich added a comment - origin/10.6- MDEV-32027 bddd1da9e939835dbbf61ea3c90638789db86733 2023-11-13T16:27:37+02:00 behaved well in RQG testing.
            wlad Vladislav Vaintroub added a comment - - edited

            Even on Windows it is not slow. I could not get it as slow, as the original reporter, but 85 000 files add 6-15 seconds startup (Windows seems to caches some metadata, and it is faster second time around). However, delay scales linearly with number of files, so startup with 850000 files can take 2.5 minutes on my machine. The reporter has something that is factors of magnitude slower, and for him it is really much too much. We do not know what kind of storage reporter had, but it would be interesting to know . kennyliao, can you comment on that?

            wlad Vladislav Vaintroub added a comment - - edited Even on Windows it is not slow. I could not get it as slow, as the original reporter, but 85 000 files add 6-15 seconds startup (Windows seems to caches some metadata, and it is faster second time around). However, delay scales linearly with number of files, so startup with 850000 files can take 2.5 minutes on my machine. The reporter has something that is factors of magnitude slower, and for him it is really much too much. We do not know what kind of storage reporter had, but it would be interesting to know . kennyliao , can you comment on that?

            People

              marko Marko Mäkelä
              kennyliao kennyliao
              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.