Будут ли pg_dump и pg_restore PostgreSQL влиять на буферный кеш и кеш файловой системы ядра?

Question

Могу ли я запросить информацию о поведении буферного кэша PostgreSQL во время pg_dump и pg_restore?

Как мы знаем, PostgreSQL имеет буферный кэш для кэширования последнего рабочего набора, и Linux также имеет свой кэш уровня файловой системы.

Когда мы используем pg_dump для резервного копирования базы данных, повлияет ли операция резервного копирования на буферный кэш PostgreSQL и системный файловый кеш?

А как насчет операции pg_restore?

Answer 1

Поскольку эти операции чтения или записи файлов на компьютере, они, несомненно, будут влиять на кэш файловой системы ядра, потенциально уничтожая некоторые ранее кэшированные данные.

То же самое верно для общего ресурса PostgreSQL буферы, хотя существует оптимизация, которая позволяет избежать перезаписи всех общих буферов во время большого последовательного сканирования: если таблица больше совместно используемых буферов больше четверти, будет использоваться кольцевой буфер размером 256 КБ, что исключит большую часть кэша.

См. Следующие цитаты из src/backend/access/heap/heapam.c и src/backend/storage/buffer/README:

    /*
     * If the table is large relative to NBuffers, use a bulk-read access
     * strategy and enable synchronized scanning (see syncscan.c).  Although
     * the thresholds for these features could be different, we make them the
     * same so that there are only two behaviors to tune rather than four.
     * (However, some callers need to be able to disable one or both of these
     * behaviors, independently of the size of the table; also there is a GUC
     * variable that can disable synchronized scanning.)
     *
     * Note that table_block_parallelscan_initialize has a very similar test;
     * if you change this, consider changing that one, too.
     */
    if (!RelationUsesLocalBuffers(scan->rs_base.rs_rd) &&
        scan->rs_nblocks > NBuffers / 4)
    {
        allow_strat = (scan->rs_base.rs_flags & SO_ALLOW_STRAT) != 0;
        allow_sync = (scan->rs_base.rs_flags & SO_ALLOW_SYNC) != 0;
    }
    else
        allow_strat = allow_sync = false;

For sequential scans, a 256KB ring is used. That's small enough to fit in L2
cache, which makes transferring pages from OS cache to shared buffer cache
efficient.  Even less would often be enough, but the ring must be big enough
to accommodate all pages in the scan that are pinned concurrently.  256KB
should also be enough to leave a small cache trail for other backends to
join in a synchronized seq scan.  If a ring buffer is dirtied and its LSN
updated, we would normally have to write and flush WAL before we could
re-use the buffer; in this case we instead discard the buffer from the ring
and (later) choose a replacement using the normal clock-sweep algorithm.
Hence this strategy works best for scans that are read-only (or at worst
update hint bits).  In a scan that modifies every page in the scan, like a
bulk UPDATE or DELETE, the buffers in the ring will always be dirtied and
the ring strategy effectively degrades to the normal strategy.

Как указывает README, эта стратегия вероятно, не очень эффективен для массовых записей.

Тем не менее, pg_dump или pg_restore повлияет на многие таблицы, поэтому вы можете ожидать, что он уничтожит значительную часть общих буферов.