网站建设 长沙开福区注册万网后网站怎么赚钱的

当前位置： 首页 > news >正文

网站建设 长沙开福区,注册万网后网站怎么赚钱的,设计师怎么做响应式网站,集团网站群当你的服务器CPU飙升到900%#xff0c;系统卡顿、响应迟缓、业务受阻#xff0c;这种令人焦虑的场景是否让你束手无策#xff1f;别慌#xff0c;这并不是世界末日#xff0c;只要掌握正确的分析与定位方法#xff0c;就能快速找到问题根源#xff0c;并有效解决。 CPU…当你的服务器CPU飙升到900%系统卡顿、响应迟缓、业务受阻这种令人焦虑的场景是否让你束手无策别慌这并不是世界末日只要掌握正确的分析与定位方法就能快速找到问题根源并有效解决。 CPU 飙升到 900%到底是哪些因素导致如何快速定位问题并溯源处理 分析 CPU 飙升的常见原因 CPU 使用率异常高的情况通常可以归因于以下几类问题 代码问题 死循环、大量的计算密集型任务或低效算法。流量暴增 高并发请求导致系统资源耗尽。数据库瓶颈 SQL 查询未优化导致数据库CPU占用高。外部依赖问题 消息队列、第三方接口阻塞。恶意攻击 DDoS 攻击或者僵尸进程。 案例 某电商平台在促销活动期间用户访问量激增导致多个服务的CPU飙升。排查发现问题是由于缓存穿透导致大量请求直接打到数据库引发资源争夺。 01 场景1MySQL进程飙升900% 评估 大家在使用MySQL过程想必都有遇到过CPU突然过高或者达到200%以上的情况。 数据库执行查询或数据修改操作时系统需要消耗大量的CPU资源维护从存储系统、内存数据中的一致性。 并发量大并且大量SQL性能低的情况下比如字段是没有建立索引则会导致快速CPU飙升如果还开启了慢日志记录会导致性能更加恶化。生产上有MYSQL 飙升900% 的恶劣情况。 定位 使用top 命令观察确定是mysqld导致还是其他原因。 如果是mysqld导致的show processlist查看session情况确定是不是有消耗资源的sql在运行。 找出消耗高的 sql看看执行计划是否准确 index 是否缺失或者实在是数据量太大造成。 处理 kill 掉这些线程(同时观察 cpu 使用率是否下降)
一般来说肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降)等进行相应的调整(比如说加索引、改 sql、改内存参数)之后再重新跑这些 SQL。 进行相应的调整(比如说加索引、改 sql、改内存参数)
index 是否缺失如果是则建立索引。也有可能是每个 sql 消耗资源并不多但是突然之间有大量的 session 连进来导致 cpu 飙升这种情况就需要跟应用一起来分析为何连接数会激增再做出相应的调整比如说限制连接数等 优化的过程往往不是一步完成的而是一步一步执行一项优化措辞再观察再优化。分析当前的数据量、索引情况、缓存使用情况。目测数据量不大也就几百万条而已。接下来就去定位索引、缓存问题。 经过询问发现很多查询都是走MySQL没有用到缓存。 既然没有用到缓存则是大量请求全部查询MySQL导致。通过下面的命令查看: 发现类似很多相同的SQL语句一直处于query状态中。 初步分析可能是 user_code 字段没有索引导致。接着查询user表的索引情况 发现这个字段是没有建立索引。增加索引之后该条SQL查询能够正常执行。 没隔一会又发生大量的请求超时问题。接着进行分析发现是开启了 慢日志查询。大量的SQL查询语句超过慢日志设置的阀值于是将慢日志关闭之后速度瞬间提升。CPU的使用率基本保持在300%左右。但还不是理想状态。 紧接着将部分实时查询数据的SQL语句都通过缓存(redis)读写实现。观察一段时间后基本维持在了70%~80%。 总结 其实本次事故的解决很简单就是添加索引与缓存结合使用。 不推荐在这种CPU使用过高的情况下进行慢日志的开启。因为大量的请求如果真是慢日志问题会发生日志磁盘写入性能贼低。 直接通过MySQL show processlist命令查看基本能清晰的定位出部分查询问题严重的SQL语句在针对该SQL语句进行分析。一般可能就是索引、锁、查询大量字段、大表等问题导致。 再则一定要使用缓存系统降低对MySQL的查询频次。 对于内存调优也是一种解决方案。 02 场景2Java进程飙升900% 一般来说Java 进程不做大量 CPU 运算正常情况下CPU 应该在 100~200% 之间但是一旦高并发场景要么走到了死循环要么就是在做大量的 GC,  容易出现这种 CPU 飙升的情况CPU飙升900%是完全有可能的。 定位  CPU飙升问题定位的一般步骤是 首先通过top指令查看当前占用CPU较高的进程PID 查看当前进程消耗资源的线程PIDtop -Hp PID 通过print命令将线程PID转为16进制根据该16进制值去打印的堆栈日志内查询查看该线程所驻留的方法位置。 通过jstack命令查看栈信息定位到线程对应的具体代码。 分析代码解决问题。 处理 1、如果是空循环或者空自旋。 处理方式可以使用Thread.sleep或者加锁让线程适当的阻塞。 2、在循环的代码逻辑中创建大量的新对象导致频繁GC。比如从mysql查出了大量的数据比如100W以上等等。 处理方式可以减少对象的创建数量或者可以考虑使用 对象池。 3、其他的一些造成CPU飙升的场景比如  selector空轮训导致CPU飙升 。 处理方式 参考Netty源码无效的事件查询到了一定的次数进行 selector 重建。 采用top命令定位进程登录服务器执行top命令查看CPU占用情况找到进程的pid 很容易发现PID为29706的java进程的CPU飙升到700%多且一直降不下来很显然出现了问题。 使用top -Hp命令定位线程 使用top -Hp命令为Java进程的id号查看该Java进程内所有线程的资源占用情况按shftp按照cpu占用进行排序按shiftm按照内存占用进行排序 此处按照cpu排序 多个线程的CPU占用达到了90%多。我们挑选线程号为30309的线程继续分析。 使用jstack命令定位代码 线程号转换5为16进制
printf “%x\n” 命令tid指线程的id号将以上10进制的线程号转换为16进制 转换后的结果分别为7665由于导出的线程快照中线程的nid是16进制的而16进制以0x开头所以对应的16进制的线程号nid为0x7665 采用jstack命令导出线程快照
通过使用dk自带命令jstack获取该java进程的线程快照并输入到文件中 命令为Java进程的id号来获取线程快照结果并输入到指定文件。 根据线程号定位具体代码
在jstack_result.txt 文件中根据线程好nid搜索对应的线程描述 根据搜索结果判断应该是ImageConverter.run()方法中的代码出现问题当然这里也可以直接采用 来定位具体代码 分析代码解决问题 重启项目后测试发现项目运行稳定对应项目进程的CPU消耗占比不到10%。 随着云计算和微服务的普及系统复杂度日益增加CPU飙升的情况并不少见。许多企业缺乏完善的性能监控和溯源机制导致问题处理效率低下。强化监控体系、提升性能优化能力已成为技术团队的刚需。 CPU 飙升不是无解的难题而是系统给出的一个信号告诉你某些地方需要改进。通过监控、定位、溯源、优化你不仅能解决当前的问题还能为系统未来的稳定性打下基础。 “CPU飙升时别慌它是问题的表象解决它你才是真正的幕后英雄。”