结论先行：只关机不能彻底停费。按量付费 ECS 的账是按资源项分别算的，关机只停其中一项。一、关机后，四项资源各怎么算1. 实例规格（vCPU、内存、镜像）：大多数通用规格关机后停止计费，这就是控制台说的“关机不收费”。但 GPU 实例、本地盘实例、专属主机上的实例等部分规格不支持，关机后仍按原价计费，关机时控制台会有提示，以提示为准。2. 系统盘和数据盘（EVS 云硬盘）：独立计费，只要盘还在就按容量持续收费，和开机关机没有关系。系统盘一般随实例删除，数据盘默认不随实例删除。3. 弹性公网 IP（EIP）：独立计费，关机后继续按购买时的计费方式收费；解绑后如果不释放，还会产生闲置保有费。4. 快照和镜像：超出免费额度的部分按容量持续计费，留着也会出账。二、两种场景，操作不一样场景 A：以后可能还要用，只是暂停。关机就行，算力费用停掉，只剩磁盘和 EIP 的小额费用，数据都在，开机就能用。提醒一点：按量带宽下，关机后再开机公网 IP 可能会变，绑了域名解析的要留意。场景 B：确定彻底不用了。按下面顺序收尾：先给要保留的数据做整机镜像或云硬盘快照并确认可用；再到 ECS 控制台删除实例，删除时确认系统盘随实例删除、数据盘按需一并删除；然后到“弹性公网 IP 和带宽”控制台释放不再用的 EIP；最后到费用中心按产品核对 ECS、EVS、EIP 是否还在出账。三、三个最容易漏的点1. 数据盘默认不随实例删除，删了实例还在为一块盘付费，去费用中心按产品核对最清楚。2. EIP 解绑不等于释放，闲置 EIP 也会收费。3. 按量付费最容易出现“忘了释放”的欠费，建议顺手设一个费用预算告警。一句话总结：关机停的是算力，磁盘和 EIP 不停；彻底不用就备份后删除实例、释放 EIP，再去费用中心对账确认。

先给一个可以直接照着算的办法：前面几楼把“先画像、再压测”的框架讲得很清楚了，这里补三处最容易算错的数。一、不要只看核数，先确认 vCPU 是独享还是共享通用型、计算型是独享 vCPU；突发性能型是共享 vCPU 加积分制，积分耗尽后会被限速到基准性能。个人博客、测试环境用突发性能型很划算，但线上持续跑满的业务用它，月底会发现性能“莫名”掉下来。选型时先看规格说明里的 CPU 模式，再看价格，同一核数下价格差很多往往就是这个原因。二、拿一个具体例子算一遍假设一个小网站：日活几千，峰值并发 100 左右，单请求 CPU 耗时 20ms，常驻内存 1.5GB，数据库和应用放同一台：CPU：100 并发乘以 20ms，2 核基本刚好跑满，留余量就选 2 核起步，峰值水位控制在 70% 以内；内存：应用 1.5GB 加系统与缓存约 1GB，数据库如果同机还要再加，2 核 4GB 会先满内存，这时该选 2 核 8GB 而不是 4 核 4GB，内存配比比核数更关键；磁盘：随机读写多的业务先看云硬盘类型和 IOPS，系统盘和数据盘分开，磁盘先成为瓶颈时升 CPU 是白花钱；带宽：按峰值带宽选，不要按平均值，下载、文件分发类业务尤其要单独算带宽。三、别一次买定，用“按量试一周再转包年包月”先按量计费开一台跑满一周，在云监控里看 CPU、内存、磁盘 IOPS、带宽四条峰值曲线，哪个指标先到瓶颈就补哪个；确认水位后再转包年包月。规格选小了不用重建，可以在控制台变更规格，操作前先做快照、选业务低峰期。这比一开始按峰值买一台大机器便宜得多，试错成本也低。一句话：先分清独享还是共享 CPU，再按“并发乘以单请求耗时”算 CPU、按常驻内存算内存配比，最后按量试水位、按月复核，成本和性能就不用在下单那一刻一次赌对。

