[转帖]通过配置优化KingbaseES服务器性能

目录

1. 概述

2. 数据库应用类型

3. 服务器参数

3.1. max_connections

3.2. shared_buffers

3.3. effective_cache_size

3.4. maintenance_work_mem

3.5. checkpoint_completion_target

3.6. wal_buffers

3.7. default_statistics_target

3.8. random_page_cost

3.9. effective_io_concurrency

3.10. work_mem

3.11. min_wal_size  max_wal_size

3.12. max_worker_processes

3.13. max_parallel_workers_per_gather

3.14. max_parallel_workers

3.15. max_parallel_maintenance_workers

4. 示例

---

1. 概述

数据库服务器的性能表现，既受到硬件条件的约束，同时又受各种应用系统的需求差异所影响。因此，在KingbaseES安装完成后，建议首先调优和配置一些数据库服务器参数。用户可以基于系统的CPU、内存和磁盘等硬件资源，根据数据库使用的应用场景，在配置文件kingbase.conf中，对如下数据库服务器参数进行差异化的优化设置：

• max_connections
• shared_buffers
• effective_cache_size
• maintenance_work_mem
• checkpoint_completion_target
• wal_buffers
• default_statistics_target
• random_page_cost
• effective_io_concurrency
• work_mem
• min_wal_size  max_wal_size
• max_worker_processes
• max_parallel_workers_per_gather
• max_parallel_workers
• max_parallel_maintenance_workers

例如，当数据库经常有大量数据频繁访问，可以调大shared_buffers。

2. 数据库应用类型

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

• 网络应用程序（WEB）
  • 通常受 CPU 限制
  • 数据库体量比内存小得多
  • 90% 或更多的简单查询
• 在线事务处理 (OLTP)
  • 通常受 CPU 或 I/O 限制
  • 数据库数据量远大于系统内存 ​
  • 20-40%事务是小数据量写入和查询
  • 长事务和复杂的读取查询
• 数据仓库 (DW) ​
  • 通常受 I/O 或 RAM 限制 ​
  • 大量数据加载 ​
  • 大型复杂报表查询 ​
  • 也称为“决策支持”或“商业智能”
• 混合型应用(MIX) ​
  • 混合 DW 和 OLTP 特性 ​
  • 各种的查询组合

3. 服务器参数

3.1. max_connections

最大并发连接数。

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

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

3.2. shared_buffers

共享内存缓冲区量

数据库服务器将使用的共享内存缓冲区量。默认情况下这个值设置得较低。因此，在大多数现代操作系统上更新shared_buffers是提高整体性能最有效的设置之一。

shared_buffers没有特定的推荐值，但为特定系统计算共享内存缓冲区量的确定值并不困难。

一般来说，对于专用DB服务器，shared_buffers的值大约是总系统RAM的25%。shared_buffers的值不应该设置成为KingbaseES保留所有的系统内存。例如，如果将系统RAM的值设置为整个数据库工作数据集都能放入缓存中，那么超过系统RAM的25%是有用的，这将大大减少从磁盘读取数据的时间。

另外，虽然较大的shared_buffers值可以在'读繁重'用例中提高性能，但对于'写繁重'用例，较大的shared_buffer值可能是有害的，因为shared_buffers的全部内容必须在写期间处理。

3.3. effective_cache_size

设置规划器关于数据缓存的总量的假设。

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

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

3.4. 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。

3.5. checkpoint_completion_target

检查点期间刷新脏缓冲区所花费的时间(占检查点间隔的百分比)。

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

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

3.6. wal_buffers

为WAL设置共享内存中的磁盘页缓冲区的数量。

用于尚未写入磁盘的WAL数据的共享内存数量。默认值-1选择的大小等于shared_buffers的1/32(大约3%)，但不小于64kB也不大于一个WAL段的大小，通常是16MB。

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

在非常繁忙的高核机器上，建议将这个值提高到128MB。

3.7. default_statistics_target

设置默认统计目标。

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

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

3.8. 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。

3.9. effective_io_concurrency

磁盘子系统可以有效处理的并发请求的数量。

在支持的系统上，默认值为1，否则为0。通过设置表空间参数，可以覆盖特定表空间中的表的这个值。

设置RAID中磁盘的个数或I/O通道的个数。仅适用于支持posix_fadvise的平台(例如Linux)。目前只影响并行位图扫描的执行，但可能会影响其他I/O操作的未来版本。

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

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

3.10. work_mem

指定在写到临时磁盘文件之前被内部排序操作和哈希表使用的内存量。

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

但是，确保' work_mem '值不要设置得太高是很重要的，因为当应用程序执行排序操作时，它会“瓶颈”系统上的可用内存。例如，在这种情况下，系统将尝试分配。' work_mem '在每个并发排序操作中多次执行。

由于这个重要的警告，理想的做法是将' work_mem '的全局值设置为一个相对较低的值，然后修改任何特定查询本身，以使用更高的' work_mem '值。

当查询调用排序、哈希或任何其他需要空间分配的结构时，都会分配work_mem，每个查询都可能发生多次。所以最好假设 max_connections * 2 或 max_connections * 3 是实际使用的内存。至少，您需要从分配给work_mem中的连接的数量中减去shared_buffers。

需要考虑的一件事是，不应让可用内存在边缘运行。如果这样做，那么内存不足的杀手就会出现，linux系统OOM机制则开始杀掉KingbaseES后台进程。建议需要留下某些的缓冲区，以防止内存使用超过峰值。所以work_mem中可用的最大内存应该是((RAM - shared_buffers) / (max_connections * 3) / max_parallel_workers_per_gather。

3.11. min_wal_size  max_wal_size

min_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

3.12. max_worker_processes

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

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

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

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

3.13. 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，这取决于核心/并发会话。

3.14. max_parallel_workers

设置系统可支持并行操作的最大worker数。

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

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

3.15. max_parallel_maintenance_workers

设置单一工具性命令能够启动的并行工作者的最大数目。

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

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

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

4. 示例

例1：OLTP系统，内存 64GB，CPUs 数量：32， 连接数：500，数据存储：HDD

在kingbase.conf配置文件中做如下设置：

max_connections = 500





 





shared_buffers = 16GB





 





effective_cache_size = 48GB





 





maintenance_work_mem = 2GB





 





checkpoint_completion_target = 0.9





 





wal_buffers = 16MB





 





default_statistics_target = 100





 





random_page_cost = 1.1





 





effective_io_concurrency = 200





 





work_mem = 8388kB





 





min_wal_size = 2GB





 





max_wal_size = 8GB





 





max_worker_processes = 32





 





max_parallel_workers_per_gather = 4





 





max_parallel_workers = 32





 





max_parallel_maintenance_workers = 4

文章知识点与官方知识档案匹配，可进一步学习相关知识

MySQL入门技能树设计优化生成列59737 人正在系统学习中