操作系统资源使用类问题 内存不足问题 问题描述 操作系统内存不足,导致数据库运行异常。 可能影响 可能会导致执行的SQL因申请不到内存报错; 可能会导致新建连接无法建立; 可能会导致操作系统主动KILL掉数据库进程,导致数据库异常重启。 解决步骤 1. 执行shell命令 free h,查看内存整体使用情况 > free命令输出结果示例: total used free shared buff/cache available Mem: 14G 2.3G 195M 5.7G 12G 6.6G Swap: 0B 0B 0B Linux操作系统的内存主要看内存大小,剩余内存是否足够。在Linux中经常发现空闲内存很少,似乎所有的内存都被系统占用了,表面感觉是内存不够用了:Linux系统默认的设置倾向于把内存尽可能的用于文件cache,所以在一台大内存机器上,往往我们可能发现没有多少剩余内存。 对于操作系统,free命令显示出的空闲内存,应该更多关注/+ buffers/cache: 这表明了你的系统可能还剩余的空闲内存。对于应用程序来说,buffers/cached占有的内存是可用的,因为buffers/cached是为了提高文件读取的性能,当应用程序需要用到内存的时候,buffers/cached会很快地被回收,以供应用程序使用。 同时,我们应关注是否用到了swap,当前服务器内存配置足够,通常在数据库服务器上需要关闭swap使用,避免因使用到swap导致性能下降。 2. 通过top o %MEM查看内存使用情况,及内存使用排名TOP的进程 top命令输出结果示例: 这里是按%MEM内存使用TOP排名的结果,可以查看对应的命令和进程ID,进一步分析原因,并进行针对性优化。 3. 或者,通过ps auxsort rnk 4head 5 查看内存使用排名TOP5的进程 ps aux命令输出结果示例: 4. TeleDB数据库常见内存不足问题及解决办法: 1)非数据库进程占用较大内存,如已知的在多个项目中遇到麒麟V10系统auditd服务占用大量内存问题,导致数据库实例运行异常 解决办法: a、麒麟V10系统已有补丁,可联系麒麟厂商升级补丁解决; b、在更新操作系统补丁前,需要关闭操作系统的auditd服务,并设置为服务不自动启动。如有安全要求,不能关闭audited服务,则必须有方案来定期重启auditd服务。 a)关闭audited服务方法: 用root用户执行以下命令来关闭auditd服务: systemctl stop auditd systemctl disable auditd b)或者root用户下配置定时任务来自动重启auditd服务,例如,每天凌晨1点重启: crontab e 0 1 systemctl restart auditd > /dev/null 2>&1 & 需要确保root用户可重启auditd服务,验证定时任务已生效。 如重启服务有如下提示: Failed to restart auditd.service: Operation refused, unit auditd.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status auditd.service' for details. 可通过注释/usr/lib/systemd/system/auditd.service文件中RefuseManualStopyes,然后执行 systemctl daemonreload 重新加载生效。 2)分区表过多,分区的catalog cache占用大量内存,特别需要注意并不是explain里面已经裁减了就代表relcache也裁剪了; 解决办法: a、控制分区表使用数量,表分区的目的主要拆分大表,降低维护成本,TeleDB分布式数据库,可通过多组DN节点,达到同样的目的,在部分情况下可以不使用分区表,或者减少分区数量; b、分区表的SQL语句应该尽量使用分布键+分区键条件,尽量缩减访问范围,避免因未使用分布式键、未使用分区键导致的SQL重分布问题、读取全部分区的问题; 3)业务使用了大量长连接, 并且没有设置连接的生命周期, 或者生命周期很长. 连接时间越长, 访问的元数据积累越多, 导致每个会话的私有内存较大。 解决办法: a、降低应用到数据库的总连接数, 并且设置连接的生命周期(例如, 一个连接最多使用15分钟后自动释放); b、业务侧做好连接管理,通过连接池限制连接数上限; c、数据库层面做好连接管理,定期清理空闲连接、长时间未执行结束的SQL; 4)设置了较大的workmem或hashmemmultiplier, 并且有大量SQL使用了hash agg或hash join, 导致内存消耗过多; 解决办法:调小workmem或hashmemmultiplier. 业务层减少此类请求的并发量。此类SQL使用PG HINT把hash agghash join改成group agg或merge join等。 5)数据库有性能问题, 高峰期引起了雪崩, 并且应用程序配置的连接池上限较大, 导致向数据库请求了大量连接, 最终耗费大量内存引起OOM; 解决办法: a、降低应用到数据库的总连接数, 并且设置连接的生命周期(例如一个连接最多使用15分钟后自动释放); b、设置数据库或USER的connection limit, 限制用户或数据库级别的连接数上限; c、收集SQL并分析优化。 6)业务量未预期突增,服务器内存规划不足 解决办法:调整部署策略,如: a、更换配置更高的服务器,提供更多的内存; b、提供更多的服务器,将CN、DN节点扩容或调整到更多服务器上,降低单台服务器负载; c、可能原规划单能服务器上有主、备节点混部情况,在发生切换时,有服务器上存在多个主节点,主节点有业务流入,需要更多的内存,导致高峰期内存不足;建议重新规划部署,充分考虑此类情况下的服务器资源使用情况; 7)开启资源隔离,实例节点分配内存资源预估不足,导致OOM 解决办法:优先尝试优化;在资源需求充分评估后,扩容实例资源; 8)操作系统内存相关参数配置不合理,导致操作系统内存无法充分利用 解决办法:原因可能是vm.overcommitmemory配置为2,同时overcommitratio配置较小,导致操作系统有足够的内存,但无法使用; 例如: sysctl a grep i vm.overcommitmemory 看到为2,也就是关闭了overcommmit overcommitratio 配置为50%,这样只能用系统一半的内存 通常推荐不要关闭overcommit,vm.overcommitmemory应配置为0。
来自: