To tylko jedna z 2 stron tej notatki. Zaloguj się aby zobaczyć ten dokument.
Zobacz
całą notatkę
Compression and the InnoDB Buffer Pool
In a compressed InnoDB table, every compressed page (whether 1K, 2K, 4K or 8K) corresponds to an
uncompressed page of 16K bytes (or a smaller size if innodb_page_size [1776] is set). To access
the data in a page, MySQL reads the compressed page from disk if it is not already in the buffer pool,
then uncompresses the page to its original form. This section describes how InnoDB manages the
buffer pool with respect to pages of compressed tables.
To minimize I/O and to reduce the need to uncompress a page, at times the buffer pool contains
both the compressed and uncompressed form of a database page. To make room for other required
database pages, MySQL can evict from the buffer pool an uncompressed page, while leaving the
compressed page in memory. Or, if a page has not been accessed in a while, the compressed form of
the page might be written to disk, to free space for other data. Thus, at any given time, the buffer pool
might contain both the compressed and uncompressed forms of the page, or only the compressed form
of the page, or neither.
MySQL keeps track of which pages to keep in memory and which to evict using a least-recentlyused
(LRU) list, so that hot (frequently accessed) data tends to stay in memory. When compressed
tables are accessed, MySQL uses an adaptive LRU algorithm to achieve an appropriate balance of
compressed and uncompressed pages in memory. This adaptive algorithm is sensitive to whether the
system is running in an I/O-bound or CPU-bound manner. The goal is to avoid spending too much
processing time uncompressing pages when the CPU is busy, and to avoid doing excess I/O when the
CPU has spare cycles that can be used for uncompressing compressed pages (that may already be
in memory). When the system is I/O-bound, the algorithm prefers to evict the uncompressed copy of
a page rather than both copies, to make more room for other disk pages to become memory resident.
When the system is CPU-bound, MySQL prefers to evict both the compressed and uncompressed
page, so that more memory can be used for “hot” pages and reducing the need to uncompress data in
memory only in compressed form.
... zobacz całą notatkę
Komentarze użytkowników (0)