KingbaseES 数据库无响应问题分析

一、背景及理论阐述

某项目数据库系统是集群环境，主库业务卡顿，应用反馈部分业务无法正常进行。
在操作系统中，物理内存（RAM）是有限的资源，当内存需求超过物理内存的容量时，操作系统会使用页面调度机制来管理内存资源。页面调度涉及将不常用的内存页面（Page）移到磁盘上的交换空间（Swap Space）或文件缓存中，以释放物理内存供其他进程使用。当需要再次访问这些页面时，它们会被从磁盘中读回内存。
pgpgout是操作系统性能监控中的一个关键指标，表示页面从物理内存被写出到磁盘的速率。当 pgpgout 的值增加时，说明系统正在频繁地进行页面调度，这可能是由于物理内存不足或某些进程使用了大量内存。

二、问题分析

原主库数据库日志：

20:51 worker took too long to start; canceled
20:55 terminating connection due to unexpected kingbase exit
从数据库日志结合现场情况分析，业务一些连接受到影响，应用反馈卡顿，怀疑系统资源紧张造成数据库运行卡顿，性能收到影响。

此时再看集群日志repmgr.log：

[2024-05-17 20:50:58] [WARNING] unable to ping "host=172.20.1.4 user=esrep dbname=esrep port=54321 connect_timeout=10 keepalives=1 keepalives_idle=2 keepalives_interval=2 keepalives_count=3 tcp_user_timeout=9000"
[2024-05-17 20:50:58] [DETAIL] KCIping() returned "KCIPING_NO_RESPONSE"
[2024-05-17 20:50:58] [WARNING] connectI/On to node "node1" (ID: 1) lost
[2024-05-17 20:50:58] [DETAIL]
[2024-05-17 20:50:58] [INFO] attempting to reconnect to node "node1" (ID: 1)
[2024-05-17 20:51:08] [ERROR] connectI/On to database failed
[2024-05-17 20:51:08] [DETAIL]

repmgr进程尝试连接主节点但通讯失败，通过对数据库日志的分析可以判断数据库运行卡顿造成的集群主节点通讯异常，而此原因往往和操作系统I/O性能相关。后面我们还会提到I/O相关问题，下面继续分析

操作系统message日志：
几乎在数据库异常同时，操作系统显示kingabse进程发生core dump，但最终进程超时退出。
May 17 20:50:48 new-oadb1 kernel: [5] kingbase[8]: segfault at 500000256 ip 000000000097e..................................
May 17 20:50:48 new-oadb1 kernel: [58030] Code: 89 6d 18 4c 89....................(此处忽略程序崩溃地址信息)
May 17 20:50:48 new-oadb1 systemd[1]: Started Process Core Dump (PID 6/UID 0).
coredump超时退出,此处也有可能和I/O相关
May 17 20:55:48 new-oadb1 systemd[1]: [email protected]: Service reached runtime time limit. Stopping.
May 17 20:55:51 new-oadb1 systemd[1]: [email protected]: Failed with result 'timeout'.

至此已经没有更多的信息，如果希望继续分析，我们需要更多的信息支持，例如操作系统资源使用情况。
随后我联系现场收集nmon日志并继续分析。具体信息图片不方便暂时，所以我用文字描述代替。

nmom查看MEM：
memfree（空闲物理内存）突然降低：
从20:51:04的22199.2
到20:51:34的4996.8往后一直降低
20:52:04降低到1GB左右
这里swap显示为0，这个操作系统没有启用swap内存。

查看DISK_SUMM：
Disk Write KB/s从几十KB/s突然增加达到280791.8KB/s

查看PROC：
20:51:04 pswitch从700多增加到14000多，这个数字与进程切换相关。这个指标增加很有可能是并发进程数增加。
从这个时间开始，block的进程也从0慢慢增长。

查看TOP：
相同的kingbase进程占用resset物理内存数量从20:51:04开始一直增长，从之前的1041060增加到14109520，22886728....这是十多倍的增长速度。
其他kingbase进程相同现象。经询问现场情况，这些kingbase进程是客户端的连接进程，不是数据库后台进程。

查看VM：
VM几个关键指标说明：
20:51:04这几个指标都有明显的增长。
在Linux的内存管理和监控中，nr_mapped、nr_writeback、pgpgout、pgfree 和 pgalloc_normal 是与内存使用和分配相关的关键指标。以下是这些指标的详细解释：

