CentOS 7 服务器项目盘点与端口管理
一台服务器上跑了 11 个项目，端口、进程、资源怎么理清楚？这篇给你完整答案。
背景
之前清理完磁盘和木马后，顺手把服务器上正在运行的项目盘了一遍。发现不知不觉已经部署了 11 个项目，端口从 5002 到 42120 都有，还有 frp/nps 内网穿透占了一堆端口。
本文整理如何查看正在运行的项目、端口对照表、资源占用分析、以及优化建议。
一、查看正在运行的项目
1.1 看 systemd 服务
systemctl list-units --type=service --state=running
输出会列出所有 active 的服务。过滤掉系统服务：
systemctl list-units --type=service --state=running | grep -vE "systemd|dbus|network|ssh|chrony|crond|firewalld|auditd|tuned|postfix|rsyslog|jcloud|jcs|jdog|ifritd|polkit|irqbalance|lvm|getty|rpc|nfs|gssproxy|sssd|NetworkManager|abrt|microcode|mcelog"
1.2 看监听端口
/usr/sbin/ss -tlnp
输出显示所有监听端口和对应进程，是最直接的"项目地图"。
1.3 看进程详情
# 按内存排序
ps aux --sort=-%mem | head -20
# 看 gunicorn 项目路径
ps aux | grep gunicorn | grep -v grep
gunicorn 进程的完整命令里包含项目路径和端口，一眼就能对上。
1.4 看 Docker 容器
docker ps
二、端口对照表
2.1 自己的项目
| 端口 | 项目 | 路径 | 对外 |
|---|---|---|---|
| 5002 | music_player | /usr/local/music_player | ✅ |
| 5004 | software_library | /usr/local/software_library | 🔒 仅本机 |
| 5006 | giftbook | /usr/local/giftbook | ✅ |
| 5008 | shared_diary | /usr/local/shared_diary | ✅ |
| 5012 | music-uniapp 后端 | /usr/local/music-uniapp/backend | ✅ |
| 5014 | registration | /usr/local/registration_system | ✅ |
| 8000 | iris-app | /root/iris-app | ✅ |
| 8501 | webpage-summary | Streamlit | ✅ |
| 8080 | filebrowser | 文件管理 | ✅ |
| 8082 | global-radio | Docker 容器 | ✅ |
| 42120 | daoliyu-music | /opt/daoliyu-music | ✅ |
2.2 基础环境
| 端口 | 服务 |
|---|---|
| 80 / 443 | Nginx |
| 3306 / 33060 | MySQL |
| 6379 | Redis（仅本机） |
| 9000 | PHP-FPM（仅本机） |
| 22 | SSH（已改端口） |
2.3 内网穿透
| 端口 | 服务 |
|---|---|
| 7000、7500、5555、3663、3664、5680、5005 | frps |
| 5000、8024、8443、4000、5677-5681、8081、3662、9669 | nps |
三、资源占用分析
3.1 内存占用
| 项目 | worker 数 | 累计内存 |
|---|---|---|
| iris-app | 4 | ~308M |
| mysqld | - | ~323M |
| giftbook | 4 | ~192M |
| shared_diary | 4 | ~120M |
| music_player | 4 | ~60M |
| registration | 4 | ~36M |
| music-uniapp | 4 | ~32M |
| software_library | 4 | ~12M |
结论：
iris-app最吃内存：机器学习应用，加载模型占 ~308M- MySQL 是单进程大头：~323M
- 其余项目都很轻
3.2 CPU 占用
所有进程 CPU 都低于 1.3%，完全不是瓶颈。
四、优化建议
4.1 内存优化
| 优化项 | 做法 | 收益 |
|---|---|---|
| 不常用项目减 worker | -w 4 改 -w 2 | 省内存 |
| iris-app 按需启动 | 不用时 systemctl stop iris-app | 省 ~300M |
| MySQL 调优 | 调小 innodb_buffer_pool_size | 省内存 |
4.2 安全优化
端口收口：很多项目绑定 0.0.0.0，外部可直接访问。建议：
- 云服务器安全组：只放行 80、443、96，以及 frp/nps 用到的端口
- gunicorn 绑本机：改成
-b 127.0.0.1:端口，由 Nginx 反代 - firewalld：在系统层面限制端口访问
4.3 管理脚本
把项目状态检查做成脚本，随时能看：
cat > /root/projects.sh << 'EOF'
#!/bin/
echo "===== 我的项目状态 ====="
for s in music-player music-uniapp daoliyu-music giftbook shared-diary software_library webpage-summary iris-app registration filebrowser frps Nps; do
printf "%-20s %s\n" "$s" "$(systemctl is-active $s 2>/dev/null)"
done
echo ""
echo "===== 监听端口 ====="
/usr/sbin/ss -tlnp | grep -E "5002|5004|5006|5008|5012|5014|8000|8501|8080|8082|42120"
EOF
chmod +x /root/projects.sh
以后随时跑：
/root/projects.sh
五、项目清单汇总
| # | 项目 | 端口 | 技术栈 | systemd 服务名 |
|---|---|---|---|---|
| 1 | music_player | 5002 | Flask + gunicorn | music-player |
| 2 | software_library | 5004 | Flask + gunicorn | software_library |
| 3 | giftbook | 5006 | Flask + gunicorn | giftbook |
| 4 | shared_diary | 5008 | Flask + gunicorn | shared-diary |
| 5 | music-uniapp | 5012 | FastAPI + uvicorn | music-uniapp |
| 6 | registration | 5014 | Flask + gunicorn | registration |
| 7 | iris-app | 8000 | Flask + gunicorn | iris-app |
| 8 | webpage-summary | 8501 | Streamlit | webpage-summary |
| 9 | filebrowser | 8080 | 文件管理 | filebrowser |
| 10 | daoliyu-music | 42120 | 音乐服务 | daoliyu-music |
| 11 | global-radio | 8082 | Docker 容器 | - |
结语
一台服务器跑了 11 个项目，端口、进程、资源理清楚后，管理起来就轻松了。
几个关键点：
ss -tlnp是查看端口映射最快的方法ps aux | grep gunicorn能直接看到项目路径和端口- 内存大头往往是 MySQL 和机器学习类应用
- 对外端口要收口，安全组 + Nginx 反代是最佳实践
定期盘点，及时优化，服务器才能稳定运行。
CentOS 7 内存优化实战：从 Swap 告急到从容运行
2G 内存的服务器跑 11 个项目，Swap 一度用到 973M/1G。记录一次完整的内存排查与优化过程。
背景
之前清理完磁盘和木马后，顺手检查了一下内存，发现一个更隐蔽的问题：
total used free shared buff/cache available
Mem: 2.0G 1.0G 254M 55M 689M 736M
Swap: 1.0G 983M 41M
Swap 用了 983M，只剩 41M。 这意味着系统长期内存不足，已经把大量数据换出到磁盘。Swap 快满时，服务器会变得很卡，甚至触发 OOM（杀进程）。
本文记录如何定位内存问题、分析 Swap 占用、以及分步优化。
一、发现问题：Swap 告急
1.1 看内存总览
free -h
输出：
total used free shared buff/cache available
Mem: 2.0G 1.0G 254M 55M 689M 736M
Swap: 1.0G 983M 41M
- 物理内存：2G，用了 1G，还有 736M 可用 —— 看起来还行
- Swap：1G 用了 983M —— 这才是真正的问题
1.2 为什么 Swap 满了要警惕
- Swap 是磁盘，比内存慢几个数量级，用多了系统会卡
- Swap 快满时，新内存分配会失败，触发 OOM 杀进程
- 说明物理内存长期不够用
二、定位：谁在吃 Swap
2.1 安装 smem
yum install -y smem
2.2 按 Swap 排序
smem -t -k -s swap | tail -20
输出（节选）：
| 进程 | Swap | 项目 |
|---|---|---|
| mysqld | 180.1M | MySQL |
| shared_diary × 4 | 54.9+56.1+64.1+64.3 = 239.4M | 共享日记 |
| registration × 4 | 29.1+29.4+29.5+37.5 = 125.5M | 注册系统 |
| software_library × 4 | 29.9+30.0+30.0+30.1 = 120M | 软件库 |
| music-uniapp × 4 | 23.1+23.1+30.0+30.1 = 106.3M | 音乐后端 |
| giftbook × 5 | 11.2+17.8+18.2+18.5+18.6 = 84.3M | 礼物书 |
| music_player × 4 | 40.4M | 音乐播放器 |
| php-fpm × 5 | 39.4M | PHP |
Swap 占用约 983M，其中：
- shared_diary 系列：239M ← 最大
- MySQL：180M
- registration：125M
- software_library：120M
- music-uniapp：106M
2.3 核心问题
每个项目都用了 -w 4（4 个 worker），但很多项目访问量并不大。
4 个 worker 意味着 4 份内存，每个 worker 即使空闲也要占几十 M。2G 内存的机器跑 11 个项目 × 4 worker + MySQL + Redis + Nginx + PHP，确实太挤了。
三、处理：分步优化
3.1 第一步：停掉不常用的项目
# 停掉机器学习应用（最吃内存，~300M）
systemctl stop iris-app
systemctl disable iris-app
# 停掉网页摘要（Streamlit，~23M）
systemctl stop webpage-summary
systemctl disable webpage-summary
注意：停服务后 Swap 不会自动降，因为 Swap 里的数据不会因为进程停止就换回物理内存，需要 swapoff/swapon 或重启才能释放。
3.2 第二步：加 Swap（立刻缓解）
发现原来的 Swap 是个文件，放在 /www/swap，只有 1G：
swapon --show
# NAME TYPE SIZE USED PRIO
# /www/swap file 1G 973.8M -2
再加 2G：
fallocate -l 2G /swapfile2
chmod 600 /swapfile2
mkswap /swapfile2
swapon /swapfile2
# 开机自动挂载
echo '/swapfile2 swap swap defaults 0 0' >> /etc/fstab
# 确认
free -h
swapon --show
结果：
total used free shared buff/cache available
Mem: 2.0G 1.0G 127M 54M 828M 748M
Swap: 3.0G 977M 2.0G ← Swap 总量变 3G，可用 2G
Swap 危机暂时解除。
3.3 第三步：调小 worker 数（治本）
这是减少内存占用的根本办法。先看各项目配置：
for s in shared-diary registration software_library music-uniapp giftbook music-player; do
echo "=== $s ==="
systemctl cat $s 2>/dev/null | grep -E "ExecStart"
done
或一次性列出所有 -w 4 的服务：
grep -r "w 4" /etc/systemd/system/*.service 2>/dev/null
建议调整：
| 项目 | 当前 worker | 建议 | 省的 Swap |
|---|---|---|---|
| shared-diary | 4 | 2 | ~120M |
| registration | 4 | 1 | ~94M |
| software_library | 4 | 1 | ~90M |
| music-uniapp | 4 | 2 | ~53M |
| giftbook | 4 | 2 | ~42M |
| music-player | 4 | 2 | ~20M |
合计可省约 400M+ Swap。
修改方法（以 shared-diary 为例）：
# 1. 编辑服务文件
vi /etc/systemd/system/shared-diary.service
# 2. 把 ExecStart 里的 -w 4 改成 -w 2
# 3. 重载并重启
systemctl daemon-reload
systemctl restart shared-diary
# 4. 确认
systemctl cat shared-diary | grep ExecStart
3.4 第四步：MySQL 调优（进阶）
MySQL 占了 180M Swap + 311M RSS。如果数据量不大，可以调小 innodb_buffer_pool_size：
vi /etc/my.cnf
# [mysqld] 下加或改：
# innodb_buffer_pool_size = 128M
systemctl restart mysqld
3.5 第五步：重启释放 Swap（可选）
调完 worker、加完 Swap 后，如果想让 Swap 重新分配：
# ⚠️ 危险操作！确认物理内存够用再执行
swapoff -a && swapon -a
注意：2G 物理内存 + 973M Swap 的情况下，直接 swapoff 会把 973M 数据读回内存，极可能触发 OOM 杀进程。建议在加完新 Swap、且业务低峰期再操作，或者干脆重启机器。
四、经验总结
内存排查要点
| 命令 | 用途 |
|---|---|
free -h | 看内存和 Swap 总览 |
smem -t -k -s swap | 按 Swap 占用排序各进程 |
swapon --show | 看 Swap 文件/分区详情 |
ps aux --sort=-%mem | 按内存排序进程 |
Swap 优化要点
- Swap 快满要警惕：会导致系统卡顿、OOM
- 停进程 ≠ 释放 Swap：Swap 数据不会自动换回内存
- 加 Swap 是治标：缓解压力，但不解决根本问题
- 调小 worker 是治本：减少内存占用
gunicorn 项目优化
- worker 数不是越多越好：
-w 4对小内存机器偏多 - 按访问量调整：高频项目保留 4，低频项目降到 1~2
- 公式参考：
worker = 2 × CPU核数 + 1，但内存有限时要酌情减少
安全建议
- 2G 内存的机器，别跑太多重型应用
- 机器学习类应用（如 iris-app）按需启动，不用就停
- 定期用
smem检查内存占用，早发现早优化
五、最终状态
| 项目 | 优化前 | 优化后 |
|---|---|---|
| 物理内存可用 | 736M | 748M |
| Swap 总量 | 1G | 3G |
| Swap 可用 | 41M | 2.0G |
| iris-app | 运行中（~300M） | 已停 |
| webpage-summary | 运行中（~23M） | 已停 |
从 Swap 告急到从容运行，关键三步：
- 停掉不常用的重型应用
- 加 Swap 缓解压力
- 调小 worker 数治本
结语
内存优化和磁盘清理一样，先定位，再处理，分步执行。
free -h 看总览，smem 找大户，systemctl 停服务，swapon 加 Swap —— 一套流程下来，2G 内存的机器也能稳定跑多个项目。
关键是不要贪多：worker 数按需配置，不常用的应用该停就停。服务器稳定，比什么都重要。