前面几位把“先找瓶颈、按瓶颈选系列”讲得很全了，我补充一个容易被忽略的维度：同样的钱，买 1 台大规格和买 2 台小规格，效果差很多。选型之前，先定架构形态，再定单台大小。一、先问一句：这业务能不能水平扩展？Web、API、网关这类无状态服务可以，单机 MySQL、单机 Redis、本地文件依赖强的服务不行。判断方法很直接：把应用停掉一台，另一台能不能接着跑；会话是不是存在本机内存、文件是不是写在本地磁盘。如果这两处都没摘干净，买再多台也扩展不起来，先把会话放 Redis、文件放 OBS，配置用环境变量。二、能扩展时，2 台小规格常常比 1 台大规格划算举个例子：1 台 8 核 16G 和 2 台 4 核 8G 加负载均衡，总核数、总内存差不多，价格要以控制台实时价目为准，通常不会差太多，但差别在三处：一是单台挂了就是全停，两台挂一台还能撑着；二是升级、变更规格可以一台一台滚动做，不用全停业务；三是流量涨了加机器比换大规格快，闲时还能缩回两台。代价也要说清楚：要多管负载均衡和健康检查，定时任务只能让一台跑，别两台重复执行。三、不能扩展时，再老老实实买单台大规格单机数据库、跑批、视频转码、单个进程就要吃满 CPU 的业务，拆多台没意义，就按前面几位说的，先找瓶颈再选系列，留 20%~30% 余量。还有一点：别把应用和数据库挤在同一台机器上，内存和 CPU 互相抢，出问题也不好分清是谁的锅，数据库单独一台，磁盘用高 IO，应用另外算。四、一个能照着走的顺序1. 先确认无状态，会话和文件已摘出去；2. 应用层用 2 台起步加弹性伸缩，起步规格按峰值选够用的小一档；3. 数据库单独选型，别和应用混在一起；4. 上线后在云监控里盯 CPU、内存、磁盘 IO 和响应时间，CPU 峰值长期超过 70% 或响应变慢再加机器，长期低于 20% 就降一档。一句话：能水平扩展的业务，选型重点不在“单台买多大”，而在“能不能多台一起跑”；不能扩展的，才按瓶颈老老实实买单台。先把形态定对，规格大小反而好定了。

4楼把权限、存储类别、版本控制、分段上传讲得很全了，我补充几个新手同样常踩、但4楼没展开的坑，都是我自己或身边同事真实遇到过的：1. 403和404先分清，别一股脑怪权限。访问不到对象时先看状态码：404多半是桶名、区域endpoint或对象键写错了（比如把测试桶的键抄到生产桶）；403才是没权限。只看“打不开”就去改桶策略，容易把私有桶改成公共读，越改越危险。2. 别把OBS当文件系统用。OBS里没有真正的文件夹，控制台看到的“文件夹”只是以 / 结尾的对象键前缀。按文件夹批量删、按文件夹授权时，实际生效的是前缀匹配，写错一个前缀就可能删错一批对象。对象键也别用中文、空格和特殊字符，SDK拼接URL时容易编码不一致，导致上传成功了却下载不到。3. 同名上传直接覆盖，没有确认框。往桶里上传一个和已存在对象同名的文件，旧文件会被直接替换；没开版本控制就找不回来了。重要的配置文件、发版包建议先开版本控制，或者上传前在键里带上日期、版本号。4. 浏览器里直接打开图片、视频却被下载。上传时没设对Content-Type，浏览器就不知道这是图片还是附件，点开就直接下载。上传时按文件后缀设好Content-Type（比如image/jpeg、text/html），需要强制下载时再用Content-Disposition单独控制。5. 前端直传要先配CORS，不然浏览器报跨域。网页里用JS直接往OBS传文件，必须先在桶上配好CORS规则（允许的来源、方法和请求头），否则浏览器会把请求拦掉；只配服务端SDK是不够的。6. AK/SK别写进前端代码和公开仓库。前端直传应该让服务端签发临时凭证或预签名URL，AK/SK只留在服务端；一旦泄露要立刻在IAM里停用、轮换，并检查桶的访问日志有没有异常下载。7. 删桶之前先清空。桶删不掉时，九成是桶里还有对象、历史版本或未完成的分段上传。先在控制台或用工具清掉对象和分段，再删桶；开了版本控制的桶，删除标记和历史版本也要一起清理。新手建议：先用一个测试桶把权限、CORS、生命周期、分段上传各走一遍，确认计费项（存储、请求次数、流量）都看得懂，再往生产桶里放数据。

