做地推的网站,用wordpress制作网页的思路,菜单设计制作模板免费,wordpress教育模版问题排查的思路与方向
问题排查思路
分析问题#xff1a;根据理论知识经验分析问题#xff0c;判断问题可能出现的位置或可能引起问题的原因#xff0c;将目标缩小到一定范围#xff1b;排查问题#xff1a;基于上一步的结果#xff0c;从引发问题的“可疑性”角度出发…问题排查的思路与方向
问题排查思路
分析问题根据理论知识经验分析问题判断问题可能出现的位置或可能引起问题的原因将目标缩小到一定范围排查问题基于上一步的结果从引发问题的“可疑性”角度出发从高到低依次进行排查进一步排除一些选项将目标范围进一步缩小定位问题通过相关的监控数据的辅助以更“细粒度”的手段将引发问题的原因定位到精准位置解决问题判断到问题出现的具体位置以及引发的原因后采取相关措施对问题加以解决尝试最优解非必须将原有的问题解决后在能力范围内且环境允许的情况下应该适当考虑问题的最优解可以从性能、拓展性、并发等角度出发
问题排查方向
应用程序本身导致的问题
程序内部频繁触发GC造成系统出现长时间停顿导致客户端堆积大量请求。JVM参数配置不合理导致线上运行失控如堆内存、各内存区域太小等。Java程序代码存在缺陷导致线上运行出现Bug如死锁/内存泄漏、溢出等。程序内部资源使用不合理导致出现问题如线程/DB连接/网络连接/堆外内存等。
上下游内部系统导致的问题
上游服务出现并发情况导致当前程序请求量急剧增加从而引发问题拖垮系统。下游服务出现问题导致当前程序堆积大量请求拖垮系统如Redis宕机/DB阻塞等。
程序所部署的机器本身导致的问题
服务器机房网络出现问题导致网络出现阻塞、当前程序假死等故障。服务器中因其他程序原因、硬件问题、环境因素如断电等原因导致系统不可用。服务器因遭到入侵导致Java程序受到影响如木马病毒/矿机、劫持脚本等。
第三方的RPC远程调用导致的问题
作为被调用者提供给第三方调用第三方流量突增导致当前程序负载过重出现问题。作为调用者调用第三方但因第三方出现问题引发雪崩问题而造成当前程序崩溃。
数据库问题可能发生方面
SQL执行报错
业务代码bug编写的SQL语句报错
一般会抛出异常信息如Error updating database. Cause: java.sql.SQLException: Field category_name doesnt have a default value可根据异常信息百度解决
慢SQL
偶发的SQL执行缓慢的情况 慢查询日志 查看慢查询日志show variables like slow_query_log_file; 行慢查询SQL的用户root登录IP为localhost[127.0.0.1]。慢查询执行的具体耗时为0.014960s锁等待时间为0s。本次SQL执行后的结果集为4行数据累计扫描6行数据。本次慢查询发生在db_zhuzi这个库中发生时间为16674669322022-11-03 17:15:32。最后一行为具体的慢查询SQL语句。 排查SQL执行缓慢的原因 根据慢查询日志中的信息得到具体慢SQL信息并根据Look_time耗时判断是不是由于并发事物导致的长时间阻塞如果不是则使用explain执行分析工具判断索引情况如果在慢查询日志中存在大量由于并发事物导致的慢查询则可以通过查看Mysql的锁状态来判断当前Mysql节点的承载并发压力是否过高
机器故障
部署MySQL的及其故障如磁盘、内存、CPU100%、MySQL自身故障等
客户端连接异常
数据库的连接数超出了最大连接数此时再出现新连接时会出现异常 解决办法排查数据库和客户端连接池的配置是否合理适当调整参数 客户端数据库连接池与Mysql版本不匹配或超时时间过小可能导致连接中断 解决办法排查数据库和客户端连接池的配置是否合理适当调整参数 Mysql、JAVA程序所部署的机器不在同一网段导致两者之间可能存在网络通信故障 排查方向如下 检测防火墙与安全组的端口是否开放或与外网机器是否做了端口映射。检查部署MySQL的服务器白名单以及登录的用户IP限制可能是IP不在白名单范围内。如果整个系统各节点部署的网段不同检查各网段之间交换机的连接超时时间是多少。检查不同网段之间的网络带宽大小以及具体的带宽使用情况有时因带宽占满也会出现问题。如果用了MyCat、MySQL-Proxy这类代理中间件记得检查中间件的白名单、超时时间配置。 机器资源不足如CPU、硬盘占用过高导致MySQL没有资源分配给新连接 在一切正常的情况下有时候出现连接不上MySQL的情况时可以去查看部署Mysql服务的机器的硬件使用情况若出现异常则说明是机器问题
死锁频发
MySQL会默认开启死锁检测算法当运行期间出现死锁问题时会主动介入并解除死锁具体可参考Mysql锁机制中的死锁介绍但其指标不治本死锁现象是由于业务代码不合理造成的极大可能反复出现 定位死锁问题可通过SHOW ENGINE INNODB STATUS\G;查看InnoDB的运行状态日志其中包含InnoDB运行期间所有的状态日志其中死锁日志在LATEST DETECTED DEADLOCK这块区域 信息中包含了死锁发生的时间*** (n) TRANSACTION产生死锁的事物和具体sql*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 指明了发生死锁冲突的地点位于order库中order_salesorder表的uk_tenant_store_order索引上第二个事务正在等待获取插入意向锁但是由于第一个事务持有了表级的共享锁并且也在等待获取插入意向锁 *** WE ROLL BACK TRANSACTION (2)解决方案是回滚了第二个事物
CPU100% 排查思路 找到CPU过高的服务器定位具体进程top定位进程中的具体线程top -Hp [PID]找到线程正在执行的代码逻辑从代码层面着手优化 具体步骤 通过top命令查看占用CPU最高的进程这里假设mysql占用率最高 top - 16:02:11 up 623 days, 23:46, 1 user, load average: 0.24, 0.22, 0.19
Tasks: 139 total, 1 running, 138 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.5 us, 0.1 sy, 0.0 ni, 98.2 id, 0.0 wa, 0.2 hi, 0.0 si, 0.0 st
MiB Mem : 15469.9 total, 152.1 free, 6837.6 used, 8480.2 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 8314.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND
3093986 admin 20 0 6576080 1.4g 18008 S 5.3 9.6 2:50.12 java
3057999 admin 20 0 6335928 1.2g 16864 S 0.7 8.1 4:42.53 java 13699 root 20 0 1722052 283200 5076 S 0.3 1.8 3126:16 /usr/local/clou 106781 admin 20 0 5079784 1.0g 2612 S 0.3 6.9 3184:01 java 765635 mysql 20 0 2653408 1.4g 10140 S 0.3 9.0 54062:02 mysqld
2836690 admin 20 0 273680 9612 2008 S 0.3 0.1 356:23.41 redis-server
3054745 admin 20 0 4696200 815644 16600 S 0.3 5.1 3:24.90 java
3499020 root 10 -10 89768 13020 9316 S 0.3 0.1 66:17.11 AliYunDun
3499031 root 10 -10 133384 24060 12164 S 0.3 0.2 126:29.57 AliYunDunMonito 1 root 20 0 111468 6140 3204 S 0.0 0.0 8:14.12 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:13.04 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 之后可以通过top -Hp [PID]命令查询进程中CPU占用率最高的线程 top - 16:09:44 up 623 days, 23:54, 2 users, load average: 0.00, 0.05, 0.11
Threads: 53 total, 0 running, 53 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.1 us, 0.3 sy, 0.0 ni, 94.2 id, 0.0 wa, 0.3 hi, 0.1 si, 0.0 st
MiB Mem : 15469.9 total, 179.2 free, 6847.7 used, 8443.0 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 8303.9 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND
3096811 mysql 20 0 2653408 1.4g 10140 S 0.7 9.0 0:00.02 mysqld 765637 mysql 20 0 2653408 1.4g 10140 S 0.3 9.0 2:54.55 mysqld
3087933 mysql 20 0 2653408 1.4g 10140 S 0.3 9.0 0:01.49 mysqld
3096213 mysql 20 0 2653408 1.4g 10140 S 0.3 9.0 0:00.03 mysqld 765635 mysql 20 0 2653408 1.4g 10140 S 0.0 9.0 0:04.38 mysqld 765636 mysql 20 0 2653408 1.4g 10140 S 0.0 9.0 0:00.00 mysqld 765638 mysql 20 0 2653408 1.4g 10140 S 0.0 9.0 3:08.71 mysqld 查看OS线程ID与MySQL线程ID关系MySQL5.7及以上通过查询performance_schema库中的threads表SELECT * FROM threads where THREAD_OS_ID 3096811; THREAD_IDMysql内部线程IdPROCESSLIST_USER数据库连接的客户端用户PROCESSLIST_HOST数据库连接的客户端地址PROCESSLIST_DB访问的库PROCESSLIST_INFO当前线程正在执行的sqlTHREAD_OS_ID操作系统的线程ID 得到当前线程正在执行的sql则可以从代码层面着手优化
磁盘100%
可能导致磁盘IO占用过高的原因 突然大批量变更库中数据需要执行大量写入操作如主从数据同步时就会出现这个问题。MySQL处理的整体并发过高磁盘I/O频率跟不上比如是机械硬盘材质读写速率过慢。内存中的BufferPool缓冲池过小大量读写操作需要落入磁盘处理导致磁盘利用率过高。频繁创建和销毁临时表导致内存无法存储临时表数据因而转到磁盘存储导致磁盘飙升。执行某些SQL时从磁盘加载海量数据如超2张表的联查并每张表数据较大最终导致IO打满。日志刷盘频率过高其实这条是i、ii的附带情况毕竟日志的刷盘频率跟整体并发直接挂钩。 解决办法 **提升硬件**若磁盘不是固态硬盘的可将磁盘升级成固态硬盘引入中间件如引入Redis减小读压力引入MQ进行流量削峰调大BufferPool缓冲池大小SQl语句上优化撰写SQL语句时尽量减少多张大表联查不要频繁的使用和销毁临时表
Performance_Schema库监控全局资源
MySQL5.6引入主要记录数据库整体的监控信息比如事务监控信息、最近执行的SQL信息、最近连接的客户端信息、数据库各空间的使用信息等基于这个库可以在线上构建出一个完善的MySQL监控系统 Statements/execution stagesMySQL统计的一些消耗资源较高的SQL语句。Table and Index I/OMySQL统计的那些表和索引会导致I/O负载过高。Table LocksMySQL统计的表中数据的锁资源竞争信息。Users/Hosts/Accounts消耗资源最多的客户端、IP机器、用户。Network I/OMySQL统计的一些网络相关的资源情况。
