pmset -g

pmset -g

常用设置

关闭显示器（分钟）

sudo pmset displaysleep 15

sudo pmset displaysleep 15

电脑休眠（分钟）

sudo pmset sleep 30

sudo pmset sleep 30

硬盘休眠（分钟）

sudo pmset disksleep 10

sudo pmset disksleep 10

待机延迟（秒）

sudo pmset standbydelay 10800

sudo pmset standbydelay 10800

混合休眠模式

sudo pmset standby 1 # 启用待机
sudo pmset hibernatemode 25 # 混合休眠

sudo pmset standby 1 # 启用待机
sudo pmset hibernatemode 25 # 混合休眠

常用组合

永不休眠（接电源）

sudo pmset -c sleep 0 displaysleep 0 disksleep 0

sudo pmset -c sleep 0 displaysleep 0 disksleep 0

电池省电模式

sudo pmset -b sleep 15 displaysleep 5 disksleep 10

sudo pmset -b sleep 15 displaysleep 5 disksleep 10

字段说明

查看所有设置详情

pmset -g custom

pmset -g custom

恢复默认设置

sudo pmset -a sleep 10 displaysleep 10 disksleep 10

sudo pmset -a sleep 10 displaysleep 10 disksleep 10

禁用休眠（适合常开机）

sudo pmset -a sleep 0 disksleep 0
udo pmset -a hibernatemode 0

sudo pmset -a sleep 0 disksleep 0
udo pmset -a hibernatemode 0

查看唤醒原因

# 查看当前阻止系统 / 显示器睡眠的所有电源断言（Power Assertions），快速定位 Mac 无法自动休眠的原因。
pmset -g assertions 

# 查看唤醒原因
pmset -g | grep wake

# 查看当前阻止系统 / 显示器睡眠的所有电源断言（Power Assertions），快速定位 Mac 无法自动休眠的原因。
pmset -g assertions 

# 查看唤醒原因
pmset -g | grep wake

参数说明

• -a 所有电源模式
• -c 电源适配器（接充电器）
• -b 电池模式
• -u UPS 模式

hibernatemode 取值

• 0 – 内存休眠，唤醒快
• 1 – 安全休眠到磁盘
• 3 – 内存+磁盘混合（默认）
• 25 – 强制休眠到磁盘

相关命令

# 立即锁屏
pmset displaysleepnow

# 查看电池状态
pmset -g batt

# 查看唤醒原因
pmset -g wake

# 立即锁屏
pmset displaysleepnow

# 查看电池状态
pmset -g batt

# 查看唤醒原因
pmset -g wake

来源: macOS 系统命令

添加 Microsoft 仓库

sudo rpm -Uvh https://packages.microsoft.com/config/centos/8/packages-microsoft-prod.rpm

安装运行时

sudo dnf install -y aspnetcore-runtime-8.0

验证

dotnet –list-runtimes

如果上面的源不可用，可以用脚本安装：

下载安装脚本

curl -sSL https://dot.net/v1/dotnet-install.sh -o dotnet-install.sh
chmod +x dotnet-install.sh

安装到 /usr/share/dotnet（全局）

sudo ./dotnet-install.sh –channel 8.0 –runtime aspnetcore –install-dir /usr/share/dotnet

创建软链接

sudo ln -sf /usr/share/dotnet/dotnet /usr/bin/dotnet

验证

dotnet –list-runtimes

本文是一次完整的 线上问题排查 + 架构修复 + 压力测试验证 的工程级总结，可作为 事故复盘、容量评估报告、运维 Runbook 使用。

一、问题背景与现象

初始问题

• Nginx 错误日志频繁出现：

  upstream timed out (110: Connection timed out) while connecting to upstream

• 请求多为：

  OPTIONS /api/Ads/resolve HTTP/2.0

• 上游地址：<code>127.0.0.1:5085</code>（.NET Kestrel）

同时观测到的内核异常

• <code>listen queue overflow</code>
• <code>SYNs to LISTEN sockets dropped</code>
• <code>SYN cookies sent</code>
• <code>TCPTimeWaitOverflow</code>

直接影响

• Nginx 无法连接本机上游
• API 出现大量失败
• 高并发下服务不可用

二、根因分析（结论级）

1⃣ Nginx → Kestrel 连接模型错误（核心根因）

在 <code>location /</code> 中错误地配置了：

proxy_set_header Connection "upgrade";

导致：

• 所有普通 HTTP 请求被迫使用 <code>Connection: upgrade</code>
• Keepalive 失效
• 每个请求都建立/断开 TCP 连接

直接引发短连接风暴

2⃣ OPTIONS 预检请求被放大

• 外站（如豆瓣）触发大量跨域请求
• 每个请求都会先发 <code>OPTIONS</code>
• <code>OPTIONS</code> 被转发到上游应用

在短连接模型下形成 连接洪峰。

3⃣ 内核层连锁反应

• SYN backlog 被打满
• accept queue 溢出
• 内核开始丢 SYN / 启用 SYN cookies
• Nginx 连接上游直接超时（110）

三、关键修复措施（工程级）

1⃣ 引入 upstream keepalive（最关键修复）

在 <code>http {}</code> 作用域中新增：

upstream eaglex_upstream {
    server 127.0.0.1:5085;
    keepalive 256;
}

统一使用：

