KingbaseES 数据库参数优化

一、数据库应用类型

针对不同的应用模型，需要对数据库配置进行优化：

1、网络应用程序（WEB）

通常受 CPU 限制
DB比RAM小得多
90% 或更多的简单查询

2、在线事务处理 (OLTP)

通常受 CPU 或 I/O 限制
数据库数据量远大于系统内存
20-40% 小数据写入查询
长事务和复杂的读取查询

3、数据仓库 (DW)

通常受 I/O 或 RAM 限制
大量数据加载
大型复杂报表查询
也称为“决策支持”或“商业智能”

4、混合型应用(MIX)

混合 DW 和 OLTP 特性
各种的查询组合

上述各种应用系统的需求存在差异，因此，建议在安装PostgreSQL完成后，首先执行的操作之一就是调优和配置一些高级设置。可以基于系统的CPU、内存和磁盘等硬件资源，分别设置数据库配置参数：

二、主要参数

max_connections

确定到数据库服务器的最大并发连接数。默认情况下，KingbaseES 允许的最大连接数相对较低，默认限制为100。这个限制与共享缓冲区的大小有关，连接利用共享缓冲区中的内存。

建议设置为预期峰值负载时需要的最大连接数。请注意，每个连接都使用shared_buffer内存，以及额外的非共享内存。一般来说，如果需要超过200个连接，就应该更多地使用连接池。请谨慎设置最大并发连接数，避免开发人员不要滥用他们的系统资源。

shared_buffers

默认情况下这个值设置得比较低。因此，更新 shared_buffers 是在大多数现代操作系统上提高整体性能最有效的设置之一。

shared_buffers 没有特定的推荐值，但是为特定系统确定值的计算并不特别困难。一般来说，对于专用DB服务器， shared_buffers 的值应该大约是总系统RAM的30%。另外，虽然较大的 shared_buffers 值可以在'读繁重'用例中提高性能，但对于'写繁重'用例，较大的 shared_buffer 值可能是有害的，因为 shared_buffers 的全部内容必须在写期间处理。

effective_cache_size

设置规划器对查询可用的磁盘缓存的有效大小的假设。这被考虑到基于代价的成本估计中。值越高，使用索引扫描的可能性越大，值越低，使用顺序扫描的可能性越大。在设置这个参数时，应该同时考虑KingbaseES 的shared_buffers 和用于数据文件的磁盘缓存部分。另外，还要考虑不同表上并发查询的预期数量，因为它们必须共享可用空间。该参数对PostgreSQL分配的共享内存大小没有影响，也不保留内核磁盘缓存，它仅用于估算目的。系统也不会假设数据在查询之间仍保留在磁盘缓存中。

建议，effective_cache_size设置系统内存的 75%。

maintenance_work_mem

指定在维护性操作（例如VACUUM、CREATE INDEX和ALTER TABLE ADD FOREIGN KEY）中使用的最大的内存量。其默认值是 64 兆字节（64MB）。因为在一个数据库会话中，一个时刻只有一个这样的操作可以被执行，并且一个数据库安装通常不会有太多这样的操作并发执行，把这个数值设置得比work_mem大很多是安全的。更大的设置可以改进清理和恢复数据库转储的性能。

注意当自动清理运行时，可能会分配最多达这个内存的 autovacuum_max_workers 倍，因此要小心不要把该默认值设置得太高，通过单独设置autovacuum_work_mem，可能会对避免这种情况出现。将其设置为中等高值会提高vacuum和其他操作的效率。执行大型ETL操作的应用程序可能需要分配多达1/4的RAM来支持大容量真空。注意，每个autovacuum 进程可能使用这么多，所以如果使用多个autovacuum进程，您可能希望降低这个值，以便他们不能要求超过1/8或1/4的可用RAM。建议，maintenance_work_mem 通常设置为系统内存的 1/16，但是数据仓库系统可以设置为系统内存的 1/8。

checkpoint_completion_target

