结论先行不要从「是不是该调大 max_connections」起手。先判断这是连接泄漏、突发流量，还是慢 SQL 把连接占住，三种情况的处理方式完全不同。调大上限只对第三种有一点缓和作用，对前两种是掩盖问题。第一步：先看还能不能进RDS 控制台的会话管理（DAS）走的是独立通道，不占数据库连接名额，能进就先进去看现场，进不去再从应用侧截断流量。第二步：三个数分出方向show variables like 'max_connections';show status like 'Threads_connected'; -- 当前连接数show status like 'Threads_running'; -- 正在执行的连接数Threads_connected 接近上限、Threads_running 很小：连接都被占着但多数空闲，方向是连接泄漏或连接池配置过大。Threads_running 也接近上限：连接都在干活，方向是慢 SQL 或锁等待堆积。第三步：按来源和状态定位select user, host, command, count(*) c, max(time) mxfrom information_schema.processlistgroup by user, host, commandorder by c desc limit 20;select id, user, host, db, command, time, state, left(info,80)from information_schema.processlistorder by time desc limit 20;看三个特征：某台应用主机的连接数远高于其他主机，说明那台机器的连接池配置有问题，或者某个服务在泄漏。大量 Command=Sleep 且 Time 达到几百上千秒：连接池的空闲回收没生效，或者用完没归还。大量 Command=Query 且 Time 很大：慢 SQL，配合慢日志定位具体语句。第四步：应用侧四个必查项连接池上限乘以实例数是否超过 max_connections。常见错误是一个服务 20 个 Pod，每池 50 个连接，合计 1000，而实例上限只有 800。计算要按所有连这个库的服务求和。空闲连接回收。HikariCP 看 idleTimeout 和 minimumIdle，Druid 看 minEvictableIdleTimeMillis。minimumIdle 设成和 maximumPoolSize 一样，池就永远不会释放空闲连接。泄漏检测。HikariCP 开 leakDetectionThreshold（比如 60000 毫秒），Druid 开 removeAbandoned，能直接在日志里指出是哪段代码借了没还。长事务。事务里套 RPC、循环里逐条写、异常分支漏了 commit，都会让连接一直挂着。临时止血的顺序先固定现场：把 processlist 完整导出一份，杀完就查不到了。只杀长时间 Sleep、来源明确为非核心服务的连接，分批杀，每次几十条，一边杀一边看业务影响。不要重启实例。重启会清掉现场，如果是泄漏，几小时后必然复发，等于白丢证据。扛不住时从入口限流，或者临时摘掉有问题的服务节点，让核心业务先活着。长期处理连接数上限与实例规格绑定，升规格是买余量，不是解决方案。在应用和数据库之间加连接代理，或者用 RDS 的数据库代理，把「应用连接数」和「数据库连接数」解耦。只读流量分到只读实例，主库连接压力直接减半。给 max_connections 和 Threads_connected 配告警，阈值设在 80%，别等到应用报错才发现。

