The diskpagebuffer
table provides statistics
about disk page buffer usage by NDB Cluster Disk Data tables.
The diskpagebuffer
table contains the
following columns:
node_id
The data node ID
block_instance
Block instance
pages_written
Number of pages written to disk.
pages_written_lcp
Number of pages written by local checkpoints.
pages_read
Number of pages read from disk
log_waits
Number of page writes waiting for log to be written to disk
page_requests_direct_return
Number of requests for pages that were available in buffer
page_requests_wait_queue
Number of requests that had to wait for pages to become available in buffer
page_requests_wait_io
Number of requests that had to be read from pages on disk (pages were unavailable in buffer)
Notes
You can use this table with NDB Cluster Disk Data tables to
determine whether
DiskPageBufferMemory
is
sufficiently large to allow data to be read from the buffer
rather from disk; minimizing disk seeks can help improve
performance of such tables.
You can determine the proportion of reads from
DiskPageBufferMemory
to
the total number of reads using a query such as this one, which
obtains this ratio as a percentage:
SELECT
node_id,
100 * page_requests_direct_return /
(page_requests_direct_return + page_requests_wait_io)
AS hit_ratio
FROM ndbinfo.diskpagebuffer;
The result from this query should be similar to what is shown here, with one row for each data node in the cluster (in this example, the cluster has 4 data nodes):
+---------+-----------+
| node_id | hit_ratio |
+---------+-----------+
| 5 | 97.6744 |
| 6 | 97.6879 |
| 7 | 98.1776 |
| 8 | 98.1343 |
+---------+-----------+
4 rows in set (0.00 sec)
hit_ratio
values approaching 100% indicate
that only a very small number of reads are being made from disk
rather than from the buffer, which means that Disk Data read
performance is approaching an optimum level. If any of these
values are less than 95%, this is a strong indicator that the
setting for
DiskPageBufferMemory
needs to be increased in the config.ini
file.
A change in
DiskPageBufferMemory
requires a rolling restart of all of the cluster's data
nodes before it takes effect.
block_instance
refers to an instance of a
kernel block. Together with the block name, this number can be
used to look up a given instance in the
threadblocks
table. Using this
information, you can obtain information about disk page buffer
metrics relating to individual threads; an example query using
LIMIT 1
to limit the output to a single
thread is shown here:
mysql> SELECT
> node_id, thr_no, block_name, thread_name, pages_written,
> pages_written_lcp, pages_read, log_waits,
> page_requests_direct_return, page_requests_wait_queue,
> page_requests_wait_io
> FROM ndbinfo.diskpagebuffer
> INNER JOIN ndbinfo.threadblocks USING (node_id, block_instance)
> INNER JOIN ndbinfo.threads USING (node_id, thr_no)
> WHERE block_name = 'PGMAN' LIMIT 1\G
*************************** 1. row ***************************
node_id: 1
thr_no: 1
block_name: PGMAN
thread_name: rep
pages_written: 0
pages_written_lcp: 0
pages_read: 1
log_waits: 0
page_requests_direct_return: 4
page_requests_wait_queue: 0
page_requests_wait_io: 1
1 row in set (0.01 sec)