因表并行引发的血案【故障处理案例】

1 说明

某天值班，收到应用反馈说有个测试库最近每天都出现接口超时情况，请求排查。

虽说这个库是一个测试库，但承载着核心系统订单模块的回归测试、新功能验证等核心测试场景，最近系统很卡：

接口超时导致第三方无法完成每日既定的测试用例，可能影响后续版本的上线计划，用户体验极差，抱怨频繁。

2 处理措施1

2.1 检查进程数

根据该 11g RAC 集群的历史维护记录，此前曾因最大进程数设置过低（原设 2000）导致进程数满，进而引发接口超时，后来将节点 1 的processes调整为 5000。

查看参数设置情况：

节点2的最大进程数只有1000，当时基于ASH判断节点 2 业务量低（峰值小于 1000），便未同步调整，保持 1000 不变。

查看近期节点1历史进程数：

可以看到，节点 1 每天中午 12 点左右，当前进程数会都会超过 4000 左右，距离 5000 的上限仅差几百，接近满负荷；而9月3日这天，当前进程数的峰值更是达到4985，这时候新进程完全是连不上节点1了，导致接口连接超时。

再查看节点2进程数：

而节点 2 的进程数在相同时间峰值最高仅 760，远低于 1000 的上限，两个节点的负载差异悬殊，大量应用连接集中在节点 1，导致节点 1 进程数频繁接近阈值。

2.2 调整参数

既然节点 2 存在资源冗余，且节点 1 负载过高，决定将节点 2 的最大进程数同步调整为 5000，然后将节点1部分的业务连接分流到节点2，以提升整体资源承载能力。

修改参数：

bash 复制代码

# 关闭实例2
srvctl stop instance -d xxx -i xxx -o immediate

# 启动实例2到nomount状态
srvctl start instance -d xxx -i xxx2 -o nomount

# 修改参数
alter system set processes=5000 scope=both sid='xxx2';

# 关闭实例2
srvctl stop instance -d xxx -i xxx -o immediate

# 启动实例2
srvctl start instance -d xxx -i xxx2

由于processes是静态参数，需重启实例才能生效。

2.3 服务调整

调整参数后，如何快速把一部分应用连接分到节点2？

肯定不能让应用去改代码，最快的办法就是调整服务，修改主节点。用以下脚本可以直观看出各个服务的负载占比情况：

可以看到，节点 1 上有两个核心服务的DBTIME占比分别为 55.69% 和 44.29%，合计达 99.98%，几乎所有应用连接都集中在这两个服务上。

为分摊负载，决定将其中一个服务的主节点从节点 1 切换为节点 2，操作如下：

bash 复制代码

# 将服务改为主2备1
srvctl modify service -d xxx -s xxx -modifyconfig -preferred xxx2 -acailable xxx1

# 把服务从xxx1节点切换到xxx2
srvctl relocate service -d xxx -s xxx -i xxx1 -t xxx2

操作完成后，让应用重启相关服务关联的应用进程，因应用端会复用旧连接，仅调整服务配置无法让现有连接切换，重启后新连接才会优先分配至节点 2。