Baoding-FenShuaJiang
/
Green_GoodERP18_FSJ_Standard
關注 1
收藏 0
Wiki 捐赠
gooderp18绿色标准版
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
目錄樹: 0f75e31513
分支列表 標籤
${ item.name }
建立分支 ${ searchTerm }
從 '0f75e31513'
${ noResults }
Green_GoodERP18_FSJ_Standard/PostgreSQL/doc/postgresql/html/routine-vacuuming.html

590 line
45KB
原始文件 Blame 歷史記錄 

  1. <?xml version="1.0" encoding="UTF-8" standalone="no"?>

  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>24.1. Routine Vacuuming</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /><link rel="prev" href="maintenance.html" title="Chapter 24. Routine Database Maintenance Tasks" /><link rel="next" href="routine-reindex.html" title="24.2. Routine Reindexing" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">24.1. Routine Vacuuming</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="maintenance.html" title="Chapter 24. Routine Database Maintenance Tasks">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="maintenance.html" title="Chapter 24. Routine Database Maintenance Tasks">Up</a></td><th width="60%" align="center">Chapter 24. Routine Database Maintenance Tasks</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 12.4 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="routine-reindex.html" title="24.2. Routine Reindexing">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="ROUTINE-VACUUMING"><div class="titlepage"><div><div><h2 class="title" style="clear: both">24.1. Routine Vacuuming</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="routine-vacuuming.html#VACUUM-BASICS">24.1.1. Vacuuming Basics</a></span></dt><dt><span class="sect2"><a href="routine-vacuuming.html#VACUUM-FOR-SPACE-RECOVERY">24.1.2. Recovering Disk Space</a></span></dt><dt><span class="sect2"><a href="routine-vacuuming.html#VACUUM-FOR-STATISTICS">24.1.3. Updating Planner Statistics</a></span></dt><dt><span class="sect2"><a href="routine-vacuuming.html#VACUUM-FOR-VISIBILITY-MAP">24.1.4. Updating the Visibility Map</a></span></dt><dt><span class="sect2"><a href="routine-vacuuming.html#VACUUM-FOR-WRAPAROUND">24.1.5. Preventing Transaction ID Wraparound Failures</a></span></dt><dt><span class="sect2"><a href="routine-vacuuming.html#AUTOVACUUM">24.1.6. The Autovacuum Daemon</a></span></dt></dl></div><a id="id-1.6.11.10.2" class="indexterm"></a><p>

  3.    <span class="productname">PostgreSQL</span> databases require periodic

  4.    maintenance known as <em class="firstterm">vacuuming</em>.  For many installations, it

  5.    is sufficient to let vacuuming be performed by the <em class="firstterm">autovacuum

  6.    daemon</em>, which is described in <a class="xref" href="routine-vacuuming.html#AUTOVACUUM" title="24.1.6. The Autovacuum Daemon">Section 24.1.6</a>.  You might

  7.    need to adjust the autovacuuming parameters described there to obtain best

  8.    results for your situation.  Some database administrators will want to

  9.    supplement or replace the daemon's activities with manually-managed

  10.    <code class="command">VACUUM</code> commands, which typically are executed according to a

  11.    schedule by <span class="application">cron</span> or <span class="application">Task

  12.    Scheduler</span> scripts.  To set up manually-managed vacuuming properly,

  13.    it is essential to understand the issues discussed in the next few

  14.    subsections.  Administrators who rely on autovacuuming may still wish

  15.    to skim this material to help them understand and adjust autovacuuming.

  16.   </p><div class="sect2" id="VACUUM-BASICS"><div class="titlepage"><div><div><h3 class="title">24.1.1. Vacuuming Basics</h3></div></div></div><p>

  17.     <span class="productname">PostgreSQL</span>'s

  18.     <a class="xref" href="sql-vacuum.html" title="VACUUM"><span class="refentrytitle">VACUUM</span></a> command has to

  19.     process each table on a regular basis for several reasons:

  20. 

  21.     </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">To recover or reuse disk space occupied by updated or deleted

  22.       rows.</li><li class="listitem">To update data statistics used by the

  23.       <span class="productname">PostgreSQL</span> query planner.</li><li class="listitem">To update the visibility map, which speeds

  24.       up <a class="link" href="indexes-index-only-scans.html" title="11.9. Index-Only Scans and Covering Indexes">index-only

  25.       scans</a>.</li><li class="listitem">To protect against loss of very old data due to

  26.       <em class="firstterm">transaction ID wraparound</em> or

  27.       <em class="firstterm">multixact ID wraparound</em>.</li></ol></div><p>

  28. 

  29.     Each of these reasons dictates performing <code class="command">VACUUM</code> operations

  30.     of varying frequency and scope, as explained in the following subsections.

  31.    </p><p>

  32.     There are two variants of <code class="command">VACUUM</code>: standard <code class="command">VACUUM</code>

  33.     and <code class="command">VACUUM FULL</code>.  <code class="command">VACUUM FULL</code> can reclaim more

  34.     disk space but runs much more slowly.  Also,

  35.     the standard form of <code class="command">VACUUM</code> can run in parallel with production

  36.     database operations.  (Commands such as <code class="command">SELECT</code>,

  37.     <code class="command">INSERT</code>, <code class="command">UPDATE</code>, and

  38.     <code class="command">DELETE</code> will continue to function normally, though you

  39.     will not be able to modify the definition of a table with commands such as

  40.     <code class="command">ALTER TABLE</code> while it is being vacuumed.)

  41.     <code class="command">VACUUM FULL</code> requires exclusive lock on the table it is

  42.     working on, and therefore cannot be done in parallel with other use

  43.     of the table.  Generally, therefore,

  44.     administrators should strive to use standard <code class="command">VACUUM</code> and

  45.     avoid <code class="command">VACUUM FULL</code>.

  46.    </p><p>

  47.     <code class="command">VACUUM</code> creates a substantial amount of I/O

  48.     traffic, which can cause poor performance for other active sessions.

  49.     There are configuration parameters that can be adjusted to reduce the

  50.     performance impact of background vacuuming — see

  51.     <a class="xref" href="runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST" title="19.4.4. Cost-based Vacuum Delay">Section 19.4.4</a>.

  52.    </p></div><div class="sect2" id="VACUUM-FOR-SPACE-RECOVERY"><div class="titlepage"><div><div><h3 class="title">24.1.2. Recovering Disk Space</h3></div></div></div><a id="id-1.6.11.10.5.2" class="indexterm"></a><p>

  53.     In <span class="productname">PostgreSQL</span>, an

  54.     <code class="command">UPDATE</code> or <code class="command">DELETE</code> of a row does not

  55.     immediately remove the old version of the row.

  56.     This approach is necessary to gain the benefits of multiversion

  57.     concurrency control (<acronym class="acronym">MVCC</acronym>, see <a class="xref" href="mvcc.html" title="Chapter 13. Concurrency Control">Chapter 13</a>): the row version

  58.     must not be deleted while it is still potentially visible to other

  59.     transactions. But eventually, an outdated or deleted row version is no

  60.     longer of interest to any transaction. The space it occupies must then be

  61.     reclaimed for reuse by new rows, to avoid unbounded growth of disk

  62.     space requirements. This is done by running <code class="command">VACUUM</code>.

  63.    </p><p>

  64.     The standard form of <code class="command">VACUUM</code> removes dead row

  65.     versions in tables and indexes and marks the space available for

  66.     future reuse.  However, it will not return the space to the operating

  67.     system, except in the special case where one or more pages at the

  68.     end of a table become entirely free and an exclusive table lock can be

  69.     easily obtained.  In contrast, <code class="command">VACUUM FULL</code> actively compacts

  70.     tables by writing a complete new version of the table file with no dead

  71.     space.  This minimizes the size of the table, but can take a long time.

  72.     It also requires extra disk space for the new copy of the table, until

  73.     the operation completes.

  74.    </p><p>

  75.     The usual goal of routine vacuuming is to do standard <code class="command">VACUUM</code>s

  76.     often enough to avoid needing <code class="command">VACUUM FULL</code>.  The

  77.     autovacuum daemon attempts to work this way, and in fact will

  78.     never issue <code class="command">VACUUM FULL</code>.  In this approach, the idea

  79.     is not to keep tables at their minimum size, but to maintain steady-state

  80.     usage of disk space: each table occupies space equivalent to its

  81.     minimum size plus however much space gets used up between vacuumings.

  82.     Although <code class="command">VACUUM FULL</code> can be used to shrink a table back

  83.     to its minimum size and return the disk space to the operating system,

  84.     there is not much point in this if the table will just grow again in the

  85.     future.  Thus, moderately-frequent standard <code class="command">VACUUM</code> runs are a

  86.     better approach than infrequent <code class="command">VACUUM FULL</code> runs for

  87.     maintaining heavily-updated tables.

  88.    </p><p>

  89.     Some administrators prefer to schedule vacuuming themselves, for example

  90.     doing all the work at night when load is low.

  91.     The difficulty with doing vacuuming according to a fixed schedule

  92.     is that if a table has an unexpected spike in update activity, it may

  93.     get bloated to the point that <code class="command">VACUUM FULL</code> is really necessary

  94.     to reclaim space.  Using the autovacuum daemon alleviates this problem,

  95.     since the daemon schedules vacuuming dynamically in response to update

  96.     activity.  It is unwise to disable the daemon completely unless you

  97.     have an extremely predictable workload.  One possible compromise is

  98.     to set the daemon's parameters so that it will only react to unusually

  99.     heavy update activity, thus keeping things from getting out of hand,

  100.     while scheduled <code class="command">VACUUM</code>s are expected to do the bulk of the

  101.     work when the load is typical.

  102.    </p><p>

  103.     For those not using autovacuum, a typical approach is to schedule a

  104.     database-wide <code class="command">VACUUM</code> once a day during a low-usage period,

  105.     supplemented by more frequent vacuuming of heavily-updated tables as

  106.     necessary. (Some installations with extremely high update rates vacuum

  107.     their busiest tables as often as once every few minutes.) If you have

  108.     multiple databases in a cluster, don't forget to

  109.     <code class="command">VACUUM</code> each one; the program <a class="xref" href="app-vacuumdb.html" title="vacuumdb"><span class="refentrytitle"><span class="application">vacuumdb</span></span></a> might be helpful.

  110.    </p><div class="tip"><h3 class="title">Tip</h3><p>

  111.     Plain <code class="command">VACUUM</code> may not be satisfactory when

  112.     a table contains large numbers of dead row versions as a result of

  113.     massive update or delete activity.  If you have such a table and

  114.     you need to reclaim the excess disk space it occupies, you will need

  115.     to use <code class="command">VACUUM FULL</code>, or alternatively

  116.     <a class="xref" href="sql-cluster.html" title="CLUSTER"><span class="refentrytitle">CLUSTER</span></a>

  117.     or one of the table-rewriting variants of

  118.     <a class="xref" href="sql-altertable.html" title="ALTER TABLE"><span class="refentrytitle">ALTER TABLE</span></a>.

  119.     These commands rewrite an entire new copy of the table and build

  120.     new indexes for it.  All these options require exclusive lock.  Note that

  121.     they also temporarily use extra disk space approximately equal to the size

  122.     of the table, since the old copies of the table and indexes can't be

  123.     released until the new ones are complete.

  124.    </p></div><div class="tip"><h3 class="title">Tip</h3><p>

  125.     If you have a table whose entire contents are deleted on a periodic

  126.     basis, consider doing it with

  127.     <a class="xref" href="sql-truncate.html" title="TRUNCATE"><span class="refentrytitle">TRUNCATE</span></a> rather

  128.     than using <code class="command">DELETE</code> followed by

  129.     <code class="command">VACUUM</code>. <code class="command">TRUNCATE</code> removes the

  130.     entire content of the table immediately, without requiring a

  131.     subsequent <code class="command">VACUUM</code> or <code class="command">VACUUM

  132.     FULL</code> to reclaim the now-unused disk space.

  133.     The disadvantage is that strict MVCC semantics are violated.

  134.    </p></div></div><div class="sect2" id="VACUUM-FOR-STATISTICS"><div class="titlepage"><div><div><h3 class="title">24.1.3. Updating Planner Statistics</h3></div></div></div><a id="id-1.6.11.10.6.2" class="indexterm"></a><a id="id-1.6.11.10.6.3" class="indexterm"></a><p>

  135.     The <span class="productname">PostgreSQL</span> query planner relies on

  136.     statistical information about the contents of tables in order to

  137.     generate good plans for queries.  These statistics are gathered by

  138.     the <a class="xref" href="sql-analyze.html" title="ANALYZE"><span class="refentrytitle">ANALYZE</span></a> command,

  139.     which can be invoked by itself or

  140.     as an optional step in <code class="command">VACUUM</code>.  It is important to have

  141.     reasonably accurate statistics, otherwise poor choices of plans might

  142.     degrade database performance.

  143.    </p><p>

  144.     The autovacuum daemon, if enabled, will automatically issue

  145.     <code class="command">ANALYZE</code> commands whenever the content of a table has

  146.     changed sufficiently.  However, administrators might prefer to rely

  147.     on manually-scheduled <code class="command">ANALYZE</code> operations, particularly

  148.     if it is known that update activity on a table will not affect the

  149.     statistics of <span class="quote">“<span class="quote">interesting</span>”</span> columns.  The daemon schedules

  150.     <code class="command">ANALYZE</code> strictly as a function of the number of rows

  151.     inserted or updated; it has no knowledge of whether that will lead

  152.     to meaningful statistical changes.

  153.    </p><p>

  154.     As with vacuuming for space recovery, frequent updates of statistics

  155.     are more useful for heavily-updated tables than for seldom-updated

  156.     ones. But even for a heavily-updated table, there might be no need for

  157.     statistics updates if the statistical distribution of the data is

  158.     not changing much. A simple rule of thumb is to think about how much

  159.     the minimum and maximum values of the columns in the table change.

  160.     For example, a <code class="type">timestamp</code> column that contains the time

  161.     of row update will have a constantly-increasing maximum value as

  162.     rows are added and updated; such a column will probably need more

  163.     frequent statistics updates than, say, a column containing URLs for

  164.     pages accessed on a website. The URL column might receive changes just

  165.     as often, but the statistical distribution of its values probably

  166.     changes relatively slowly.

  167.    </p><p>

  168.     It is possible to run <code class="command">ANALYZE</code> on specific tables and even

  169.     just specific columns of a table, so the flexibility exists to update some

  170.     statistics more frequently than others if your application requires it.

  171.     In practice, however, it is usually best to just analyze the entire

  172.     database, because it is a fast operation.  <code class="command">ANALYZE</code> uses a

  173.     statistically random sampling of the rows of a table rather than reading

  174.     every single row.

  175.    </p><div class="tip"><h3 class="title">Tip</h3><p>

  176.      Although per-column tweaking of <code class="command">ANALYZE</code> frequency might not be

  177.      very productive, you might find it worthwhile to do per-column

  178.      adjustment of the level of detail of the statistics collected by

  179.      <code class="command">ANALYZE</code>.  Columns that are heavily used in <code class="literal">WHERE</code>

  180.      clauses and have highly irregular data distributions might require a

  181.      finer-grain data histogram than other columns.  See <code class="command">ALTER TABLE

  182.      SET STATISTICS</code>, or change the database-wide default using the <a class="xref" href="runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET">default_statistics_target</a> configuration parameter.

  183.     </p><p>

  184.      Also, by default there is limited information available about

  185.      the selectivity of functions.  However, if you create an expression

  186.      index that uses a function call, useful statistics will be

  187.      gathered about the function, which can greatly improve query

  188.      plans that use the expression index.

  189.     </p></div><div class="tip"><h3 class="title">Tip</h3><p>

  190.      The autovacuum daemon does not issue <code class="command">ANALYZE</code> commands for

  191.      foreign tables, since it has no means of determining how often that

  192.      might be useful.  If your queries require statistics on foreign tables

  193.      for proper planning, it's a good idea to run manually-managed

  194.      <code class="command">ANALYZE</code> commands on those tables on a suitable schedule.

  195.     </p></div></div><div class="sect2" id="VACUUM-FOR-VISIBILITY-MAP"><div class="titlepage"><div><div><h3 class="title">24.1.4. Updating the Visibility Map</h3></div></div></div><p>

  196.     Vacuum maintains a <a class="link" href="storage-vm.html" title="68.4. Visibility Map">visibility map</a> for each

  197.     table to keep track of which pages contain only tuples that are known to be

  198.     visible to all active transactions (and all future transactions, until the

  199.     page is again modified).  This has two purposes.  First, vacuum

  200.     itself can skip such pages on the next run, since there is nothing to

  201.     clean up.

  202.    </p><p>

  203.     Second, it allows <span class="productname">PostgreSQL</span> to answer some

  204.     queries using only the index, without reference to the underlying table.

  205.     Since <span class="productname">PostgreSQL</span> indexes don't contain tuple

  206.     visibility information, a normal index scan fetches the heap tuple for each

  207.     matching index entry, to check whether it should be seen by the current

  208.     transaction.

  209.     An <a class="link" href="indexes-index-only-scans.html" title="11.9. Index-Only Scans and Covering Indexes"><em class="firstterm">index-only

  210.     scan</em></a>, on the other hand, checks the visibility map first.

  211.     If it's known that all tuples on the page are

  212.     visible, the heap fetch can be skipped.  This is most useful on

  213.     large data sets where the visibility map can prevent disk accesses.

  214.     The visibility map is vastly smaller than the heap, so it can easily be

  215.     cached even when the heap is very large.

  216.    </p></div><div class="sect2" id="VACUUM-FOR-WRAPAROUND"><div class="titlepage"><div><div><h3 class="title">24.1.5. Preventing Transaction ID Wraparound Failures</h3></div></div></div><a id="id-1.6.11.10.8.2" class="indexterm"></a><a id="id-1.6.11.10.8.3" class="indexterm"></a><p>

  217.     <span class="productname">PostgreSQL</span>'s

  218.     <a class="link" href="mvcc-intro.html" title="13.1. Introduction">MVCC</a> transaction semantics

  219.     depend on being able to compare transaction ID (<acronym class="acronym">XID</acronym>)

  220.     numbers: a row version with an insertion XID greater than the current

  221.     transaction's XID is <span class="quote">“<span class="quote">in the future</span>”</span> and should not be visible

  222.     to the current transaction.  But since transaction IDs have limited size

  223.     (32 bits) a cluster that runs for a long time (more

  224.     than 4 billion transactions) would suffer <em class="firstterm">transaction ID

  225.     wraparound</em>: the XID counter wraps around to zero, and all of a sudden

  226.     transactions that were in the past appear to be in the future — which

  227.     means their output become invisible.  In short, catastrophic data loss.

  228.     (Actually the data is still there, but that's cold comfort if you cannot

  229.     get at it.)  To avoid this, it is necessary to vacuum every table

  230.     in every database at least once every two billion transactions.

  231.    </p><p>

  232.     The reason that periodic vacuuming solves the problem is that

  233.     <code class="command">VACUUM</code> will mark rows as <span class="emphasis"><em>frozen</em></span>, indicating that

  234.     they were inserted by a transaction that committed sufficiently far in

  235.     the past that the effects of the inserting transaction are certain to be

  236.     visible to all current and future transactions.

  237.     Normal XIDs are

  238.     compared using modulo-2<sup>32</sup> arithmetic. This means

  239.     that for every normal XID, there are two billion XIDs that are

  240.     <span class="quote">“<span class="quote">older</span>”</span> and two billion that are <span class="quote">“<span class="quote">newer</span>”</span>; another

  241.     way to say it is that the normal XID space is circular with no

  242.     endpoint. Therefore, once a row version has been created with a particular

  243.     normal XID, the row version will appear to be <span class="quote">“<span class="quote">in the past</span>”</span> for

  244.     the next two billion transactions, no matter which normal XID we are

  245.     talking about. If the row version still exists after more than two billion

  246.     transactions, it will suddenly appear to be in the future. To

  247.     prevent this, <span class="productname">PostgreSQL</span> reserves a special XID,

  248.     <code class="literal">FrozenTransactionId</code>, which does not follow the normal XID

  249.     comparison rules and is always considered older

  250.     than every normal XID.

  251.     Frozen row versions are treated as if the inserting XID were

  252.     <code class="literal">FrozenTransactionId</code>, so that they will appear to be

  253.     <span class="quote">“<span class="quote">in the past</span>”</span> to all normal transactions regardless of wraparound

  254.     issues, and so such row versions will be valid until deleted, no matter

  255.     how long that is.

  256.    </p><div class="note"><h3 class="title">Note</h3><p>

  257.      In <span class="productname">PostgreSQL</span> versions before 9.4, freezing was

  258.      implemented by actually replacing a row's insertion XID

  259.      with <code class="literal">FrozenTransactionId</code>, which was visible in the

  260.      row's <code class="structname">xmin</code> system column.  Newer versions just set a flag

  261.      bit, preserving the row's original <code class="structname">xmin</code> for possible

  262.      forensic use.  However, rows with <code class="structname">xmin</code> equal

  263.      to <code class="literal">FrozenTransactionId</code> (2) may still be found

  264.      in databases <span class="application">pg_upgrade</span>'d from pre-9.4 versions.

  265.     </p><p>

  266.      Also, system catalogs may contain rows with <code class="structname">xmin</code> equal

  267.      to <code class="literal">BootstrapTransactionId</code> (1), indicating that they were

  268.      inserted during the first phase of <span class="application">initdb</span>.

  269.      Like <code class="literal">FrozenTransactionId</code>, this special XID is treated as

  270.      older than every normal XID.

  271.     </p></div><p>

  272.     <a class="xref" href="runtime-config-client.html#GUC-VACUUM-FREEZE-MIN-AGE">vacuum_freeze_min_age</a>

  273.     controls how old an XID value has to be before rows bearing that XID will be

  274.     frozen.  Increasing this setting may avoid unnecessary work if the

  275.     rows that would otherwise be frozen will soon be modified again,

  276.     but decreasing this setting increases

  277.     the number of transactions that can elapse before the table must be

  278.     vacuumed again.

  279.    </p><p>

  280.     <code class="command">VACUUM</code> uses the <a class="link" href="storage-vm.html" title="68.4. Visibility Map">visibility map</a>

  281.     to determine which pages of a table must be scanned.  Normally, it

  282.     will skip pages that don't have any dead row versions even if those pages

  283.     might still have row versions with old XID values.  Therefore, normal

  284.     <code class="command">VACUUM</code>s won't always freeze every old row version in the table.

  285.     Periodically, <code class="command">VACUUM</code> will perform an <em class="firstterm">aggressive

  286.     vacuum</em>, skipping only those pages which contain neither dead rows nor

  287.     any unfrozen XID or MXID values.

  288.     <a class="xref" href="runtime-config-client.html#GUC-VACUUM-FREEZE-TABLE-AGE">vacuum_freeze_table_age</a>

  289.     controls when <code class="command">VACUUM</code> does that: all-visible but not all-frozen

  290.     pages are scanned if the number of transactions that have passed since the

  291.     last such scan is greater than <code class="varname">vacuum_freeze_table_age</code> minus

  292.     <code class="varname">vacuum_freeze_min_age</code>. Setting

  293.     <code class="varname">vacuum_freeze_table_age</code> to 0 forces <code class="command">VACUUM</code> to

  294.     use this more aggressive strategy for all scans.

  295.    </p><p>

  296.     The maximum time that a table can go unvacuumed is two billion

  297.     transactions minus the <code class="varname">vacuum_freeze_min_age</code> value at

  298.     the time of the last aggressive vacuum. If it were to go

  299.     unvacuumed for longer than

  300.     that, data loss could result.  To ensure that this does not happen,

  301.     autovacuum is invoked on any table that might contain unfrozen rows with

  302.     XIDs older than the age specified by the configuration parameter <a class="xref" href="runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE">autovacuum_freeze_max_age</a>.  (This will happen even if

  303.     autovacuum is disabled.)

  304.    </p><p>

  305.     This implies that if a table is not otherwise vacuumed,

  306.     autovacuum will be invoked on it approximately once every

  307.     <code class="varname">autovacuum_freeze_max_age</code> minus

  308.     <code class="varname">vacuum_freeze_min_age</code> transactions.

  309.     For tables that are regularly vacuumed for space reclamation purposes,

  310.     this is of little importance.  However, for static tables

  311.     (including tables that receive inserts, but no updates or deletes),

  312.     there is no need to vacuum for space reclamation, so it can

  313.     be useful to try to maximize the interval between forced autovacuums

  314.     on very large static tables.  Obviously one can do this either by

  315.     increasing <code class="varname">autovacuum_freeze_max_age</code> or decreasing

  316.     <code class="varname">vacuum_freeze_min_age</code>.

  317.    </p><p>

  318.     The effective maximum for <code class="varname">vacuum_freeze_table_age</code> is 0.95 *

  319.     <code class="varname">autovacuum_freeze_max_age</code>; a setting higher than that will be

  320.     capped to the maximum. A value higher than

  321.     <code class="varname">autovacuum_freeze_max_age</code> wouldn't make sense because an

  322.     anti-wraparound autovacuum would be triggered at that point anyway, and

  323.     the 0.95 multiplier leaves some breathing room to run a manual

  324.     <code class="command">VACUUM</code> before that happens.  As a rule of thumb,

  325.     <code class="command">vacuum_freeze_table_age</code> should be set to a value somewhat

  326.     below <code class="varname">autovacuum_freeze_max_age</code>, leaving enough gap so that

  327.     a regularly scheduled <code class="command">VACUUM</code> or an autovacuum triggered by

  328.     normal delete and update activity is run in that window.  Setting it too

  329.     close could lead to anti-wraparound autovacuums, even though the table

  330.     was recently vacuumed to reclaim space, whereas lower values lead to more

  331.     frequent aggressive vacuuming.

  332.    </p><p>

  333.     The sole disadvantage of increasing <code class="varname">autovacuum_freeze_max_age</code>

  334.     (and <code class="varname">vacuum_freeze_table_age</code> along with it) is that

  335.     the <code class="filename">pg_xact</code> and <code class="filename">pg_commit_ts</code>

  336.     subdirectories of the database cluster will take more space, because it

  337.     must store the commit status and (if <code class="varname">track_commit_timestamp</code> is

  338.     enabled) timestamp of all transactions back to

  339.     the <code class="varname">autovacuum_freeze_max_age</code> horizon.  The commit status uses

  340.     two bits per transaction, so if

  341.     <code class="varname">autovacuum_freeze_max_age</code> is set to its maximum allowed value

  342.     of two billion, <code class="filename">pg_xact</code> can be expected to grow to about half

  343.     a gigabyte and <code class="filename">pg_commit_ts</code> to about 20GB.  If this

  344.     is trivial compared to your total database size,

  345.     setting <code class="varname">autovacuum_freeze_max_age</code> to its maximum allowed value

  346.     is recommended.  Otherwise, set it depending on what you are willing to

  347.     allow for <code class="filename">pg_xact</code> and <code class="filename">pg_commit_ts</code> storage.

  348.     (The default, 200 million transactions, translates to about 50MB

  349.     of <code class="filename">pg_xact</code> storage and about 2GB of <code class="filename">pg_commit_ts</code>

  350.     storage.)

  351.    </p><p>

  352.     One disadvantage of decreasing <code class="varname">vacuum_freeze_min_age</code> is that

  353.     it might cause <code class="command">VACUUM</code> to do useless work: freezing a row

  354.     version is a waste of time if the row is modified

  355.     soon thereafter (causing it to acquire a new XID).  So the setting should

  356.     be large enough that rows are not frozen until they are unlikely to change

  357.     any more.

  358.    </p><p>

  359.     To track the age of the oldest unfrozen XIDs in a database,

  360.     <code class="command">VACUUM</code> stores XID

  361.     statistics in the system tables <code class="structname">pg_class</code> and

  362.     <code class="structname">pg_database</code>.  In particular,

  363.     the <code class="structfield">relfrozenxid</code> column of a table's

  364.     <code class="structname">pg_class</code> row contains the freeze cutoff XID that was used

  365.     by the last aggressive <code class="command">VACUUM</code> for that table.  All rows

  366.     inserted by transactions with XIDs older than this cutoff XID are

  367.     guaranteed to have been frozen.  Similarly,

  368.     the <code class="structfield">datfrozenxid</code> column of a database's

  369.     <code class="structname">pg_database</code> row is a lower bound on the unfrozen XIDs

  370.     appearing in that database — it is just the minimum of the

  371.     per-table <code class="structfield">relfrozenxid</code> values within the database.

  372.     A convenient way to

  373.     examine this information is to execute queries such as:

  374. 

  375. </p><pre class="programlisting">

  376. SELECT c.oid::regclass as table_name,

  377.        greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age

  378. FROM pg_class c

  379. LEFT JOIN pg_class t ON c.reltoastrelid = t.oid

  380. WHERE c.relkind IN ('r', 'm');

  381. 

  382. SELECT datname, age(datfrozenxid) FROM pg_database;

  383. </pre><p>

  384. 

  385.     The <code class="literal">age</code> column measures the number of transactions from the

  386.     cutoff XID to the current transaction's XID.

  387.    </p><p>

  388.     <code class="command">VACUUM</code> normally only scans pages that have been modified

  389.     since the last vacuum, but <code class="structfield">relfrozenxid</code> can only be

  390.     advanced when every page of the table

  391.     that might contain unfrozen XIDs is scanned.  This happens when

  392.     <code class="structfield">relfrozenxid</code> is more than

  393.     <code class="varname">vacuum_freeze_table_age</code> transactions old, when

  394.     <code class="command">VACUUM</code>'s <code class="literal">FREEZE</code> option is used, or when all

  395.     pages that are not already all-frozen happen to

  396.     require vacuuming to remove dead row versions. When <code class="command">VACUUM</code>

  397.     scans every page in the table that is not already all-frozen, it should

  398.     set <code class="literal">age(relfrozenxid)</code> to a value just a little more than the

  399.     <code class="varname">vacuum_freeze_min_age</code> setting

  400.     that was used (more by the number of transactions started since the

  401.     <code class="command">VACUUM</code> started).  If no <code class="structfield">relfrozenxid</code>-advancing

  402.     <code class="command">VACUUM</code> is issued on the table until

  403.     <code class="varname">autovacuum_freeze_max_age</code> is reached, an autovacuum will soon

  404.     be forced for the table.

  405.    </p><p>

  406.     If for some reason autovacuum fails to clear old XIDs from a table, the

  407.     system will begin to emit warning messages like this when the database's

  408.     oldest XIDs reach eleven million transactions from the wraparound point:

  409. 

  410. </p><pre class="programlisting">

  411. WARNING:  database "mydb" must be vacuumed within 10985967 transactions

  412. HINT:  To avoid a database shutdown, execute a database-wide VACUUM in that database.

  413. </pre><p>

  414. 

  415.     (A manual <code class="command">VACUUM</code> should fix the problem, as suggested by the

  416.     hint; but note that the <code class="command">VACUUM</code> must be performed by a

  417.     superuser, else it will fail to process system catalogs and thus not

  418.     be able to advance the database's <code class="structfield">datfrozenxid</code>.)

  419.     If these warnings are

  420.     ignored, the system will shut down and refuse to start any new

  421.     transactions once there are fewer than 1 million transactions left

  422.     until wraparound:

  423. 

  424. </p><pre class="programlisting">

  425. ERROR:  database is not accepting commands to avoid wraparound data loss in database "mydb"

  426. HINT:  Stop the postmaster and vacuum that database in single-user mode.

  427. </pre><p>

  428. 

  429.     The 1-million-transaction safety margin exists to let the

  430.     administrator recover without data loss, by manually executing the

  431.     required <code class="command">VACUUM</code> commands.  However, since the system will not

  432.     execute commands once it has gone into the safety shutdown mode,

  433.     the only way to do this is to stop the server and start the server in single-user

  434.     mode to execute <code class="command">VACUUM</code>.  The shutdown mode is not enforced

  435.     in single-user mode.  See the <a class="xref" href="app-postgres.html" title="postgres"><span class="refentrytitle"><span class="application">postgres</span></span></a> reference

  436.     page for details about using single-user mode.

  437.    </p><div class="sect3" id="VACUUM-FOR-MULTIXACT-WRAPAROUND"><div class="titlepage"><div><div><h4 class="title">24.1.5.1. Multixacts and Wraparound</h4></div></div></div><a id="id-1.6.11.10.8.17.2" class="indexterm"></a><a id="id-1.6.11.10.8.17.3" class="indexterm"></a><p>

  438.      <em class="firstterm">Multixact IDs</em> are used to support row locking by

  439.      multiple transactions.  Since there is only limited space in a tuple

  440.      header to store lock information, that information is encoded as

  441.      a <span class="quote">“<span class="quote">multiple transaction ID</span>”</span>, or multixact ID for short,

  442.      whenever there is more than one transaction concurrently locking a

  443.      row.  Information about which transaction IDs are included in any

  444.      particular multixact ID is stored separately in

  445.      the <code class="filename">pg_multixact</code> subdirectory, and only the multixact ID

  446.      appears in the <code class="structfield">xmax</code> field in the tuple header.

  447.      Like transaction IDs, multixact IDs are implemented as a

  448.      32-bit counter and corresponding storage, all of which requires

  449.      careful aging management, storage cleanup, and wraparound handling.

  450.      There is a separate storage area which holds the list of members in

  451.      each multixact, which also uses a 32-bit counter and which must also

  452.      be managed.

  453.     </p><p>

  454.      Whenever <code class="command">VACUUM</code> scans any part of a table, it will replace

  455.      any multixact ID it encounters which is older than

  456.      <a class="xref" href="runtime-config-client.html#GUC-VACUUM-MULTIXACT-FREEZE-MIN-AGE">vacuum_multixact_freeze_min_age</a>

  457.      by a different value, which can be the zero value, a single

  458.      transaction ID, or a newer multixact ID.  For each table,

  459.      <code class="structname">pg_class</code>.<code class="structfield">relminmxid</code> stores the oldest

  460.      possible multixact ID still appearing in any tuple of that table.

  461.      If this value is older than

  462.      <a class="xref" href="runtime-config-client.html#GUC-VACUUM-MULTIXACT-FREEZE-TABLE-AGE">vacuum_multixact_freeze_table_age</a>, an aggressive

  463.      vacuum is forced.  As discussed in the previous section, an aggressive

  464.      vacuum means that only those pages which are known to be all-frozen will

  465.      be skipped.  <code class="function">mxid_age()</code> can be used on

  466.      <code class="structname">pg_class</code>.<code class="structfield">relminmxid</code> to find its age.

  467.     </p><p>

  468.      Aggressive <code class="command">VACUUM</code> scans, regardless of

  469.      what causes them, enable advancing the value for that table.

  470.      Eventually, as all tables in all databases are scanned and their

  471.      oldest multixact values are advanced, on-disk storage for older

  472.      multixacts can be removed.

  473.     </p><p>

  474.      As a safety device, an aggressive vacuum scan will occur for any table

  475.      whose multixact-age is greater than

  476.      <a class="xref" href="runtime-config-autovacuum.html#GUC-AUTOVACUUM-MULTIXACT-FREEZE-MAX-AGE">autovacuum_multixact_freeze_max_age</a>.  Aggressive

  477.      vacuum scans will also occur progressively for all tables, starting with

  478.      those that have the oldest multixact-age, if the amount of used member

  479.      storage space exceeds the amount 50% of the addressable storage space.

  480.      Both of these kinds of aggressive scans will occur even if autovacuum is

  481.      nominally disabled.

  482.     </p></div></div><div class="sect2" id="AUTOVACUUM"><div class="titlepage"><div><div><h3 class="title">24.1.6. The Autovacuum Daemon</h3></div></div></div><a id="id-1.6.11.10.9.2" class="indexterm"></a><p>

  483.     <span class="productname">PostgreSQL</span> has an optional but highly

  484.     recommended feature called <em class="firstterm">autovacuum</em>,

  485.     whose purpose is to automate the execution of

  486.     <code class="command">VACUUM</code> and <code class="command">ANALYZE </code> commands.

  487.     When enabled, autovacuum checks for

  488.     tables that have had a large number of inserted, updated or deleted

  489.     tuples.  These checks use the statistics collection facility;

  490.     therefore, autovacuum cannot be used unless <a class="xref" href="runtime-config-statistics.html#GUC-TRACK-COUNTS">track_counts</a> is set to <code class="literal">true</code>.

  491.     In the default configuration, autovacuuming is enabled and the related

  492.     configuration parameters are appropriately set.

  493.    </p><p>

  494.     The <span class="quote">“<span class="quote">autovacuum daemon</span>”</span> actually consists of multiple processes.

  495.     There is a persistent daemon process, called the

  496.     <em class="firstterm">autovacuum launcher</em>, which is in charge of starting

  497.     <em class="firstterm">autovacuum worker</em> processes for all databases. The

  498.     launcher will distribute the work across time, attempting to start one

  499.     worker within each database every <a class="xref" href="runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME">autovacuum_naptime</a>

  500.     seconds.  (Therefore, if the installation has <em class="replaceable"><code>N</code></em> databases,

  501.     a new worker will be launched every

  502.     <code class="varname">autovacuum_naptime</code>/<em class="replaceable"><code>N</code></em> seconds.)

  503.     A maximum of <a class="xref" href="runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS">autovacuum_max_workers</a> worker processes

  504.     are allowed to run at the same time. If there are more than

  505.     <code class="varname">autovacuum_max_workers</code> databases to be processed,

  506.     the next database will be processed as soon as the first worker finishes.

  507.     Each worker process will check each table within its database and

  508.     execute <code class="command">VACUUM</code> and/or <code class="command">ANALYZE</code> as needed.

  509.     <a class="xref" href="runtime-config-autovacuum.html#GUC-LOG-AUTOVACUUM-MIN-DURATION">log_autovacuum_min_duration</a> can be set to monitor

  510.     autovacuum workers' activity.

  511.    </p><p>

  512.     If several large tables all become eligible for vacuuming in a short

  513.     amount of time, all autovacuum workers might become occupied with

  514.     vacuuming those tables for a long period.  This would result

  515.     in other tables and databases not being vacuumed until a worker becomes

  516.     available. There is no limit on how many workers might be in a

  517.     single database, but workers do try to avoid repeating work that has

  518.     already been done by other workers. Note that the number of running

  519.     workers does not count towards <a class="xref" href="runtime-config-connection.html#GUC-MAX-CONNECTIONS">max_connections</a> or

  520.     <a class="xref" href="runtime-config-connection.html#GUC-SUPERUSER-RESERVED-CONNECTIONS">superuser_reserved_connections</a> limits.

  521.    </p><p>

  522.     Tables whose <code class="structfield">relfrozenxid</code> value is more than

  523.     <a class="xref" href="runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE">autovacuum_freeze_max_age</a> transactions old are always

  524.     vacuumed (this also applies to those tables whose freeze max age has

  525.     been modified via storage parameters; see below).  Otherwise, if the

  526.     number of tuples obsoleted since the last

  527.     <code class="command">VACUUM</code> exceeds the <span class="quote">“<span class="quote">vacuum threshold</span>”</span>, the

  528.     table is vacuumed.  The vacuum threshold is defined as:

  529. </p><pre class="programlisting">

  530. vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples

  531. </pre><p>

  532.     where the vacuum base threshold is

  533.     <a class="xref" href="runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-THRESHOLD">autovacuum_vacuum_threshold</a>,

  534.     the vacuum scale factor is

  535.     <a class="xref" href="runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-SCALE-FACTOR">autovacuum_vacuum_scale_factor</a>,

  536.     and the number of tuples is

  537.     <code class="structname">pg_class</code>.<code class="structfield">reltuples</code>.

  538.     The number of obsolete tuples is obtained from the statistics

  539.     collector; it is a semi-accurate count updated by each

  540.     <code class="command">UPDATE</code> and <code class="command">DELETE</code> operation.  (It

  541.     is only semi-accurate because some information might be lost under heavy

  542.     load.)  If the <code class="structfield">relfrozenxid</code> value of the table is more

  543.     than <code class="varname">vacuum_freeze_table_age</code> transactions old, an aggressive

  544.     vacuum is performed to freeze old tuples and advance

  545.     <code class="structfield">relfrozenxid</code>; otherwise, only pages that have been modified

  546.     since the last vacuum are scanned.

  547.    </p><p>

  548.     For analyze, a similar condition is used: the threshold, defined as:

  549. </p><pre class="programlisting">

  550. analyze threshold = analyze base threshold + analyze scale factor * number of tuples

  551. </pre><p>

  552.     is compared to the total number of tuples inserted, updated, or deleted

  553.     since the last <code class="command">ANALYZE</code>.

  554.    </p><p>

  555.     Temporary tables cannot be accessed by autovacuum.  Therefore,

  556.     appropriate vacuum and analyze operations should be performed via

  557.     session SQL commands.

  558.    </p><p>

  559.     The default thresholds and scale factors are taken from

  560.     <code class="filename">postgresql.conf</code>, but it is possible to override them

  561.     (and many other autovacuum control parameters) on a per-table basis; see

  562.     <a class="xref" href="sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS" title="Storage Parameters">Storage Parameters</a> for more information.

  563.     If a setting has been changed via a table's storage parameters, that value

  564.     is used when processing that table; otherwise the global settings are

  565.     used. See <a class="xref" href="runtime-config-autovacuum.html" title="19.10. Automatic Vacuuming">Section 19.10</a> for more details on

  566.     the global settings.

  567.    </p><p>

  568.     When multiple workers are running, the autovacuum cost delay parameters

  569.     (see <a class="xref" href="runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST" title="19.4.4. Cost-based Vacuum Delay">Section 19.4.4</a>) are

  570.     <span class="quote">“<span class="quote">balanced</span>”</span> among all the running workers, so that the

  571.     total I/O impact on the system is the same regardless of the number

  572.     of workers actually running.  However, any workers processing tables whose

  573.     per-table <code class="literal">autovacuum_vacuum_cost_delay</code> or

  574.     <code class="literal">autovacuum_vacuum_cost_limit</code> storage parameters have been set

  575.     are not considered in the balancing algorithm.

  576.    </p><p>

  577.     Autovacuum workers generally don't block other commands.  If a process

  578.     attempts to acquire a lock that conflicts with the

  579.     <code class="literal">SHARE UPDATE EXCLUSIVE</code> lock held by autovacuum, lock

  580.     acquisition will interrupt the autovacuum.  For conflicting lock modes,

  581.     see <a class="xref" href="explicit-locking.html#TABLE-LOCK-COMPATIBILITY" title="Table 13.2.  Conflicting Lock Modes">Table 13.2</a>.  However, if the autovacuum

  582.     is running to prevent transaction ID wraparound (i.e., the autovacuum query

  583.     name in the <code class="structname">pg_stat_activity</code> view ends with

  584.     <code class="literal">(to prevent wraparound)</code>), the autovacuum is not

  585.     automatically interrupted.

  586.    </p><div class="warning"><h3 class="title">Warning</h3><p>

  587.      Regularly running commands that acquire locks conflicting with a

  588.      <code class="literal">SHARE UPDATE EXCLUSIVE</code> lock (e.g., ANALYZE) can

  589.      effectively prevent autovacuums from ever completing.

  590.     </p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="maintenance.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="maintenance.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="routine-reindex.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 24. Routine Database Maintenance Tasks </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 24.2. Routine Reindexing</td></tr></table></div></body></html>
上海开阖软件有限公司 沪ICP备12045867号-1