PostgreSQL内存结构详解 - 摩柯技术社区

共享内存

PostgreSQL使用共享内存来存储多个后端进程间共享的数据结构。共享内存的管理对于系统的稳定性和性能至关重要。

共享内存的用途

缓冲区高速缓存（Buffer Cache）：这是共享内存中最重要的部分之一。它用于缓存磁盘上的数据块。当一个后端进程需要访问数据库中的数据时，首先会在缓冲区高速缓存中查找。如果数据块已经在缓存中（缓存命中），则直接从缓存中读取，避免了磁盘I/O操作，大大提高了访问速度。例如，在一个频繁读取表数据的查询中，如果相关的数据块能够在缓冲区高速缓存中命中，响应时间会显著缩短。
事务状态信息：共享内存存储了当前活跃事务的状态。这包括事务的开始时间、事务ID、事务的当前阶段（例如，是否处于准备提交阶段等）。通过这些信息，PostgreSQL可以确保事务的原子性、一致性、隔离性和持久性（ACID特性）。例如，在并发事务处理时，通过共享内存中的事务状态信息，系统可以判断是否存在事务冲突，并采取相应的处理策略，如回滚冲突的事务。
共享的系统目录信息：系统目录存储了数据库的元数据，如数据库的模式信息、表结构、列信息等。这些信息在多个后端进程间共享，以便它们能够正确地解析SQL语句并执行相应的操作。例如，当一个后端进程执行SELECT * FROM users语句时，它需要从共享的系统目录信息中获取users表的结构，包括列名、数据类型等，从而正确地解析和执行查询。

共享内存的初始化

PostgreSQL在启动时会初始化共享内存。这个过程涉及到以下几个步骤：

确定共享内存大小：共享内存的大小可以通过配置参数shared_buffers来设置。这个参数指定了缓冲区高速缓存的大小，而缓冲区高速缓存是共享内存的主要组成部分。例如，通过在postgresql.conf文件中设置shared_buffers = '2GB'，可以将共享内存中缓冲区高速缓存的大小设置为2GB。
分配共享内存：操作系统提供了共享内存分配的接口，PostgreSQL通过这些接口在系统中分配一块连续的内存区域作为共享内存。在Linux系统中，通常使用shmat、shmget等系统调用来实现共享内存的分配和映射。
初始化共享数据结构：一旦共享内存分配成功，PostgreSQL会在其中初始化各种共享的数据结构，如缓冲区高速缓存的管理结构、事务状态表等。例如，对于缓冲区高速缓存，会初始化一个链表结构来管理缓存中的数据块，每个数据块都有相应的元数据，如是否被修改、最近访问时间等。

代码示例：查看共享内存相关信息

在PostgreSQL中，可以通过一些系统视图来查看共享内存的使用情况。例如，通过pg_stat_activity视图可以查看当前活跃事务的信息，这些信息存储在共享内存中。

-- 查看当前活跃事务
SELECT * FROM pg_stat_activity;

通过上述查询，可以获取到当前活跃事务的相关信息，包括事务ID、状态、执行的查询语句等。这些信息在共享内存中维护，通过该视图可以直观地了解共享内存中事务状态信息的情况。

后端进程内存

每个PostgreSQL后端进程都有自己独立的内存空间，用于执行客户端请求的SQL语句。

工作内存（Work Memory）

用途：工作内存主要用于处理排序、哈希表构建等操作。当一个SQL查询需要进行排序（如ORDER BY子句）或者构建哈希表（如GROUP BY、DISTINCT操作）时，PostgreSQL会在工作内存中进行这些操作。例如，对于SELECT column1, COUNT(*) FROM table1 GROUP BY column1;这个查询，系统会在工作内存中构建一个哈希表，将column1的值作为键，统计每个键出现的次数。
大小控制：工作内存的大小可以通过配置参数work_mem来设置。这个参数指定了每个后端进程在执行排序、哈希等操作时可以使用的最大内存量。例如，设置work_mem = '64MB'，表示每个后端进程在进行相关操作时最多可以使用64MB的工作内存。如果操作所需的内存超过了这个限制，PostgreSQL会将部分数据写入临时文件，在磁盘上进行操作，这会显著降低性能。

