List:Commits« Previous MessageNext Message »
From:john.russell Date:May 18 2010 4:35am
Subject:svn commit - mysqldoc@docsrva: r20679 - trunk/innodb-plugin-1.1
View as plain text  
Author: jrussell
Date: 2010-05-18 06:35:19 +0200 (Tue, 18 May 2010)
New Revision: 20679

Log:
Primarily clarifying that InnoDB 1.1 prereq is synonymous with MySQL 5.5 as the minimum release.


Modified:
   trunk/innodb-plugin-1.1/innodb-performance.xml


Modified: trunk/innodb-plugin-1.1/innodb-performance.xml
===================================================================
--- trunk/innodb-plugin-1.1/innodb-performance.xml	2010-05-18 00:52:46 UTC (rev 20678)
+++ trunk/innodb-plugin-1.1/innodb-performance.xml	2010-05-18 04:35:19 UTC (rev 20679)
Changed blocks: 8, Lines Added: 48, Lines Deleted: 44; 8165 bytes

@@ -322,11 +322,12 @@
       Beginning with &innodb_plugin; 1.0.3, you can control whether
       &innodb; performs insert buffering with the system configuration
       parameter &innodb_change_buffering;. Beginning with
-      &innodb_plugin; 1.1, the buffering support is expanded to include
-      delete operations (when index records are initially marked for
-      deletion) and purge operations (when index records are physically
-      deleted). &innodb_plugin; 1.1 also changes the default value from
-      <literal>inserts</literal> to <literal>all</literal>.
+      &innodb_plugin; 1.1 with MySQL 5.5, the buffering support is
+      expanded to include delete operations (when index records are
+      initially marked for deletion) and purge operations (when index
+      records are physically deleted). &innodb_plugin; 1.1 also changes
+      the default value from <literal>inserts</literal> to
+      <literal>all</literal>.
     </para>
 
     <para>

@@ -849,7 +850,7 @@
     </indexterm>
 
     <para>
-      Starting in &innodb_plugin; 1.1, the
+      Starting in &innodb_plugin; 1.1 with MySQL 5.5, the
       <link linkend="glos_asynchronous_io">asynchronous I/O</link>
       capability that has been supported on Windows systems, is now
       available on Linux systems. (Other Unix-like systems continue to

@@ -1407,18 +1408,18 @@
     </indexterm>
 
     <para>
-      Starting with &innodb_plugin; 1.1, you can profile certain
-      internal InnoDB operations using the
+      Starting with &innodb_plugin; 1.1 with MySQL 5.5, you can profile
+      certain internal InnoDB operations using the MySQL
       <ulink url="http://dev.mysql.com/doc/refman/5.5/en/performance-schema.html">Performance
-      Schema feature</ulink> from MySQL 5.5 and higher. This type of
-      tuning is primarily for expert users, those who push the limits of
-      MySQL performance, read the MySQL source code, and evaluate
-      optimization strategies to overcome performance bottlenecks. DBAs
-      can also use this feature for capacity planning, to see whether
-      their typical workload encounters any performance bottlenecks with
-      a particular combination of CPU, RAM, and disk storage; and if so,
-      to judge whether performance can be improved by increasing the
-      capacity of some part of the system.
+      Schema feature</ulink>. This type of tuning is primarily for
+      expert users, those who push the limits of MySQL performance, read
+      the MySQL source code, and evaluate optimization strategies to
+      overcome performance bottlenecks. DBAs can also use this feature
+      for capacity planning, to see whether their typical workload
+      encounters any performance bottlenecks with a particular
+      combination of CPU, RAM, and disk storage; and if so, to judge
+      whether performance can be improved by increasing the capacity of
+      some part of the system.
     </para>
 
     <para>

@@ -1551,15 +1552,17 @@
       When the InnoDB buffer pool is large, many data requests can be
       satisfied by retrieving from memory. You might encounter
       bottlenecks from multiple threads trying to access the buffer pool
-      at once. Starting in &innodb_plugin; 1.1, you can enable multiple
-      buffer pools to minimize this contention. Each page that is stored
-      in or read from the buffer pool is assigned to one of the buffer
-      pools randomly, using a hashing function. Each buffer pool manages
-      its own free lists, flush lists, LRUs, and all other data
-      structures connected to a buffer pool, and is protected by its own
-      buffer pool mutex.
+      at once. Starting in &innodb_plugin; 1.1 and MySQL 5.5, you can
+      enable multiple buffer pools to minimize this contention. Each
+      page that is stored in or read from the buffer pool is assigned to
+      one of the buffer pools randomly, using a hashing function. Each
+      buffer pool manages its own free lists, flush lists, LRUs, and all
+      other data structures connected to a buffer pool, and is protected
+      by its own buffer pool mutex.
     </para>
 
+<!-- JDR: perhaps add more advice about how to see the effects, using Performance Schema, Information Schema, SHOW INNODB STATUS, etc. -->
+
     <para>
       To enable this feature, set the
       <literal>innodb_buffer_pool_instances</literal> configuration

@@ -1588,15 +1591,16 @@
       segment</link> could be a bottleneck on high-capacity systems,
       because it can handle a maximum of 1023 concurrent transactions
       that change any data. (Read-only transactions do not count against
-      that maximum.) Starting in &innodb_plugin; 1.1, the limit on
-      concurrent transactions is greatly expanded. The single rollback
-      segment is divided into 131,072 (128K) segments, each of which can
-      support up to 1023 transactions that perform writes. Each
-      transaction is assigned to one of the rollback segments using a
-      hashing function, and remains tied to that rollback segment for
+      that maximum.) Starting in &innodb_plugin; 1.1 with MySQL 5.5, the
+      limit on concurrent transactions is greatly expanded. The single
+      rollback segment is divided into 131,072 (128K) segments, each of
+      which can support up to 1023 transactions that perform writes.
+      Each transaction is assigned to one of the rollback segments using
+      a hashing function, and remains tied to that rollback segment for
       the duration. This enhancement improves both scalability (higher
       number of concurrent transactions) and performance (less
-      contention when different threads access the rollback segments).
+      contention when different transactions access the rollback
+      segments).
     </para>
 
     <para>

