ANBOB™

最近操作系统的问题有点多，上周有套Oracle数据库RAC部分节点的日志在频繁输出“systemd-logind: Failed to start user slice user-1002.slice, ignoring: The maximum number of pending replies per connection has been reached (org.freedesktop.DBus.Error.LimitsExceeded)” 信息，找我协助分析一下。

ile cache用于缓存文件数据的最小和最大内存数量由可调的内核参数filecache_min(5)和filecache_max(5)控制。参数filecache_min指定的部分内存专门用于加速文件I/O活动。内存不能用于任何其他目的，即使它不需要缓存文件数据。参数filecache_max指定filecache的最大大小。

近日一客户应用反馈数据库使用较慢，每个数据库的性能分析应该先从操作系统负载分析开始，当CPU耗尽时，其它指标可能失真变的没有意义， 当系统缓慢时不应仅从DB里找原因，数据库中几乎无负载，查看OS层发现idle接近个位数， 操作系统为AIX， 从OS层定位top process的命令通常有topas, ps, vmstat,nmon -t等，发现ps和topas显示cpu占比存在较大差异，4%和90%. 简单记录一下。

对于oracle、Postgresql都建议配置Hugepages， 通常RHEL linux上看到的hugepage size默认都是2M, 并且在Oracle 19c的db alert log中实例启动时有对于hugepage 使用个数的提示， 但是只有4k, 2M， 最近发现一客户IBM linuxone环境的Linux默认hugepage size为1MB(for IBM Z the hardware page size is 1 MB.), 那在配置hugepage时， DB alert log关于hugepage会如何显示？

当前数据库种类较多，像oracle等闭源数据库在诊断特殊疑难问题时需要分析内部C函数的call stack， 目前的oradebug short_stack或errorstack,linux系统中的pstack只是dump当前的调用， 还有现在的开源数据库虽然可以查看源代码，但是没法较方便的方法在运行的进程过程中持续跟进多个内部调用的call stack. 增加了故障分析的复杂性和诊断时间， 这里看到了一种使用strace跟踪的方法记录一下。

最近上海某客户一套ORACLE RAC发生1节点驱逐， 问题前CPU利用率并不高， CRS日志有I/O响应和IPC超时错误, 部分进程hang死，操作系统是RHEL7.5, 在操作系统meesage提示如下信息：
“kernel: NMI watchdog: BUG: soft lockup – CPU#25 stuck for 22s!”

一客户的一套ORACLE RAC 2-nodes on AIX, 年迈的大块头25G memory, 平时反馈就非常慢，一日因存储故障实例重启后，有1实例无法启动而另1实例正常，检查启动日志在ASM 实例正在starting后报错， 手动启动ASM 超时报错，ORA-00445: background process “LMD0” did not start after 120 seconds ，这是一个比较古老且常见的问题，

系统资源的最大利用是系统优化的目标，但是过度”优化”系统的容错性就相对较差，如果出现丝毫的卡顿就会“雪崩”，前段时间分析的一个案例，号称是亚洲最好的一套HP小机配置，有Oracle原厂操刀调试的一套Oracle 12c R1环境，不过确实效率很高，突然有一天因RAC 节点之间的private network 高latency导致频繁的 gc 相关等待，从而导致性能问题。

有时跟踪 Data Guard 后台服务很有帮助，因此我们可以查看匹配的 NSSn 和 RFS 跟踪。对于深入研究，我们还希望在 Data Guard 配置的两端运行 tcpdump 捕获，并且可能在中间的网络组件上运行。为了最大限度地减少设备上的处理开销和捕获文件中的噪音，我们希望数据包过滤器尽可能具体。

