Author: paul
Date: 2009-11-04 19:11:36 +0100 (Wed, 04 Nov 2009)
New Revision: 17447
Log:
r46103@frost: paul | 2009-11-04 11:50:24 -0500
Add InnoDB Monitor info relating to buffer pool LRU algorithm
Modified:
trunk/refman-5.1/optimization.xml
trunk/refman-5.5/optimization.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:27523
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:25547
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:46102
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
+ 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:27523
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:25547
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:46103
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml 2009-11-04 18:11:30 UTC (rev 17446)
+++ trunk/refman-5.1/optimization.xml 2009-11-04 18:11:36 UTC (rev 17447)
Changed blocks: 1, Lines Added: 84, Lines Deleted: 0; 3343 bytes
@@ -10900,6 +10900,90 @@
</para>
<para>
+ The output from the InnoDB Standard Monitor contains several new
+ fields in the BUUFER POOL AND MEMORY section that pertain to
+ operation of the buffer pool LRU algorithm:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>Old database pages</literal>: The number of pages
+ in the buffer pool that have never been made young.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>Pages made young, not young</literal>: The number
+ of pages that were moved to the head of the buffer pool (the
+ new blocks sublist), and the number that have remained in
+ the old blocks sublist without being made new.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>youngs/s non-youngs/s</literal>: Like the previous
+ item, but calculated as a rate over time.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>young-making rate</literal>: Hits that cause blocks
+ to move to the head of the buffer pool.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>not</literal>: Hits that do not cause blocks to
+ move to the head of the buffer pool (due to the delay not
+ being met).
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The young-making rate and not rate will not normally add up to
+ the overall buffer pool hit rate. Hits for blocks in the old
+ sublist cause them to move to the new sublist, but hits to
+ blocks in the new sublist cause them to move to the head of the
+ list only if they are a certain distance from the head.
+ </para>
+
+ <para>
+ The information from the Monitor can help you make LRU tuning
+ decisions:
+ </para>
+
+ <para>
+ If you see very low <literal>youngs/s</literal> values when you
+ do not have large scans going on, that indicates that you might
+ need to either reduce the delay time, or increase the percentage
+ of the buffer pool used for the old sublist. Increasing the
+ percentage makes the old sublist larger, so blocks in that
+ sublist take longer to move to the tail and be evicted. This
+ increases the likelihood that they will be accessed again and be
+ made young.
+ </para>
+
+ <para>
+ If you do not see a lot of <literal>non-youngs/s</literal> when
+ you are doing large table scans (and lots of
+ <literal>youngs/s</literal>), you will want to tune your delay
+ value to be larger.
+ </para>
+
+ <para>
+ For more information about InnoDB Monitors, see
+ <xref linkend="innodb-monitors"/>.
+ </para>
+
+ <para>
The <literal>MyISAM</literal> storage engine also uses an LRU
algorithm, to manage its key cache. See
<xref linkend="myisam-key-cache"/>.
Modified: trunk/refman-5.5/optimization.xml
===================================================================
--- trunk/refman-5.5/optimization.xml 2009-11-04 18:11:30 UTC (rev 17446)
+++ trunk/refman-5.5/optimization.xml 2009-11-04 18:11:36 UTC (rev 17447)
Changed blocks: 1, Lines Added: 84, Lines Deleted: 0; 3343 bytes
@@ -12197,6 +12197,90 @@
</para>
<para>
+ The output from the InnoDB Standard Monitor contains several new
+ fields in the BUUFER POOL AND MEMORY section that pertain to
+ operation of the buffer pool LRU algorithm:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>Old database pages</literal>: The number of pages
+ in the buffer pool that have never been made young.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>Pages made young, not young</literal>: The number
+ of pages that were moved to the head of the buffer pool (the
+ new blocks sublist), and the number that have remained in
+ the old blocks sublist without being made new.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>youngs/s non-youngs/s</literal>: Like the previous
+ item, but calculated as a rate over time.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>young-making rate</literal>: Hits that cause blocks
+ to move to the head of the buffer pool.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>not</literal>: Hits that do not cause blocks to
+ move to the head of the buffer pool (due to the delay not
+ being met).
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ The young-making rate and not rate will not normally add up to
+ the overall buffer pool hit rate. Hits for blocks in the old
+ sublist cause them to move to the new sublist, but hits to
+ blocks in the new sublist cause them to move to the head of the
+ list only if they are a certain distance from the head.
+ </para>
+
+ <para>
+ The information from the Monitor can help you make LRU tuning
+ decisions:
+ </para>
+
+ <para>
+ If you see very low <literal>youngs/s</literal> values when you
+ do not have large scans going on, that indicates that you might
+ need to either reduce the delay time, or increase the percentage
+ of the buffer pool used for the old sublist. Increasing the
+ percentage makes the old sublist larger, so blocks in that
+ sublist take longer to move to the tail and be evicted. This
+ increases the likelihood that they will be accessed again and be
+ made young.
+ </para>
+
+ <para>
+ If you do not see a lot of <literal>non-youngs/s</literal> when
+ you are doing large table scans (and lots of
+ <literal>youngs/s</literal>), you will want to tune your delay
+ value to be larger.
+ </para>
+
+ <para>
+ For more information about InnoDB Monitors, see
+ <xref linkend="innodb-monitors"/>.
+ </para>
+
+ <para>
The <literal>MyISAM</literal> storage engine also uses an LRU
algorithm, to manage its key cache. See
<xref linkend="myisam-key-cache"/>.
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r17447 - in trunk: . refman-5.1 refman-5.5 | paul.dubois | 4 Nov |
