MySQL Bugs: #12701: Support >4GB buffer pool and log files on 64-bit Windows

Bug #12701	Support >4GB buffer pool and log files on 64-bit Windows
Submitted:	21 Aug 2005 10:58	Modified:	9 Dec 2005 18:57
Reporter:	Domas Mituzas	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S2 (Serious)
Version:	5.0, 4.0	OS:	Linux (Linux)
Assigned to:	Elliot Murphy	CPU Architecture:	Any

Description:
SHOW VARIABLES does not show correct size of buffer pool (that tricked monitoring scripts a bit:)

It is reported everywhere as LONG (and I guess it is implemented as multiple 4G pools), therefore, can't show proper values.

How to repeat:
[1055][midom@samuel:~]$ grep innodb_buffer_pool_size /etc/my.cnf
set-variable    = innodb_buffer_pool_size=12000M
[1055][midom@samuel:~]$ ps auxw | grep mysqld
root     12074  0.0  0.0 44068  416 ?        S    Aug02   0:00 /bin/sh /usr/local/mysql/bin/mysqld_safe
mysql    12094 38.8 85.5 14155520 13993476 ? Sl   Aug02 10614:43 /usr/local/mysql/libexec/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/var --user=mysql --pid-file=/usr/local/mysql/var/samuel.pid --skip-locking --port=3306 --socket=/tmp/mysql.sock
midom    29042  0.0  0.0 42392  676 pts/1    S+   10:55   0:00 grep mysqld
[1055][midom@samuel:~]$ mysql -e 'show variables like "%buffer_pool%"'
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 3992977408 |
+-------------------------+------------+
[1056][midom@samuel:~]$ 

Suggested fix:
display a sum of all allocated buffer pools?

Hi!

InnoDB's buffer pool is not divided into 4 GB pools. It is just one single pool. We know that one is able to allocate > 4 GB in a 64-bit computer. I recall also someone else reporting that SHOW VARIABLES shows the size wrong.

Are you sure that you are using a 64-bit client binary and a 64-bit mysqld binary?

---

As another note, in 64-bit Windows, long int is actually 32-bit! We should probably change most innobase_... variables in ha_innodb.cc to longlong, and use GET_ULL in mysqld.cc, and SHOW_LONGLONG in set_var.cc.

Regards,

Heikki

Let us fix this just in 5.0. We can use GET_LL and SHOW_LONGLONG.

Regards,

Heikki

I can't reproduce this on a 64-bit Linux (SUSE LINUX Enterprise Server 9 (x86_64)):

osalerma@melody:~> grep innodb_buffer_pool_size ~/.my.cnf
innodb_buffer_pool_size=8000M
osalerma@melody:~> ps auxw | grep mysqld | grep osalerma
osalerma 10727  0.0 15.8 8946356 723632 pts/6 S+  15:44   0:08 build-mysql-5.0/libexec/mysqld
osalerma 10739  0.0  0.0  3676  740 pts/4    R+   15:45   0:00 grep mysqld
osalerma@melody:~> build-mysql-5.0/bin/mysql -e 'show variables like "%buffer_pool_size%"'
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 8388608000 |
+-------------------------+------------+
osalerma@melody:~>

Which is expected, since the code uses a "long" variable internally which is 64 bits on Linux. Maybe the client program was compiled as a 32-bit program?

To get 64-bit Windows working, innodb_buffer_pool_size and innodb_log_file_size need to be changed to "long long". I'm working on that.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/29087

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/30263

Note: this is not committed because bug #12925 is blocking this.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/32358

Osku,

Jim Winstead fixed the other bug in October. Please check the status of this bug.

Regards,

Heikki

Heikki,

The patch has been committed for a while now in both Innobase's and MySQL's trees. The bug is assigned to Elliot so that he remembers to document it in some changelog or tell the doc team to do it.

The fix is not yet in 5.0.16. It is probably in 5.0.17. Elliot has to check that.

Noted in 5.0.16 changelog.