ctdb/doc/ctdb-tunables.7.xml

   1 <?xml version="1.0" encoding="iso-8859-1"?>
   2 <!DOCTYPE refentry
   3         PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   4         "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
   5
   6 <refentry id="ctdb-tunables.7">
   7
   8   <refmeta>
   9     <refentrytitle>ctdb-tunables</refentrytitle>
  10     <manvolnum>7</manvolnum>
  11     <refmiscinfo class="source">ctdb</refmiscinfo>
  12     <refmiscinfo class="manual">CTDB - clustered TDB database</refmiscinfo>
  13   </refmeta>
  14
  15   <refnamediv>
  16     <refname>ctdb-tunables</refname>
  17     <refpurpose>CTDB tunable configuration variables</refpurpose>
  18   </refnamediv>
  19
  20   <refsect1>
  21     <title>DESCRIPTION</title>
  22
  23     <para>
  24       CTDB's behaviour can be configured by setting run-time tunable
  25       variables.  This lists and describes all tunables.  See the
  26       <citerefentry><refentrytitle>ctdb</refentrytitle>
  27       <manvolnum>1</manvolnum></citerefentry>
  28       <command>listvars</command>, <command>setvar</command> and
  29       <command>getvar</command> commands for more details.
  30     </para>
  31
  32     <para>
  33       Unless otherwise stated, tunables should be set to the same
  34       value on all nodes.  Setting tunables to different values across
  35       nodes may produce unexpected results.  Future releases may set
  36       (some or most) tunables globally across the cluster but doing so
  37       is currently a manual process.
  38     </para>
  39
  40     <para>
  41       Tunables can be set at startup from the
  42       <filename>/usr/local/etc/ctdb/ctdb.tunables</filename>
  43       configuration file.
  44
  45       <literallayout>
  46 <replaceable>TUNABLE</replaceable>=<replaceable>VALUE</replaceable>
  47       </literallayout>
  48     </para>
  49
  50     <para>
  51       For example:
  52
  53       <screen format="linespecific">
  54 MonitorInterval=20
  55       </screen>
  56     </para>
  57
  58     <para>
  59       The available tunable variables are listed alphabetically below.
  60     </para>
  61
  62     <refsect2>
  63       <title>AllowClientDBAttach</title>
  64       <para>Default: 1</para>
  65       <para>
  66         When set to 0, clients are not allowed to attach to any databases.
  67         This can be used to temporarily block any new processes from
  68         attaching to and accessing the databases.  This is mainly used
  69         for detaching a volatile database using 'ctdb detach'.
  70       </para>
  71     </refsect2>
  72
  73     <refsect2>
  74       <title>AllowMixedVersions</title>
  75       <para>Default: 0</para>
  76       <para>
  77         CTDB will not allow incompatible versions to co-exist in
  78         a cluster.  If a version mismatch is found, then losing CTDB
  79         will shutdown.  To disable the incompatible version check,
  80         set this tunable to 1.
  81       </para>
  82       <para>
  83         For version checking, CTDB uses major and minor version.
  84         For example, CTDB 4.6.1 and CTDB CTDB 4.6.2 are matching versions;
  85         CTDB 4.5.x and CTDB 4.6.y do not match.
  86       </para>
  87       <para>
  88         CTDB with version check support will lose to CTDB without
  89         version check support.  Between two different CTDB versions with
  90         version check support, one running for less time will lose.
  91         If the running time for both CTDB versions with version check
  92         support is equal (to seconds), then the older version will lose.
  93         The losing CTDB daemon will shutdown.
  94       </para>
  95     </refsect2>
  96
  97     <refsect2>
  98       <title>AllowUnhealthyDBRead</title>
  99       <para>Default: 0</para>
 100       <para>
 101         When set to 1, ctdb allows database traverses to read unhealthy
 102         databases.  By default, ctdb does not allow reading records from
 103         unhealthy databases.
 104       </para>
 105     </refsect2>
 106
 107     <refsect2>
 108       <title>ControlTimeout</title>
 109       <para>Default: 60</para>
 110       <para>
 111         This is the default setting for timeout for when sending a
 112         control message to either the local or a remote ctdb daemon.
 113       </para>
 114     </refsect2>
 115
 116     <refsect2>
 117       <title>DatabaseHashSize</title>
 118       <para>Default: 100001</para>
 119       <para>
 120         Number of the hash chains for the local store of the tdbs that
 121         ctdb manages.
 122       </para>
 123     </refsect2>
 124
 125     <refsect2>
 126       <title>DatabaseMaxDead</title>
 127       <para>Default: 5</para>
 128       <para>
 129         Maximum number of dead records per hash chain for the tdb databses
 130         managed by ctdb.
 131       </para>
 132     </refsect2>
 133
 134     <refsect2>
 135       <title>DBRecordCountWarn</title>
 136       <para>Default: 100000</para>
 137       <para>
 138         When set to non-zero, ctdb will log a warning during recovery if
 139         a database has more than this many records. This will produce a
 140         warning if a database grows uncontrollably with orphaned records.
 141       </para>
 142     </refsect2>
 143
 144     <refsect2>
 145       <title>DBRecordSizeWarn</title>
 146       <para>Default: 10000000</para>
 147       <para>
 148         When set to non-zero, ctdb will log a warning during recovery
 149         if a single record is bigger than this size. This will produce
 150         a warning if a database record grows uncontrollably.
 151       </para>
 152     </refsect2>
 153
 154     <refsect2>
 155       <title>DBSizeWarn</title>
 156       <para>Default: 1000000000</para>
 157       <para>
 158         When set to non-zero, ctdb will log a warning during recovery if
 159         a database size is bigger than this. This will produce a warning
 160         if a database grows uncontrollably.
 161       </para>
 162     </refsect2>
 163
 164     <refsect2>
 165       <title>DeferredAttachTO</title>
 166       <para>Default: 120</para>
 167       <para>
 168         When databases are frozen we do not allow clients to attach to
 169         the databases. Instead of returning an error immediately to the
 170         client, the attach request from the client is deferred until
 171         the database becomes available again at which stage we respond
 172         to the client.
 173       </para>
 174       <para>
 175         This timeout controls how long we will defer the request from the
 176         client before timing it out and returning an error to the client.
 177       </para>
 178     </refsect2>
 179
 180     <refsect2>
 181       <title>DisableIPFailover</title>
 182       <para>Default: 0</para>
 183       <para>
 184         When set to non-zero, ctdb will not perform failover or
 185         failback. Even if a node fails while holding public IPs, ctdb
 186         will not recover the IPs or assign them to another node.
 187       </para>
 188       <para>
 189         When this tunable is enabled, ctdb will no longer attempt
 190         to recover the cluster by failing IP addresses over to other
 191         nodes. This leads to a service outage until the administrator
 192         has manually performed IP failover to replacement nodes using the
 193         'ctdb moveip' command.
 194       </para>
 195     </refsect2>
 196
 197     <refsect2>
 198       <title>ElectionTimeout</title>
 199       <para>Default: 3</para>
 200       <para>
 201         The number of seconds to wait for the election of recovery
 202         master to complete. If the election is not completed during this
 203         interval, then that round of election fails and ctdb starts a
 204         new election.
 205       </para>
 206     </refsect2>
 207
 208     <refsect2>
 209       <title>EnableBans</title>
 210       <para>Default: 1</para>
 211       <para>
 212         This parameter allows ctdb to ban a node if the node is misbehaving.
 213       </para>
 214       <para>
 215         When set to 0, this disables banning completely in the cluster
 216         and thus nodes can not get banned, even it they break. Don't
 217         set to 0 unless you know what you are doing.
 218       </para>
 219     </refsect2>
 220
 221     <refsect2>
 222       <title>EventScriptTimeout</title>
 223       <para>Default: 30</para>
 224       <para>
 225         Maximum time in seconds to allow an event to run before timing
 226         out.  This is the total time for all enabled scripts that are
 227         run for an event, not just a single event script.
 228       </para>
 229       <para>
 230         Note that timeouts are ignored for some events ("takeip",
 231         "releaseip", "startrecovery", "recovered") and converted to
 232         success.  The logic here is that the callers of these events
 233         implement their own additional timeout.
 234       </para>
 235     </refsect2>
 236
 237     <refsect2>
 238       <title>FetchCollapse</title>
 239       <para>Default: 1</para>
 240       <para>
 241        This parameter is used to avoid multiple migration requests for
 242        the same record from a single node. All the record requests for
 243        the same record are queued up and processed when the record is
 244        migrated to the current node.
 245       </para>
 246       <para>
 247         When many clients across many nodes try to access the same record
 248         at the same time this can lead to a fetch storm where the record
 249         becomes very active and bounces between nodes very fast. This
 250         leads to high CPU utilization of the ctdbd daemon, trying to
 251         bounce that record around very fast, and poor performance.
 252         This can improve performance and reduce CPU utilization for
 253         certain workloads.
 254       </para>
 255     </refsect2>
 256
 257     <refsect2>
 258       <title>HopcountMakeSticky</title>
 259       <para>Default: 50</para>
 260       <para>
 261         For database(s) marked STICKY (using 'ctdb setdbsticky'),
 262         any record that is migrating so fast that hopcount
 263         exceeds this limit is marked as STICKY record for
 264         <varname>StickyDuration</varname> seconds. This means that
 265         after each migration the sticky record will be kept on the node
 266         <varname>StickyPindown</varname>milliseconds and prevented from
 267         being migrated off the node.
 268        </para>
 269        <para>
 270         This will improve performance for certain workloads, such as
 271         locking.tdb if many clients are opening/closing the same file
 272         concurrently.
 273       </para>
 274     </refsect2>
 275
 276     <refsect2>
 277       <title>IPAllocAlgorithm</title>
 278       <para>Default: 2</para>
 279       <para>
 280         Selects the algorithm that CTDB should use when doing public
 281         IP address allocation.  Meaningful values are:
 282       </para>
 283       <variablelist>
 284         <varlistentry>
 285           <term>0</term>
 286           <listitem>
 287             <para>
 288               Deterministic IP address allocation.
 289             </para>
 290             <para>
 291               This is a simple and fast option.  However, it can cause
 292               unnecessary address movement during fail-over because
 293               each address has a "home" node.  Works badly when some
 294               nodes do not have any addresses defined.  Should be used
 295               with care when addresses are defined across multiple
 296               networks.
 297             </para>
 298           </listitem>
 299         </varlistentry>
 300         <varlistentry>
 301           <term>1</term>
 302           <listitem>
 303             <para>
 304               Non-deterministic IP address allocation.
 305             </para>
 306             <para>
 307               This is a relatively fast option that attempts to do a
 308               minimise unnecessary address movements.  Addresses do
 309               not have a "home" node.  Rebalancing is limited but it
 310               usually adequate.  Works badly when addresses are
 311               defined across multiple networks.
 312             </para>
 313           </listitem>
 314         </varlistentry>
 315         <varlistentry>
 316           <term>2</term>
 317           <listitem>
 318             <para>
 319               LCP2 IP address allocation.
 320             </para>
 321             <para>
 322               Uses a heuristic to assign addresses defined across
 323               multiple networks, usually balancing addresses on each
 324               network evenly across nodes.  Addresses do not have a
 325               "home" node.  Minimises unnecessary address movements.
 326               The algorithm is complex, so is slower than other
 327               choices for a large number of addresses.  However, it
 328               can calculate an optimal assignment of 900 addresses in
 329               under 10 seconds on modern hardware.
 330             </para>
 331           </listitem>
 332         </varlistentry>
 333       </variablelist>
 334       <para>
 335         If the specified value is not one of these then the default
 336         will be used.
 337       </para>
 338     </refsect2>
 339
 340     <refsect2>
 341       <title>KeepaliveInterval</title>
 342       <para>Default: 5</para>
 343       <para>
 344         How often in seconds should the nodes send keep-alive packets to
 345         each other.
 346       </para>
 347     </refsect2>
 348
 349     <refsect2>
 350       <title>KeepaliveLimit</title>
 351       <para>Default: 5</para>
 352       <para>
 353         After how many keepalive intervals without any traffic should
 354         a node wait until marking the peer as DISCONNECTED.
 355        </para>
 356        <para>
 357         If a node has hung, it can take
 358         <varname>KeepaliveInterval</varname> *
 359         (<varname>KeepaliveLimit</varname> + 1) seconds before
 360         ctdb determines that the node is DISCONNECTED and performs
 361         a recovery. This limit should not be set too high to enable
 362         early detection and avoid any application timeouts (e.g. SMB1)
 363         to kick in before the fail over is completed.
 364       </para>
 365     </refsect2>
 366
 367     <refsect2>
 368       <title>LockProcessesPerDB</title>
 369       <para>Default: 200</para>
 370       <para>
 371         This is the maximum number of lock helper processes ctdb will
 372         create for obtaining record locks.  When ctdb cannot get a record
 373         lock without blocking, it creates a helper process that waits
 374         for the lock to be obtained.
 375       </para>
 376     </refsect2>
 377
 378     <refsect2>
 379       <title>LogLatencyMs</title>
 380       <para>Default: 0</para>
 381       <para>
 382         When set to non-zero, ctdb will log if certains operations
 383         take longer than this value, in milliseconds, to complete.
 384         These operations include "process a record request from client",
 385         "take a record or database lock", "update a persistent database
 386         record" and "vaccum a database".
 387       </para>
 388     </refsect2>
 389
 390     <refsect2>
 391       <title>MaxQueueDropMsg</title>
 392       <para>Default: 1000000</para>
 393       <para>
 394         This is the maximum number of messages to be queued up for
 395         a client before ctdb will treat the client as hung and will
 396         terminate the client connection.
 397       </para>
 398     </refsect2>
 399
 400     <refsect2>
 401       <title>MonitorInterval</title>
 402       <para>Default: 15</para>
 403       <para>
 404         How often should ctdb run the 'monitor' event in seconds to check
 405         for a node's health.
 406       </para>
 407     </refsect2>
 408
 409     <refsect2>
 410       <title>MonitorTimeoutCount</title>
 411       <para>Default: 20</para>
 412       <para>
 413         How many 'monitor' events in a row need to timeout before a node
 414         is flagged as UNHEALTHY.  This setting is useful if scripts can
 415         not be written so that they do not hang for benign reasons.
 416       </para>
 417     </refsect2>
 418
 419     <refsect2>
 420       <title>NoIPFailback</title>
 421       <para>Default: 0</para>
 422       <para>
 423         When set to 1, ctdb will not perform failback of IP addresses
 424         when a node becomes healthy. When a node becomes UNHEALTHY,
 425         ctdb WILL perform failover of public IP addresses, but when the
 426         node becomes HEALTHY again, ctdb will not fail the addresses back.
 427       </para>
 428       <para>
 429         Use with caution! Normally when a node becomes available to the
 430         cluster ctdb will try to reassign public IP addresses onto the
 431         new node as a way to distribute the workload evenly across the
 432         clusternode. Ctdb tries to make sure that all running nodes have
 433         approximately the same number of public addresses it hosts.
 434       </para>
 435       <para>
 436         When you enable this tunable, ctdb will no longer attempt to
 437         rebalance the cluster by failing IP addresses back to the new
 438         nodes. An unbalanced cluster will therefore remain unbalanced
 439         until there is manual intervention from the administrator. When
 440         this parameter is set, you can manually fail public IP addresses
 441         over to the new node(s) using the 'ctdb moveip' command.
 442       </para>
 443     </refsect2>
 444
 445     <refsect2>
 446       <title>NoIPHostOnAllDisabled</title>
 447       <para>Default: 0</para>
 448       <para>
 449         If no nodes are HEALTHY then by default ctdb will happily host
 450         public IPs on disabled (unhealthy or administratively disabled)
 451         nodes.  This can cause problems, for example if the underlying
 452         cluster filesystem is not mounted.  When set to 1 and a node
 453         is disabled, any IPs hosted by this node will be released and
 454         the node will not takeover any IPs until it is no longer disabled.
 455       </para>
 456     </refsect2>
 457
 458     <refsect2>
 459       <title>NoIPTakeover</title>
 460       <para>Default: 0</para>
 461       <para>
 462         When set to 1, ctdb will not allow IP addresses to be failed
 463         over to other nodes.  Any IP addresses already hosted on
 464         healthy nodes will remain.  Usually IP addresses hosted on
 465         unhealthy nodes will also remain, if NoIPHostOnAllDisabled is
 466         0.  However, if NoIPHostOnAllDisabled is 1 then IP addresses
 467         will be released by unhealthy nodes and will become un-hosted.
 468       </para>
 469     </refsect2>
 470
 471     <refsect2>
 472       <title>PullDBPreallocation</title>
 473       <para>Default: 10*1024*1024</para>
 474       <para>
 475         This is the size of a record buffer to pre-allocate for sending
 476         reply to PULLDB control. Usually record buffer starts with size
 477         of the first record and gets reallocated every time a new record
 478         is added to the record buffer. For a large number of records,
 479         this can be very inefficient to grow the record buffer one record
 480         at a time.
 481       </para>
 482     </refsect2>
 483
 484     <refsect2>
 485       <title>QueueBufferSize</title>
 486       <para>Default: 1024</para>
 487       <para>
 488         This is the maximum amount of data (in bytes) ctdb will read
 489         from a socket at a time.
 490       </para>
 491       <para>
 492         For a busy setup, if ctdb is not able to process the TCP sockets
 493         fast enough (large amount of data in Recv-Q for tcp sockets),
 494         then this tunable value should be increased.  However, large
 495         values can keep ctdb busy processing packets and prevent ctdb
 496         from handling other events.
 497       </para>
 498     </refsect2>
 499
 500     <refsect2>
 501       <title>RecBufferSizeLimit</title>
 502       <para>Default: 1000000</para>
 503       <para>
 504         This is the limit on the size of the record buffer to be sent
 505         in various controls.  This limit is used by new controls used
 506         for recovery and controls used in vacuuming.
 507       </para>
 508     </refsect2>
 509
 510     <refsect2>
 511       <title>RecdFailCount</title>
 512       <para>Default: 10</para>
 513       <para>
 514         If the recovery daemon has failed to ping the main dameon for
 515         this many consecutive intervals, the main daemon will consider
 516         the recovery daemon as hung and will try to restart it to recover.
 517       </para>
 518     </refsect2>
 519
 520     <refsect2>
 521       <title>RecdPingTimeout</title>
 522       <para>Default: 60</para>
 523       <para>
 524         If the main dameon has not heard a "ping" from the recovery dameon
 525         for this many seconds, the main dameon will log a message that
 526         the recovery daemon is potentially hung.  This also increments a
 527         counter which is checked against <varname>RecdFailCount</varname>
 528         for detection of hung recovery daemon.
 529       </para>
 530     </refsect2>
 531
 532     <refsect2>
 533       <title>RecLockLatencyMs</title>
 534       <para>Default: 1000</para>
 535       <para>
 536         When using a reclock file for split brain prevention, if set
 537         to non-zero this tunable will make the recovery dameon log a
 538         message if the fcntl() call to lock/testlock the recovery file
 539         takes longer than this number of milliseconds.
 540       </para>
 541     </refsect2>
 542
 543     <refsect2>
 544       <title>RecoverInterval</title>
 545       <para>Default: 1</para>
 546       <para>
 547         How frequently in seconds should the recovery daemon perform the
 548         consistency checks to determine if it should perform a recovery.
 549       </para>
 550     </refsect2>
 551
 552     <refsect2>
 553       <title>RecoverTimeout</title>
 554       <para>Default: 120</para>
 555       <para>
 556         This is the default setting for timeouts for controls when sent
 557         from the recovery daemon. We allow longer control timeouts from
 558         the recovery daemon than from normal use since the recovery
 559         dameon often use controls that can take a lot longer than normal
 560         controls.
 561       </para>
 562     </refsect2>
 563
 564     <refsect2>
 565       <title>RecoveryBanPeriod</title>
 566       <para>Default: 300</para>
 567       <para>
 568        The duration in seconds for which a node is banned if the node
 569        fails during recovery.  After this time has elapsed the node will
 570        automatically get unbanned and will attempt to rejoin the cluster.
 571       </para>
 572       <para>
 573        A node usually gets banned due to real problems with the node.
 574        Don't set this value too small.  Otherwise, a problematic node
 575        will try to re-join cluster too soon causing unnecessary recoveries.
 576       </para>
 577     </refsect2>
 578
 579     <refsect2>
 580       <title>RecoveryDropAllIPs</title>
 581       <para>Default: 120</para>
 582       <para>
 583         If a node is stuck in recovery, or stopped, or banned, for this
 584         many seconds, then ctdb will release all public addresses on
 585         that node.
 586       </para>
 587     </refsect2>
 588
 589     <refsect2>
 590       <title>RecoveryGracePeriod</title>
 591       <para>Default: 120</para>
 592       <para>
 593        During recoveries, if a node has not caused recovery failures
 594        during the last grace period in seconds, any records of
 595        transgressions that the node has caused recovery failures will be
 596        forgiven. This resets the ban-counter back to zero for that node.
 597       </para>
 598     </refsect2>
 599
 600     <refsect2>
 601       <title>RepackLimit</title>
 602       <para>Default: 10000</para>
 603       <para>
 604         During vacuuming, if the number of freelist records are more than
 605         <varname>RepackLimit</varname>, then the database is repacked
 606         to get rid of the freelist records to avoid fragmentation.
 607       </para>
 608       <para>
 609         Databases are repacked only if both <varname>RepackLimit</varname>
 610         and <varname>VacuumLimit</varname> are exceeded.
 611       </para>
 612     </refsect2>
 613
 614     <refsect2>
 615       <title>RerecoveryTimeout</title>
 616       <para>Default: 10</para>
 617       <para>
 618         Once a recovery has completed, no additional recoveries are
 619         permitted until this timeout in seconds has expired.
 620       </para>
 621     </refsect2>
 622
 623     <refsect2>
 624       <title>SeqnumInterval</title>
 625       <para>Default: 1000</para>
 626       <para>
 627         Some databases have seqnum tracking enabled, so that samba will
 628         be able to detect asynchronously when there has been updates
 629         to the database.  Every time a database is updated its sequence
 630         number is increased.
 631       </para>
 632       <para>
 633         This tunable is used to specify in milliseconds how frequently
 634         ctdb will send out updates to remote nodes to inform them that
 635         the sequence number is increased.
 636       </para>
 637     </refsect2>
 638
 639     <refsect2>
 640       <title>StatHistoryInterval</title>
 641       <para>Default: 1</para>
 642       <para>
 643         Granularity of the statistics collected in the statistics
 644         history. This is reported by 'ctdb stats' command.
 645       </para>
 646     </refsect2>
 647
 648     <refsect2>
 649       <title>StickyDuration</title>
 650       <para>Default: 600</para>
 651       <para>
 652         Once a record has been marked STICKY, this is the duration in
 653         seconds, the record will be flagged as a STICKY record.
 654       </para>
 655     </refsect2>
 656
 657     <refsect2>
 658       <title>StickyPindown</title>
 659       <para>Default: 200</para>
 660       <para>
 661         Once a STICKY record has been migrated onto a node, it will be
 662         pinned down on that node for this number of milliseconds. Any
 663         request from other nodes to migrate the record off the node will
 664         be deferred.
 665       </para>
 666     </refsect2>
 667
 668     <refsect2>
 669       <title>TakeoverTimeout</title>
 670       <para>Default: 9</para>
 671       <para>
 672         This is the duration in seconds in which ctdb tries to complete IP
 673         failover.
 674       </para>
 675     </refsect2>
 676
 677     <refsect2>
 678       <title>TDBMutexEnabled</title>
 679       <para>Default: 1</para>
 680       <para>
 681         This parameter enables TDB_MUTEX_LOCKING feature on volatile
 682         databases if the robust mutexes are supported. This optimizes the
 683         record locking using robust mutexes and is much more efficient
 684         that using posix locks.
 685       </para>
 686     </refsect2>
 687
 688     <refsect2>
 689       <title>TickleUpdateInterval</title>
 690       <para>Default: 20</para>
 691       <para>
 692         Every <varname>TickleUpdateInterval</varname> seconds, ctdb
 693         synchronizes the client connection information across nodes.
 694       </para>
 695     </refsect2>
 696
 697     <refsect2>
 698       <title>TraverseTimeout</title>
 699       <para>Default: 20</para>
 700       <para>
 701         This is the duration in seconds for which a database traverse
 702         is allowed to run.  If the traverse does not complete during
 703         this interval, ctdb will abort the traverse.
 704       </para>
 705     </refsect2>
 706
 707     <refsect2>
 708       <title>VacuumFastPathCount</title>
 709       <para>Default: 60</para>
 710       <para>
 711        During a vacuuming run, ctdb usually processes only the records
 712        marked for deletion also called the fast path vacuuming. After
 713        finishing <varname>VacuumFastPathCount</varname> number of fast
 714        path vacuuming runs, ctdb will trigger a scan of complete database
 715        for any empty records that need to be deleted.
 716       </para>
 717     </refsect2>
 718
 719     <refsect2>
 720       <title>VacuumInterval</title>
 721       <para>Default: 10</para>
 722       <para>
 723         Periodic interval in seconds when vacuuming is triggered for
 724         volatile databases.
 725       </para>
 726     </refsect2>
 727
 728     <refsect2>
 729       <title>VacuumLimit</title>
 730       <para>Default: 5000</para>
 731       <para>
 732         During vacuuming, if the number of deleted records are more than
 733         <varname>VacuumLimit</varname>, then databases are repacked to
 734         avoid fragmentation.
 735       </para>
 736       <para>
 737         Databases are repacked only if both <varname>RepackLimit</varname>
 738         and <varname>VacuumLimit</varname> are exceeded.
 739       </para>
 740     </refsect2>
 741
 742     <refsect2>
 743       <title>VacuumMaxRunTime</title>
 744       <para>Default: 120</para>
 745       <para>
 746         The maximum time in seconds for which the vacuuming process is
 747         allowed to run.  If vacuuming process takes longer than this
 748         value, then the vacuuming process is terminated.
 749       </para>
 750     </refsect2>
 751
 752     <refsect2>
 753       <title>VerboseMemoryNames</title>
 754       <para>Default: 0</para>
 755       <para>
 756         When set to non-zero, ctdb assigns verbose names for some of
 757         the talloc allocated memory objects.  These names are visible
 758         in the talloc memory report generated by 'ctdb dumpmemory'.
 759       </para>
 760     </refsect2>
 761
 762   </refsect1>
 763
 764   <refsect1>
 765     <title>FILES></title>
 766
 767     <simplelist>
 768       <member><filename>/usr/local/etc/ctdb/ctdb.tunables</filename></member>
 769     </simplelist>
 770   </refsect1>
 771
 772   <refsect1>
 773     <title>SEE ALSO</title>
 774     <para>
 775       <citerefentry><refentrytitle>ctdb</refentrytitle>
 776       <manvolnum>1</manvolnum></citerefentry>,
 777
 778       <citerefentry><refentrytitle>ctdbd</refentrytitle>
 779       <manvolnum>1</manvolnum></citerefentry>,
 780
 781       <citerefentry><refentrytitle>ctdb.conf</refentrytitle>
 782       <manvolnum>5</manvolnum></citerefentry>,
 783
 784       <citerefentry><refentrytitle>ctdb</refentrytitle>
 785       <manvolnum>7</manvolnum></citerefentry>,
 786
 787       <ulink url="http://ctdb.samba.org/"/>
 788     </para>
 789   </refsect1>
 790
 791   <refentryinfo>
 792     <author>
 793       <contrib>
 794         This documentation was written by
 795         Ronnie Sahlberg,
 796         Amitay Isaacs,
 797         Martin Schwenke
 798       </contrib>
 799     </author>
 800
 801     <copyright>
 802       <year>2007</year>
 803       <holder>Andrew Tridgell</holder>
 804       <holder>Ronnie Sahlberg</holder>
 805     </copyright>
 806     <legalnotice>
 807       <para>
 808         This program is free software; you can redistribute it and/or
 809         modify it under the terms of the GNU General Public License as
 810         published by the Free Software Foundation; either version 3 of
 811         the License, or (at your option) any later version.
 812       </para>
 813       <para>
 814         This program is distributed in the hope that it will be
 815         useful, but WITHOUT ANY WARRANTY; without even the implied
 816         warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
 817         PURPOSE.  See the GNU General Public License for more details.
 818       </para>
 819       <para>
 820         You should have received a copy of the GNU General Public
 821         License along with this program; if not, see
 822         <ulink url="http://www.gnu.org/licenses"/>.
 823       </para>
 824     </legalnotice>
 825   </refentryinfo>
 826
 827 </refentry>