postgresql 数据库优化需要懂得几个参数

Posted 2022-11-09 yang_z_1

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了postgresql 数据库优化需要懂得几个参数相关的知识，希望对你有一定的参考价值。

postgresql 数据库优化需要懂得几个参数

文章目录

postgresql 数据库优化需要懂得几个参数
🌈前言
🌈数据库系统配置优化的主要参数
🌈软件修改参数
- PGTune
🌈后记

🌈前言

数据库的优化是非常重要的。不管对系统还是别的，一个优化后的数据库的前后对比非常明显，而数据库又该如何优化呢？
我认为可以分为俩部分：
一数据库系统配置优化
二 sql的优化
那么我们今天先简单说一说关于数据库系统配置的优化，与之相关的几个主要参数：

🌈数据库系统配置优化的主要参数

max_connections

该参数代表postgresql数据库的最大连接数，参数默认是100，显然不适用于生产，生产配置10000，如果请求大于默认连接数，就会出现无法连接数据库的错误，在生产环境中，我们可能经常会遇到too many connections的报错信息。
max_connections并不是越大就越好。
数据的最大连接数，也就是可支持的最大并发连接数，总有人把最大连接数和最大并发数混为一潭，联想到多线程，多线程总给人一种牛逼轰轰的，不用多线程就上不去台面的感觉，其实除了CPU密集型的运算之外，而日常的大部分操作，都是和IO以及网络密切相关的，处理某个单一任务，多线程或者说纯粹增加线程数据并不一定提升效率，这两者相比CPU，都会先于CPU成为瓶颈，也就是说不等你并发完全起来，IO和网络已经成为瓶颈了.
这个需要根据实际情况来，个人建议200到700。

shared_buffers

PostgreSQL一方面使用了自身的缓存区，一方面也使用了内核的缓存IO。这就意味着数据被缓存了两次，首先是缓存在数据库里面，然后是缓存到内核里面。和其他数据库不一样，PostgreSQL没有提供Direct IO。这叫做双缓冲。PostgreSQL的缓冲区叫shared_buffer,对于绝大多数操作系统来说，这个参数是最有效的一个可调参数。这个参数控制了多少指定的内存会被PostgreSQL用来做cache。
shared_buffer的默认值非常小，你很难从中获得什么好处。之所以设置这么低，是因为有些机器或是操作系统不支持太大的值。但是，在现在的操作系统中，你可以增大这个参数来获得最优的性能。建议值是设置成硬件内存的25%。你可以把这个值设置得低于或是高于这个建议值，因为某些情况下，如果把这个值设置得大约25%的内存可以获得更好的性能。这个配置实际上取决于你的硬件配置和你的工作数据集的大小。如果你能轻易将你所有的数据加载到RAM里面，那么你可以增大shared_buffer来容纳你的数据库的数据，因此整个工作数据集可以驻留在cache中。
内核支持的情况下，该参数默认为128M，通常需要自己调整为更大的值。如果服务器RAM>=1GB，建议该参数设置为25%-40%之间，同时需要增加max_wal_size的值，以便将大量更新数据的过程分散开。
官方建议是服务器的1/4左右。

PG 的 shared buffers 和 OS CACHE 共同发挥作用，可以让PG数据库有效的减少物理IO,提升数据库的总体性能；其次，Shared buffers 的设置并不是越大越好，shared buffers 的命中率也没有ORACLE DB CACHE命中率那么有指向性，没有命中的 PAGE 也可能不需要物理读，可以直接从 OS CACHE 中读取到；第三，通过对应用系统的访问特性的分析，根据数据页在 shared buffer 中可能被多次访问的比例，以及这部分数据的大小，可以大致确定 shared buffers 的合理配置，同时根据应用的访问特性，可以大致确定 OS CACHE 与 SHARED BUFFERS 的比例；第四，根据服务器的 IO 能力和数据库的 IO 访问流量，通过调整 OS 层面的脏页写入策略参数和 PG 数据库的 CHECKPOINT 相关参数，可以获得一个较匹配的配置，增加系统的 IO 总吞吐量，降低平均 IO 延时，这对于大系统上做 PG 优化十分重要。

effective_cache_size ,

effective_cache_size参数是用来估计可以做磁盘cache的内存的大小。它只是一个指导方针，而不是分配的内存大小，也不是cache的大小。这个参数并不会实际分配内存，而是告诉优化器内核中可用的cache的大小。如果这个值设置得太低，那么查询优化器会决定放弃使用索引，尽管这些索引会非常有用。因此，通常将这个参数调大，是有好处的。

maintenance_work_mem ,

maintenance_work_mem是用于维护任务的内存设置。默认值为64MB。设置较大的值对于VACUUM，RESTORE，CREATE INDEX，ADD FOREIGN KEY和ALTER TABLE等操作的性能提升效果显著。