nr_mapped:
意义：nr_mapped 通常表示当前系统中被映射到进程地址空间的文件页的数量。当一个文件的部分或全部内容被读取到内存中时，这些内存页会被标记为“映射”（mapped），以便进程可以访问它们。
相关信息：在Linux中，文件通常不会直接加载到进程的地址空间，而是使用一种称为“内存映射”的技术。这种技术允许进程像访问内存一样访问文件内容，提高了访问速度和灵活性。
nr_writeback:
意义：nr_writeback 表示当前正在等待被写回到磁盘的脏页的数量。脏页是指已经被修改但尚未写回到磁盘的内存页。
Linux writeback机制：Linux采用了一种称为writeback的机制来处理脏页。当内存页被修改后，它们会被标记为脏页，并等待内核在适当的时机将其写回到磁盘。这个过程是异步的，以避免因频繁的磁盘I/O操作而影响系统的整体性能。
触发时机：内核会在多种情况下触发writeback操作，如当系统空闲、脏页数量达到阈值或进程显式调用sync/fsync等系统调用时。
pgpgout:
意义：pgpgout 表示从主存（内存）写入块设备（如硬盘）的页面数量。这通常发生在内存页需要被替换或回收时，其内容被写回到磁盘上的交换空间或文件系统中。
与pswpin/pswpout的区别：pgpgout主要关注主存与块设备之间的页面写出操作，而pswpin和pswpout则关注虚拟内存中从块设备swap区中读入/读出的页面，这个造作系统没有启动虚拟内存，该值均为0.
pgfree:
意义：pgfree 表示被释放到空闲内存列表中的页面数量。当系统检测到有内存页不再需要时（例如，缓存数据过期或被替换），这些页面会被释放回操作系统，以便其他进程或系统组件可以使用。
作用：pgfree是Linux系统中一个非常重要的内存管理操作，它有助于有效地管理内存资源，避免内存泄漏和浪费，提高系统的稳定性和性能。
pgalloc_normal:
意义：pgalloc_normal 表示在normal内存区域中成功申请的页面数量。在Linux中，物理内存被划分为多个区域（zones），每个区域有不同的属性和用途。normal区域是其中之一，通常用于存储大多数进程和数据的内存页。
内存分配与回收：当进程需要内存时，它会向操作系统申请一定数量的内存页。如果系统中有足够的空闲内存，操作系统会为该进程分配相应的内存页，并更新相应的计数器（如pgalloc_normal）。如果系统内存不足，操作系统可能会采取一系列措施来回收内存，如通过页面交换（swapping）或页面压缩（compactI/On）来腾出更多的内存空间。
归纳：
这些指标共同反映了Linux系统内存使用、分配和管理的各个方面。通过监控和分析这些指标，管理员可以更好地了解系统的内存使用状况，诊断潜在的性能问题，并进行相应的优化和调整。
注意：如果这些指标（nr_mapped、nr_writeback、pgpgout、pgfree、pgalloc_normal）在同一时间都在增长，这通常表明系统正在进行大量的内存操作和磁盘I/O活动。

原因推断：
1、物理内存不足：

系统正在尝试通过页面调度来释放物理内存，以满足新的内存需求。(pgpgin/pgpgout增加)
2、进程内存使用不当：

某些进程可能占用了大量内存，导致系统频繁地进行页面调度，这里可对应之前我们在TOP页分析的kingbase进程占用内存不断增加的情况。
被写回到磁盘的脏页的数量增加：怀疑此时数据库有大量更新操作导致脏页数据急剧增加，影响系统I/O性能。
3、磁盘I/O瓶颈：由于大量的页面被写出到磁盘（pgpgout），磁盘I/O可能成为瓶颈，进一步影响系统性能；被写回到磁盘的脏页的数量增加，怀疑此时数据库有大量更新操作导致脏页数据急剧增加，影响系统I/O性能。
潜在影响，性能下降：
频繁的页面调度和I/O操作会消耗操作系统资源，导致系统响应变慢。
物理内存被kingbase进程占用太多导致数据库响应不及时，影响业务进行。

三、问题解决方案

增加物理内存：
增加操作系统的物理内存是最直接的解决方案。这可以显著减少页面调度的频率，提高系统性能。当然要同时增加数据库共享内存shared_buffer
优化应用程序：
评估和优化应用程序的内存使用模式，确保它们有效地使用内存并避免不必要的内存分配。合理规划前端会话连接时长，避免空闲会话长时间不释放占用物理内存。
建议使用连接池管理连接数量，连接时长等,避免大量连接会话并发写入，导致脏页过多，消耗大量I/O资源。
调整系统参数：
调整操作系统的内存管理参数，增加了swap空间，以前是0，建议增加30G左右的swap，以影响系统使用交换空间的倾向。
监控和调整工作负载：
对于高内存需求的进程，考虑使用资源限制或优先级调度来优化工作负载分配。避免高内存消耗使用数据库出现coredump的情况。
考虑使用更快的存储设备：
如果磁盘I/O成为瓶颈，考虑使用SSD等更快的存储设备来提高I/O性能。
数据库会话监控部署，kwr部署，监控TOP SQL等

四、总结

当操作系统出现memfree降低、pgpgout增加和大量I/O写入等情况时，通常意味着系统正在经历内存压力。通过增加物理内存、优化应用程序、调整系统参数、监控和调整工作负载以及考虑使用更快的存储设备等方法，可以有效缓解这一问题，提高系统性能。