List:Commits« Previous MessageNext Message »
From:john.russell Date:July 22 2010 8:09pm
Subject:svn commit - mysqldoc@docsrva: r21866 - trunk/refman-5.5
View as plain text  
Author: jrussell
Date: 2010-07-22 22:09:02 +0200 (Thu, 22 Jul 2010)
New Revision: 21866

Log:
Reorg the buffer pool section a little bit, adding bridge heads and an initial section with guidelines.
(Also need some info here about the "multiple buffer pools" feature. That's next.)


Modified:
   trunk/refman-5.5/optimization.xml


Modified: trunk/refman-5.5/optimization.xml
===================================================================
--- trunk/refman-5.5/optimization.xml	2010-07-22 19:33:42 UTC (rev 21865)
+++ trunk/refman-5.5/optimization.xml	2010-07-22 20:09:02 UTC (rev 21866)
Changed blocks: 5, Lines Added: 42, Lines Deleted: 4; 3278 bytes

@@ -10094,6 +10094,38 @@
       <para>
         <literal role="se">InnoDB</literal> maintains a buffer pool for
         caching data and indexes in memory.
+      </para>
+
+      <bridgehead>Guidelines</bridgehead>
+
+      <para>
+        Ideally, you set the size of the buffer pool to as large a value
+        as practical, leaving enough memory for other processes on the
+        server to run without excessive paging. The larger the buffer
+        pool, the more <literal>InnoDB</literal> acts like an in-memory
+        database, reading data from disk once and then accessing the
+        data from memory during subsequent reads. The buffer pool also
+        holds data changed by insert and update operations, so that disk
+        writes can be done more efficiently.
+      </para>
+
+      <para>
+        Depending on the typical workload on your system, you might
+        adjust the proportions of the parts within the buffer pool. You
+        can tune the way the LRU algorithm works to keep frequently
+        accessed data in the cache, despite sudden spikes of activity
+        for operations such as backups or reporting.
+      </para>
+
+      <para>
+        With 64-bit systems with large memory sizes, you can split the
+        buffer pool into multiple parts, to minimize contention for the
+        buffer pool among concurrent operations.
+      </para>
+
+      <bridgehead>Internal Details</bridgehead>
+
+      <para>
         <literal role="se">InnoDB</literal> manages the pool as a list,
         using a least recently used (LRU) algorithm incorporating a
         midpoint insertion strategy. When room is needed to add a new

@@ -10203,9 +10235,11 @@
         eviction.
       </para>
 
+      <bridgehead>Configuration Options</bridgehead>
+
       <para>
-        <literal role="se">InnoDB</literal> has several system variables
-        that control the size of the buffer pool or enable LRU algorithm
+        Several <literal role="se">InnoDB</literal> system variables
+        control the size of the buffer pool or enable LRU algorithm
         tuning:
       </para>
 

@@ -10301,6 +10335,8 @@
         sublist.
       </para>
 
+      <bridgehead>Monitoring the Buffer Pool</bridgehead>
+
       <para>
         The output from the InnoDB Standard Monitor contains several new
         fields in the <literal>BUFFER POOL AND MEMORY</literal> section

@@ -10387,8 +10423,8 @@
           <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.
+            <literal>youngs/s</literal>), to tune your delay value to be
+            larger.
           </para>
         </listitem>
 

@@ -10399,6 +10435,8 @@
         <xref linkend="innodb-monitors"/>.
       </para>
 
+      <bridgehead>Related Tuning Topics</bridgehead>
+
       <para>
         The <literal>MyISAM</literal> storage engine also uses an LRU
         algorithm, to manage its key cache. See


Thread
svn commit - mysqldoc@docsrva: r21866 - trunk/refman-5.5john.russell22 Jul