检查点期间刷新脏缓冲区所花费的时间(占检查点间隔的百分比)。指定检查点完成的目标，作为检查点之间总时间的一部分。默认值是0.5（50%）。通常磁盘IO的写入速度为300M/s-1000M/s，，在checkpoint_completion_target设置的越高的情况下，写入速度越低，体验越好，性能越高。反之，较低的值可能会引起I/O峰值，导致“卡死”的现象。

建议，checkpoint_completion_target可以设置为0.9（90%）。

wal_buffers

为WAL设置共享内存中的磁盘页缓冲区的数量。默认设置-1选择的大小等于shared_buffers的1/32(大约3%)，但不小于64kB也不大于一个WAL段的大小。

在每次事务提交时，WAL缓冲区的内容都被写到磁盘上，所以非常大的值不太可能有显著的好处。但是，将这个值设置为至少几个兆字节可以提高在许多客户机同时提交的繁忙服务器上的写性能。在大多数情况下，由缺省设置-1选择的自动调优应该会给出合理的结果。

在非常繁忙的高核机器上，将这个值提高到128MB是很有用的。

default_statistics_target

设置默认统计目标（直方图数量）。

为不通过ALTER table set statistics设置列特定目标的表列设置默认统计目标。较大的值会增加ANALYZE所需的时间，但可能会提高计划者评估的质量。默认值为100。

大多数应用程序可以使用默认值100。对于非常小/简单的数据库，减少到10或50。数据仓库应用程序通常需要使用500到1000。否则，在每列的基础上增加统计目标。

random_page_cost

设置规划器对非顺序获取磁盘页的成本的估计，默认为4.0。通过设置表空间参数，可以覆盖特定表空间中的表和索引的这个值。

相对于seq_page_cost降低这个值将导致系统更倾向于索引扫描；提高它将使索引扫描看起来相对更昂贵。您可以同时提高或降低这两个值，以改变磁盘I/O成本相对于CPU成本的重要性。

对机械磁盘的随机存取通常比顺序存取cost昂贵得多。但是，使用较低的默认值(4.0)，因为大多数对磁盘的随机访问，比如索引读取，都假定是在缓存中。默认值可以被认为是建模随机访问比顺序慢40倍，而预期90%的随机读取被缓存。如果您认为90%的缓存率对于您的工作负载是一个不正确的假设，那么您可以增加random_page_cost来更好地反映随机存储读取的真实成本。相应地，如果您的数据可能完全在缓存中，例如当数据库小于服务器总内存时，可以适当降低random_page_cost。相对于顺序存储，具有较低的随机读成本的存储，例如固态硬盘，也可以使用较低的random_page_cost值进行建模，例如，1.1。

尽管系统允许将random_page_cost设置为小于seq_page_cost，但这样做在物理上是不合理的。但是，如果数据库完全缓存在RAM中，那么设置它们相等是有意义的，因为在这种情况下，不按顺序访问页面不会受到负面影响。此外，在高缓存的数据库中，应该降低这两个值，因为获取RAM中已经存在的页面的成本比正常情况下要小得多。

建议，机械硬盘设置为 4, 固态硬盘设置为1.1, SAN存储设置为1.1。

effective_io_concurrency

磁盘子系统可以有效处理的并发请求的数量，在支持的系统上，默认值为1，否则为0。通过设置表空间参数，可以覆盖特定表空间中的表的这个值。仅适用于支持posix_fadvise的平台(例如Linux)。目前只影响并行位图扫描的执行，但可能会影响其他I/O操作的未来版本。

但是，如果数据库经常因为并发会话中发出的多个查询而繁忙，那么较低的值可能足以使磁盘阵列保持忙碌。高于使磁盘繁忙所需的值只会导致额外的CPU开销。ssd和其他基于内存的存储通常可以处理许多并发请求，所以最好的值可能是几百。

建议，机械硬盘设置为 2, 固态硬盘设置为 200, SAN存储设置为 300。

