| List: | Commits | « Previous MessageNext Message » | |
| From: | jon.stephens | Date: | February 9 2009 1:25pm |
| Subject: | svn commit - mysqldoc@docsrva: r13668 - trunk/refman-5.1 | ||
| View as plain text | |||
Author: jstephens Date: 2009-02-09 13:25:43 +0100 (Mon, 09 Feb 2009) New Revision: 13668 Log: Documented ThreadPool configuration parameter for Cluster-6.4 Causes and handling of GCP Stop errors (Thanks, Jonas!) Modified: trunk/refman-5.1/mysql-cluster-configuration.xml trunk/refman-5.1/mysql-cluster-disk-data.xml Modified: trunk/refman-5.1/mysql-cluster-configuration.xml =================================================================== --- trunk/refman-5.1/mysql-cluster-configuration.xml 2009-02-09 12:04:20 UTC (rev 13667) +++ trunk/refman-5.1/mysql-cluster-configuration.xml 2009-02-09 12:25:43 UTC (rev 13668) Changed blocks: 4, Lines Added: 167, Lines Deleted: 31; 9236 bytes @@ -5366,7 +5366,7 @@ <title>Disk Data Configuration Parameters</title> - <para> + <para id="mysql-cluster-ndbd-definition-disk-data-parameters"> Configuration parameters affecting Disk Data behavior include the following: @@ -5400,36 +5400,8 @@ </para> <para> - For MySQL Cluster databases with large amounts of data - on disk under high load, the default may not be large - enough; data node failures with NDB error 2303 can - indicate that this is a problem. In such cases, you - should increase the value of - <literal>DiskPageBufferMemory</literal> to include most - of the memory available to the data nodes after - accounting for index memory, data memory, internal - buffers, and memory needed by the data node host - operating system. You can use this formula as a guide: + This parameter was added in MySQL 5.1.6. </para> - -<programlisting> -DiskPageBufferMemory - = 0.8 - x ( - [total memory] - - ([operating system memory] + [buffer memory] + DataMemory + IndexMemory) - ) -</programlisting> - - <para> - Once you have established that sufficient memory is - reserved for <literal>DataMemory</literal>, - <literal>IndexMemory</literal>, - <literal role="se">NDB</literal> internal buffers, and - operating system overhead, it is possible (and sometimes - desirable) to allocate more of the remainder to - <literal>DiskPageBufferMemory</literal>. - </para> </listitem> <listitem> @@ -5455,11 +5427,166 @@ <para> The default value is <literal>20M</literal>. </para> + + <para> + This parameter was added in MySQL 5.1.6. + </para> </listitem> + <listitem> + <indexterm> + <primary>ThreadPool</primary> + </indexterm> + + <para id="mysql-cluster-param-ndbd-definition-threadpool"> + <literal>ThreadPool</literal> + </para> + + <para> + This parameter determines the number of unbound threads + used for file access. The default is 8; however, it + should not be set higher than the number of data files + being used. <literal>ThreadPool</literal> should be the + same for all data nodes, so it is best practice to set + it in the <filename>config.ini</filename> file's + <literal>[ndbd default]</literal> section. + </para> + + <para> + This parameter was added in MySQL Cluster NDB 6.4.0. + </para> + </listitem> + </itemizedlist> + </para> - These parameters were added in MySQL 5.1.6 + </formalpara> + + <formalpara> + + <title>Disk Data and <errortext>GCP Stop</errortext> errors</title> + + <para id="mysql-cluster-ndbd-definition-gcp-stop-errors"> + <indexterm> + <primary>MySQL Cluster</primary> + <secondary>GCP Stop errors</secondary> + </indexterm> + + <indexterm> + <primary>GCP Stop errors (MySQL Cluster)</primary> + </indexterm> + + Errors encountered when using Disk Data tables such as + <errortext>Node <replaceable>nodeid</replaceable> killed this + node because GCP stop was detected</errortext> (error 2303) + are often referred to as <quote>CGP stop errors</quote>. Such + errors are usually due to slow disks and insufficient disk + throughput. You can help prevent these errors from occurring + by using faster disks, and by adjusting the cluster + configuration as discussed here: + + <itemizedlist> + + <listitem> + <formalpara> + + <title>MySQL Cluster NDB 6.2 and 6.3</title> + + <para> + When working with large amounts of data on disk under + high load, the default value for + <literal>DiskPageBufferMemory</literal> may not be + large enough. In such cases, you should increase its + value to include most of the memory available to the + data nodes after accounting for index memory, data + memory, internal buffers, and memory needed by the + data node host operating system. You can use this + formula as a guide: + +<programlisting> +DiskPageBufferMemory + = 0.8 + x ( + [total memory] + - ([operating system memory] + [buffer memory] + DataMemory + IndexMemory) + ) +</programlisting> + + Once you have established that sufficient memory is + reserved for <literal>DataMemory</literal>, + <literal>IndexMemory</literal>, NDB internal buffers, + and operating system overhead, it is possible (and + sometimes desirable) to allocate more than the above + amount of the remainder to + <literal>DiskPageBufferMemory</literal>. + </para> + + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title>MySQL Cluster NDB 6.4</title> + + <para> + In addition to the considerations given for + <literal>DiskPageBufferMemory</literal> as explained + in the previous item, it is also very important that + the <literal>ThreadPool</literal> configuration + parameter be set correctly, according to the number of + data files in use for data on disk, because having + <literal>ThreadPool</literal> set higher than the + number of data files is very likely to cause GCP stop + errors (Bug #37227). By <quote>number of data + files</quote>, we mean the number of data files per + data node; since the statements + <literal role="stmt" condition="create-tablespace">CREATE + TABLESPACE ... ADD DATAFILE ...</literal>, + <literal role="stmt" condition="alter-tablespace">ALTER + TABLESPACE ... ADD DATAFILE ...</literal>, and + <literal>ALTER TABLESPACE ... DROP DATAFILE + ...</literal> each act on the MySQL Cluster as a + whole, this number is always the same for all data + nodes. You can determine in the + <command>mysql</command> client how many data files + are in use by means of a query against the + <literal role="is">INFORMATION_SCHEMA.FILES</literal> + table, such as the one shown here: + +<programlisting> +mysql> <userinput>SELECT COUNT(FILE_NAME) AS Datafiles</userinput> + > <userinput>FROM INFORMATION_SCHEMA.FILES</userinput> + > <userinput>WHERE FILE_TYPE='DATAFILE'</userinput> + > <userinput>GROUP BY EXTRA</userinput> + > <userinput>LIMIT 1;</userinput> ++-----------+ +| Datafiles | ++-----------+ +| 4 | ++-----------+ +1 row in set (0.00 sec) + +</programlisting> + + Alternatively, you can obtain this information by + invoking <command>ndb_show_tables</command> from the + system shell as shown here: + +<programlisting> +shell> <userinput>./ndb_show_tables | grep Datafile | wc -l</userinput> +</programlisting> + + (This assumes that you are using + <command>bash</command> as your shell. However, + similar commands can be devised for other + environments.) + </para> + + </formalpara> + </listitem> + + </itemizedlist> </para> </formalpara> @@ -7471,6 +7598,15 @@ <entry>N</entry> </row> <row> + <entry><literal><link linkend="mysql-cluster-param-ndbd-definition-threadpool">ThreadPool</link></literal> + (Added in MySQL Cluster NDB 6.4.0)</entry> + <entry>integer</entry> + <entry>8</entry> + <entry>0</entry> + <entry>4294967039</entry> + <entry>N</entry> + </row> + <row> <entry><literal><link linkend="mysql-cluster-param-ndbd-definition-timebetweenepochs">TimeBetweenEpochs</link></literal> (Added in MySQL Cluster NDB 6.2.5 and MySQL Cluster NDB 6.3.2)</entry> Modified: trunk/refman-5.1/mysql-cluster-disk-data.xml =================================================================== --- trunk/refman-5.1/mysql-cluster-disk-data.xml 2009-02-09 12:04:20 UTC (rev 13667) +++ trunk/refman-5.1/mysql-cluster-disk-data.xml 2009-02-09 12:25:43 UTC (rev 13668) Changed blocks: 1, Lines Added: 15, Lines Deleted: 4; 1833 bytes @@ -35,17 +35,28 @@ </para> <para> - As part of implementing Cluster Disk Data work, a number of + As part of implementing MySQL Cluster Disk Data work, a number of improvements were made in MySQL Cluster for the efficient handling of very large amounts (terabytes) of data during node recovery and restart. These include a <quote>no-steal</quote> algorithm for synchronising a starting node with very large data sets. For more information, see the paper - <ulink url="http://www.vldb2005.org/program/paper/wed/p1108-ronstrom.pdf">Recovery - Principles of MySQL Cluster 5.1</ulink>, by MySQL Cluster developers - Mikael Ronström and Jonas Oreland. + <citetitle><ulink url="http://www.vldb2005.org/program/paper/wed/p1108-ronstrom.pdf">Recovery + Principles of MySQL Cluster 5.1</ulink></citetitle>, by MySQL + Cluster developers Mikael Ronström and Jonas Oreland. </para> + <para> + MySQL Cluster Disk Data performance can be influenced by a number of + configuration parameters. For information about these parameters and + their effects, see + <citetitle><link linkend="mysql-cluster-ndbd-definition-disk-data-parameters">MySQL + Cluster Disk Data configuration parameters</link></citetitle> and + <citetitle><link linkend="mysql-cluster-ndbd-definition-gcp-stop-errors">MySQL + Cluster Disk Data storage and <errortext>GCP Stop</errortext> + errors</link></citetitle> + </para> + <section id="mysql-cluster-disk-data-objects"> <title>MySQL Cluster Disk Data Objects</title>
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r13668 - trunk/refman-5.1 | jon.stephens | 9 Feb 2009 |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.457 sec. using MySQL 5.1.14-beta-log