java程序运行一段时间后内存爆满,cpu使用率迅速增加(解决)

探讨了Java程序中定时任务导致CPU使用率异常升高的问题,分析了资源占用及线程堆积的原因,并提出了解决方案,包括优化数据处理逻辑和设置合理的超时时间。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

java程序在运行一段时间后,内存逐渐爆满,随后cpu使用率上升

上周遇到一个很奇葩的问题,现场反应,程序运行20分钟以后cpu使用率在90%以上,拿到代码无从下手,经过几天的研究,最终找到原因并解决。

通过现场bug现象,初步分析,是由于程序占用过多的系统资源,导致cpu使用率过高,怀疑是资源没有合理释放,或者程序在运行时出现死循环

一、通过windows自带工具查看占用内存的线程

https://blog.youkuaiyun.com/hexin373/article/details/8846919

我参照上面这篇文章,可以定位到具体问题位置,不得不说,这种方式也许可以解决几乎所有由代码引起的cpu使用率过高的问题,但我通过这种方式并没有定位到程序的具体代码,而是如下的位置:

 在计算机上,我的cpu使用率过高的线程被定位到了这几个垃圾回收器上,进一步陷入迷惑,垃圾回收器不是java自己维护的吗!!怎么会有问题!!这也排除了cpu使用率过高是由于死循环造成的可能

二、cpu使用率高是由于GC线程

GC占用cpu线程,那肯定是程序中资源占用不释放了,那就去排查代码喽,通过一系列鬼知道发生了什么的操作(什么开启关闭部分功能,代码logger打印查看...),最终定位到了一个定期任务上,然后就去看看哪的资源不释放,也在网上看了下需要手动关闭的资源:

  1. io流需要手动关闭
  2. 获取到的连接,不管是redis还是jdbc
  3. hibernate通过openSession创建的连接(getCurrentSession()绑定线程,在rollback或commit后自动归还连接到池或关闭)

局部代码排查后并没有发现未释放的资源...wtf....这怎么办!!!

三、问题描述

既然代码没问题,就从业务方面入手,下面我说下我的问题,希望能提供一些思路:

既然是定时任务模块的问题,那就看定时任务,如下是定时任务的部分代码:

 for (String runId : runIds) {
      tempObj = tempMap.get(runId);//从缓存中获取运行中对象
      if(tempObj != null){
            // 异步执行普通节点线程任务
            DbThreadPool.getInstance().add( new DealRunTempTask(tempObj,dealDataService));
      }
  }

大概就是加载一个模版开启一个线程,线程数已经被限定在了一定数量,那问题就是在处理每个线程的时间过长,导致多个任务叠加在一起,老线程没运行完不释放资源;新线程拿不到资源,无法运行。

线程运行时间过长是因为每个线程中需要处理的数据越来越多,程序运行时间越长,叠加的待处理数据越多,一些数据在获取失败后,会判断数据库连接等是否可用,造成超时等待,这样时间会更长,大概业务是这样:

可以看出,处理失败的数据只要不过期会不断累加,造成处理时间越来越长,最终内存爆满,cpu暴增。

 四、解决方法

为业务设置合理超时时长,并优化数据处理失败时的逻辑。使数据处理失败的处理判断用时更短,例如:同一类超时情况只判断一次,失败任务分批处理。

五、总结

我碰到的cpu使用率过高,是由于定时任务处理时间过长,每次定期任务间隔时间短,导致定期任务叠加执行,耗用大量系统资源。解决方法是:优化缩短每次定时任务执行时间。

<think>好的,我现在需要解决在八核服务器上部署DeepSeek模型时CPU占用率过高的问题。首先,我应该回顾用户提供的引用内容,看看有没有相关的解决方案。 引用[4]提到了解决systemd-journald占用CPU过高的问题,包括修改日志配置关闭相关服务。虽然这不是直接针对模型部署的,但可能系统日志服务在后台消耗资源,影响模型运行。可以考虑检查系统日志服务是否占用了过多资源,必要时调整日志配置。 接下来,用户提到的是DeepSeek模型在八核服务器上的CPU占用率高,可能涉及到模型本身的优化服务器资源配置。根据引用[2][3],Ollama是运行DeepSeek模型的底层,部署时需要注意模型权重的路径资源分配。可能需要调整Ollama的配置,比如线程数或资源限制。 另外,模型并行化处理可能不够有效,导致CPU核心未能充分利用或者争抢资源。需要确认模型是否支持多线程,并正确配置Ollama使用合适的线程数。此外,服务器本身的性能调优,如进程优先级、资源限制,也可能有帮助。 还可能存在其他后台进程占用CPU资源,需要监控系统资源使用情况,找出具体是哪个进程导致的高负载。如果是模型推理本身的问题,可能需要优化模型或调整批处理大小。 最后,参考引用[4]中的方案,可以尝试关闭不必要的系统服务,释放CPU资源给模型使用。同时,确保系统更新到最新版本,以获得更好的资源管理支持。</think>针对在八核服务器上部署DeepSeek模型时CPU占用率过高的问题,以下是分步解决方案: ### 1. 检查系统日志服务占用 修改日志配置文件并重启服务: ```bash # 修改journald日志存储策略 sudo vi /etc/systemd/journald.conf # 将[Journal]下的Storage改为none Storage=none # 重启服务 sudo systemctl restart systemd-journald ``` 该操作可降低日志服务对CPU的消耗[^4]。 ### 2. 优化Ollama资源配置 (1)创建模型时指定并行度: ```bash # 在Modelfile中添加并行参数 PARAMETER num_threads 8 PARAMETER num_parallel 4 ``` (2)限制CPU核心使用: ```bash # 启动时绑定CPU核心 taskset -c 0-7 ollama serve ``` ### 3. 模型加载优化 ```bash # 指定模型加载方式(示例) OLLAMA_NUM_PARALLEL=8 ollama run deepseek-r1 ``` 通过环境变量控制并行计算线程数[^3]。 ### 4. 监控与诊断 (1)实时监控工具: ```bash htop # 查看CPU核心利用率 iotop # 检查IO等待 ``` (2)生成资源报告: ```bash sudo perf top -p $(pgrep ollama) ``` ### 5. 系统级优化 (1)调整进程优先级: ```bash renice -n -5 $(pgrep ollama) ``` (2)禁用超线程: ```bash echo 0 > /sys/devices/system/cpu/cpu4/online # 对cpu5-7重复操作 ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值