发现服务器的cpu使用率特别高 排查思路: -使用top或者mpstat查看cpu的使用情况# mpstat -P ALL 2 1Linux 2.6.32-358.el6.x86_64 (linux—host) 01/05/2016 _x86_64_ (24 CPU) 04:41:13 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle04:41:15 PM all 0.56 0.00 0.25 0.00 0.00 0.04…

--调优SQL --sqlreview ->logshipping -> ag辅助副本 --查看正确的执行计划 打开实际的执行计划set statistics io on --查看错误的执行计划 打开实际的执行计划set statistics io on --对比 正确和错误 执行计划的差别紧盯最大返回记录数处,找最粗的,不要看cost百分比 没用!找出问题点,是否走错了索引,或未走做引 --对于缺失索引的 创建索引 use SiccDBsp_spaceused CDRSub_Current_…

1. 获取需要的binlog 日志: [root@zjzc01 binlog]# mysqlbinlog --start-datetime='2016-08-01 00:00:00' --stop-datetime='2016-08-11 12:00:00' mysql-bin.00006* >a.txt 2.获取对应行的记录 匹配 update ProductAccess [root@zjzc01 binlog]# cat get_num.pl open (A,"<",&…

block正常满 (磁盘实际不足)inode 满 大量的小文件block 满 文件没有被彻底删除(硬链接数0 进程调用数不为0) 解放方法: 1 查看df -h 磁盘使用量根据占用量大小逐步逐步排查 2 使用du -sh 查看大磁盘所有文件大小使用|grep G 过滤大文件数据 3 根据查找到的文件询问删除解决磁盘空间没满但是无法写入文件(inode用完了) 注意: # df -sh /* | grep G 查找到具体的文件或目录中,对此目录进行删除等操作,不能盲目的删除,要确定无用了,才能进行…

先 django 定好sql框架 再 sqlalchemy 根据框架写...…

最近在做一个分布式调用链跟踪系统, 在两个地方采用了flume (我使用的flume版本是1.5.0-cdh5.4.4),一个是宿主系统 ,用flume agent进行日志搜集. 一个是从kafka拉日志分析后写入hbase. 后面这个flume(从kafka拉日志分析后写入flume)用了3台  , 系统上线以后 ,线上抛了一个这样的异常: Caused by: org.apache.flume.ChannelException: Put queue for MemoryTransaction…

查询最慢的SQL select * from (select sa.SQL_TEXT, sa.SQL_FULLTEXT, sa.EXECUTIONS "执行次数", round(sa.ELAPSED_TIME / 1000000, 2) "总执行时间", round(sa.ELAPSED_TIME / 1000000 / sa.EXECUTIONS, 2) "平均执行时间", sa.COMMAND_TYPE, sa.PARSING_USER_ID…

前言 平时在工作中每天都会做巡检,将前一天所有超过500ms的慢SQL排查出来 查找原因,是否能进行优化.慢慢中,在形成了一套思路方法论. 我个人认为对于排查慢SQL还是有一定的帮助 (一).是否是SQL语句本身导致的慢SQL SQL语句是否走了索引.此条可以用explain命令查看 SQL语句是不是select的数据量非常非常的大.比如是一个长长的json串,在网络传输的过程中会非常的耗时 (二).SQL慢查询是否是其他外在因素导致的 如果SQL语句本身没有问题,大概率就是偶尔出现,其他因素影…

You need to enable JavaScript to run this app.   原文内容来自于LZ(楼主)的印象笔记,如出现排版异常或图片丢失等情况,可查看当前链接:https://app.yinxiang.com/fx/bf7839b3-5f7b-4212-9f7d-5f5577e952ea MySql CPU彪高到百分之1000的排查思路   查看当前MySql的CPU已经在百分之 1019   下述为当前MySql的所以子线程的CPU使用状况,可以看到当前已经有11个线程…

解Bug之路-记一次中间件导致的慢SQL排查过程 前言 最近发现线上出现一个奇葩的问题,这问题让笔者定位了好长时间,期间排查问题的过程还是挺有意思的,正好博客也好久不更新了,就以此为素材写出了本篇文章. Bug现场 我们的分库分表中间件在经过一年的沉淀之后,已经到了比较稳定的阶段.而且经过线上压测的检验,单台每秒能够执行1.7W条sql.但线上情况还是有出乎我们意料的情况.有一个业务线反映,每天有几条sql有长达十几秒的超时.而且sql是主键更新或主键查询,更奇怪的是出现超时的是不同的sql,似…