[MDEV-9451] innodb_buffer_pool_populate does not seem to work on 10.1.10 Created: 2016-01-22  Updated: 2017-05-15  Resolved: 2016-12-02

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - XtraDB
Affects Version/s: 10.0.23, 10.1.10, 10.1.17
Fix Version/s: 10.1.20, 10.2.3

Type: Bug Priority: Major
Reporter: aleksandr stankevic Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: contribution, foundation, innodb, patch
Environment:

Debian Wheezy / Debian Jessie
MariaDB 10.1.10


 Description   

It seems that innodb_buffer_pool_populate stopped working in MariaDB 10.1.10, it does work properly in 10.1.9:

MariaDB 10.1.9:

# bin/mysqld --version
 
bin/mysqld  Ver 10.1.9-MariaDB for Linux on x86_64 (MariaDB Server)
 
# /etc/init.d/mysql-test1-1 restart; free -m; perl /tmp/numa-maps-summary.pl < /proc/$(pidof mysqld)/numa_maps
 
Stopping MySQL database server: mysqld.
 
Starting MySQL database server: mysqld.
 
             total       used       free     shared    buffers     cached
 
Mem:         24113      20301       3811          0          3         49
 
-/+ buffers/cache:      20248       3864
 
Swap:         3905          0       3905
 
N0        :      2558892 (  9.76 GB)
 
N1        :      2558471 (  9.76 GB)
 
active    :         1355 (  0.01 GB)
 
anon      :      5113825 ( 19.51 GB)
 
dirty     :      5113825 ( 19.51 GB)
 
mapmax    :          272 (  0.00 GB)
 
mapped    :         3586 (  0.01 GB)

MariaDB 10.1.10:

# bin/mysqld --version
 
bin/mysqld  Ver 10.1.10-MariaDB for Linux on x86_64 (MariaDB Server)
 
# /etc/init.d/mysql-test1-1 restart; free -m; perl /tmp/numa-maps-summary.pl < /proc/$(pidof mysqld)/numa_maps
 
Stopping MySQL database server: mysqld.
 
Starting MySQL database server: mysqld.
 
             total       used       free     shared    buffers     cached
 
Mem:         24113       1829      22284          0          3         49
 
-/+ buffers/cache:       1775      22337
 
Swap:         3905          0       3905
 
N0        :       199871 (  0.76 GB)
 
N1        :       199523 (  0.76 GB)
 
active    :         1296 (  0.00 GB)
 
anon      :       395819 (  1.51 GB)
 
dirty     :       395819 (  1.51 GB)
 
mapmax    :          272 (  0.00 GB)
 
mapped    :         3631 (  0.01 GB)

mysql.cnf:

[mysqld]
 
innodb_buffer_pool_size = 18G
 
innodb_buffer_pool_populate = 1



 Comments   
Comment by Daniel Black [ 2016-09-19 ] 

sql/mysqld --skip-networking --datadir=/tmp/datadir --log-bin=/tmp/datadir/mysqlbin --socket /tmp/s.sock --lc-messages-dir=`pwd`/sql/share --verbose  --innodb_buffer_pool_populate=1 --innodb_buffer_pool_size=5G
 
2016-09-19 16:16:32 140487729948864 [Note] sql/mysqld (mysqld 10.1.18-MariaDB) starting as process 25682 ...
 
2016-09-19 16:16:32 140487729948864 [Note] InnoDB: Using mutexes to ref count buffer pool pages
 
2016-09-19 16:16:32 140487729948864 [Note] InnoDB: The InnoDB memory heap is disabled
 
2016-09-19 16:16:32 140487729948864 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
 
2016-09-19 16:16:32 140487729948864 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
 
2016-09-19 16:16:32 140487729948864 [Note] InnoDB: Compressed tables use zlib 1.2.8
 
2016-09-19 16:16:32 140487729948864 [Note] InnoDB: Using Linux native AIO
 
2016-09-19 16:16:32 140487729948864 [Note] InnoDB: Using SSE crc32 instructions
 
2016-09-19 16:16:32 140487729948864 [Note] InnoDB: Initializing buffer pool, size = 5.0G
 
2016-09-19 16:16:32 140487729948864 [Note] InnoDB: Completed initialization of buffer pool
 
2016-09-19 16:16:32 140487729948864 [Note] InnoDB: Highest supported file format is Barracuda.
 
2016-09-19 16:16:33 140487729948864 [Note] InnoDB: 128 rollback segment(s) are active.
 
2016-09-19 16:16:33 140487729948864 [Note] InnoDB: Waiting for purge to start
 
2016-09-19 16:16:33 140487729948864 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.31-77.0 started; log sequence number 1616819
 
2016-09-19 16:16:33 140481266689792 [Note] InnoDB: Dumping buffer pool(s) not yet started
 
2016-09-19 16:16:33 140487729948864 [Note] Plugin 'FEEDBACK' is disabled.
 
2016-09-19 16:16:33 140487729948864 [Note] sql/mysqld: ready for connections.
 
Version: '10.1.18-MariaDB'  socket: '/tmp/s.sock'  port: 0  Source distribution


free -m; perl /tmp/numa-maps-summary.pl < /proc/25682/numa_maps
 
              total        used        free      shared  buff/cache   available
 
Mem:           7653        2882         333        2220        4436        2117
 
Swap:          7807         633        7174
 
 
 
N0        :       118195 (  0.45 GB)
 
active    :         2641 (  0.01 GB)
 
anon      :       114246 (  0.44 GB)
 
dirty     :       114246 (  0.44 GB)
 
kernelpagesize_kB:          576 (  0.00 GB)
 
