buffers 和 cache 都是内存中存放的数据,不同的是,buffers 存放的是准备写入磁盘的数据,而 cache 存放的是从磁盘中读取的数据
测试环境tomcat进程占用CPU一直持续99%,但是通过jstack查看log,也没有任何线程死锁的情况。 此时通过$catalina_home/bin/shutdown.sh脚本无法正常停止tomcat。
上次我们说到PaaS的发展历史,从Cloud Foundry黯然退场,到Docker加冕,正是Docker“一点点”的改进,掀起了一场蝴蝶效应,煽动了整个PaaS开源项目市场风起云涌。
前几个月换了一个新工作,Windows端完全转入了Linux服务器端,语言也彻底变成了C,偶尔夹杂着C++。对于我来说,之前的Vxworks,Qt,VS之类的IDE之下的调试定位也完全都没用了,最近一直在做提测项目,对问题定位,查找问题也有了一定的了解。 在这简单说一下,最近的定位调试命令。
在常见的面试的过程中,面试官都会问你一下常用的的linux命令,如果一上的来就说一些 cd.. , cp ls , vi, mkdir, rm -rf 什么的是没错的但是这些常用的命令说出去就显示不出你的优势,但凡是用过linux的都会这几个常用的命令,所以要突出自己的优势可以了解一些更深入的linux命令。
java TestLinuxDemo
当一个循环可以执行无限次,也就是没有终止条件,我们称这个循环是死循环。编写死循环程序实际上是不对的,一旦写出来一个程序运行后发现是死循环,一定要立即终止程序的运行!用Python实现一个死循环非常简单,while True就可以。
最近看牛客网发现了CPU 100% 怎么办这个问题,这个问题的重点是定位和解决,会用到Linux和java的的很多命令,所以写篇博客记录和总结一下。
在项目中遇到一个问题,我们服务提供给外部的一个接口 queryXXX 一直返回 429 错误(Too Many Requests),接口没有返回值,而且服务越用越卡,要重启一下才能恢复。于是马上就想到是不是因为这个接口产生了死循环,导致接口无法正确返回,同时导致后台 CPU 和内存占用飙升,顺着这个思路定位下去,确实顺利的找到的问题所在。
最近因为太忙,时间不够,导致长时间没写笔录,没有好好去总结自己,很不应该,要调整回来。
Magic SysRq 组合键是一串能直接与 Linux 内核沟通的组合键,允许使用者就算在系统进入死循环濒临崩溃时,直接呼叫系统底层将数据写入档案系统或重新开机,避免尚未写入档案系统与硬盘的数据在开机后消失。在 Linux 系统中,推荐尽量使用 Magic SysRq 组合键而不是直接硬关机。
最近新版本发布后,在运行一段时间后程序突然无响应了,观察监控,发现JVM堆内存占用在某个时间点突然飙升,最终导致应用无响应:
lldb工具的安装,linux下netcore如何生成dump文件,查看下文 centos7使用lldb调试netcore应用转储dump文件
(友情提示:本博文章欢迎转载,但请注明出处:hankchen,http://www.blogjava.net/hankchen)
本来是在研究epoll的另一个问题的,结果发现这个问题,所以这篇文章就先写这个问题吧。
PS:一般的生产服务器CPU稳定在80-85以内,不会让资源利用率太高,也不会太低,资源利用率很高的话,留一些剩余的空间,证明你的机器买了那么多可能就是浪费,CPU和内存都是一样的。在高并发的情况,一般都是需要提前做优化,做测试的,往往有时候大家的一些编码习惯导致的出其不意的问题。网络突然慢了,请求慢了,都可以按照这个思路来定位问题。
CGI 服务发布到现网后,现网机器出现了Full GC告警,同时CPU飙高99%。在优先恢复现网服务正常后,开始着手定位Full GC的问题。
CGI 服务发布到现网后,现网机器出现了Full GC告警,同时CPU飙高99%。在优先恢复现网服务正常后,开始着手定位Full GC的问题。在现场只能够抓到四个GC线程占用了很高的CPU,无法抓到引发Full GC的线程。查看了服务故障期间的错误日志,发现更多的是由于Full GC引起的问题服务异常日志,无法确定Full GC的根源。为了查找问题的根源,只能从发布本身入手去查问题,发现一次bugfix的提交,有可能触发一个死循环逻辑:
1、在Linux中启动项目:java -cp ref-jvm.jar -XX:+PrintGC -Xms200M -Xmx200M ex13.FullGCProblem
读过《重构 - 改善既有代码的设计》一书的同学们应该都很了解“代码的坏味道”。当然确定什么是代码“坏味道”是主观的,它会随语言、开发人员和开发方法的不同而不同。在工作当中,很多时候都是在维护之前的项目和在此基础上增加一些新功能,为了能让项目代码易于理解和维护,要时刻注意代码中的“坏味道”,当发现代码如果有坏味道了,要及时去重构它使其变成优秀的整洁的代码。今天我们要聊的是“坏味道的代码”给系统性能带来的影响,笔者会给大家展示几个案例,希望能对大家有所启发和帮助。
以上就是我目前的理解,还有一种使用迭代器时的fast-fail,以后有机会更新。 关于ConcurrentHashMap可以看看我的另外一篇,欢迎指正:ConcurrentHashMap浅析
CPU占用率突然飙升是技术人员常遇到的一个棘手问题,它是一个与具体技术无关的普遍挑战。
CPU 利用率,又称 CPU 使用率。顾名思义,CPU 利用率用于描述 CPU 的运行情况,反映了一段时间内 CPU 被程序占用的情况。使用率越高,表示计算机在该时间段内运行了更多的程序,反之则较少。CPU 的利用率与其性能直接相关。
上一篇介绍了ANR问题的相关知识,本篇介绍如何分析ANR问题。下面链接是我之前分析的一个ANR问题实例,实战与理论结合更容易理解。 https://blog.csdn.net/qq_43804080/article/details/99978439
通常情况下,我们一台宿主机上会同时启动多个Docker容器,而在默认情况下,Docker是没有限制其运行的容器所使用的硬件资源,比如CPU,内存,IO等。而在实际环境中,往往一个容器的负载过高,会占用宿主机的大部分资源,会导致其他容器的访问资源被抢占,而出现响应超时或无法响应等情况。
docker 利用 Linux 内核的 cgroup 功能,实现对容器的资源使用限制,通过将容器内的进程 PID号 加入同一个以容器ID为开头命名的cgroup控制组内,实现容器进程的资源限制
2、设置应用程序池的回收时间,默认为1720小时,可以根据情况修改。同时,设置同时运行的w3wp进程数目为1.再设置当内存或者cpu占用超过多少,就自动回收内存
内存溢出 out of memory : 通俗理解就是内存不够用了,是我们工作当中经常会遇到的问题,内存溢出有可能发生在正常的情况下,而非代码层面问题导致,比如高并发下,大量的请求占用内存,垃圾回收机制无法进行回收,而导致的内存溢出,这种情况就需要我们去调整架构了。一但出现内存溢出问题,我们需要快速定位并解决,尤其是生产环境,所以针对内存溢出问题,我们需要掌握一些常用的排查工具,针对不同场景、现象有快速排查思路。引起内存溢出的原因有很多种,常见的有以下几种:
在日常生活中我们基本都是使用有操作系统的计算机来完成我们的需求的,比如在计算机上玩游戏、写文档等等,这些工作都是在有操作系统的计算机上完成的,没有操作系统,我们就没能在计算机上完成我们想做的事情。常见的操作系统有Windows、Linux、Unix。
代码的正确性是实现策划案的基本,是功能的基本要求,所以上线需要检查自己负责的代码是否有问题。包括规范问题,逻辑问题,是否符合需求,以及设计的合理性。
最近在看《深入理解Java虚拟机:JVM高级特性与最佳实践》(第二版)这本书,理论+实践结合,深入浅出,强烈推荐给大家。 这两天在“小怪的java群”里面也对JVM内容进行了一个讨论,讨论的内容主要包括如下几个方面: 1)内存溢出和内存泄露的介绍? 2)如何排查和处理内存泄露? 一、内存溢出和内存泄露 一种通俗的说法。 1、内存溢出:你申请了10个字节的空间,但是你在这个空间写入11或以上字节的数据,出现溢出。 2、内存泄漏:你用new申请了一块内存,后来很长时间都不再使用了(按理应该释放),但是
学校校园网登录是web式的,即随便打开一个网页就会自动跳转到登录页面,然后输入用户名密码,点登录,便可以上网了。
大家在工作中或许或多或少都接触过Docker,那你知道Docker以及容器化背后的原理到底是什么吗?
线上问题排查总结 Cpu飙高可能的原因 CAS自旋 没有控制自旋次数;乐观锁 死循环----cpu飙高的问题;控制循环次数 云服务器redis被注入挖矿程序;端口像公网暴露;Redis端口不要被外网访问,ip黑名单 服务器被DDOS攻击导致cpu飙高。限流ip、黑名单,图形验证码。 Windows系统排查cpu飙高方法 制造死循环让cpu飙高的代码 package com.company; /** * @author 晓果冻 * @version 1.0 * @date 2021/6/23 7:45
最近在看《深入理解Java虚拟机:JVM高级特性与最佳实践》(第二版)这本书,理论+实践结合,深入浅出,强烈推荐给大家。 这两天对JVM内容进行了一个讨论,讨论的内容主要包括如下几个方面。 1)内存溢出和内存泄露的介绍? 2)如何排查和处理内存泄露? 一、内存溢出和内存泄露 一种通俗的说法。 1、内存溢出:你申请了10个字节的空间,但是你在这个空间写入11或以上字节的数据,出现溢出。 2、内存泄漏:你用new申请了一块内存,后来很长时间都不再使用了(按理应该释放),但是因为一直被某个或某些实例所持
最近在看《深入理解Java虚拟机:JVM高级特性与最佳实践》(第二版)这本书,理论+实践结合,深入浅出,强烈推荐给大家。
也叫 同步阻塞IO , 请求数据的进程需要一直阻塞等待读取完成才能返回,同时整个读取的动作也是要同步等待I/O操作的完成才返回。
所谓Apache出现CPU高占用率就是指Apache在一段时间内持续占用很高的CPU使用率,甚至达到CPU100%,这个时候造成网站无法访问。解决的方法就是仔细观察Apache的日志文件,查阅错误的信息。 下面针对几种错误信息进行分析并给出解决的方法: 1.Apache与WinSockv2相冲突 Apache官方提供的手册中提到,在Windows系统下Apache2.x为了提高性能而使用了MicrosoftWinSockv2API,但是一些常见的防火墙软件会破坏他的正确性,从而使得Apache出现死循环操作造成CPU100%。 可以依次采用下面的方法来解决上问题,如果进行了一步还有问题就继续下一步: 1)在httpd.conf文件中使用Win32DisableAcceptEx禁止Apache使用MicrosoftWinSockv2API: Win32DisableAcceptEx#禁止使用AcceptEx() 2)使用SystemRepairEngineer(SREng)查看WinSocket供应者,如果出现非MS的陌生项则将其删除,并使用软件的“重置WinSocket”按钮进行重置。 3)卸载与Apache相冲突的杀毒软件或防火墙软件。 如果进行上面的三个步骤之后还有问题,那应该看看是不是还有下面的错误。 2.是否加载了第三方模块(so文件) Apache2.x要求所有的第三方模块都必须是线程安全的,但有很多第三方的模块可能存在内存泄露,因此时间一长就可以极大的消耗Apache资源。所以可以采用将所有的第三方模块逐个关闭的方法看看运行一段时间之后Apache对资源的占用是否有所改善。 3.“Terminating1threadsthatfailedtoexit”错误 上面错误中的数字1有可能是其他数字,造成这个错误的原因是Apache在关闭并发线程的时候出现线程溢出,从而造成内存泄露,表现出来的就是Apache所占用的系统资源持续增长。 具体来说,Apache的子进程在结束当前请求之前会首先将所有的并发线程进行关闭,在关闭的时候会等待3分钟,如果3分钟之内没有将所有的线程关闭则会抛出上述的错误提示,然后强制关闭。这样就造成了内存溢出,时间一长会使得Apache所占用资源持续增长直到无法工作。这个时候可以适当将MaxRequestsPerChild的值降低,使得Apache子进程所并发的线程数量减少,从而降低该错误出现的几率。 但是这种方式并不能彻底解决问题,幸好Apache2.0.x的最新版本(2.0.63)解决了之前版本的这个问题,如果3分钟之内有线程没有关闭的话会自动根据时间情况再增加等待结束的时间直到最终将所有的线程结束。日志文件中会出现类似下面的信息: Child1952:Waiting150moresecondsfor2workerthreadstofinish. Child1952:Waiting120moresecondsfor1workerthreadstofinish. Child1952:Allworkerthreadshaveexited. 4.“file.//server//mpm//winnt//child.c,line1078,assertion“(rv>=0)&&(rv 这个错误是Apache的一个bug(#11997),可以通过Win32DisableAcceptEx禁止Apache使用WinSocketv2来避免此bug,具体设置见前述。 5.PHP5.2.1以上版本的libmysql.dll与MySQL5不兼容 PHP5.2.1以后的新版本(截止目前最新版本为5.2.5)中用于连接MySQL的libmysql.dll组件与MySQL5不兼容,在Apache中运行PHP的时候会造成Apache产生CPU100%的问题。 解决的方法就是从http://www.php.net/releases/下载5.2.1版本,将压缩包中的libmysql.dll文件覆盖现在的文件,然后重启Apache就可以了。 6.病毒或木马程序命名为Apache.exe 有的时候病毒或木马程序会将其名称命名为Apache.exe文件达到一种掩饰的目的,这个时候使用第三方进程分析器查看进程的路径然后将其删除或使用杀毒软件清除就可以了。 7.程序编写不严谨造成死循环等错误 如果上面的问题都不存在Apache依然产生CPU100%的问题的话,通常来说就应该是Web程序自身的问题了,例如死循环等等。这个时候需要在日志中设置HTTP请求的文件及执行的时间,然后查找出执行时间比较长的地址进行分析排查。
版本: redis-3.2.9 部署: 5台64G内存的物理机,每台机器启动2个redis进程组成5主5备集群,每台机器1个主1个备,并且错开互备。 问题: 发现redis进程占用内存高达40G,而且全是备进程。尝试通过重启进程方式释放内存,但进入复制死循环,报如下所示错误: for lack of backlog (Slave request was: 51875158284) 通过网上查找资料,修改client-output-buffer-limit和repl-timeout值,问题未能得到解决,仍然报for lack of backlog,并仍然循环复制。 move备进程的data目录,但保留nodes.conf文件,然后再重启,这次重启成功。采取同样方法处理其它备进程,同样成功,内存同样降到和主进程接近的大小10G。 待分析:为何备进程占用的内存是它的主进程的4倍(分别40G和10G)?除了上述方法外,是否有其它更安全可靠的释放办法?
代码中存在无限循环或者条件判断错误导致的死循环,使得CPU一直在执行相同的操作,导致CPU利用率达到100%。
要说最常见的JVM参数应该是 -Xmx 与 -Xms 这两个参数,前者用于指定初始化堆的大小,而后者用于指定堆的最大值。然后就是-Xss参数,它用于指定线程的堆栈大小。可以看到这三个参数都是以-X开头的,它们是-X参数吗?实际上不是的,它们是XX参数,是属于一种缩写形式:
答:栈溢出发生的时候,栈顶指针(SP - Stack Pointer)一定会超出栈的范围,所以也可以在发生线程切换的时候,检测SP指向的地址是否超过了栈的内存限定。
currentHashMap是线程安全并且高效的一种容器,我们就需要研究一下currentHashMap为什么既能够保证线程安全,又可以保证高效的操作
笔者非科班转行,两个月拿了十多个offer,其中包括了互联网大厂,央企,国企,银行等,下面看看都面了什么(部分回忆)。总之,在面试国企等企业时,会有一些有意思的问题,也会出现群面的场景。 1 阿里一面 指针和引用的区别 define和const 内联函数和define c++内存管理 栈和堆区别,全局变量和局部变量 c++多态,虚函数,纯虚函数 多态的好处 数据库索引,给一个语句问有没有用到索引,底层怎么实现的 B树和B+树 哈希冲突 说一说常见的排序算法和时间,空间复杂度 TCP,UDP,可靠传输,网络什
在分布式计算系统中,有两个以上的进程在并发执行,每个进程都在等待被其它的进程所占用的系统资源而不能继续运行,即导致系统中任何一个进程都无法运行下去(死循环),这就产生了死锁。
在普遍的操作系统中,我们所遇到的进程状态有:运行、新建、就绪、挂起、阻塞、停止、挂机、死亡…等等,但是我们并不懂它们(学了等于没学),因为这是操作系统层面的说法,它的理论放到哪个操作系统中都对。所以我们要学习一个具体的操作系统来理解进程状态,而这里我们使用的当然就是Linux!
一直在忙,之前一直怀疑机器中马,kswapd0这个进程4核心CPU24小时跑满单核心,简单排查无果,看了
领取专属 10元无门槛券
手把手带您无忧上云