Linux中CPU负载高必须引起关注，通常需要先查看CPU使用类型，CPU使用分为us(用户进程)还是sy(内核调用)， sys通常不应该超过user , 数据库专用主机主要来自用户级的 CPU 时间（无论是“user”还是“nice”）。因此，当 CPU 时间的大部分时间花在内核（sys）中时，这表明出现了问题, %sys一般也不超过10%, 但是%sys超高这样的问题遇到好多次，原因有：NFS4 bug、 swap IO、安装了linux杀毒如卡巴斯基、3rd party modules、NUMA、cpu 中断、内核参数配置错误等

有个客户的多套RAC节点总是频繁的重启， 故障并没有时间规律，环境Oracle RAC 11G r2 ON OEL 6.9 , 当然首先建议要排除一些硬件共性的配置，如是否电源电压不稳?机器所在区域空调是否差? 是否同一个宿主机上的VM? 硬件是否有报错？ 一线同学说都排查过也做了些调整并未解决。 下面分享一些处理建议。

Trace File Analyzer(TFA) 是oracle用于分析和收集日志的程序，可以安装在独立或集群节点的数据库节点上。从Oracle12.2开始，这个工具包含在 RDBMS 软件中，当我们运行 root.sh 脚本时，这也是可选的，如果不需要，我们仍然可以跳过它,从19c开始Oracle将ORAchk，EXAchk，TFA等多个诊断工具合并入Autonomous Health Framework(AHF)，作为一个独立的安装软件，也被集成到了RAC安装介质中，AHF可以使用root或者非root用户安装，但是用root可以收集更全的日志

A core dump is an image copy of a processes state at the instant it ‘aborted’. It is produced in the form of a file called ‘core’ usually located in the current directory.

OSW工具不用多说oracle数据库环境建议采集OS系统数据的脚本集， 采集的数据可以拿到其它机器，如WINDOWS上分析输出图形， 在ORACLE 12c后 AHF自动健康框架中已自带， 同时还有oracheck等，当troubleshooting时使用tfactl 可以一并收集相对全面的日志数据,几年前记录过2篇OSW，不做过多介绍，这里简单记录一下在Windows上使用oswbba.jar分析时的一些小问题。

一套oracle single instance on AIX环境，数据库未启动，客户硬件只是扩容了内存OS重启后，sqlplus启库无法登录，sqlplus / as sysdba命令挂起。

1, rename sqlnet.ora
2, 检查了/etc/hosts
3, 尝试了listener可以启动

最近同事遇到一个案例，Oracle数据库频繁重启，数据库日志也是各种后台进程IO hang, 环境VMWARE，RHEL6, multipath, 华为存储。iostat显示问题时间段共享存储设备io 为0，%util 100%. RHEL官方有过相同案例，这里简单的记录。

Oracle 希望在数据库主机CPU使用率枯竭时，尽可能让核心的几个后台进程可以最大优先级获取CPU, 当然CPU过高会导致I/O 响应时间变长和网络延迟增加，也会间接影响数据的整体性能, 使用ps -c在查看LMS时发现没有在RT模式引起了注意，在19c中 LMS还是有一些变化，下面简单的记录

The received warning means the kdump operation might fail and the crashdump parameter should be configured correctly. This is the procedure of kdumping:

The normal kernel is booted with crashkernel=… as a kernel option, reserving some memory for the kdump kernel. The memory reserved by the crashkernel parameter is not available to the normal kernel during regular operation. It is reserved for later use by the kdump kernel.
The system panics.

最近查询时发现一套Linux(Suse Linux 12)平台上的Oracle主机CPU使用率偏高，该数据库并不繁忙，从top中发现大量的systemd-udevd 进程，是CPU的主要花费进程， 该现象并不局限于Suse，RHEL和OEL同样可能存在这些现象， 通常是当udev加载时，即使系统当前并无任何磁盘存储的调整，也会存在该现象。

最近遇到一个案例AIX 7.2 挂转NFS v3(源为Suse 11), RMAN restore 控制文件到NFS上 hang， 检查了AIX端mount选项和权限一切正常，在oracle用户下同样可以cp 和vi 文件，最终发现是因为rpcbind服务未启动导致，简单记录。