mapmax    :         1648 (  0.01 GB)
 
mapped    :         4045 (  0.02 GB)

Comment by Marko Mäkelä [ 2016-11-28 ]

It seems that this was caused by the following:

commit 1e270d504d56cb015efe060b319e3a5b9bc6513f
 
Author: Sergei Golubchik <serg@mariadb.org>
 
Date:   Sun Dec 13 10:13:18 2015 +0100    5.6.27-76.0

The following hunk in ha_innodb.cc should be reverted:

@@ -17232,10 +17310,9 @@ static MYSQL_SYSVAR_LONGLONG(buffer_pool_size, innobase_buffer_pool_size,
 
  "The size of the memory buffer InnoDB uses to cache data and indexes of its tables.",
 
  NULL, NULL, 128*1024*1024L, 5*1024*1024L, LONGLONG_MAX, 1024*1024L);
 
 
 
-static MYSQL_SYSVAR_BOOL(buffer_pool_populate, srv_buf_pool_populate,
 
+static MYSQL_SYSVAR_BOOL(buffer_pool_populate, srv_numa_interleave,
 
  PLUGIN_VAR_NOCMDARG | PLUGIN_VAR_READONLY,
 
-  "Preallocate (pre-fault) the page frames required for the mapping "
 
-  "established by the buffer pool memory region. Disabled by default.",
 
+  "Depricated. This option is temporary alias of --innodb-numa-interleave.",
 
  NULL, NULL, FALSE);
 
 
 
static MYSQL_SYSVAR_ENUM(foreground_preflush, srv_foreground_preflush,

Note: the variable srv_numa_interleave is correctly bound in the hunk that immediately follows the above:

@@ -17675,6 +17752,13 @@ static MYSQL_SYSVAR_BOOL(use_native_aio, srv_use_native_aio,
 
   "Use native AIO if supported on this platform.",
 
   NULL, NULL, TRUE);
 
 
+#ifdef HAVE_LIBNUMA
 
+static MYSQL_SYSVAR_BOOL(numa_interleave, srv_numa_interleave,
 
+  PLUGIN_VAR_NOCMDARG | PLUGIN_VAR_READONLY,
 
+  "Use NUMA interleave memory policy to allocate InnoDB buffer pool.",
 
+  NULL, NULL, FALSE);
 
+#endif // HAVE_LIBNUMA
 
+
 
 static MYSQL_SYSVAR_BOOL(api_enable_binlog, ib_binlog_enabled,
 
   PLUGIN_VAR_NOCMDARG | PLUGIN_VAR_READONLY,
 
   "Enable binlog for applications direct access InnoDB through InnoDB APIs",

Comment by Daniel Black [ 2016-11-28 ]

Good find marko. Kinda obvious in hindsight. Pull request added.

Numa wasn't really enabled until 10.2 - MDEV-10829

Comment by Daniel Black [ 2016-11-28 ]

Reverting the hunk isn't sufficient. Percona have removed the srv_buf_pool_populate functionality entirely as the description says.

https://github.com/MariaDB/server/commit/1e270d504d56cb015efe060b319e3a5b9bc6513f#diff-515733e5f476075d9efe7615b2dbc668L1348

I updated https://mariadb.com/kb/en/mariadb/xtradbinnodb-server-system-variables/#innodb_buffer_pool_populate to reflect the version it got deprecated. As NUMA never got enabled in 10.1 this had no effect at all.

I suggest the best course of action is to remove the option in 10.2.

Comment by Daniel Black [ 2016-11-30 ]

referenced pull request 262 removes option innodb_buffer_pool_populate

Comment by Marko Mäkelä [ 2016-12-01 ]

I changed 10.1 so that it will display a clear warning message when the option is set.
I am going to merge the contributed patch to 10.2.3 to remove the parameter.

Comment by Marko Mäkelä [ 2016-12-01 ]

I merged the contribution to remove the parameter in 10.2.3. The deprecation message would be introduced in 10.1.20.

Comment by Daniel Black [ 2016-12-01 ]

Thanks marko. good idea including deprecation in 10.1.

Comment by Sergei Golubchik [ 2016-12-02 ]

Ok to push.
Thanks!

Comment by Marko Mäkelä [ 2017-03-06 ]

For the record:
The variable innodb_buffer_pool_populate was originally introduced in a merge of Percona 5.5.28-rel29.1 to XtraDB. When this XtraDB-only option is set, XtraDB would pass the flag MAP_POPULATE to the Linux mmap() call that is used for allocating memory to the buffer pool. As far as I understand, this would immediately allocate the physical memory pages, instead of relying on the normal copy-on-write mechanism to allocate the pages on the first modification of the virtual memory pages.

MySQL 5.6.27 included a contributed fix for MySQL Bug #72811. The merge of Percona 5.6.27-76.0 to MariaDB Server 10.0.23 removed the MAP_POPULATE flag altogether, and instead made innodb_buffer_pool_populate an alias to innodb_numa_interleave. If NUMA is not available, the innodb_buffer_pool_populate would have no effect. It could make sense to retain the MAP_POPULATE flag in that case.

My commit for MariaDB 10.1.20 removed the connection between innodb_buffer_pool_populate and innodb_numa_interleave. The bug still exists in the 10.0 series since 10.0.23.

Comment by Arnaud Adant [ 2017-05-15 ]

please document this. the deprecated variable replacement is not documented in the manual

https://mariadb.com/kb/en/mariadb/xtradbinnodb-server-system-variables/#innodb_buffer_pool_populate

thanks !

Generated at Thu Feb 08 07:34:46 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.