先说一个和直觉相反的结论：华为云 ECS 上 yum/apt 慢，很多时候不该换源。默认配置已经指向华为云的内网镜像，走内网不产生公网流量费，速度也最好。把它换成公网源，慢是必然的，还开始产生流量费。一、先确认默认源是什么# RHEL / CentOS / openEuler / EulerOScat /etc/yum.repos.d/*.repo | grep -E 'baseurl|metalink'# Ubuntu / Debiangrep -rE '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/如果看到 mirrors.huaweicloud.cn 或内网域名，说明本来就是内网源，慢的原因不在源，跳到第三节。如果看到的是 mirror.centos.org、archive.ubuntu.com 这类境外地址，才需要换。二、换源的正确姿势（华为云场景）首选华为云内网源，不要换成第三方公网镜像。同一区域内的 ECS 解析 mirrors.huaweicloud.cn 会走内网链路，延迟低、不计流量费。换的时候有四个细节必须对上，错一个就报错或者装到一半失败：发行版代号：Ubuntu 用 noble / jammy 这类代号，Debian 用 bookworm，CentOS 7 是 centos7 目录。代号写错会返回 404，表现是 Failed to fetch 或 Cannot find a valid baseurl。架构路径：ARM 实例（鲲鹏）的源路径和 x86 不同，直接照抄 x86 的配置会装不上包。GPG 公钥：换源后必须导入新源的 key，否则 apt update 报 NO_PUBKEY，yum 报 Public key not installed。包管理器版本：openEuler、EulerOS 用 dnf；CentOS 8 之后 yum 是 dnf 的软链，配置写法有差异（metalink 与 baseurl 互斥）。三、源没问题但还是慢，查这四个1. DNS 解析慢先用 time nslookup mirrors.huaweicloud.cn 看解析耗时。超过 1 秒说明 DNS 有问题，检查 /etc/resolv.conf 里是否指到了不可用的 DNS。华为云内网 DNS 是 100.125.0.4 之类，被手动改掉的机器会解析超时。2. IPv6 优先导致超时机器没有 IPv6 出口但 /etc/gai.conf 让 IPv6 优先，每次连接都要先超时再回落 IPv4，表现就是每个请求卡几秒。在 /etc/gai.conf 里把 IPv4 优先级调高，或者在源地址里只保留 IPv4。3. 并发下载数太小apt 默认单线程下载，包多的时候慢得明显。可以在 /etc/apt/apt.conf.d/ 下加 Acquire::Queue-Mode "access"; 或者用 apt-fast。yum/dnf 可以调 max_parallel_downloads（dnf 支持，yum 不支持）。4. 带宽本身到了上限固定带宽实例如果带宽只有 1~5 Mbps，装几百 MB 的包就是慢，跟源无关。iftop 或者云监控里看入方向是否跑满。这种情况要么临时升带宽，要么把包先传到对象存储再内网拉取。四、几个常见的「换源换出问题」换了源但不换 key：apt update 全部报 NO_PUBKEY，然后跳过所有包，看起来像源坏了。混着写好几个源：同一个发行版挂两个源，包版本冲突，apt install 报依赖不满足。换源时把旧的全部注释掉。没备份就改：改坏后连 apt 都用不了，恢复只能靠重装。改之前 cp sources.list sources.list.bak。CentOS 7 已停止维护：官方源 2024 年后陆续下架，仍指向 mirror.centos.org 的机器会一直超时，这种情况必须换到 vault.centos.org 或者迁移到 openEuler。小结顺序是：先确认默认源是不是已经指向华为云内网源 → 是就查 DNS、IPv6、并发、带宽 → 不是才换源，换源时对齐代号、架构、GPG key、包管理器版本。多数「装软件特别慢」的根因不在源，而在 DNS 解析和带宽。

三个问题分开答：能在控制台重置，不用重装；重置本身不动数据盘和系统盘里的业务文件；但生效方式和后续能否连上，有几个条件必须满足。一、重置的是哪个密码重置的是操作系统里的账号密码，Linux 改的是 /etc/shadow，Windows 改的是本地账号库。这个过程只写一个文件，不触碰你的业务数据、不重建系统盘、不换镜像，所以数据不会因为「重置密码」这个动作丢失。真正会丢数据的是另外几件事：重装系统、切换操作系统、更换系统盘、误删云硬盘。这几项和重置密码在控制台里离得很近，操作时看清楚按钮名字。二、在线重置还是关机重置华为云 ECS 有两条路径，能不能用在线的方式取决于实例状态：一键重置密码（在线）：要求实例运行中、且已安装并正常运行密码重置插件（CloudResetPwdAgent）。装了的机器在控制台能看到「一键重置密码」入口，提交后几十秒生效，不用关机。关机重置：插件缺失、插件异常、或者镜像本身不支持在线重置时，会提示先关机。关机后重置，再开机生效。插件是否存在可以直接在实例详情里看，也可以登录后查进程。插件缺失不影响关机重置这条路。三、重置完还是连不上，按这五项查这是实际最常见的卡点，密码明明重置成功了，SSH 还是拒绝：sshd 禁止了密码登录。配置文件里 PasswordAuthentication no 时，密码再对也登不进，只能走密钥。要改这个配置得先能进去，或者用 VNC 登录控制台改。禁止 root 直接登录。PermitRootLogin no 的情况下，用 root 重置了密码也登不上，得用普通用户进再 su。账号被锁定。多次输错密码触发了锁定策略（faillock、pam_tally2），锁定状态不会因为重置密码而解除，需要 faillock --reset 或等锁定时间过期。安全组没放行端口。Linux 是 22，Windows 是 3389，重置密码不会改安全组。系统盘满了或变成只读。这时候 sshd 起不来或者写不了日志，表现也是连不上，跟密码无关。排查顺序建议：先在控制台用 VNC（远程登录）试，VNC 能进说明是网络或 sshd 配置问题，VNC 也进不去才是系统层面的问题。四、密钥对丢了怎么办私钥丢失没法找回，控制台不会重新给你一份。两条路：重置密码，然后把 sshd 改成允许密码登录，之后自己重新生成密钥对并把公钥写进 authorized_keys。关机状态下「替换密钥对」，用新密钥注入，开机后直接用新私钥登录。这条更适合批量机器，不用先进系统。五、Windows 实例的差别Windows 重置密码后必须重启才生效，不重启一直是旧密码。另外 RDP 端口要在安全组放行，账号如果在域里还要注意本地账号和域账号的区别。六、动手前建议做的一件事重置密码本身安全，但顺手做个快照成本很低。控制台 → 云硬盘 → 创建快照，几十秒的事。万一后面因为别的操作进不去系统，有快照可以直接回滚，比重新部署省事得多。补充一句判断依据：重置密码属于系统盘内的账号操作，跟数据盘完全无关，只挂在数据盘上的数据在任何情况下都不会受影响。