临时内存

用途：临时内存用于存储临时数据，这些数据通常是在查询执行过程中临时生成的，并且在查询结束后就不再需要。例如，在执行子查询时，子查询的结果可能会存储在临时内存中，供主查询使用。另外，在进行复杂的连接操作时，中间结果也可能会临时存储在临时内存中。
管理方式：PostgreSQL会自动管理临时内存的分配和释放。当一个查询开始执行时，系统会根据需要分配临时内存。在查询执行结束后，临时内存会被释放，供其他查询使用。与工作内存不同的是，临时内存的使用没有一个固定的配置参数来限制其大小，而是根据实际的查询需求动态分配。

代码示例：测试工作内存对查询性能的影响

-- 创建一个测试表
CREATE TABLE test_table (id INT, data TEXT);

-- 插入大量测试数据
INSERT INTO test_table (id, data)
SELECT generate_series(1, 1000000), md5(random()::text);

-- 设置较小的work_mem
SET work_mem = '1MB';

-- 执行需要排序的查询
EXPLAIN ANALYZE SELECT * FROM test_table ORDER BY id;

-- 设置较大的work_mem
SET work_mem = '64MB';

-- 再次执行相同的查询
EXPLAIN ANALYZE SELECT * FROM test_table ORDER BY id;

在上述代码中，首先创建了一个包含大量数据的测试表。然后，分别设置较小和较大的work_mem值，并执行一个需要排序的查询。通过EXPLAIN ANALYZE语句可以观察到不同work_mem值下查询的执行时间和性能差异。当work_mem较小时，查询可能需要将部分数据写入临时文件进行排序，导致性能下降；而当work_mem较大时，排序操作可以在内存中高效完成，查询性能得到提升。

内存管理机制

PostgreSQL有一套完善的内存管理机制，以确保内存的高效使用和系统的稳定性。

内存分配策略

基于需求的分配：PostgreSQL根据不同的操作需求来分配内存。例如，对于缓冲区高速缓存，当一个数据块需要被缓存时，系统会从共享内存的空闲空间中分配一块合适大小的内存来存储该数据块。对于后端进程的工作内存，当一个查询需要进行排序或哈希操作时，系统会根据操作的规模和work_mem参数的值来分配相应大小的内存。
内存池的使用：为了提高内存分配的效率，PostgreSQL使用内存池的概念。内存池是预先分配好的一块内存区域，当需要分配内存时，首先从内存池中获取。如果内存池中的内存不足，再从系统中申请新的内存。例如，对于频繁分配和释放的小内存块，使用内存池可以减少系统调用的开销，提高内存分配的速度。

内存回收策略

事务结束时的回收：当一个事务结束时，该事务在执行过程中使用的所有临时内存和工作内存都会被回收。例如，如果一个事务在执行过程中使用工作内存进行了排序操作，事务结束后，这部分工作内存会被释放，供其他事务使用。
缓冲区高速缓存的回收：缓冲区高速缓存中的数据块会根据一定的策略进行回收。其中最常用的策略是最近最少使用（LRU）策略。当缓冲区高速缓存已满，而又需要缓存新的数据块时，系统会根据LRU策略选择最近最少使用的数据块，将其从缓存中移除，释放出内存空间。例如，如果一个数据块在很长时间内都没有被访问，而此时缓存空间不足，该数据块就有可能被LRU策略选中并移除。

代码示例：模拟内存分配和回收

-- 创建一个函数来模拟内存分配和回收
CREATE OR REPLACE FUNCTION simulate_memory_operations() RETURNS void AS $$
BEGIN
    -- 模拟使用工作内存进行排序
    CREATE TEMP TABLE temp_table AS SELECT generate_series(1, 1000000) AS id ORDER BY generate_series(1, 1000000);

    -- 事务结束，工作内存和临时表占用的内存会被回收
END;
$$ LANGUAGE plpgsql;