checkpoint_completion_target ,

查点完成的速度（默认值为0.5，这意味着它将在checkpoint_timeout的一半时间（即2.5分钟）内完成）
checkpoint_completion_target越大,意味着checkpointer进程休眠的机会越多，以控制脏块刷盘的进度，在休眠过程中，文件缓存会自动往下刷盘，在checkpoint完成后，会调用一次fsync，将page cache都刷到磁盘。休眠越多，就会让fsync操作时的IO平滑一点。

wal_buffers ,

用于还未写入磁盘的 WAL 数据的共享内存量。默认值 -1 选择等于shared_buffers的 1/32 的尺寸（大约3%），但是不小于64kB也不大于 WAL 段的尺寸（通常为）。如果自动的选择太大或太小可以手工设置该值，但是任何小于32kB的正值都将被当作32kB。如果指定值时没有单位，则以WAL块作为单位，即为 XLOG_BLCKSZ 字节，通常为8kB。这个参数只能在服务器启动时设置。

在每次事务提交时，WAL 缓冲区的内容被写出到磁盘，因此极大的值不可能提供显著的收益。不过，把这个值设置为几个兆字节可以在一个繁忙的服务器（其中很多客户端会在同一时间提交）上提高写性能。由默认设置 -1 选择的自动调节将在大部分情况下得到合理的结果。

default_statistics_target ,

为没有通过ALTER TABLE SET STATISTICS设置列相关目标的表列设置默认统计目标。更大的值增加了需要做ANALYZE的时间，但是可能会改善规划器的估计质量。默认值是 100。

random_page_cost

设置规划器对一次非顺序获取磁盘页面的代价估计。默认值是 4.0。通过把表和索引放在一个特殊的表空间（要设置该表空间的同名参数）中可以覆盖这个值。

减少这个值（相对于seq_page_cost）将导致系统更倾向于索引扫描；提高它将让索引扫描看起来相对更昂贵。你可以一起提高或降低两个值来改变磁盘 I/O 代价相对于 CPU 代价的重要性，后者由下列参数描述。

对磁盘存储的随机访问通常比顺序访问要贵不止四倍。但是，由于对磁盘的大部分随机访问（例如被索引的读取）都被假定在高速缓冲中进行，所以使用了一个较低的默认值（4.0）。默认值可以被想成把随机访问建模为比顺序访问慢 40 倍，而期望 90% 的随机读取会被缓存。
如果你相信 90% 的缓冲率对你的负载是一个不正确的假设，你可以增加 random_page_cost 来更好的反映随机存储读取的真正代价。相应地，如果你的数据可以完全放在高速缓存中（例如当数据库小于服务器总内存时），降低 random_page_cost 可能是合适的。为具有很低的随机读取代价的存储（例如固态驱动器）采用较低的 random_page_cost 值可能更好。
虽然允许你将random_page_cost设置的比 seq_page_cost小，但是物理上的实际情况并不受此影响。然而当所有数据库都位于内存中时，两者设置为相等是非常合理的，因为在此情况下，乱序抓取并不比顺序抓取开销更大。同样，在缓冲率很高的数据库上，你应当相对于 CPU 开销同时降低这两个值，因为获取内存中的页比通常情况下的开销小许多。尽管系统可以是你把random_page_cost设置得小于seq_page_cost，但是实际上没有意义。不过，如果数据库被整个缓存在 RAM 中，将它们设置为相等是有意义的，因为在那种情况中不按顺序访问页面是没有惩罚值的。同样，在一个高度缓存化的数据库中，你应该相对于 CPU 参数降低这两个值，因为获取一个已经在 RAM 中的页面的代价要远小于通常情况下的代价。

effective_io_concurrency

effective_io_concurrency (integer)

设置PostgreSQL可以同时被执行的并发磁盘 I/O 操作的数量。
调高这个值，可以增加任何单个PostgreSQL会话试图并行发起的 I/O 操作的数目。允许的范围是 1 到 1000，或 0 表示禁用异步 I/O 请求。当前这个设置仅影响位图堆扫描。
对于磁盘驱动器，这个设置的一个很好的出发点是组成一个被用于该数据库的 RAID 0 条带或 RAID 1 镜像的独立驱动器数量（对 RAID 5 而言，校验驱动器不计入）。
但是，如果数据库经常忙于在并发会话中发出的多个查询，较低的值可能足以使磁盘阵列繁忙。比保持磁盘繁忙所需的值更高的值只会造成额外的 CPU 开销。
SSD 以及其他基于内存的存储常常能处理很多并发请求，因此它们的最佳值可能是数百。
异步 I/O 依赖于一个有效的 posix_fadvise 函数（一些操作系统可能没有）。如果不存在这个函数，将这个参数设置为除 0 之外的任何东西将导致错误。在一些操作系统上（如Solaris）虽然提供了这个函数，但它不会做任何事情。
在支持的系统上默认值为 1，否则为 0。对于一个特定表空间中的表，可以通过设定该表空间的同名参数（见ALTER TABLESPACE）可以覆盖这个值。

