Example 6.1. Using the Compression Information Schema Tables
The following is sample output from a database that contains
compressed tables (see Chapter 3, InnoDB Data Compression,
INNODB_CMP
, and INNODB_CMPMEM
).
The following table shows the contents of
INFORMATION_SCHEMA.INNODB_CMP
under light
load. The only compressed page size that the buffer pool
contains is 8K. Compressing or uncompressing pages has
consumed less than a second since the time the statistics were
reset, because the columns COMPRESS_TIME
and UNCOMPRESS_TIME
are zero.
page size | compress ops | compress ops ok | compress time | uncompress ops | uncompress time |
---|---|---|---|---|---|
1024 | 0 | 0 | 0 | 0 | 0 |
2048 | 0 | 0 | 0 | 0 | 0 |
4096 | 0 | 0 | 0 | 0 | 0 |
8192 | 1048 | 921 | 0 | 61 | 0 |
16384 | 0 | 0 | 0 | 0 | 0 |
According to INNODB_CMPMEM
, there are 6169 compressed 8KB
pages in the buffer pool. The only other allocated block size
is 64 bytes. The smallest PAGE_SIZE
in
INNODB_CMPMEM
is used for block descriptors of those
compressed pages for which no uncompressed page exists in the
buffer pool. We see that there are 5910 such pages.
Indirectly, we see that 259 (6169-5910) compressed pages also
exist in the buffer pool in uncompressed form.
The following table shows the contents of
INFORMATION_SCHEMA.INNODB_CMPMEM
under
light load. We can see that some memory is unusable due to
fragmentation of the InnoDB memory allocator for compressed
pages: SUM(PAGE_SIZE*PAGES_FREE)=6784
. This
is because small memory allocation requests are fulfilled by
splitting bigger blocks, starting from the 16K blocks that are
allocated from the main buffer pool, using the buddy
allocation system. The fragmentation is this low, because some
allocated blocks have been relocated (copied) to form bigger
adjacent free blocks. This copying of
SUM(PAGE_SIZE*RELOCATION_OPS)
bytes has
consumed less than a second
(SUM(RELOCATION_TIME)=0)
.
This is the User’s Guide for InnoDB storage engine 1.1 for MySQL 5.5, generated on 2010-04-13 (revision: 19994) .