运维排查相关技术文章

php mysql shell go vue css api接口对接支付接口对接

把 ABNORMAL 归进失败分支之后：重复建实例、误告警和一次 nodemanager 自杀

把 ABNORMAL 归进失败分支之后：重复建实例、误告警和一次 nodemanager 自杀
2026-11-01 00:03:35
状态字段 ABNORMAL 和 FAILED 并列，不是失败终态。从 ModelArts pod status、VIAS task_state、BCC serverEventStatus 三份枚举出发，加上 MindIE-Motor PR #334 里快照恢复后过期 abnormal status 导致 nodemanager 自杀的案例，给出终态/聚合态/瞬时态三分判据与排查顺序。
ABNORMAL 状态机接口对接枚举值运维排查

php -S 长跑后的 fd 泄漏与 pcntl 丢信号：三个只在容器里出现的故障

php -S 长跑后的 fd 泄漏与 pcntl 丢信号：三个只在容器里出现的故障
2026-10-30 21:05:34
三条只在长跑进程里暴露的故障：内建服务器每处理一个静态文件 HEAD 请求泄漏一个 fd、accept 前 RST 导致崩溃、部分写后错误页截断；pcntl_signal_dispatch 在异常挂起或处理器抛异常时丢弃排队信号；pcntl_fork 后 /proc/self 仍解析到父进程。附复现命令与容器内的坑。
PHP CLI pcntl 运维排查

MySQL 死锁不报 1213：先确认 innodb_print_all_deadlocks 有没有开

MySQL 死锁不报 1213：先确认 innodb_print_all_deadlocks 有没有开
2026-09-21 21:04:15
线上死锁常伪装成连接超时而非 1213。本文整理 MySQL 死锁的六种定位手段（错误日志、SHOW ENGINE INNODB STATUS、performance_schema、慢查询联动等）、常见根因类型，以及 innodb_lock_wait_timeout 与 innodb_deadlock_detect 的取舍。
MySQL 死锁 InnoDB 运维排查

LVS 四层负载均衡 + gRPC 长连接：8 台后端只有 1 台扛 CPU，78 条连接扛住 6000 QPS

LVS 四层负载均衡 + gRPC 长连接：8 台后端只有 1 台扛 CPU，78 条连接扛住 6000 QPS
2026-09-20 20:01:58
keepalived + LVS DR 后端 8 台 gRPC 服务，CPU 却总有一台冲到 90%+:78 条活跃连接扛着 6000 QPS,30 秒只有 9 次 TCP 建连。根因是四层 LB 的公平粒度是「连接」不是「请求」。本文用 ipvsadm、tcpdump SYN 抓包逐层定位，给出 MaxConnectionAge 连接轮换、L7 兜底与连接倾斜巡检脚本。
LVS gRPC 负载均衡运维排查 keepalived Nginx 6G

跨洋主从复制延迟 300 秒：sysctl 把接收窗口焊死在 42KB

跨洋主从复制延迟 300 秒：sysctl 把接收窗口焊死在 42KB
2026-09-20 20:01:10
MySQL 跨洋主从复制平时延迟为 0，一跑归档批处理就飙到 300 秒。根因是从国内同城机房抄来的 sysctl 把 net.core.rmem_max 焊死在 87380，152ms RTT 下接收窗口只有 42KB，吞吐被压到 279KB/s。本文用 ss -tinm 逐层定位，按 BDP 重算内核参数，并给 binlog 开 zstd 压缩。
MySQL 主从复制 TCP调优运维排查 sysctl binlog 报表调优

大家都在搜索什么？

devops 易支付一个官网+多少钱统一接受回调统一回调 python sub node 宝塔日志 mysql shell ElasticSearch css vue api接口对接 2025 支付接口对接 go php php回调