按踩坑频率排，从最容易卡住新手的开始，每条都给出现象和处置。1. 桶名：创建后就改不了桶名全局唯一（所有华为云账号共享同一命名空间），只能用小写字母、数字、中划线，3~63 位，不能含下划线、不能以中划线开头结尾、不能是 IP 形式。更关键的是桶名和所属区域创建后都不可修改，名字起错只能新建桶再迁数据，数据量大时非常麻烦。命名时把业务、环境、区域都带上，例如 myapp-prod-ap-southeast-3。2. 403 报错：三套权限叠加，逐层排查OBS 的访问控制有三层，任一层不通过都返回 403，新手最容易只改一层就以为好了：身份认证：AK/SK 是否正确、临时 AK 是否过期、签名是否用了正确的 Region 和 endpoint。桶策略 / IAM 策略：桶策略管匿名和跨账号，IAM 策略管本账号子用户，两者是叠加关系。对象 ACL：桶开了「阻止公共访问」时，ACL 里设的 public-read 会被直接忽略，此时只能通过桶策略放开。排查顺序建议：先用 obsutil ls 或 API Explorer 带同一组凭证试，能通就是业务代码的签名问题；不通再看桶策略和 IAM。3. 上传大小与分片规则单次 PUT 上限 5 GB，超过必须用分片上传。分片上传每片 5 MB~5 GB，最后一片可以小于 5 MB，其余片小于 5 MB 会直接报错。分片数最多 10000 片。分片上传后必须调用合并（CompleteMultipartUpload），中途失败会留下碎片，碎片照样占存储和计费。建议同时配一条生命周期规则清理未完成的分片上传。4. 浏览器直传失败：CORS 没配前端用 SDK 直传时，浏览器会先发 OPTIONS 预检，桶上没有 CORS 规则就整个失败，控制台报跨域错误而服务端日志什么都没有。桶设置里加一条 CORS：来源写具体域名（不要图省事写 * 又带凭证），方法至少包含 PUT、POST、GET、HEAD，暴露头加上 ETag（前端做分片续传要用它）。5. 内网 endpoint 与流量费同区域的 ECS 访问 OBS 用内网 endpoint（形如 obs.region.myhuaweicloud.com 的内网域名），走内网不产生公网流出流量费，速度也更好。用公网 endpoint 做同区域数据交换，是账单莫名变高的常见原因。公网流出按流量计费，入流量免费。6. 删除不释放空间：版本控制桶开启多版本后，「删除」只是加了一个删除标记，历史版本还在，存储量不减。真要清理得显式删除所有版本，或者用生命周期规则过期非当前版本。7. 其他高频小事Content-Type 设错：上传时没指定类型，浏览器访问图片会变成下载。上传时按扩展名显式设置 Content-Type。对象名以 / 开头：会生成一个空的对象当「目录」，列表里看着别扭，批量工具容易多算一个对象。归档存储不是随时能读：归档/深度归档要先取回（解冻），有时间和费用，别把需要实时访问的数据放进去。列举性能：单次列举最多 1000 个对象，要翻页；对象数上百万时按前缀分目录组织，别平铺。

