如何给网站做二维码安装建设手机银行移动门户网站

如何给网站做二维码,安装建设手机银行移动门户网站,3d设计公司,凡客平台场景:1#xff1a;MySQL进程飙升900% 大家在使用MySQL过程#xff0c;想必都有遇到过CPU突然过高#xff0c;或者达到200%以上的情况。 数据库执行查询或数据修改操作时#xff0c;系统需要消耗大量的CPU资源维护从存储系统、内存数据中的一致性。 并发量大并且大量SQL性…场景:1MySQL进程飙升900%大家在使用MySQL过程想必都有遇到过CPU突然过高或者达到200%以上的情况。数据库执行查询或数据修改操作时系统需要消耗大量的CPU资源维护从存储系统、内存数据中的一致性。并发量大并且大量SQL性能低的情况下比如字段是没有建立索引则会导致快速CPU飙升如果还开启了慢日志记录会导致性能更加恶化。生产上有MYSQL 飙升900% 的恶劣情况。场景2Java进程飙升900%一般来说Java 进程不做大量 CPU 运算正常情况下CPU 应该在 100~200% 之间但是一旦高并发场景要么走到了死循环要么就是在做大量的 GC, 容易出现这种 CPU 飙升的情况CPU飙升900%是完全有可能的。其他场景其他的类似进程飙升900%的场景比如Redis、Nginx等等。陈某提示大家介绍场景的时候就说自己主要涉及了两个场景 Java进程飙升900%、MySQL进程飙升900%两种场景其实这两个场景就足够讲半天了 其他的使用规避技巧规避一下就行。场景一MySQL进程CPU飙升到900%怎么处理定位过程使用top 命令观察确定是mysqld导致还是其他原因。如果是mysqld导致的show processlist查看session情况确定是不是有消耗资源的sql在运行。找出消耗高的 sql看看执行计划是否准确 index 是否缺失或者实在是数据量太大造成。处理过程kill 掉这些线程(同时观察 cpu 使用率是否下降) 一般来说肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降)等进行相应的调整(比如说加索引、改 sql、改内存参数)之后再重新跑这些 SQL。进行相应的调整(比如说加索引、改 sql、改内存参数)index 是否缺失如果是则 建立索引。也有可能是每个 sql 消耗资源并不多但是突然之间有大量的 session 连进来导致 cpu 飙升这种情况就需要跟应用一起来分析为何连接数会激增再做出相应的调整比如说限制连接数等关注公z号码猿技术专栏回复关键词1111 获取阿里内部Java性能调优手册优化的过程往往不是一步完成的而是一步一步执行一项优化措辞再观察再优化。场景1的真实案例MySQL数据库优化的真实案例陈某提示以下案例来自互联网。大家参考一下准备一个自己的案例。本问题亲身经历过。之前开发同事编写的SQL语句就导致过线上CPU过高MySQL的CPU使用率达到900%通过优化最后降低到70%~80%。下面说说个人在这个过程中的排查思路。首先我们要对问题定位而不是盲目的开启什么 慢日志在并发量大并且大量SQL性能低的情况下开启慢日志无意是将MySQL推向崩溃的边缘。当时遇到这个情况分析了当前的数据量、索引情况、缓存使用情况。目测数据量不大也就几百万条而已。接下来就去定位索引、缓存问题。经过询问发现很多查询都是走MySQL没有用到缓存。既然没有用到缓存则是大量请求全部查询MySQL导致。通过下面的命令查看:show processlist;发现类似很多相同的SQL语句一直处于query状态中。select id form user where user_code xxxxx;初步分析可能是 user_code 字段没有索引导致。接着查询user表的索引情况show index form user;发现这个字段是没有建立索引。增加索引之后该条SQL查询能够正常执行。3、没隔一会又发生大量的请求超时问题。接着进行分析发现是开启了 慢日志查询。大量的SQL查询语句超过慢日志设置的阀值于是将慢日志关闭之后速度瞬间提升。CPU的使用率基本保持在300%左右。但还不是理想状态。4、紧接着将部分实时查询数据的SQL语句都通过缓存(redis)读写实现。观察一段时间后基本维持在了70%~80%。总结其实本次事故的解决很简单就是添加索引与缓存结合使用。不推荐在这种CPU使用过高的情况下进行慢日志的开启。因为大量的请求如果真是慢日志问题会发生日志磁盘写入性能贼低。直接通过MySQL show processlist命令查看基本能清晰的定位出部分查询问题严重的SQL语句在针对该SQL语句进行分析。一般可能就是索引、锁、查询大量字段、大表等问题导致。再则一定要使用缓存系统降低对MySQL的查询频次。对于内存调优也是一种解决方案。场景2展开Java进程CPU飙升到900%怎么处理定位过程CPU飙升问题定位的一般步骤是首先通过top指令查看当前占用CPU较高的进程PID查看当前进程消耗资源的线程PIDtop -Hp PID通过print命令将线程PID转为16进制根据该16进制值去打印的堆栈日志内查询查看该线程所驻留的方法位置。通过jstack命令查看栈信息定位到线程对应的具体代码。分析代码解决问题。处理过程如果是空循环或者空自旋。处理方式可以使用Thread.sleep或者加锁让线程适当的阻塞。在循环的代码逻辑中创建大量的新对象导致频繁GC。比如从mysql查出了大量的数据比如100W以上等等。处理方式可以减少对象的创建数量或者可以考虑使用 对象池。其他的一些造成CPU飙升的场景比如 selector空轮训导致CPU飙升 。处理方式参考Netty源码无效的事件查询到了一定的次数进行 selector 重建。Java的CPU 飙升700%优化的真实案例陈某提示以下案例来自互联网。大家参考一下准备一个自己的案例。最近负责的一个项目上线运行一段时间后发现对应的进程竟然占用了700%的CPU导致公司的物理服务器都不堪重负频繁宕机。那么,针对这类java进程CPU飙升的问题我们一般要怎么去定位解决呢、采用top命令定位进程登录服务器执行top命令查看CPU占用情况找到进程的pidtop很容易发现PID为29706的java进程的CPU飙升到700%多且一直降不下来很显然出现了问题。使用top -Hp命令定位线程使用 top -Hp命令为Java进程的id号查看该Java进程内所有线程的资源占用情况按shftp按照cpu占用进行排序按shiftm按照内存占用进行排序此处按照cpu排序top -Hp 23602很容易发现多个线程的CPU占用达到了90%多。我们挑选线程号为30309的线程继续分析。使用jstack命令定位代码1.线程号转换5为16进制printf “%x\n” 命令tid指线程的id号将以上10进制的线程号转换为16进制printf %x\n 30309转换后的结果分别为7665由于导出的线程快照中线程的nid是16进制的而16进制以0x开头所以对应的16进制的线程号nid为0x76652.采用jstack命令导出线程快照通过使用dk自带命令jstack获取该java进程的线程快照并输入到文件中jstack -l 进程ID ./jstack_result.txt命令为Java进程的id号来获取线程快照结果并输入到指定文件。jstack -l 29706 ./jstack_result.txt3.根据线程号定位具体代码在jstack_result.txt 文件中根据线程好nid搜索对应的线程描述cat jstack_result.txt |grep -A 100 7665根据搜索结果判断应该是ImageConverter.run()方法中的代码出现问题当然这里也可以直接采用jstack pid |grep -A 200 nid来定位具体代码$jstack 44529 |grep -A 200 ae24 System Clock #28 daemon prio5 os_prio0 tid0x00007efc19e8e800 nid0xae24 waiting on condition [0x00007efbe0d91000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at java.lang.Thread.sleep(Thread.java:340) at java.util.concurrentC.TimeUnit.sleep(TimeUnit.java:386) at com.*.order.Controller.OrderController.detail(OrderController.java:37) //业务代码阻塞点分析代码解决问题下面是ImageConverter.run()方法中的部分核心代码。逻辑说明/存储minicap的socket连接返回的数据 (改用消息队列存储读到的流数据) 设置阻塞队列长度防止出现内存溢出 //全局变量 private BlockingQueuebyte[] dataQueue new LinkedBlockingQueuebyte[](100000); //消费线程 Override public void run() { //long start System.currentTimeMillis(); while (isRunning) { //分析这里从LinkedBlockingQueue if (dataQueue.isEmpty()) { continue; } byte[] buffer device.getMinicap().dataQueue.poll(); int len buffer.length; }在while循环中不断读取堵塞队列dataQueue中的数据如果数据为空则执行continue进行下一次循环。如果不为空则通过poll()方法读取数据做相关逻辑处理。初看这段代码好像每什么问题但是如果dataQueue对象长期为空的话这里就会一直空循环导致CPU飙升。那么如果解决呢分析LinkedBlockingQueue阻塞队列的API发现//取出队列中的头部元素如果队列为空则调用此方法的线程被阻塞等待直到有元素能被取出如果等待过程被中断则抛出InterruptedException E take() throws InterruptedException; //取出队列中的头部元素如果队列为空返回null E poll();这两种取值的API显然take方法更时候这里的场景。代码修改为while (isRunning) { /* if (device.getMinicap().dataQueue.isEmpty()) { continue; }*/ byte[] buffer new byte[0]; try { buffer device.getMinicap().dataQueue.take(); } catch (InterruptedException e) { e.printStackTrace(); } …… }重启项目后测试发现项目运行稳定对应项目进程的CPU消耗占比不到10%。