work_mem

设置在写入临时磁盘文件之前查询操作(例如排序或哈希表)可使用的最大内存容量。如果指定值时没有单位，则以千字节为单位。默认值是4兆字节 (4MB)。注意对于一个复杂查询，可能会并行运行好几个排序或者哈希操作；每个操作都会被允许使用这个参数指定的内存量，然后才会开始写数据到临时文件。同样，几个正在运行的会话可能并发进行这样的操作。因此被使用的总内存可能是work_mem值的好几倍，在选择这个值时一定要记住这一点。ORDER BY、DISTINCT和归并连接都要用到排序操作。哈希连接、基于哈希的聚集以及基于哈希的IN子查询处理中都要用到哈希表。

min_wal_size

只要 WAL 磁盘用量保持在这个设置之下，在检查点时旧的 WAL 文件总是被回收以便未来使用，而不是直接被删除。这可以被用来确保有足够的 WAL 空间被保留来应付 WAL 使用的高峰，例如运行大型的批处理任务。如果指定值时没有单位，则以兆字节为单位。默认是 80 MB。这个参数只能在postgresql.conf 或者服务器命令行中设置。

max_wal_size

在自动 WAL 检查点之间允许 WAL 增长到的最大尺寸。这是一个软限制，在特殊的情况下 WAL 尺寸可能会超过max_wal_size，例如在重度负荷下、archive_command失败或者高的 wal_keep_segments设置。如果指定值时没有单位，则以兆字节为单位。默认为 1 GB。增加这个参数可能导致崩溃恢复所需的时间。这个参数只能在postgresql.conf 或者服务器命令行中设置。

max_worker_processes

设置系统能够支持的后台进程的最大数量。这个参数只能在服务器启动时设置。默认值为 8。

在运行一个后备服务器时，你必须把这个参数设置为等于或者高于主控服务器上的值。否则，后备服务器上可能不会允许查询。

在更改这个值时，考虑也对max_parallel_workers、max_parallel_maintenance_workers以及max_parallel_workers_per_gather进行调整。

max_parallel_workers_per_gather

设置单个Gather或者Gather Merge节点能够开始的工作者的最大数量。并行工作者会从max_worker_processes建立的进程池中取得，数量由max_parallel_workers限制。注意所要求的工作者数量在运行时可能实际无法被满足。如果这种事情发生，该计划将会以比预期更少的工作者运行，这可能会不太高效。默认值是2。把这个值设置为 0（默认值）将会禁用并行查询执行。

注意并行查询可能消耗比非并行查询更多的资源，因为每一个工作者进程时一个完全独立的进程，它对系统产生的影响大致和一个额外的用户会话相同。在为这个设置选择值时，以及配置其他控制资源利用的设置（例如work_mem）时，应该把这个因素考虑在内。work_mem之类的资源限制会被独立地应用于每一个工作者，这意味着所有进程的总资源利用可能会比单个进程时高得多。例如，一个使用 4 个工作者的并行查询使用的 CPU 时间、内存、I/O 带宽可能是不使用工作者时的 5 倍之多。

max_parallel_workers

设置系统为并行操作所支持的工作者的最大数量。默认值为8。在增加或者减小这个值时，也要考虑对max_parallel_maintenance_workers以及max_parallel_workers_per_gather进行调整。此外，要注意将这个值设置得大于max_worker_processes将不会产生效果，因为并行工作者进程都是从max_worker_processes所建立的工作者进程池中取出来的。

max_parallel_maintenance_workers

设置单一工具性命令能够启动的并行工作者的最大数目。当前，唯一一种支持使用并行工作者的工具性命令是CREATE INDEX，并且只有在构建B-树索引时才能并行。并行工作者从由max_worker_processes创建的进程池中取出，数量由max_parallel_workers控制。注意实际在运行时所请求数量的工作者可能不可用。如果发生这种情况，工具性操作将使用比预期数量少的工作者运行。默认值为2。将这个值设置为0可以禁用工具性命令对并行工作者的使用。

注意并行工具性命令不应该消耗比同等数量非并行操作更多的内存。这种策略与并行查询不同，并行查询的资源限制通常是应用在每个工作者进程上。并行工具性命令把资源限制maintenance_work_mem当作对整个工具性命令的限制，而不管其中用到了多少个并行工作者进程。不过，并行工具性命令实际上可能仍会消耗更多的CPU资源和I/O带宽。