Author: jdrussel
Date: 2011-04-06 08:15:27 +0200 (Wed, 06 Apr 2011)
New Revision: 25755
Log:
Clarified guidance on innodb_purge_thread, when to increase the value or
keep it at or near 1.
Modified:
trunk/refman-5.6/innodb-performance.xml
trunk/refman-5.6/se-innodb-core.xml
Modified: trunk/refman-5.6/innodb-performance.xml
===================================================================
--- trunk/refman-5.6/innodb-performance.xml 2011-04-06 06:07:27 UTC (rev 25754)
+++ trunk/refman-5.6/innodb-performance.xml 2011-04-06 06:15:27 UTC (rev 25755)
Changed blocks: 2, Lines Added: 14, Lines Deleted: 14; 2497 bytes
@@ -1845,10 +1845,9 @@
</indexterm>
<para>
- Starting in InnoDB 1.1 with MySQL 5.5, the
- <link linkend="glos_purge">purge</link> operations (a type of
+ 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
+ in one or more separate threads, rather than as part of the
<link linkend="glos_master_thread">master thread</link>. This
change improves scalability, because the main database operations
run independently from maintenance work happening in the
@@ -1857,20 +1856,21 @@
<para>
To enable this feature, set the configuration option
- <literal>innodb_purge_threads=1</literal>, as opposed to the
- default of 0, which combines the purge operation into the master
- thread.
+ <literal>innodb_purge_threads=<replaceable>n</replaceable></literal>,
+ as opposed to the default of 0, which combines the purge operation
+ into the master thread. If DML action is concentrated on a single
+ table or a few tables, keep the setting low so that the threads do
+ not contend with each other for access to the busy tables. If DML
+ operations are spread across many tables, increase the setting.
+ Its maximum is 32.
</para>
<para>
- You might not notice a significant speedup, because the purge
- thread might encounter new types of contention; the single purge
- thread really lays the groundwork for further tuning and possibly
- multiple purge threads in the future. There is another new
- configuration option, <literal>innodb_purge_batch_size</literal>
- with a default of 20 and maximum of 5000. This option is mainly
- intended for experimentation and tuning of purge operations, and
- should not be interesting to typical users.
+ There is another related configuration option,
+ <literal>innodb_purge_batch_size</literal> with a default of 20
+ and maximum of 5000. This option is mainly intended for
+ experimentation and tuning of purge operations, and should not be
+ interesting to typical users.
</para>
<para>
Modified: trunk/refman-5.6/se-innodb-core.xml
===================================================================
--- trunk/refman-5.6/se-innodb-core.xml 2011-04-06 06:07:27 UTC (rev 25754)
+++ trunk/refman-5.6/se-innodb-core.xml 2011-04-06 06:15:27 UTC (rev 25755)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 1; 703 bytes
@@ -11744,7 +11744,8 @@
reduce internal contention within InnoDB, improving
scalability. Increasing the value to greater than 1 creates
that many separate purge threads, which can improve
- efficiency on systems with extra CPU capacity.
+ efficiency on systems where DML operations are performed on
+ multiple tables. The maximum is 32.
</para>
</listitem>
| Thread |
|---|
| • svn commit - mysqldoc@oter02: r25755 - trunk/refman-5.6 | john.russell | 6 Apr |