-- 调用函数
SELECT simulate_memory_operations();

在上述代码中，创建了一个函数simulate_memory_operations。在函数内部，通过创建一个临时表并对其进行排序操作，模拟了工作内存的使用。当函数执行结束时，事务结束，临时表占用的内存以及在排序过程中使用的工作内存都会被回收。通过这种方式，可以直观地理解PostgreSQL在事务结束时的内存回收机制。

内存结构与性能优化

理解PostgreSQL的内存结构对于性能优化至关重要。

共享内存参数调整

shared_buffers：如前文所述，shared_buffers参数决定了缓冲区高速缓存的大小。合理调整这个参数可以显著提高系统的I/O性能。一般来说，如果服务器有足够的物理内存，可以适当增大shared_buffers的值。例如，对于一个拥有32GB物理内存的数据库服务器，可以将shared_buffers设置为物理内存的25% - 40%，即8GB - 12.8GB。但需要注意的是，设置过大可能会导致系统内存不足，影响其他进程的运行。
effective_cache_size：这个参数告诉PostgreSQL系统中可用的缓存大小，包括操作系统缓存和共享内存中的缓冲区高速缓存。它用于查询规划器，帮助规划器做出更合理的查询计划。例如，如果设置effective_cache_size = '20GB'，查询规划器在生成查询计划时会考虑到有大约20GB的缓存可用，从而更倾向于选择那些利用缓存效率高的执行计划。

后端进程内存参数调整

work_mem：调整work_mem参数可以优化查询中排序和哈希操作的性能。对于复杂的查询，尤其是涉及大数据量的排序和分组操作，适当增大work_mem可以避免数据写入临时文件，提高查询速度。但也要注意，过大的work_mem可能会导致系统内存不足，影响其他后端进程的运行。例如，对于一个主要处理分析型查询的数据库，可以根据查询的平均规模，将work_mem设置为相对较大的值，如128MB或256MB。
maintenance_work_mem：这个参数用于VACUUM、CREATE INDEX等维护操作。这些操作通常需要大量的内存来处理数据。例如，在执行VACUUM FULL操作时，系统会使用maintenance_work_mem指定大小的内存来重建表。合理设置这个参数可以提高维护操作的效率，减少操作所需的时间。一般来说，可以根据服务器的内存情况，将maintenance_work_mem设置为一个较大的值，但同样要避免设置过大导致系统内存不足。

代码示例：通过调整内存参数优化查询性能

-- 查看当前的内存参数
SHOW shared_buffers;
SHOW work_mem;
SHOW effective_cache_size;

-- 调整参数
SET shared_buffers = '4GB';
SET work_mem = '128MB';
SET effective_cache_size = '16GB';

-- 执行一个复杂查询
EXPLAIN ANALYZE SELECT column1, COUNT(*) FROM large_table GROUP BY column1;

在上述代码中，首先通过SHOW语句查看当前的内存参数。然后，根据实际情况调整了shared_buffers、work_mem和effective_cache_size参数。最后，执行一个复杂的分组查询，并使用EXPLAIN ANALYZE语句观察调整参数前后查询性能的变化。通过这种方式，可以验证内存参数调整对查询性能的优化效果。

内存结构与并发控制

PostgreSQL的内存结构在并发控制中起着关键作用。

共享内存中的并发控制

锁机制：在共享内存中，为了保证多个后端进程对共享数据结构的并发访问安全，PostgreSQL使用锁机制。例如，对于缓冲区高速缓存中的数据块，当一个后端进程要读取或修改某个数据块时，它需要先获取相应的锁。如果该数据块已经被其他进程加锁，那么当前进程需要等待锁的释放。这种锁机制确保了在同一时间只有一个进程可以对共享数据块进行修改，从而保证了数据的一致性。
多版本并发控制（MVCC）：MVCC也是共享内存并发控制的重要手段。在PostgreSQL中，每个数据行都有多个版本，不同的事务可以看到不同版本的数据行。例如，当一个事务修改了某条数据行时，系统并不会直接覆盖旧版本，而是创建一个新版本。其他事务在读取数据时，根据自身的事务ID和数据行版本的可见性规则，决定读取哪个版本的数据。这样可以避免读写冲突，提高并发性能。