proxy_pass http://eaglex_upstream;
proxy_http_version 1.1;
proxy_set_header Connection "";

2⃣ 修正 Connection 头使用方式（非常关键）

• 禁止在普通 HTTP 路径中使用：

  Connection: upgrade

• 只在 WebSocket 专用 location 中使用 upgrade

3⃣ 在 Nginx 层直接短路 OPTIONS 预检

location = /api/Ads/resolve {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin $http_origin always;
        add_header Access-Control-Allow-Methods "GET,POST,OPTIONS" always;
        add_header Access-Control-Allow-Headers "Content-Type,Authorization" always;
        add_header Access-Control-Max-Age 86400 always;
        return 204;
    }
    proxy_pass http://eaglex_upstream;
}

彻底消除预检请求对上游的压力放大

4⃣ 缩短 proxy_connect_timeout（防止雪崩）

proxy_connect_timeout 2s;

避免 Nginx worker 在连接失败时长时间阻塞。

四、压测阶段的验证结论

压测过程中观测到的健康状态

• <code>.NET</code> CPU：≈ 260%–300%（4C 机器，尚有余量）
• Nginx CPU：≈ 10%–20%
• <code>ksoftirqd</code>：极低

• TCP 状态：

  estab ≈ 3000
  timewait ≈ 30
  orphan = 0

• 内核累计计数在压测前后 完全无增长：

  • listen queue overflow
  • SYN dropped
  • TCPTimeWaitOverflow

明确结论

连接层 / Nginx / 内核 TCP 已完全稳定，系统瓶颈成功转移至 .NET 应用 CPU 层。

五、错误日志的两类问题区分（重要）

A. <code>110 Connection timed out</code>

while connecting to upstream

• 含义：连接队列 / accept / backlog 问题
• 根因：连接模型错误
• 已在本次修复中解决

B. <code>111 Connection refused</code>

connect() failed (111: Connection refused)

• 含义：上游端口当时 没有进程在监听

• 可能原因：

  • dotnet 进程崩溃
  • 被 OOM killer 杀死
  • 重启 / 发布

属于 上游进程稳定性问题，与 backlog 无关。

六、压测与日常排障常用监控命令清单

1⃣ TCP 全局状态（必看）

ss -s

关注：<code>estab / timewait / orphan</code>

2⃣ 上游端口连接数（Nginx → Kestrel）

ss -ant | awk '$4=="127.0.0.1:5085"{c++} END{print c}'

3⃣ 上游连接状态分布

ss -ant | awk '$4=="127.0.0.1:5085"{print $1}' | sort | uniq -c | sort -nr

4⃣ 内核是否再次被打爆（差分判断）

netstat -s | egrep -i 'listen queue|SYNs to LISTEN|SYN cookies|TCPTimeWaitOverflow'

必须用 前后对比 判断是否仍在发生。

5⃣ Nginx 错误日志关键字

tail -n 200 /www/wwwlogs/eaglex_ads_api.error.log | egrep -i 'timed out|refused|502|504'

6⃣ 上游进程是否存活 / 是否重启

ps -p <dotnet_pid> -o pid,etimes,%cpu,%mem,cmd
ss -lntp | grep 5085

7⃣ OOM / 内核杀进程检查

dmesg -T | egrep -i 'oom|killed process'
journalctl -k | egrep -i 'oom|killed'

8⃣ .NET 运行时指标（强烈推荐）

dotnet-counters monitor System.Runtime --process-id <pid>

关注：

• CPU Usage
• ThreadPool Queue Length
• % Time in GC

七、最终工程级结论（可直接写入文档）

本次问题的根因是 Nginx → Kestrel 连接模型错误（短连接 + OPTIONS 预检放大），导致 TCP listen queue 溢出与 upstream connect timeout。

通过引入 upstream keepalive、修正 Connection 头、在 Nginx 层短路 CORS 预检，并配合合理的超时配置，连接层问题已完全消除。

压测结果表明：系统当前瓶颈已转移至 .NET 应用 CPU 层，TCP 与代理层稳定可靠，具备可预测的容量上限。

一行通用万能命令（推荐直接用这个）

在 终端（Terminal） 中执行：

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

输入你的 系统登录密码（不会显示），回车即可完成刷新。

这个命令适用于：

• macOS Ventura (13)
• macOS Sonoma (14)
• macOS Sequoia (15)
• Monterey (12)
• Big Sur (11)
• Catalina (10.15)
• Mojave (10.14)

各系统版本对应命令（备用参考）

如何判断是否刷新成功？

macOS 刷新 DNS 默认是没有任何成功提示的，这是正常现象
如果你想确认是否真的生效，可以：

ping your-domain.com

或：

nslookup your-domain.com

适合你的使用场景（比如你刚刚在折腾这些）

你最近使用的场景包括：

• 花生壳 / 动态域名解析
• 公网 IP + 远程桌面
• 路由器 DDNS 解析切换
• 域名刚刚改解析但访问不生效

这时候刷新 DNS 是“必须操作”之一，否则很容易一直命中旧 IP。

进阶：同时刷新 WiFi/网络缓存（更彻底）

如果你遇到的是那种 “DNS 已改，但 Mac 仍然连不上” 的顽固情况，可以：

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
sudo ifconfig en0 down
sudo ifconfig en0 up

（<code>en0</code> 是常见的 WiFi 网卡）