先说一个前提，再给排查顺序。这个帖子问的是 RDS for MySQL，有一条路在 RDS 上走不通：RDS 不授予 SUPER 权限，不能用 SET GLOBAL 去改 max_connections 这类系统变量，参数要走控制台的参数组改，而且改完是否立即生效、要不要重启，以控制台上的提示为准。另外 RDS 的 max_connections 默认值是按实例内存算出来的，不是固定值，升规格后上限会跟着变，盲目调大也可能把内存问题引出来。所以下面的顺序里，调参数是最后一步，而且是在控制台做的。0-2 分钟：先保住进库通道，别再重试业务已经报 Too many connections 时，不要用新连接反复重试，那会把最后的名额也占掉。用已经建立的连接进，或者走 RDS 控制台的会话管理（DAS 走独立通道，不占业务连接名额）。MySQL 会给有 SUPER/CONNECTION_ADMIN 权限的账号预留一个连接，但 RDS 上你拿不到这个通道，所以 DAS 会话管理就是你的救命通道。一进库先把现场固定下来：把 information_schema.processlist 全量导出来存一份（SELECT ... INTO OUTFILE 或者直接复制到文本里）。杀完就查不到了，复盘全靠这份快照。2-5 分钟：四个数定性，别只看总数SHOW GLOBAL STATUS LIKE 'Threads_connected';SHOW GLOBAL STATUS LIKE 'Threads_running';SHOW VARIABLES LIKE 'max_connections';SHOW GLOBAL STATUS LIKE 'Max_used_connections';SHOW GLOBAL STATUS LIKE 'Connection_errors_max_connections';判读方法：Threads_connected 接近上限、Threads_running 很小，说明连接都被占着但多数空闲，方向是连接泄漏或连接池配得过大；Threads_running 也高，说明连接都在干活，方向是慢 SQL 或锁等待堆积；Connection_errors_max_connections 大于 0，说明确实已经有人被拒绝过；Max_used_connections 接近上限，说明已经没有余量了。再按账号、来源 IP、状态分组，定位大头：SELECT USER, SUBSTRING_INDEX(HOST, ':', 1) AS client_ip, COMMAND, COUNT(*) AS cnt, MAX(TIME) AS max_time_s FROM information_schema.processlist GROUP BY USER, client_ip, COMMAND ORDER BY cnt DESC LIMIT 20;同时看一眼长事务：SELECT trx_mysql_thread_id, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS age_s FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 10;补充一个容易漏的区分：如果是短时间内同一来源反复新建连接，还要看 Aborted_connects 计数和错误日志，区分是业务重试风暴，还是外部在扫端口、暴力破解。前者要从应用侧限流，后者要封 IP、改端口、加白名单，处理方法完全不同。5-10 分钟：应用侧四项必查第一，算连接池总账。所有连这个库的服务，实例数乘以每个实例的连接池上限，再加上定时任务、监控采集、运维工具占的连接，总和要留 20% 到 30% 的余量。常见错误是一个服务 20 个 Pod，每池 50 个连接，合计 1000，而实例上限只有 800。扩容应用副本之前，先算这笔账。第二，空闲回收两端对齐。连接池的 maxLifetime 和 idleTimeout 要小于数据库的 wait_timeout，否则池里会留着已被服务端断开的“死连接”，表现为偶发的 Communications link failure，又会触发重连风暴。第三，泄漏检测。HikariCP 开 leakDetectionThreshold（比如 60000 毫秒），Druid 开 removeAbandoned，能直接在日志里指出是哪段代码借了连接没还。第四，长事务。事务里套 RPC、循环里逐条写、异常分支漏了 commit 或 rollback，都会让连接一直挂着。临时止血：分批杀，别重启只杀长时间 Sleep、来源明确为非核心或已下线服务的连接，分批、逐个 KILL，每次几十条，一边杀一边看业务影响。不要批量杀正在执行的业务连接，更不要重启实例：重启清掉现场，如果是泄漏，几小时后必然复发，等于白丢证据。如果扛不住，从入口限流，或者临时摘掉有问题的服务节点，让核心业务先活着。调大 max_connections 只是最后一步：RDS 上走参数组改，改之前先算内存，每个连接除了线程栈，还会按需分配排序、连接等缓冲区，连接数从几百调到几千，极端并发下内存占用可能成倍上涨。长期治理不同服务用不同数据库账号，必要时用 MAX_USER_CONNECTIONS 限制次要服务，某个报表任务出问题时不会把核心交易的连接名额挤光。只读流量分到只读实例，主库连接压力直接减半。条件允许时用 RDS 数据库代理做连接复用，把应用侧上万条连接收敛成后端几十条。云监控里给连接数使用率配两级告警，70% 到 80% 告警、90% 升级，连续多个周期触发再通知；把 Max_used_connections 和 Connection_errors_max_connections 纳入日常巡检，前者接近上限说明已经没有余量，后者大于 0 说明确实有人被拒过。最后把“连接池总账”写进变更检查项，下次应用扩容前先自查。

