收起左侧

待机环境下相册服务程序占用cpu资源偏高,希望优化

0
回复
28
查看
[ 复制链接 ]

1

主题

11

回帖

0

牛值

江湖小虾

提交问题前,请尽量一次性提供完整信息。
信息不完整、无明确复现路径、缺少关键日志的帖子,将不予处理并直接关闭;请补充完整信息后重新发帖。
请先按下方格式填写;除以下基础信息外,也请根据你遇到的问题补充截图、录屏、报错提示、复现步骤等信息,便于更快定位和处理。
应用中心第三方开发者上架应用问题可以联系对应开发者反馈。

系统版本:X86

设备环境:(虚拟机、局域网、系统:1.1.3107/相册:0.9.7;)

BUG现象:本提议并非影响使用Bug,只是建议优化。通过shell排查现象,结合AI总结如下:

一、现象概述

相册程序trim-photos长期空载无图片处理任务,但单一线程持续稳定占用CPU,长时间运行后累计CPU耗时异常巨大;当前服务器已连续运行6天20小时,肉眼观察程序无业务动作,却累积110小时CPU运算时长。

二、观测证据(按排查顺序整理)

证据1:top全局进程/线程CPU耗时数据

  1. 整机系统状态
%Cpu(s): 0.4 us, 0.4 sy, 0.0 ni, 82.4 id, 16.6 wa

CPU整体空闲82.4%,系统瓶颈为磁盘IO等待(wa=16.6%),CPU算力充足,不存在业务繁忙场景。
2. 进程线程拆分(top -H -p 4697

PID    %CPU  TIME+      COMMAND
4697   1.0%  110:51.48  trim-photos  # 唯一持续耗CPU线程
4735   0.3%  30:35.89   trim-photos  # 次要低负载线程
其余15个线程 0.0% CPU,长期休眠
  • 核心问题线程PID=4697,稳定占用1%单核CPU;
  • 累计CPU运行时长110小时,和服务器6天运行时长匹配,属于空载持续微量消耗累积;
  • 包含ZeroMQ官方后台线程 ZMQbg/ReaperZMQbg/IO/0,无CPU占用,排除库底层问题。

证据2:strace系统调用,确认高频空循环逻辑

持续抓取PID4697系统调用,固定循环模式高频重复执行:

futex(0x55615ba31230, FUTEX_WAIT_PRIVATE, 0, NULL) = 0  # 线程阻塞休眠
write(6, "\1\0\0\0\0\0\0\0", 8) = 8                     # 向fd=6写入唤醒标记

30秒内该循环重复数十次,无任何图片解码、文件读写、业务处理相关系统调用,仅做「阻塞等待→短唤醒写标记」空轮询。

证据3:lsof确认fd=6为ZeroMQ内部eventfd事件句柄

执行过滤命令 lsof -p 4697 | awk '$4 ~ /^6/',输出:

trim-phot 4697 root  6u  a_inode  0,16  0  2074 [eventfd:162]
  • fd=6是Linux eventfd,为ZeroMQ内部线程唤醒机制专用句柄;
  • write(6, 8字节数据) 是zmq_poll超时唤醒后的内部状态同步操作,无实际业务产出。

三、问题根因推导(基于底层行为锁定)

  1. 代码存在 zmq_poll 极短超时轮询逻辑(超时0~10ms)
  2. 开发误区:误以为短超时才能保证消息低延迟,不了解Linux eventfd可内核主动唤醒阻塞线程,长超时不会造成消息延迟;
  3. 空载行为:无图片任务消息时,poll每隔十几毫秒超时返回,执行一次eventfd写操作后再次休眠;
  4. 损耗特征:单次循环CPU消耗极低,瞬时仅1%占用,短期无法察觉;长期7×24小时不间断循环,CPU时长持续累积,出现“没干活但耗时极高”的异常现象。

四、对业务/服务器的负面影响

  1. 长期无效消耗CPU资源,多实例部署后损耗会线性放大;
  2. 无业务任务时持续占用CPU,挤占其他图片处理、存储服务算力;
  3. 持续高频系统调用增加内核上下文切换开销,轻微拉高整机sy系统CPU占比;
  4. 长时间运行后进程CPU累计时长虚高,运维监控易误判程序卡死、异常繁忙。

出现频率:(必现)

收藏
送赞
分享
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则