SiameseUIE Linux常用命令速查手册
1. 为什么需要这份速查手册
你刚在星图GPU平台上拉起一个SiameseUIE信息抽取镜像，服务跑起来了，但过了一阵发现响应变慢，或者API开始返回错误。这时候你打开终端，手指悬在键盘上——该敲什么命令？top？htop？还是journalctl？又或者该去哪个目录找日志？
这不是理论考试，而是真实运维现场。SiameseUIE镜像虽然开箱即用，但部署之后的日常维护、问题排查和性能观察，依然离不开Linux系统层面的基本功。这份手册不讲原理，不堆概念，只收录你在维护SiameseUIE服务时真正会反复敲、反复查、反复依赖的命令。
它面向的是正在屏幕前操作的你：可能刚接手这个服务，可能正被告警电话催着查问题，也可能只是想提前备一份“保命清单”。所有命令都经过实测验证，适配星图平台常见的Ubuntu/CentOS基础镜像环境，覆盖容器内进程监控、日志定位、资源瓶颈识别三个最常遇到的场景。
不需要记住全部，挑你当前最需要的那几条，复制粘贴，回车执行，就能看到结果。等哪天你发现自己已经能闭着眼敲出docker logs --tail 50 -f siameseuie，那就说明这份手册完成了它的使命。
2. 服务状态与进程监控
2.1 确认服务是否在运行
SiameseUIE镜像通常以Docker容器方式运行，第一步永远是确认容器本身是否存活。别急着看日志，先看状态：
docker ps | grep siameseuie这条命令会过滤出所有含siameseuie关键词的容器。如果输出为空，说明容器没启动，或者名字不是默认名。这时可以看全量列表：
docker ps -a注意看STATUS列：Up 2 hours表示正常运行；Exited (1) 5 minutes ago说明已崩溃退出；Created则代表只创建了还没启动。
如果你用的是docker-compose.yml启动，更直接的方式是：
docker-compose ps它会清晰列出每个服务的状态、端口映射和运行时长，比docker ps更直观。
2.2 查看容器内主进程
容器在运行，但服务不一定健康。比如Python进程卡死、内存耗尽被OOM Killer干掉，容器还在，但API已无响应。这时要深入容器内部看真正的业务进程：
docker exec -it siameseuie ps aux --sort=-%cpu | head -10这条命令做了三件事：进入容器、列出所有进程、按CPU使用率倒序、只取前10行。你会看到类似这样的输出：
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 123456 7890 ? Ss 10:23 0:00 python3 app.py root 23 98.7 12.4 2345678 1234567 ? R 10:23 2:15 python3 app.py重点关注两行：PID为1的通常是启动脚本或主进程；另一行CPU占98.7%的，大概率就是正在疯狂处理请求的worker。如果只有第一行且CPU长期为0，说明服务可能卡在初始化阶段；如果第二行RSS（物理内存）持续飙升到接近宿主机上限，就要警惕内存泄漏了。
2.3 实时监控资源占用
单次快照不够，你需要动态观察。htop比top更友好，但很多精简镜像默认没装。所以优先掌握原生命令：
watch -n 1 'docker stats --no-stream siameseuie | grep -E "(NAME|siameseuie)"'watch命令每秒刷新一次，docker stats显示容器实时资源消耗。输出类似：
NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O siameseuie 42.3% 1.2GiB / 16GiB 7.5% 1.2MB / 345KB 0B / 0B这里的关键指标是MEM USAGE / LIMIT。如果MEM %稳定在10%-30%，说明一切正常；一旦超过70%并持续上升，就要准备查日志了。CPU %同理，短时冲高到80%+没问题，但若长期维持在60%以上，结合ps aux看是不是某个worker在死循环。
3. 日志查看与问题定位
3.1 快速查看最新日志
日志是问题的第一线索。SiameseUIE镜像默认将日志输出到标准输出，因此docker logs是最直接的入口：
docker logs --tail 50 -f siameseuie--tail 50只显示最后50行，避免刷屏；-f表示持续跟踪新日志（类似tail -f）。当你看到类似这样的报错：
ERROR:root:Failed to load model from /models/siamese-uie-base OSError: Unable to load weights from pytorch checkpoint说明模型文件路径或权限出了问题。而如果是：
INFO:uvicorn.error:Started server process [1] INFO:uvicorn.error:Waiting for application startup. INFO:uvicorn.error:Application startup complete. INFO:uvicorn.error:Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)恭喜，服务已就绪，可以开始调用API了。
3.2 按时间范围筛选日志
线上服务出问题，往往不是此刻发生的，而是几分钟前某个异常请求触发的连锁反应。这时需要回溯：
docker logs --since "10m" --until "2m" siameseuie | grep -i "error\|exception\|traceback"--since "10m"从10分钟前开始，--until "2m"截止到2分钟前，中间的日志再用grep过滤关键词。这样能精准定位故障窗口期内的错误堆栈，避免在海量日志里大海捞针。
3.3 查看日志文件（当镜像持久化日志时）
部分定制镜像会将日志写入文件而非标准输出。常见路径有/var/log/siameseuie/或/app/logs/。先进入容器查看：
docker exec -it siameseuie ls -lt /var/log/siameseuie/-lt按修改时间倒序，最新的日志文件排在最上面。然后用tail查看：
docker exec -it siameseuie tail -n 30 /var/log/siameseuie/app.log如果日志文件很大，用less分页更高效：
docker exec -it siameseuie less +G /var/log/siameseuie/app.log+G表示直接跳到文件末尾，按Shift+G也能回到末尾，q退出。
4. 性能分析与瓶颈识别
4.1 检查磁盘IO是否成为瓶颈
SiameseUIE在加载大模型或处理批量文本时，会频繁读取磁盘。如果API响应明显变慢，先排除IO问题：
iostat -x 1 3这条命令每秒采样一次，共3次，-x显示扩展统计。重点关注%util（设备利用率）和await（I/O平均等待时间）：
%util持续接近100%，说明磁盘忙不过来；await超过10ms，表示每次IO请求等待太久。
如果确认是IO瓶颈，检查模型文件是否放在机械硬盘上，或者是否有其他进程在大量刷盘。临时缓解方法是把模型缓存到内存：
docker exec -it siameseuie echo 3 > /proc/sys/vm/drop_caches这会清空页面缓存、目录项缓存和inode缓存（仅限测试环境，生产慎用）。
4.2 分析网络连接状态
API超时或连接拒绝，可能是网络层问题。先看服务监听的端口是否正常：
docker exec -it siameseuie ss -tuln | grep ':8000'ss比netstat更快，-tuln分别表示TCP、UDP、监听、数字地址。正常输出应为：
tcp LISTEN 0 128 *:8000 *:* users:(("python3",pid=1,fd=6))如果没输出，说明Uvicorn没起来，或启动参数绑定了127.0.0.1:8000而非0.0.0.0:8000。再检查宿主机到容器的连通性：
curl -I http://localhost:8000/health返回HTTP/1.1 200 OK说明网络通；若超时，检查Docker端口映射是否正确（docker ps看PORTS列），或防火墙是否拦截。
4.3 定位高CPU进程的具体线程
前面ps aux看到某个Python进程CPU飙高，但不知道是哪个函数在作怪。这时需要深入线程级：
docker exec -it siameseuie top -H -p $(pgrep -f "app.py" | head -1)-H显示线程，-p指定进程ID，pgrep -f "app.py"找出包含app.py的进程PID。你会看到类似：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1234 root 20 0 2345678 1234567 12345 R 98.7 12.4 2:15.23 python3 1235 root 20 0 2345678 1234567 12345 R 95.2 12.4 2:10.44 python3多个线程CPU都很高，说明是计算密集型任务（如模型推理）。此时可结合strace看系统调用：
docker exec -it siameseuie strace -p 1234 -c 2>&1 | tail -10-c汇总调用次数和耗时，最后一行会显示% time最高的系统调用，比如futex占比过高，说明线程在锁竞争；read占比高，则可能在等磁盘或网络。
5. 常见问题速查与应急处理
5.1 容器启动失败：端口已被占用
错误提示常为Bind for 0.0.0.0:8000 failed: port is already allocated。先找出谁占了8000端口：
sudo lsof -i :8000 # 或 sudo netstat -tulpn | grep :8000如果输出显示是另一个docker-proxy进程，说明有旧容器还在运行：
docker ps | grep 8000 docker stop <container_id>如果显示是node或python进程，直接杀掉：
sudo kill -9 $(lsof -t -i :8000)5.2 日志刷屏：磁盘空间告急
docker logs太多导致/var/lib/docker/containers/占满磁盘。临时清理：
# 清空指定容器日志（谨慎！会丢失历史日志） sudo truncate -s 0 /var/lib/docker/containers/*/logs/json.log # 或更安全的方式：限制日志大小（需重启容器） docker run --log-opt max-size=10m --log-opt max-file=3 ...5.3 内存不足：OOM Killer杀死进程
dmesg -T | grep -i "killed process"会显示被杀进程名。如果看到python3，说明内存超限。临时方案是增加容器内存限制：
docker update --memory 4g siameseuie长期方案是优化模型加载逻辑，或升级宿主机内存。
6. 维护习惯与实用技巧
用熟这些命令后，你会发现有些操作重复度极高。与其每次都敲一遍，不如做成小工具。比如，在宿主机创建一个siamese-check.sh脚本：
#!/bin/bash echo "=== SiameseUIE 服务状态 ===" docker ps | grep siameseuie echo -e "\n=== 最新10行日志 ===" docker logs --tail 10 siameseuie 2>/dev/null || echo "容器未运行" echo -e "\n=== 内存使用 ===" docker stats --no-stream siameseuie | grep siameseuie | awk '{print $3}'给执行权限后，一键执行：
chmod +x siamese-check.sh ./siamese-check.sh再比如，把常用docker exec命令 alias 成短命令：
alias slogs='docker logs --tail 50 -f siameseuie' alias sps='docker exec -it siameseuie ps aux --sort=-%cpu | head -10'加到~/.bashrc里，下次登录就能直接用slogs和sps。
这些技巧没有技术含量，但能省下大量重复劳动的时间。运维的本质，从来不是记住多少命令，而是让重复工作自动化，把精力留给真正需要判断的问题。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