补充两个今天刚实测过的坑，前面几楼没提到，正好对应楼主“密钥和密码同时被拒”的情况。一、密码没错也可能被拒：先怀疑输入方式，而不是密码本身今天我在一台 Ubuntu 22.04 的 ECS 上实测：密码里带 !，在网页终端（CloudShell / Theia 终端）里逐键敲密码，三次都报 Permission denied。同一串密码，改用控制台“远程登录”打开的 CloudShell 登录页（HTML 表单框）输入，一次就进去了。结论：密码本身是对的，是网页终端逐键输入时对 ! 这类特殊字符处理不可靠，敲进去的密码和实际密码已经不是同一串了。如果你也是在浏览器里的终端输密码，先别急着重置密码，换两种方式验证一下：1. 用粘贴的方式把密码贴进终端再回车；2. 或者直接用控制台“远程登录”的表单页登录。如果换种输入方式一次就进去了，问题就在输入环节，不在账号和 sshd。二、安全组没放 22 端口，现象是“挂住”不是秒回 denied同一台机器今天还遇到：随实例创建的安全组里只有 ICMP 和自引用规则，入方向根本没有 22 端口，ssh 连上去直接挂起，十几秒后超时。手动加一条优先级 1、允许、TCP 22、源 0.0.0.0/0 的入方向规则，立刻就通了。所以可以拿现象反推：秒回 Permission denied，说明 22 端口是通的，安全组不用查；如果是连上后半天没反应、最后超时，那才优先查安全组有没有放行 22。把这两点加到前面几楼的顺序里：先用 ssh -vvv 定性是 denied 还是超时，再按“用户名 → 输入方式 → 密钥/密码 → sshd 开关”的顺序查，能少走不少弯路。

前面几位主要讲了权限、版本控制和计费，我补充几个新手在对象模型和日常操作上最容易踩的坑，角度不太一样，都是实际用的时候反复出现的。 一、别把桶当成普通文件夹OBS 里没有真正的文件夹，对象 key 里的“/”只是分隔符，控制台看到的目录是按前缀模拟出来的。所以：1. “重命名”一个对象，其实是复制一份新 key 再删旧的，大文件改名会产生一次完整的复制；目录改名同理，是批量复制加删除，耗时和你以为的改名完全不是一回事。2. 列对象一次默认只返回 1000 条，程序里必须按分页循环拉全量，直接 list 一次就当全量会漏数据。3. 对象一旦上传就不可修改，改一点内容也要整对象重新上传；高频小文件追加写、实时读写不适合放 OBS。 二、域名分清内外网，流量费差很多同一个桶有内网域名和公网域名：ECS 在同一区域内通过内网域名访问不收下行流量费，走公网域名就要收；跨区域访问同样按公网流量计费。代码里写死公网域名是最常见的多花钱方式，上线前先确认访问端点。自定义域名绑定到桶做静态网站时，域名要先备案；只做下载链接不需要绑自定义域名，直接用桶域名加临时签名 URL 就够了。 三、Content-Type 没设对，浏览器行为就变了上传时不指定 Content-Type，对象默认是 application/octet-stream，浏览器打开链接会直接下载而不是预览。图片、网页、PDF 这类需要在线打开的文件，上传时要按真实类型设置；已经传上去的可以在控制台修改对象元数据。 四、删桶、删对象之前先看三样东西1. 桶删不掉，多数是里面还有对象、历史版本或未完成的分片上传残留。开版本控制的桶，删除当前版本后历史版本还在计费，要用生命周期规则定期清理过期版本。2. 分片上传失败后残留的分片会一直占存储、持续计费，要在生命周期里配清理碎片或定期用工具清理。3. 归档存储的对象不能直接下载，要先发起恢复，等恢复完成才能取回，着急用的数据不要直接放归档。 一句话：把 OBS 当对象存储用，而不是当磁盘用。先确认桶的区域和访问域名、上传时设好 Content-Type、开好版本控制与生命周期清理碎片，这几项做对了，新手阶段的大多数坑都能避开。

