Nginx配置检查测试

引言

改完Nginx配置直接reload最容易踩坑：语法错、证书路径错、端口被占会导致Nginx起不来甚至站点全挂。规范流程是先检查语法，通过后再平滑重载，出问题能快速回退。

语法检查

nginx -t

检查默认配置文件语法，输出syntax ok和test is successful才说明配置无误。

指定配置文件检查

nginx -t -c /etc/nginx/nginx.conf

自定义路径时用-c指定，避免检查错文件。

平滑重载

nginx -s reload

不中断现有连接重新加载配置，改动生效不宕机。

查看编译参数和版本

nginx -V

大写V看版本和编译模块，确认是否包含ssl、gzip、stream等模块。

打印生效配置

nginx -T

大写T会把所有include进来的配置打印出来，排查重复server或覆盖时用。

出错常见原因

• 括号不配对、分号漏写；
• 证书key路径不存在或权限600不对；
• listen端口已被其他进程占用；
• upstream后端地址写错；
• include路径下的文件本身语法错。

注意事项

• 永远先-t再reload，禁止跳过检查；
• 改配置前备份原文件，出错可立刻回退；
• -T输出很长，重定向到文件再查；
• reload失败先看error.log定位行号；
• 生产环境改完curl本机验证再放行；
• 多台机器逐台灰度，不要一次全改。

总结

nginx -t检查语法，-c指定文件，-s reload平滑生效，-V看编译模块，-T打印完整配置。铁律是先检查通过再重载，改前备份、出错看error.log、本机curl验证后再上线，生产逐台灰度，避免一次改全量导致整站不可用。

Linux查看CPU信息

引言

服务器扩容、压测、排查性能瓶颈前，先要知道机器几颗CPU、多少核、主频和架构。/proc/cpuinfo是内核暴露的原生信息，配合lscpu、nproc能快速拿到规格，top/mpstat再看实时占用。

lscpu看汇总

lscpu

一次列出架构、颗数、每颗核数、线程数、主频、缓存，最简洁。

nproc看逻辑核数

nproc

直接输出可用逻辑CPU数，脚本里取核数最方便。

读/proc/cpuinfo

cat /proc/cpuinfo

每颗逻辑核一段，看model name型号、cpu MHz频率、flags指令集。

统计物理颗数和核数

# 物理CPU颗数
grep "physical id" /proc/cpuinfo | sort -u | wc -l
# 每颗物理核数
grep "cpu cores" /proc/cpuinfo | uniq
# 逻辑核总数
grep -c processor /proc/cpuinfo

物理颗数×每颗核数×超线程=逻辑核数。

实时CPU占用

top
mpstat 1

top看整体和进程，mpstat每秒采样看用户态、系统态、idle占比。

注意事项

• 云主机看到的是分配的vCPU，不一定是物理独占；
• 超线程逻辑核不等于物理性能翻倍；
• flags里看是否支持虚拟化、AVX等指令集；
• 排查高占用先top按P按CPU排序找进程；
• 结合uptime看负载和核数是否匹配；
• lscpu在大部分发行版预装，无此命令再读/proc。

总结

规格用lscpu看汇总、nproc取核数、/proc/cpuinfo读型号和指令集，配合grep统计物理颗数与核数，实时占用用top和mpstat。压测和扩容前先分清物理核、逻辑核和超线程，避免按vCPU误判真实算力。

Linux查找大文件

引言

服务器磁盘爆满时，df先看哪个分区满，再用du一层层往下钻，找到吃掉空间的大目录和大文件。很多人只会df -h，却定位不到具体是哪个文件，这里讲完整排查链路。

第一步看分区占用

df -h

看Use%和挂载点，确认是/、/data还是/var满，别在没满的分区里瞎找。

第二步定位大目录

du -sh /* 2>/dev/null | sort -rh | head

du -sh统计每个一级目录大小，sort -rh按大小倒序，head取前几名，快速锁定大头目录，再逐层深入：

du -sh /var/* 2>/dev/null | sort -rh | head

第三步找超过100M的单文件

find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null

-size +100M表示大于100MB，2>/dev/null丢弃无权限报错，直接列出大文件路径和大小。

常见膨胀位置

• /var/log：日志没轮转，单个日志几个G；
• /tmp：临时文件没清理；
• Docker：/var/lib/docker镜像和容器层堆积；
• 网站上传目录、数据库binlog。

处理建议

• 日志优先清空而不是删文件（> log.log），避免占用文件句柄不释放；
• Docker用docker system prune清理悬空镜像；
• 删之前确认文件没被进程占用，lsof | grep 文件名；
• 不要直接rm正在写入的日志，用truncate -s 0截断。

注意事项

• du统计含磁盘占用，find看文件真实大小，两者结合；
• 根目录全盘find慢，先缩小到df定位的分区；
• 系统目录(/usr、/lib)别乱删，只清理业务数据和日志。

总结

df -h定位满的分区，du -sh逐层排序找大目录，find -size找大文件，先看日志和Docker，清空用truncate别rm占用文件。按分区→目录→文件三层下钻，几分钟就能找到磁盘元凶。