work_mem

work_mem 的值用于复杂的排序操作，并定义用于中间结果(如哈希表)和排序的最大内存量。当对 work_mem 的值进行适当调优时，大多数排序操作将在更快的内存中执行，而不是读写磁盘。

确保' work_mem '值不要设置得太高是很重要的，因为在并行操作中，并发排序操作需要多份的' work_mem '。由于这个重要的警告，理想的做法是将' work_mem '的全局值设置为一个相对较低的值，然后修改任何特定查询本身，以使用更高的' work_mem '值。

当查询调用排序、哈希或任何其他需要空间分配的结构时，都会分配work_mem，每个查询都可能发生多次。需要考虑的一件事是，不应让可用内存在边缘运行，避免OOM。总是需要留下某种类型的缓冲区，以防止内存使用高峰。所以work_mem中可用的最大内存应该是((RAM - shared_buffers) / (max_connections * 3) / max_parallel_workers_per_gather。

min_wal_size max_wal_size

只要WAL磁盘使用率保持在这个设置之下，旧的WAL文件就会被回收，以供将来在检查点使用，而不是被删除。这可以用来确保保留足够的WAL空间来处理WAL使用的峰值，例如在运行大型批处理作业时。如果这个值没有指定单位，它将被接受为兆字节。min_wal_size , 默认为80mb。

max_wal_size ，允许WAL在自动检查点期间增长的最大尺寸。除非数据库每小时写入的数据超过1GB，在这种情况下，增加日志的大小，使其至少相当于一个小时的日志

建议：

WEB ：min_wal_size = 1GB max_wal_size = 4GB
OLTP：min_wal_size = 2GB max_wal_size = 8GB
DW ：min_wal_size = 4GB max_wal_size = 16GB
MIX ：min_wal_size = 1GB max_wal_size = 4GB

max_worker_processes

设置系统可以支持的最大后台进程数。该参数只能在服务器启动时设置。默认值是8。

运行备用服务器时，必须将该参数设置为与主服务器相同或更高的值。否则，备用服务器将不允许查询。

当更改此值时，请考虑同时调整max_parallel_workers、max_parallel_maintenance_workers和max_parallel_workers_per_gather。

增加到max_parallel_workers +其他workers，例如用于逻辑复制的workers和自定义后台workers。不过不会超过CPU的核数。

max_parallel_workers_per_gather

设置单个“收集”或“收集合并”节点可启动的工作人员的最大数量。并行作业从max_worker_processes建立的进程池中获取，受max_parallel_workers的限制。请注意，请求的worker数量可能在运行时实际上不可用。如果发生这种情况，该计划将使用比预期更少的worker运行，这可能是低效的。缺省值是2。将此值设置为0将禁用并行查询执行。

请注意，并行查询可能比非并行查询消耗更多的资源，因为每个工作进程是完全独立的进程，它对系统的影响与额外的用户会话大致相同。在为该设置选择值时，以及在配置其他控制资源利用率的设置(如work_mem)时，都应该考虑到这一点。资源限制(如work_mem)单独应用于每个worker，这意味着所有进程的总利用率可能比通常情况下任何单个进程的总利用率要高得多。例如，使用4个worker的并行查询使用的CPU时间、内存、I/O带宽等可能是完全不使用worker的查询的5倍。

计划使用并行查询，建议增加到4或8，这取决于核心/并发会话。

max_parallel_workers

设置系统可支持并行操作的最大worker数。缺省值为8。当增加或减少这个值时，也考虑调整max_parallel_maintenance_workers和max_parallel_workers_per_gather。另外，请注意，该值的设置高于max_worker_processes将不会产生影响，因为并行工作进程是从该设置建立的工作进程池中获取的。

如果您认为可以从并行查询，在DW系统中，设置为CPU核心数。

max_parallel_maintenance_workers

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

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

计划使用并行查询，建议增加到4或8，这取决于核心/并发会话。