选型要算的是「峰值够用 + 平时不浪费」，不是一次性买大。给一套能落地的算法，三步：先量化瓶颈，再按瓶颈选族，最后用弹性手段把成本压下来。一、先量化瓶颈，别看感觉从现有实例的监控取四个数，缺一个都可能选错：CPU：看 5 分钟粒度的 P95 使用率，不看平均值。平均 20%、P95 90% 的机器，平均看着很闲，高峰期已经在排队。内存：看可用内存最低点，同时看 swap 使用量。swap 一旦持续有读写，说明内存已经不够，CPU 会被 IO 拖慢。磁盘 IOPS/吞吐：云硬盘的 IOPS 跟容量挂钩，40G 的通用型 SSD 基准 IOPS 有限，数据库这类随机读写场景很容易先撞 IOPS 墙而不是 CPU 墙。带宽：看外网出方向峰值。带宽跑满时 CPU 和内存都很闲，但用户端就是慢，这种「假性性能不足」最容易被误判成要升 CPU。判断阈值建议：CPU P95 长期高于 70%、内存可用低于 20%、磁盘 await 明显偏高、带宽峰值接近规格上限，这四项里命中哪项就补哪项，不要整体升配。二、按瓶颈选实例族CPU 密集（编译、转码、计算）：计算型，vCPU 与内存比 1:2。内存密集（Redis、MySQL 大 buffer、JVM 堆大）：内存型，1:8。通用业务（Web、中间件）：通用型，1:4。轻负载、低并发（个人站、测试环境、小工具服务）：突发性能型或 Flexus L 这类轻量规格，靠 CPU 积分撑短时峰值。这里有个容易踩的坑：突发性能实例的 CPU 积分是有限的，持续高负载把积分耗尽后会降频到基准性能，表现为「一开始很快，跑一段时间突然变慢」。长期跑满的业务不要选突发型。三、成本怎么压计费方式：按需适合验证期，确定要长期跑就换包年包月，同规格通常能省一半以上；再叠加代金券、折扣，实际支出还能降。先小后调：按峰值倒推规格时，先买满足峰值 70% 的规格，上线后看一到两周监控。云服务器支持升配（部分规格族支持降配），升配比重买便宜，也比一开始买大一直闲置划算。带宽单独算：固定带宽按峰值买，适合流量稳定的站；按流量计费适合有明显波谷的站。很多账单里带宽占比不低，这一项选错比 CPU 选错更费钱。存储分层：系统盘用通用型 SSD 够用，热数据放高 IOPS 盘，冷数据丢对象存储。别把大容量低价值数据放在高性能云盘上。四、验证选完不是结束。上线后按周看 CPU P95、内存最低可用、磁盘 await、带宽峰值四条曲线，连续两周都在阈值的 60% 以下就可以考虑降一档，反过来命中阈值就升一档。用监控数据驱动调规格，比凭经验买大靠谱得多。

