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.1 | john.russell | 18 May |