后端进程内存中的并发控制

独立的工作空间：每个后端进程都有自己独立的工作内存和临时内存，这避免了不同后端进程之间在这些内存区域的直接冲突。例如，一个后端进程在自己的工作内存中进行排序操作，不会影响其他后端进程的工作内存使用。
事务隔离级别：事务隔离级别定义了一个事务对其他事务的可见性程度。不同的事务隔离级别会影响后端进程内存中数据的处理方式。例如，在可重复读（Repeatable Read）隔离级别下，一个事务在整个事务期间看到的数据是一致的，即使其他事务在该事务执行期间修改了数据。这意味着在后端进程内存中，对于已经读取的数据，不会因为其他事务的修改而发生变化，保证了事务的一致性。

代码示例：演示并发控制与内存结构的关系

-- 开启两个事务，在不同会话中执行
-- 会话1
BEGIN;
SELECT * FROM table1 WHERE id = 1 FOR UPDATE;
-- 此时会话1获取了id = 1数据行的排它锁，在共享内存中该数据行被锁定

-- 会话2
BEGIN;
SELECT * FROM table1 WHERE id = 1;
-- 会话2尝试读取id = 1的数据行，但由于会话1持有排它锁，会话2会等待

-- 会话1
UPDATE table1 SET data = 'new_data' WHERE id = 1;
COMMIT;
-- 会话1提交事务，释放锁

-- 会话2
-- 此时会话2可以读取到更新后的数据
SELECT * FROM table1 WHERE id = 1;
COMMIT;

在上述代码示例中，通过两个会话模拟并发事务。在会话1中，首先获取了id = 1数据行的排它锁，这体现了共享内存中锁机制对并发访问的控制。会话2在尝试读取该数据行时会等待锁的释放。当会话1提交事务释放锁后，会话2可以读取到更新后的数据。这个过程展示了共享内存中的锁机制如何保证并发事务对共享数据的一致性访问，以及后端进程在这种并发控制下的数据处理方式。

内存结构与故障恢复

PostgreSQL的内存结构在故障恢复过程中扮演着重要角色。

共享内存与故障恢复

检查点机制：检查点是共享内存与故障恢复的关键环节。PostgreSQL定期执行检查点操作，将共享内存中已修改的数据块（脏页）写回磁盘。检查点记录了系统在某个时间点的状态，包括哪些数据块已被修改、哪些事务处于活跃状态等。当系统发生故障后重启时，通过检查点信息可以快速恢复到故障前的状态，减少恢复时间。例如，如果在检查点之后发生故障，系统只需要重放检查点之后的日志记录，而不需要重放整个日志，从而大大提高了恢复效率。
日志记录：共享内存中的事务状态信息与日志记录紧密相关。在事务执行过程中，系统会将事务的操作记录到日志中。这些日志记录不仅用于保证事务的持久性，还在故障恢复时发挥重要作用。例如，在系统重启后，通过日志记录可以重新执行未完成的事务，回滚已失败的事务，确保数据库的一致性。

后端进程内存与故障恢复

事务状态恢复：每个后端进程在事务执行过程中会在自己的内存中维护事务的局部状态。当系统发生故障并重启后，后端进程需要根据共享内存中的事务状态信息和日志记录，恢复自己的事务状态。例如，如果一个事务在故障发生时处于部分执行状态，后端进程在重启后需要根据日志记录重新执行该事务的剩余部分，或者回滚该事务，以保证事务的完整性。
工作内存和临时内存的清理：在故障恢复过程中，后端进程的工作内存和临时内存中的数据是无效的，需要进行清理。系统重启后，会重新初始化这些内存区域，为新的事务执行做好准备。这确保了在故障恢复后，后端进程能够正常执行新的查询和事务，不会受到故障前残留数据的影响。

代码示例：模拟故障恢复过程

