gc current request等待高需同步排查私网延迟、lms负载和热点块分布；首查私网两两ping avg是否超0.5ms，再查lms cpu及内核栈，最后定位热点段并优化分区与服务绑定。
gc current request 等待高，不是 SQL 写错了或索引没建好，而是当前节点要修改的数据块（current mode）正被其他节点持有，且传输延迟或协调失败导致本地会话卡住——必须从私网质量、LMS 负载、热点块分布三方面同步查，单点优化基本无效。
查私网延迟是否超标（关键第一步）
gc current request 对首跳延迟极其敏感，超 0.5ms 就开始明显恶化。
- 必须用私网 IP（不是 VIP 或 public IP），在所有节点两两之间执行：ping -c 10 <peer_private_ip></peer_private_ip>
- 关注 avg 值，不是 mdev；avg > 0.5ms 就算超标
- 常见死因：交换机 buffer 不足、jumbo frame 全链路 MTU 不一致（混用 1500 和 9000）
- 若某对节点（如 node2 → node3）持续超标，优先检查该链路物理连接和交换机 QoS 设置
看 LMS 进程是否吃满 CPU
LMS 是gc current request 的最终承压点，它负责把 current 块打包发出去。
- 执行：ps -eo pid,ppid,pcpu,pmem,comm --sort=-pcpu | grep lms
- 持续 >50% 就危险，尤其 lms0 或 lms1 单点飙高
- 结合：cat /proc/<pid>/stack</pid> 看内核栈：若停在 kslgetl 或 skgxp_receive，说明锁争用或 UDP 收包卡住
- 检查参数：GCS_SERVER_PROCESSES 是否匹配物理 CPU 核数（16 核建议设 4~6，别用默认 2）
定位是不是热点块引发的连锁阻塞
gc current request 高常伴随 gc buffer busy acquire 和 enq: TX - index contention 同时飙升，这是典型热点信号。
- 查 AWR 的 Segments by Global Cache Buffer Busy，找 top 3 表/索引
- 如果是主键索引或序列字段索引，大概率是写热点（如流水表按时间递增插入）
- 不要只加索引或调 SQL，优先做：
- 表按时间列 range 分区 + 每个分区 local 索引
- 增大
_gc_affinity_time（默认 300 秒），减少主节点频繁切换 - 用
srvctl modify service把写密集型模块绑定到固定节点组
gc current request 无 blocker 卡死，需打 PSU
确认是不是 GC 流量暴增压垮了 UDP 栈
AWR 里gc current block 2-way 高是正常开销，但若 Estd Interconnect traffic (KB) 突增至几 MB/s（比如 24 MB/s），就是异常。
- 检查 OS UDP 缓存：AIX 上 udp_sendspace 应 ≥ (DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4096，且不低于 65536
- 查 db_file_multiblock_read_count 是否设得过大（如 128），全表扫描会触发大量 multi-block gc current request
- 若刚升级过版本（如 10.2 → 11.2），注意 LMS 进程数可能自动下调，需手动统一各实例的 GCS_SERVER_PROCESSES 值
真正卡住的地方，往往不在 SQL 计划里，而在服务路由没对齐、分区策略没覆盖写热点、或者私网 MTU 混用这种“看不见”的配置上。