先说结论，再拿一个能直接照着做的例子讲清楚。结论：FunctionGraph 适合“事件一来就跑、跑完就走”的任务；需要常驻进程、一直记着状态、一次跑很久的任务，不适合。拿最常见的例子走一遍——OBS 上传图片后自动生成缩略图：触发器选 OBS 事件通知（对象创建），函数收到事件后做三件事：下载原图、生成缩略图、把结果写回另一个 OBS 桶并记一条记录到数据库。平时没上传就不花钱，有突发上传就自动扩容。落地时这几项要一起定，不能只看场景：1. 超时：按最慢一次执行留余量设置，超时后平台可能重试，非幂等的操作（写库、发通知）要先做幂等，比如用对象名加时间戳做唯一键，重复触发时直接跳过。2. 内存与并发：内存给够、别贪大；并发上限要和下游一起看——函数扩容时每个实例都可能新建数据库连接，RDS 连接数很容易先被打满。办法是限制函数并发上限、把连接池调小，或者用消息队列把突发流量削平。3. 冷启动：对延迟敏感的接口做预留实例，把初始化（建连接、加载模型）放在函数初始化阶段，别放在每次请求里。4. 配置别写死：桶名、表名、密钥放环境变量或凭据管理，一个函数只做一件事，方便单独排障。不适合的：单次执行可能超过超时上限的长任务、需要常驻内存缓存或本地磁盘状态的服务、WebSocket 长连接、对延迟极其敏感且持续高并发的核心链路——这些更适合 ECS、CCE 或容器。建议先从一个非核心的定时或事件任务试点，跑通监控、日志、超时和重试，再推广。

前面几位已经把“先找瓶颈、再按量起步、每月复核”的主线讲清楚了，我补充一个能直接套用的算例和三个容易踩的坑，供题主对照着算一遍。一、先拿一个具体业务算一遍，再选规格假设是一个日活约 5000 的小程序后端，峰值 300 QPS，接口平均响应 120 毫秒。按“并发 ≈ 峰值 QPS × 平均响应时间”粗算，同一时刻在处理的请求大约是 300 × 0.12 = 36 个。单个请求在应用层大约占 30MB 内存，36 个并发大约需要 1.1GB 堆内存，再加上 JVM 或运行时的基础占用，2 核 4GB 的通用型实例起步是够的；如果平均响应涨到 500 毫秒，同样 300 QPS 的并发就是 150 个，内存和线程数需求直接翻几倍，这时就该先看接口为什么慢，而不是先加机器。所以选型前，先在云监控里拉出高峰期一周的四条曲线：CPU 利用率、内存利用率、磁盘读写速率、网络带宽。哪条先贴近上限，钱就花在哪条上。二、三个容易被忽略的坑1. 突发性能型实例不是省钱的万能选择。它的 CPU 积分用完后性能会被限制，只适合流量有明显波峰波谷、平时很闲的场景；如果业务长期跑在 70% 以上的 CPU 上，积分很快耗尽，反而要频繁升配，算下来并不便宜。2. 注意实例是共享型还是独享型。共享型实例的 CPU 可能会被邻居争抢，压测时表现很好，上线后高峰期却抖动明显。对延迟敏感的核心接口，建议选独享型或通用型，验证阶段可以先用共享型压测对比一次。3. 磁盘和带宽经常被漏算。数据库跑在普通云硬盘上，IOPS 不够时 CPU 再高也没用；带宽按出口峰值选，图片、安装包这类静态资源尽量走对象存储，不要让应用服务器的带宽去扛。三、验证和复核的具体做法压测：用 wrk 或 JMeter，从 50 并发起步，每轮加 50，观察 99 分位延迟出现拐点的并发数；拐点对应的 QPS 就是当前规格的上限，选型时按峰值 QPS 的 1.5 倍留余量。复核阈值（每月看一次监控）：高峰期 CPU 持续超过 70% 就升配或横向扩展；内存持续超过 80% 先查有没有泄漏或缓存过大，再升配；连续两周利用率低于 30% 就降一档；磁盘读写延迟持续超过 10 毫秒，就换更高 IOPS 的云硬盘。计费组合：验证期用按量付费随时换规格，业务稳定后把长期运行的核心实例转包年包月，波峰部分用弹性伸缩按量补齐。这样既不用一次买大规格，也不会在高峰期手忙脚乱。