安全组只是其中一层放行 80 只解决了「云平台允许这个包进来」，从客户端到进程之间还有五六道关卡。按下面的顺序走，一般三步之内就能定位。第一步：服务到底有没有在 80 上监听ss -lntp | grep ':80'重点看监听地址：127.0.0.1:80 —— 只监听本地，外部永远连不上。改成 0.0.0.0:80（nginx 里是 listen 80; 或 listen 0.0.0.0:80;）。[::]:80 —— 只监听了 IPv6，纯 IPv4 客户端连不上。什么都没有 —— 服务没起来，或者起在别的端口。再在本机自测一次，区分「服务不通」和「网络不通」：curl -I http://127.0.0.1/curl -I http://实例私网IP>/第二步：本机防火墙云上的安全组和操作系统里的防火墙是两套东西，经常只放行了一套。systemctl status firewalld && firewall-cmd --list-allufw status verboseiptables -S | grep -E '80|DROP|REJECT'第三步：安全组规则的四个属性规则看起来放行了，实际不生效，通常是这几个原因之一：方向错了：只加了出方向规则。入方向才是控制别人访问你。协议/端口写错：协议选了 ICMP 或 UDP，或者端口写成 8080。源地址限制：源写成了某个内网段，不是 0.0.0.0/0。没挂对实例：安全组换过、实例有多张网卡时，规则可能只挂在一张网卡上。第四步：网络 ACL（最容易被忽略）安全组保护实例，网络 ACL 保护子网。两者冲突时优先匹配网络 ACL，所以「安全组明明放行了」却不通，很可能是子网的 ACL 规则把包丢了。ACL 有独立的入方向和出方向规则，两个方向都要看。第五步：公网入口本身实例有没有绑定弹性公网 IP？只有私网地址的话，公网当然连不上，要么绑 EIP，要么走 NAT 网关/负载均衡。带宽是不是 0，或者按流量计费但账户欠费——这两种情况下握手会直接失败。如果前面挂了负载均衡或 CDN：后端端口和回源端口要分别放行，健康检查不通过时用户看到的是 502 而不是超时。一条组合拳快速定位从三个位置各测一次，结果组合直接指出问题在哪一层：# A. 本机curl -I http://127.0.0.1/# B. 同 VPC 的另一台机器（走私网）curl -I http://私网IP>/# C. 你自己的电脑（走公网）curl -v --connect-timeout 5 http:///ABC结论通通不通公网入口问题：EIP、安全组入方向、ACL通不通不通本机防火墙或监听地址只绑了 127.0.0.1不通不通不通服务没起来或端口不对还有一种情况值得单独提：A、B 都通，只有你自己的电脑不通，而且换手机热点就正常——那是本地运营商封了 80 出方向，跟云上配置一点关系都没有。

先说结论：按证书来源分三种情况「续费」不等于「延长同一张证书的有效期」。证书是一份不可变的对象，续费的结果是重新签发一张新证书（新序列号、通常也是新私钥），旧证书在新证书生效前依然有效，到它自己的到期时间才失效。所以要不要重新部署，取决于你在哪一层用它。云证书管理服务签发的证书：续费后会重新签发。签发完成不会自动替换到 ELB / CDN / WAF 上，需要手动部署一次，或者事先配置了托管/自动部署。自签或第三方证书：与云平台无关。续费就是拿到新的证书文件，把它替换到 Web 服务器上并 reload。多年期证书：平台按年度重新签发，仍然需要部署，只是不用再走一遍申请流程。为什么必须重新部署服务端加载的是硬盘上的证书文件，不是「域名」这个概念。文件不换，进程里就是旧证书。nginx 改了配置不 reload 也一样。# nginx：替换文件后先校验配置，再平滑重载nginx -t && nginx -s reload部署完怎么验证不要只看浏览器地址栏，直接读服务端实际下发的证书：openssl s_client -connect your.domain:443 -servername your.domain -showcerts

核心：写不在原地覆盖Postgres 的 UPDATE 不是把原行改掉，而是把旧行标记为已删除、再插入一个新行版本。每个行版本都带隐藏列：xmin 记录创建它的事务号，xmax 记录删除它的事务号，ctid 记录物理位置。SELECT 拿到的是事务开始时的一份快照（当时的 xmin、xmax 加上活跃事务列表 xip），顺着这条规则判断"这个版本对我可不可见"。整个过程不申请行锁。UPDATE 只对自己要写的新版本加行级排他锁。读的人和写的人操作的是不同的版本，所以互不阻塞。三个例外：这几种情况读照样被挡SELECT ... FOR UPDATE / FOR SHARE：显式要求加锁，会等写事务提交。DDL：ALTER TABLE 拿的是 AccessExclusiveLock，会排队，并把排在它后面的读一起堵住。线上改表要么用 CREATE INDEX CONCURRENTLY 这类不锁表的写法，要么先 SET lock_timeout 让它快速失败而不是拖死业务。VACUUM FULL、TRUNCATE、CLUSTER 都要排他锁，业务高峰别碰。代价不是锁，是膨胀旧版本不会立刻消失，要等到没有任何事务还能看见它，才能被 vacuum 回收。判断标准是全局的 xmin horizon：所有活跃事务里最老的那个事务号。只要有一个长事务挂着，比它新的死元组全都收不掉——只读事务、开着事务去调外部接口、甚至备库反馈的 backend_xmin，都会把 horizon 钉住。-- 谁在挡住回收SELECT pid, state, backend_xmin, now() - xact_start AS dur, left(query, 60)FROM pg_stat_activityWHERE backend_xmin IS NOT NULLORDER BY age(backend_xmin) DESCLIMIT 5;-- 表级死元组比例SELECT relname, n_live_tup, n_dead_tup, round(n_dead_tup * 100.0 / nullif(n_live_tup + n_dead_tup, 0), 1) AS dead_pctFROM pg_stat_user_tablesORDER BY n_dead_tup DESCLIMIT 10;实际能做的五件事掐掉长事务：设 idle_in_transaction_session_timeout 和 statement_timeout，应用层也不要开着事务去等外部接口。批量删除/更新分批提交。一条删十万行的语句会产生十万个死元组，并且整个过程占着 xmin，期间 autovacuum 无从下手。让 autovacuum 跟得上：对大表单独调 autovacuum_vacuum_scale_factor = 0.02、提高 autovacuum_vacuum_cost_limit，别用全局默认的 0.2。已经膨胀又不敢锁表，用 pg_repack 在线重整，它靠触发器和临时表保持一致性，只在收尾时短暂加锁。尽量制造 HOT 更新：新版本能放进同一页、且被改的列上没有索引，才能省掉所有索引的维护开销。给频繁更新的宽表把 fillfactor 调到 90 左右，给新版本留空间。还有一个不常被提到的点vacuum 不只清垃圾，还负责把老事务号冻结（freeze）。长期不 vacuum 的表会逼近 20 亿事务号上限，触发保护性停机。所以"表不大、没膨胀"也不能完全不管它，监控 age(relfrozenxid) 是必要的。