@@ -1621,7 +1625,7 @@
     </indexterm>
 
     <para>
-      Starting in &innodb_plugin; 1.1, the
+      Starting in &innodb_plugin; 1.1 with MySQL 5.5, the
       <link linkend="glos_purge">purge</link> operations (a type of
       garbage collection) that InnoDB performs automatically can be done
       in a separate thread, rather than as part of the

@@ -1679,10 +1683,10 @@
       <link linkend="glos_buffer_pool">buffer pool</link> that are
       changed when a
       <link linkend="glos_mini_transaction">mini-transaction</link> is
-      committed. Starting in &innodb_plugin; 1.1, these two kinds of
-      operations are protected by separate mutexes, with a new
-      <literal>log_buf</literal> mutex controlling writes to buffer pool
-      pages due to mini-transactions.
+      committed. Starting in &innodb_plugin; 1.1 with MySQL 5.5, these
+      two kinds of operations are protected by separate mutexes, with a
+      new <literal>log_buf</literal> mutex controlling writes to buffer
+      pool pages due to mini-transactions.
     </para>
 
   </section>

@@ -1696,14 +1700,14 @@
     </indexterm>
 
     <para>
-      Starting with &innodb_plugin; 1.1, concurrent access to the
-      <link linkend="glos_buffer_pool">buffer pool</link> is faster.
-      Operations involving the <link linkend="glos_flush_list">flush
-      list</link>, a data structure related to the buffer pool, are now
-      controlled by a separate <link linkend="glos_mutex">mutex</link>
-      and do not block access to the buffer pool. You do not need to
-      configure anything to take advantage of this speedup; it is fully
-      automatic.
+      Starting with &innodb_plugin; 1.1 with MySQL 5.5, concurrent
+      access to the <link linkend="glos_buffer_pool">buffer pool</link>
+      is faster. Operations involving the
+      <link linkend="glos_flush_list">flush list</link>, a data
+      structure related to the buffer pool, are now controlled by a
+      separate <link linkend="glos_mutex">mutex</link> and do not block
+      access to the buffer pool. You do not need to configure anything
+      to take advantage of this speedup; it is fully automatic.
     </para>
 
   </section>


Thread
svn commit - mysqldoc@docsrva: r20679 - trunk/innodb-plugin-1.1john.russell18 May