先把差额算出来，再逐项对账，比逐个目录猜要快。df 和 du 的统计口径本来就不同，差额本身不一定是某个大文件，可能是几类看不见的占用加在一起。 第一步：把两个数放到同一口径假设满的是 /data，先确认它到底是哪个文件系统，再用字节单位对比：findmnt -T /datasudo df -B1 /datasudo du -x -B1 --max-depth=1 /data 2>/tmp/du.err注意三点：一是要用 sudo 跑，否则权限不足的目录会被悄悄跳过，du 结果就偏小；二是加 -x，不要跨到别的挂载点；三是不要把错误输出丢掉，/tmp/du.err 里如果有大量 Permission denied，du 的总数就不可信。 第二步：用差额反推，而不是继续往下钻目录差额 = df 的 Used - du 的总计。然后按下面顺序逐项核对，每确认一项就从差额里减掉它：1）挂载点遮挡。先往目录里写了数据，后来又把另一块盘挂到这个目录上，旧数据就被盖住了。验证不用卸载业务盘，用 bind 挂载绕过去看一眼：sudo mkdir -p /mnt/rootview && sudo mount --bind / /mnt/rootviewsudo du -sh /mnt/rootview/data如果这里出现了 du 之前统计不到的几十 GB，就是它。2）已删除但仍被打开的文件。你已经查过 lsof，但要注意两个漏查点：一是普通用户只能看到自己的进程，必须用 sudo；二是容器里的进程可能在另一个挂载命名空间，宿主机上的 lsof 不一定看得到。换一种方式直接扫 /proc：sudo find /proc/[0-9]*/fd -lname '* (deleted)' -printf '%p -> %l\n' 2>/dev/null确认之后，不必重启服务也能释放：找到对应的 PID 和 FD 编号，用 : > /proc//fd/ 截断内容，空间会立即回来。3）inode 和预留块。先跑 df -i /data：如果 inode 用满了，表现也是写不进文件，但它解释不了 df 已用空间远大于 du。ext4 默认给 root 预留 5%，用 tune2fs -l 设备 | grep Reserved 看一眼，这部分会计入 Used，但对普通用户不可用，差额如果正好在 5% 左右，就先考虑它。4）稀疏文件和特殊文件系统。如果是容器环境，再看 /var/lib/docker 的 overlay 层和容器日志；如果是 btrfs，看快照和子卷，du 按目录树累加会和文件系统统计对不上。 第三步：确认之后再动手定位到具体目录或进程之前，先不要批量删除。先确认这份数据的归属和保留要求，能归档的先归档，能截断的先截断，需要重启服务的选维护窗口。清理完再跑一次 df -B1 和 du -B1，确认差额已经缩小到可以解释的范围，而不是只看使用率百分比降没降。建议你把 findmnt、df -B1、df -i 的结果和 du 的报错贴出来，差额具体是多少 GB，大家才能帮你判断是哪一类占用占了大头。