作者小头像 Lv.3
更多个人资料
269 成长值
0 关注
0 粉丝
+ 关注 私信

个人介绍

这个人很懒，什么都没有留下

感兴趣或擅长的领域

暂无数据
个人勋章
  • 活跃之星
成长雷达
245
24
0
0
0

个人资料

个人介绍

这个人很懒，什么都没有留下

感兴趣或擅长的领域

暂无数据

达成规则

以上满足项可达成此勋章

  • 博客
  • 关注
  • 粉丝
  • 论坛
全部时间
全部时间
最近三天
最近一周
最近一月
  • 全部
  • 暂无专栏分类
Nginx 的 worker_connections 调大了还是 502，问题可能在 upstream keepalive
并发上不去，很多时候不是 worker 不够，是 upstream 连接没复用。现象upstream_resp_time 正常，但大量连接处于 TIME_WAIT，端口耗尽后新连接失败。处理在 upstream 块里配 keepalive 32，并让 proxy_http_version 1.1，同时清掉 proxy_set_header Connection close。三者缺一不可。验证...
Nginx
作者小头像 yd_286814013 2026-11-09 10:13:49
1
0
0
2026-11-09 10:13:49
1
0
0
Go 的 context 到底该怎么传，三个常见误用
context 不是万能的取消开关，用错会让超时链路断掉。一、把 context 存进 structcontext 应当作为函数第一个参数显式传递，塞进结构体字段会导致生命周期失控，调用方无法取消。二、用 context.Background() 新建而没有父级下游拿不到上游的 deadline，上游超时了下游还在跑。正确做法是从入参 ctx 派生 context.WithTimeout。三...
作者小头像 yd_286814013 2026-11-08 08:09:58
0
0
0
2026-11-08 08:09:58
0
0
0
Kubernetes Job 的 backoffLimit 和 restartPolicy 组合，踩过才知道的四个坑
批处理任务用 Job 跑，最容易被 backoffLimit 和 restartPolicy 这两个字段的组合绕进去。下面四个场景都是实际踩过的。一、restartPolicy 只能是 OnFailure 或 NeverJob 的 pod 模板里写 Always 会直接被 API Server 拒绝。想让任务失败后重试，就得用 OnFailure，让容器在同一个 Pod 里重启。区别在于：O...
Kubernetes
作者小头像 yd_286814013 2026-11-07 08:17:04
7
0
0
2026-11-07 08:17:04
7
0
0
iptables 和 nftables 混用后规则不生效，先确认流量走了哪张表
同一台机器上，旧的 iptables 规则和新的 nftables 规则同时存在时，最容易出现的情况是：规则写进去了、`iptables -L` 也能看到，但流量就是不按预期走。先分清当前系统实际在用哪个后端：```bashiptables --version          # 显示 (nf_tables) 说明 iptables 已经是 nftables 的前端update-alter...
作者小头像 yd_286814013 2026-11-06 00:07:46
7
0
0
2026-11-06 00:07:46
7
0
0
Kubernetes 里 ConfigMap 改了但 Pod 没生效，四个容易被忽略的原因
改完 ConfigMap 直接等 Pod 自动更新，是很多人踩过的坑。ConfigMap 以卷方式挂载时确实会自动同步，但进程读的还是启动时那份；以环境变量注入时根本不会更新。下面按排查顺序列四个原因。一、用环境变量注入的，永远不会热更新envFrom / valueFrom.configMapKeyRef 只在容器启动时求值一次。改完 ConfigMap，Pod 里进程看到的还是旧值，必须...
Kubernetes
作者小头像 yd_286814013 2026-11-05 15:33:44
13
0
0
2026-11-05 15:33:44
13
0
0
Nginx 反向代理偶发 499，先分清是客户端断开还是后端超时
线上 Nginx 的 access log 里偶尔出现 499，很多人第一反应是“后端慢”，但 499 的定义是客户端在服务端返回响应之前就关掉了连接，它和后端超时是两件事，处理方向完全不同。先说怎么区分。看三条信息：request_time、upstream_response_time、upstream_status。如果 request_time 很小（几十毫秒）且 upstream_r...
Nginx
作者小头像 yd_286814013 2026-11-04 13:52:28
14
0
0
2026-11-04 13:52:28
14
0
0
Kubernetes Ingress 报 502，从 upstream 超时查到连接复用
线上一个 Java 服务迁到 K8s 后，Ingress 偶发 502，后端 Pod 日志里却啥都没有。这类"网关报错、应用无感"的问题，八成不是应用代码，而是网关和上游之间的连接层。下面是我这次排查的完整顺序。第一步，先分清 502 是谁给的。nginx-ingress 的 access log 里 502 有两种来源：一种是 upstream 连接建立失败（connect() faile...
Kubernetes
作者小头像 yd_286814013 2026-11-03 00:24:37
27
0
0
2026-11-03 00:24:37
27
0
0
数据库连接池被占满，三分钟从监控定位到具体 SQL
线上突然大量报错，日志里清一色是获取连接超时。这时候先别急着重启，重启只是把所有等待中的请求一起掐掉，十分钟后大概率复发。按下面四步走，通常三分钟内能锁定是哪类 SQL 把池子耗干了。第一步，确认是「池子小」还是「有人不还」。看连接池监控的三个数：活跃连接数、空闲连接数、等待队列长度。活跃数长时间顶在 maxPoolSize 上、等待队列持续增长，说明池子被占满；如果活跃数不高但等待队列很长...
SQL 数据库
作者小头像 yd_286814013 2026-11-02 12:33:04
27
0
0
2026-11-02 12:33:04
27
0
0
MySQL 索引下推（ICP）什么时候生效，什么时候反而更慢
索引下推（Index Condition Pushdown，ICP）是 MySQL 5.6 引入的优化，把本该在 Server 层做的条件过滤下推到存储引擎层，减少回表次数。但它不是万能开关，有些场景打开反而更慢。先说原理。没有 ICP 时，存储引擎按索引找到主键后全部回表，把整行交给 Server 层，再由 Server 层用 WHERE 里的条件过滤。有了 ICP，存储引擎在索引上就能用...
MySQL
作者小头像 yd_286814013 2026-11-01 00:44:23
33
0
0
2026-11-01 00:44:23
33
0
0
Kubernetes Pod 一直 CrashLoopBackOff，按这五步定位
CrashLoopBackOff 不是一个独立故障，它是 kubelet 反复重启容器后给出的状态。真正的原因永远在 pod 的上一轮生命周期里，所以第一步不是看状态，是看现场。第一步，看退出码。kubectl describe pod 里 Last State 的 Exit Code 是关键。退出码 0 或 1：应用自己崩了，多半是配置缺失或依赖连不上。退出码 137：被 SIGKILL，...
Kubernetes
作者小头像 yd_286814013 2026-10-31 11:37:38
35
0
0
2026-10-31 11:37:38
35
0
0
总条数：18
10
10
20
50
100
  • 1
  • 2

上滑加载中

https://www.baidu.com/s?ie=utf-8&f=3&rsv_bp=0&rsv_idx=1&tn=baidu&wd=sed%20%E6%9B%BF%E6%8D%A2%E5%AD%97%E7%AC%A6%E4%B8%B2&rsv_pq=c7db61a600035dc5&rsv_t=5e19yEsbV9N5fIvdlGRU
作者小头像
作者小头像
快速交付
+ 关注