1、yum install -y htop iotop smem 2、smem -k -s uss //查看进程使用的内存量 smem -p -s uss //查看进程使用的内部百分比.../perf -k //查看单个进程使用的内存量 3、 ps aux|head -1;ps aux|sort -nr -k4|head -10 //获取内存使用最大的10个进程 ps aux|head...-1;ps aux|sort -nr -k3|head -10 //获取CPU使用最大的10个进程 4、查找僵尸进程：ps -e -o stat,ppid,pid,cmd|grep -e...'^[zZ]' 5、杀死僵死进程：ps -e -o stat,ppid,pid,cmd|grep -e '^[zZ]'|awk '{print $2}'|xargs kill -9
16 系统出现异常排查思路 16.1 查看用户信息 16.1.1查看当前的用户 # who 04:39:39 up 1:30, 1 user, load average: 0.01, 0.01,...history *************** 683 last 684 clear 685 last 686 clear 687 history 16.3查看现在运行的进程...S 03:09 0:00 [stopper/0] 16.4查看网络服务的进程 16.4.1查看正在运行的端口 # netstat -nltl Active Internet connections...0 0 0 0 57 84 1 1 99 0 0 ********************* 16.9.3实时的对系统的监控 # mpstat 2 10 Linux...0.00 0.00 0.00 0.00 0.50 0.00 0.00 99.50 ********************* 16.9.4动态显示当前的操作IO的进程
比如当 CPU iowait 高时，应优先排查磁盘 I/O；当 CPU steal 高时，就优先排查宿主机状态。...---- #### 0x01 Linux信息收集 描述:当我们对异常系统进行处理，必须先进行主机基础信息的收集，以防出错后可以更快的恢复或者求助; CentOS系列: #!...如何排查用户态 CPU 使用率高？...因此，当你在做应用发布、配置变更或性能优化时，如果想定位消耗 CPU 最多的 Java 代码，可以遵循如下思路： 排查思路: #1.定位高负载进程 pid 通过观察load average，以及负载评判标准确认服务器是否存在负载较高的情况...] #比如0x431 #4.jstack日志异常查询 jstack 1040|vim +/0x431 - #5.定位具体的异常业务使用 pwdx 命令根据 pid 找到业务进程路径 pwdx [PID
一、查看某个进程占用CPU过高问题 查看当前系统CPU占用情况 top PID为29706占用过高 查看占用过高进程中线程使用情况(可以得到每个线程占用资源情况) top -Hp 29706 将JVM...信息导出到pid.txt文件汇总 jstack 29709 > pid.txt 将进程PID转为16进制 printf '%x' 29709 在打开的文件中寻找占用CPU过高进程信息 vim pid.txt
今天来给大家分享下这两天遇到的一个问题，服务器被挖矿了，把我的排查记录分享下，希望能帮到有需要的同学。...cpu使用率基本跑满（用户态），没有发现可疑的进程，初步怀疑可能是进程在哪里隐藏了 执行命令ps -aux --sort=-pcpu|head -10 嗯哼，藏得够深的，可还是被揪出来啦 ? ?...这个eta可能是起的一个守护进程，用于唤起上面圈起来的python进程， 这个脚本的用途是，链接远程服务"http://g.upxmr.com:999/version.txt",并下载 写入到本地隐藏文件....d目录下都存在S01nfstruncate文件，可能是自启动文件 现在排查的很明朗了，接下来着手清理工作 1....这次分享希望对也中挖矿程序的同学， 提供一些排查思路
Linux系统编程 - 进程异常自动重启 开篇 在Linux平台，自研服务进程通常以守护进程的形式在后台常驻运行。但偶尔也会遇到服务进程异常crash，导致产品基本功能异常，影响恶劣。 ...则可以通过这点，实现进程异常crash的重启。 「方案一」 在《Linux系统编程》中，有讲道：当子进程终止时，会发送SIGCHLD至父进程。...父进程注册信号SIGCHLD监听，在处理函数中，通过wait()/waitpid()获取异常子进程的pid。 通过pid匹配异常进程对应的bin文件路径，再重新拉起此进程。...但是在实测过程中发现，子进程异常终止时，父进程存在小概率收到不到信号SIGCHLD，网上的说法是SIGCHLD不可靠。从而导致监测子进程状态失败，因此将终端触发改为轮询，衍生了方案三。...经过此方案，在Linux系统部署用户进程时，加入此方案，能够避免进程异常导致的系统宕机等其他严重问题。
通过《Linux进程的内存管理之malloc和mmap》我们知道，这两个函数只是建立了进程的vma，但还没有建立虚拟地址和物理地址的映射关系。...当进程访问这些还没建立映射关系的虚拟地址时，处理器会自动触发缺页异常。 ARM64把异常分为同步异常和异步异常，通常异步异常指的是中断（可看《上帝视角看中断》），同步异常指的是异常。...关于ARM异常处理的文章可参考《ARMv8异常处理简介》。...由于内存和磁盘的读写性能差异较大，Linux会在内存充裕时将空闲内存当作swap cache，用来缓存磁盘数据，以提高I/O性能。相对的在内存紧张时Linux会将这些缓存回收，将脏页回写到磁盘中。...换入操作结束后，对应swap area的页引用减1，当减少到0时，代表没有任何进程引用了该页，可以进行回收。
到机器上通过ps查看进程，发现凌晨01:07开始调起的python进程，经过了10多个小时依然没有退出的迹象，正常情况下这类任务执行不会超过10s，这已经严重超出了预期时间。...幸好卡死的进程还在，我们有现场可以对这个进程做进一步分析，定位此时python任务内部在做什么。...1、找到进程pid首先通过ps -ef找到对应的pid， 拿到对应的python进程pid： 49912、通过strace命令: strace -T -tt -e trace=all -p 4991...可以看到此时进程在接收数据。...将文件拷贝到本地使用浏览器打开，就可以看到python进程当前的调用栈。
2、排查思路 2.1 定位高负载进程 pid 首先登录到服务器使用top命令确认服务器的具体情况，根据具体情况再进行分析判断。...通过观察load average，以及负载评判标准（8核），可以确认服务器存在负载较高的情况； 观察各个进程资源使用情况，可以看出进程id为682的进程，有着较高的CPU占比 2.2 定位具体的异常业务...2.3 定位异常线程及具体代码行 传统的方案一般是4步： 1、top oder by with P：1040 // 首先按进程负载排序找到 maxLoad(pid) 2、top -Hp 进程PID：1073...4、解决方案 定位到问题之后，首先考虑是要减少计算次数，优化异常方法。排查后发现，在逻辑层使用时，并没有使用该方法返回的set集合中的内容，而是简单的用set的size数值。...https://my.oschina.net/leejun2005/blog/1524687 [2] linux 系统监控、诊断工具之 top 详解 https://my.oschina.net/leejun2005
排查云镜异常，可以收集云镜日志让售后看下C:\Program Files\QCloud\YunJing\log复制该目录，对复制后的目录进行压缩，压缩成.7z格式（压缩率高，压缩文件小，方便传输）云镜的
2、排查思路 2.1 定位高负载进程 pid 首先登录到服务器使用top命令确认服务器的具体情况，根据具体情况再进行分析判断。 ?...观察各个进程资源使用情况，可以看出进程id为682的进程，有着较高的CPU占比 2.2 定位具体的异常业务 这里咱们可以使用 pwdx 命令根据 pid 找到业务进程路径，进而定位到负责人和项目： ?...2.3 定位异常线程及具体代码行 传统的方案一般是4步： 1、top oder by with P：1040 // 首先按进程负载排序找到 maxLoad(pid) 2、top -Hp 进程PID：1073...4、解决方案 定位到问题之后，首先考虑是要减少计算次数，优化异常方法。排查后发现，在逻辑层使用时，并没有使用该方法返回的set集合中的内容，而是简单的用set的size数值。...https://my.oschina.net/leejun2005/blog/1524687 [2] linux 系统监控、诊断工具之 top 详解 https://my.oschina.net/leejun2005
develop': __DevelopmentConfig, 'testing': __TestingConfig, 'product': __ProductionConfig, } 问题排查
集群熔断-Data too large 问题现象： 排查监控发现存在熔断，查看日志如下 应用日志： 2022-05-24T21:17:53.142+0800 ERROR service/...15578885480/14.4gb ES已经使⽤的内存 new bytes reserved: 222/222b 本次查询需要的内存 原因分析和解决方案 出现熔断说明当前节点 JVM 使用率过高，通过熔断保护进程不会
--新加的异常处理，只处理ConnectTimeoutException和UnknownHostException异常--> <!...长连接中，向server发请求，是先发送数据的，如果连接断开，应该是写数据异常，为什么是读数据异常呢？请求是否发送成功？发送之前有校验连接是否可用吗？...第3个异常是java.net.SocketException: Socket is closed，该异常在客户端和服务器均可能发生。...该异常在客户端和服务器端均有可能发生，引起该异常的原因有两个，第一个就是如果一端的Socket被关闭（或主动关闭或者因为异常退出而引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常(Connect...第5个异常是java.net.SocketException: Broken pipe。该异常在客户端和服务器均有可能发生。
背景 在使用腾讯云产品过程中，经常会遇到一些类似扣费异常，但又无法确认是否扣费异常的问题；本文基于这个主题，将通过一些案例来总结一下关于扣费异常的基本排查方法。 如何查看扣费详情？...排查方法-------通过明细账单自助排查 1）在账单概览控制台查看费用趋势，确认费用上涨的产品。...排查方法-------通过明细账单自助排查 1）按量结算：这个小时收取上个小时的使用费用，第二天收取前一天的使用费用。因此在销毁资源的这个时间段，也会计入使用周期，进行结算扣费。...排查方法---通过明细账单和点播产品计费文档自助排查 1）产品日结后付费，将于每日12:00 - 18:00，对前一日实际用量所产生的费用进行结算，所以可以通过明细账单查看扣费时间对应的使用时间。...总结 账号产生莫名扣费时，可以先通过收支明细和账单查看扣费产品及扣费时间，然后通过对应扣费产品的计费文档了解扣费规则，自助排查扣费是否属于异常情况。
前言 除了解决业务Bug之外，工作中通常我们还会面临两类问题： 线上服务负载异常，比如CPU负载异常飙高 线上服务内存持续增长，存在泄漏 一般我们会通过各种监控、报警系统，发现和定位问题，关于如何搭建服务监控可以参考之前的文章...所以今天就来看看这种情况下，如何定位服务负载异常的原因。...首先关于「负载异常」的问题，大都肯定都知道使用top或者htop等命令定位到某个进程或线程，好，问题来了： 如何定位到是哪个具体的函数导致的服务负载异常呢？...安装方式 yum install perf apk add --update perf 模拟请求 siege -c 3 -t 30S "http://localhost:6060/v1/demo" 采样进程...(当前目录会生成一个perf.data文件) perf record -F 99 -p 6 -g sleep 10 释义： -F 频率 每秒采样多少次 -p 进程 进程id -g 记录调用栈 sleep
| grep java ps –o nlwp 27989 获取真正在running的线程 JVM CPU高负载的排查办法 前言 通过本文，你将学会： 1、linux上进程及进程中线程排查的基本方法，如查看进程中的线程数...与普通进程相比，LWP与其他进程共享所有（或大部分）它的逻辑地址空间和系统资源；与线程相比，LWP有它自己的进程标识符，优先级，状态，以及栈和局部存储区，并和其他进程有着父子关系。...JVM CPU高负载的排查办法 今天线上一个java进程cpu负载100%。按以下步骤查出原因。...找到CPU负载高的线程pid 8627, 把这个数字转换成16进制，21B3（10进制转16进制，用linux命令: printf %x 8627）。...排查问题从这里深入。 今天最后排查出来的结果是“VM THREAD”把进程的资源耗尽。那只能说明是jvm在耗cpu。
参考链接： Java中的异常 今天，内网测试服务器A总是运行一段时间就服务器进程自行退出了，给出了“Java Result ：137”这样的错误码。上网查了一下这个137，感觉没有啥有价值的东西。...*这样的崩溃日志，同时也没有发现OOM的日志，也没有常见的Java 的堆异常log，关键是同样的环境，另外一台机器B，压力远比这个大，都稳定运行很长时间没有问题。...拿起手机，随意搜了一下“JAVA进程无端退出”，看到了一篇博客提出一个运维神指令dmesg（ps：有时候这个真是救命的神指令）可以查到一个进程的异常信息，在故障诊断方面非常有用。...“top”，“free”，“ps”，甚至 JVM 等工具都没有针对在容器内执行高度受限的 Linux 进程进行优化。...详情：https://fabiokung.com/2014/03/13/memory-inside-linux-containers/；所以这些收集程序的信息是不准确，只能反映物理机的状况。
生产环境发现的问题 1、NoHttpResponseException导致退款失败 功能上线后，我便开始监控B端支付模块的交易数据，前两天的数据并没有什么异常，支付完成的订单都已经退款完成。...排查到这里基本已经可以确定不是支付模块这边的问题了，但问题毕竟还是要解决的，于是我联系了C端的同事，暂时先通过接口的方式把消费者的钱进行退款。...然后开始排查C端系统的问题，通过C端的日志发现，在请求支付模块进行退款时存在一个异常信息，报错信息如下 ?...，服务端响应RST包导致此异常情况的发生。...大多数文章的建议是：捕获NoHttpResponseException异常进行重试。 3、验证思路 既然有了上述猜想，那么下一步肯定是要做验证的，验证一下在这个场景下确实会出现此现象。
二.找不到进程 1.总使用率高，但进程使用率很低，6个进程，但nginx和php-fpm均是sleep，stress才是运行的进程。...2.查看stress进程，发现不存在，进程关闭后又启动了一个新的，说明一直在关闭启动 pidstat -p 24344 第一个原因，进程在不停地崩溃重启，比如因为段错误、配置错误等等，这时，进程在退出后可能又被监控系统自动重启了...第二个原因，这些进程都是短时进程，也就是exec 调用的外面命令。这些命令一般都只运行很短的时间就会结束，你很难用top 这种间隔时间比较长的工具发现。...3.查看相应进程，找到父进程 pstree | grep stress 可以看到是php-fpm的子进程 4.查看php源码 grep stress -r index.php 5.记录性能事件，等待大约
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