先说结论：OBS 客户端连接池调优的收益，八成来自"连接被正确复用"，只有两成来自把参数调大。参数调大但连接没复用，只会把问题从"超时"变成"端口耗尽"。一、四个动作，按收益排序1. ObsClient 必须单例复用。它是线程安全的，生命周期应该和进程一致。每次请求 new 一个再 close，连接池等于不存在，每次都要 TCP + TLS 握手，高并发下 CPU 会先被打满在握手上。这一条做不对，后面调什么参数都没用。2. 池大小按并发算，不要凭感觉。maxConnections 是并发 HTTP 请求的上限，估算方式是：maxConnections ≈ 峰值 QPS × 平均 RT(秒) × 1.3。例如 200 QPS、平均 RT 50ms，算下来约 13，取 20 就够；如果你算出来是 400，那是 RT 出问题了，应该先查网络而不是调池。maxIdleConnections 不要小于 maxConnections，否则连接刚用完就被回收，下一秒又重建。3. 超时要分级，不能一刀切。connectionTimeout 应该短（1~3 秒），建连失败要快速失败并重试别的节点；socketTimeout 要按对象大小定，上传 1GB 大对象却只给 60 秒，必然超时。这两个值搞反是最常见的配置错误。4. 重试要有选择性。maxErrorRetry 只对 5xx 和连接超时生效，4xx（403 签名错、404 不存在）重试只会放大压力。重试间隔要有退避，否则故障时会把服务端打得更惨。二、三个容易被忽略的点网关空闲超时比客户端短。如果 NAT 网关或负载均衡的空闲连接回收时间是 60 秒，而客户端 idleConnectionTime 设成 300 秒，池里就会留着一批"本端以为是好的、对端已经关了"的连接，表现是偶发超时、重试后成功。把 idleConnectionTime 调到明显小于链路空闲超时即可。分片上传的并发会挤占连接池。大对象分片上传的 taskNum 用的是同一批连接，分片并发设成 20，业务请求就只能排队。要么给上传单独留配额，要么把分片并发降下来。连接复用率要能观测。至少要采三个指标：池内活跃连接数、空闲连接数、单位时间新建连接数。新建连接数居高不下，说明复用在漏。三、一个可直接用的排查顺序看单位时间新建连接数：高 → 有代码在重复创建客户端或主动关闭连接；看池是否被打满：活跃数长时间等于 maxConnections → 要么池太小，要么下游变慢；看 RT 的分位数：p99 远高于均值 → 先查网络和 DNS，不是池的问题；最后才动参数。参考资料：华为云 OBS SDK for Java - 创建并配置客户端（ObsConfiguration 参数说明）https://support.huaweicloud.cn/sdk-java-devg-obs/obs_21_0101.html