checkpoint防火墙CPU飙高报警

前些天报警系统频繁报出checkpoint防火墙CPU0,CPU1使用率高达95%。登陆checkpoint命令行

expert模式使用"top"命令可以看到一个"monitored"的进程很占用CPU

查了一下相关文档主要是/var/log/db/var/log/下的db文件高达700多M

官方提供的处理方法如下:

=========================================================================================================

tellpmprocess:monitord

此命令是用来暂停monitored进程

cp /var/log/db /var/log/db_ORIGINAL
将db备份为db_ORIGNAL

sqlite3 /var/log/db
    VACUUM;
    .exit

tellpm process:monitord t

启动monitored进程

但是执行之后效果不怎么样,原本db的大小为700多M,执行之后变成了700M

可以使用  ls-lh /var/log/db* 查看db的大小

========================================================================================================

网上查找到另外的解决方法,直接将整个db文件备份之后删除,等待系统重新生成

tellpmprocess:monitord

此命令是用来暂停monitored进程

mv /var/log/db /var/log/db_ORIGINAL

将db备份为db_ORIGNAL并删除原db文件

tellpm process:monitord t

启动monitored进程

执行之后等待几分钟系统重新生成db文件,整个CPU负载下降

可以使用以下命令查看monitored进程的状态

ps auxwww | grep monitord

=============================================================

时间: 2024-12-14 11:42:53

checkpoint防火墙CPU飙高报警的相关文章

STORM在线业务实践-集群空闲CPU飙高问题排查

源:http://daiwa.ninja/index.php/2015/07/18/storm-cpu-overload/ 2015-07-18AUTHORDAIWA STORM在线业务实践-集群空闲CPU飙高问题排查有2条评论 STORM在线业务实践-集群空闲CPU飙高问题排查 最近将公司的在线业务迁移到Storm集群上,上线后遇到低峰期CPU耗费严重的情况.在解决问题的过程中深入了解了storm的内部实现原理,并且解决了一个storm0.9-0.10版本一直存在的严重bug,目前代码已经合并

mongoDB cpu飙高问题

问题描述: 最近几天生产环境上的mongodb一直在报警,cpu飙高,其他如内存.iops.连接数.磁盘操作等都正常.通过定位业务,发现是由于mongodb的表其中一个查询未建立索引导致,110多W的数据,每秒经历的查询10次左右.但是未建立索引导致数据查询走全表扫描,从而致使导致cpu飙高. 解决方式:db.preservationlog.createIndex({eid:1}) ; 为preservationlog表的eid字段创建索引,问题得以解决. cpu曲线图 mongodb所在服务器

java进程CPU飙高

因为这段时间一直在弄监控,但是工作还是在进行中 因为机器不多,所以今天早上巡检了一下,看到一台生产机器上的CPU飙高 top 然后就请出了大神工具JVM 具体JVM的介绍看:http://www.cnblogs.com/smail-bao/p/6027756.html CPU飙高的话,我们就是用jstack的工具 首先我们使用top查出来是哪个进程导致的CPU飙高 这里我们看到是PID号为11506的进程 这个进程对应的项目是哪个(为了后面可以把错误的定位发给相关的开发人员看),使用ps -au

STORM在线业务实践-集群空闲CPU飙高问题排查(转)

最近将公司的在线业务迁移到Storm集群上,上线后遇到低峰期CPU耗费严重的情况.在解决问题的过程中深入了解了storm的内部实现原理,并且解决了一个storm0.9-0.10版本一直存在的严重bug,目前代码已经合并到了storm新版本中,在这篇文章里会介绍这个问题出现的场景.分析思路.解决的方式和一些个人的收获. 背景 首先简单介绍一下Storm,熟悉的同学可以直接跳过这段. Storm是Twitter开源的一个大数据处理框架,专注于流式数据的处理.Storm通过创建拓扑结构(Topolog

平时碰到系统CPU飙高和频繁GC,你会怎么排查

处理过线上问题的同学基本上都会遇到系统突然运行缓慢,CPU 100%,以及Full GC次数过多的问题.当然,这些问题的最终导致的直观现象就是系统运行缓慢,并且有大量的报警.本文主要针对系统运行缓慢这一问题,提供该问题的排查思路,从而定位出问题的代码点,进而提供解决该问题的思路. 对于线上系统突然产生的运行缓慢问题,如果该问题导致线上系统不可用,那么首先需要做的就是,导出jstack和内存信息,然后重启系统,尽快保证系统的可用性.这种情况可能的原因主要有两种: 代码中某个位置读取数据量较大,导致

几个常用的内存、CPU飙高 分析工具

Process Hacker.Windbg.vs2017 调试托管内存.Microsoft.Samples.Debugging.ants memory profiler.ants performance profiler 有时间详细介绍这几个工具怎么玩,不过这几个工具只是辅助分析飙高原因,都很难直接定位,需要经验......

JVM 线上故障排查基本操作--CPU飙高

JVM 线上故障排查基本操作 CPU 飚高 线上 CPU 飚高问题大家应该都遇到过,那么如何定位问题呢? 思路:首先找到 CPU 飚高的那个 Java 进程,因为你的服务器会有多个 JVM 进程.然后找到那个进程中的 “问题线程”,最后根据线程堆栈信息找到问题代码.最后对代码进行排查. 如何操作呢? 通过 top 命令找到 CPU 消耗最高的进程,并记住进程 ID. 再次通过 top -Hp [进程 ID] 找到 CPU 消耗最高的线程 ID,并记住线程 ID. 通过 JDK 提供的 jstac

Hession反序列化导致CPU占用飙高

背景 今天发布一个线上服务,暂且称之为O,发布完后,依赖O服务的2个服务C和W大量Time报警,并且这两个服务的CPU占用都飙到了40%左右,平时只有10%的样子. 这时去看O服务的监控,Time并没有升高,QPS反倒降了一半.同时C和W服务器日志中出现了大量的WARNING,信息如下: java.lang.ClassNotFoundException: com.我是不可描述的信息.PropertyAo Dec 02, 2016 6:24:33 PM com.alibaba.com.caucho

记一次查内存异常问题(续《记一次Web应用CPU偏高》)

继上一次查应用的CPU飙高问题(http://www.cnblogs.com/hzmark/p/JVM_CPU.html)过去10天了.上次只是定位到了是一个第三方包占用了大量的CPU使用,但没有细致的去查第三方包为什么占用了这么高的CPU,并且内存为什么如此诡异.总的来说上一次排查带来的收获是熟悉了JVM的工具使用和大致定位到了问题. 在上次排查问题之后,应用出现异常的频率还是较高,终下定决心再查一次,而这次排查的重点落在内存方面.因为怀疑CPU偏高是因为内存的异常导致频繁的GC引起的. 首先