-- 开启一个事务
BEGIN;
UPDATE table1 SET data = 'new_value' WHERE id = 1;
-- 此时事务执行了部分操作，但未提交

-- 模拟系统故障（这里无法实际模拟，仅为示意）

-- 系统重启后
-- PostgreSQL会根据检查点信息和日志记录
-- 回滚未提交的事务，确保数据库一致性

在上述代码示例中，首先开启了一个事务并执行了部分更新操作。虽然无法实际模拟系统故障，但从概念上理解，在系统发生故障重启后，PostgreSQL会利用共享内存中的检查点信息和日志记录，回滚未提交的事务，如上述代码中的未提交事务，从而保证数据库的一致性。这展示了PostgreSQL内存结构在故障恢复过程中的关键作用，通过共享内存中的检查点和日志，以及后端进程对事务状态的恢复和内存清理，实现了高效可靠的故障恢复。

内存结构的监控与调优工具

为了更好地管理和优化PostgreSQL的内存结构，有多种监控与调优工具可供使用。

系统视图

pg_stat_activity：如前文提到，这个视图可以显示当前活跃的后端进程信息，包括每个进程正在执行的查询、事务状态等。通过分析这些信息，可以了解后端进程的内存使用情况，例如哪些查询占用了大量的工作内存。例如，通过以下查询可以查看执行时间较长的查询，这些查询可能存在内存使用不合理的情况：

SELECT * FROM pg_stat_activity WHERE state = 'active' AND query_start < (NOW() - INTERVAL '1 minute');

pg_stat_bgwriter：该视图提供了后台写进程（Background Writer）的统计信息。后台写进程负责将共享内存中的脏页写回磁盘，与缓冲区高速缓存的管理密切相关。通过这个视图，可以了解缓冲区高速缓存的写操作频率、检查点的执行频率等信息，从而评估共享内存的使用效率。例如，通过以下查询可以查看最近一次检查点的相关信息：

SELECT * FROM pg_stat_bgwriter WHERE checkpoint_time = (SELECT MAX(checkpoint_time) FROM pg_stat_bgwriter);

外部工具

pgBadger：pgBadger是一个强大的日志分析工具，它可以解析PostgreSQL的日志文件，生成各种统计报表。其中包括查询执行时间、查询频率、内存使用情况等信息。通过分析这些报表，可以发现哪些查询消耗了大量的内存，进而对这些查询进行优化。例如，pgBadger可以生成一个按内存使用量排序的查询列表，帮助管理员快速定位内存消耗大户。
top和htop：这些是系统级的监控工具，可以查看PostgreSQL进程的内存使用情况。通过观察PostgreSQL进程占用的系统内存，可以大致了解整个数据库系统的内存使用趋势。例如，使用top命令可以实时查看PostgreSQL进程的内存占用百分比，判断是否存在内存泄漏或内存使用异常的情况。

代码示例：使用系统视图优化查询内存使用

-- 通过pg_stat_activity查看长时间运行的查询
SELECT * FROM pg_stat_activity WHERE state = 'active' AND query_start < (NOW() - INTERVAL '1 minute');

-- 假设查询结果中某个查询为：
-- SELECT column1, COUNT(*) FROM large_table GROUP BY column1 ORDER BY COUNT(*) DESC;

-- 分析该查询可能存在的内存问题
-- 此查询进行了分组和排序操作，可能需要大量工作内存
-- 可以尝试增加work_mem参数值
SET work_mem = '256MB';

-- 再次执行查询并观察性能
EXPLAIN ANALYZE SELECT column1, COUNT(*) FROM large_table GROUP BY column1 ORDER BY COUNT(*) DESC;

在上述代码示例中，首先通过pg_stat_activity视图查找长时间运行的查询，假设找到一个涉及分组和排序的查询。分析该查询可能由于工作内存不足导致性能问题，于是增加work_mem参数值，然后再次执行查询并使用EXPLAIN ANALYZE观察性能变化。通过这种方式，利用系统视图来发现和解决查询中的内存使用问题，实现对PostgreSQL内存结构的优化。