负载过高问题快速排查思路教程二

已于 2022-11-03 11:48:24 修改
阅读量219 收藏
点赞数
文章标签： 数据库 sql java
于 2022-11-03 11:44:57 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/feidododekefu/article/details/127667293
版权

由于之前查询发现有部分 left JOIN 的查询，故查询了 “异常容器” 的 left JOIN 的查询，，随后将读取条数为 0 的排除掉。

select * from (select LEFT(query, 100) as sql, count() as quneryNum, sum(query_duration_ms) as totalTime, totalTime/queryNum as avgTime from system.query_log ql where sql like '%异常容器%' and read_rows != 0 and event_time > toDateTime('2022-09-23 12:00:00') and event_time < toDateTime('2022-09-23 17:00:00') and query not like '%INSERT INTO%' group by sql order by queryNum desc)

根据小时 聚合 每个小时 / 分钟段查询次数耗时

--按照每小时聚合
select toHour(event_time) as t, count() as queryNum, sum(query_duration_ms) as totalTime, totalTime/queryNum as avgTime from system.query_log ql where event_time > toDateTime('2022-09-23 08:00:00') and event_time < toDateTime('2022-09-23 17:00:00') and query not like '%INSERT INTO%' and query like '%异常容器%' and read_rows != 0 group by t limit 50
--按照每分钟聚合
select toMinute(event_time) as t, count() as queryNum, sum(query_duration_ms) as totalTime, totalTime/queryNum as avgTime from system.query_log ql where event_time > toDateTime('2022-09-23 12:00:00') and event_time < toDateTime('2022-09-23 13:00:00') and query not like '%INSERT INTO%' and query like '%异常容器%' and read_rows != 0 group by t limit 50

查询结果如下：10 点开始有，12 点查询响应时间翻了 10 倍。

从 32s 开始，响应时间变为 24s 多，后面的时间也逐渐变长。

查询 left JOIN 的查询个数。

select * from (select LEFT(query, 100) as sql, count() as quneryNum, sum(query_duration_ms) as totalTime, totalTime/queryNum as avgTime from system.query_log ql where query like '% JOIN%' and read_rows != 0 and event_time > toDateTime('2022-09-23 12:00:00') and event_time < toDateTime('2022-09-23 21:00:00') and query not like '%INSERT INTO%' group by sql order by queryNum desc)

发现有问题的表时，查询该表结构。

show create table "shard_2"."cw_db_zabbix_metric_data01_replica"

经查询发现该表创建的比较差，order by 仅有一个 UUID。且该表 JOIN 的 SQL 也比较多，每次查询的读取的条数也特别大。

停掉 SQL ，观察结果

通过观察，发现有不少类似的 JOIN 的 SQL。当停掉一个异常容器指标的 SQL 时会发现 load 值有些许变化，偶尔会降到 700 多。由于指标管理都是通过 gatewayAPI 调用，停掉 SQL 最快的方法便是直接将 gatewayAPI 停掉，这样只会影响指标 SQL 调，不会影响其他功能使用。将 gatewayAPI 停掉后就不会出现指标调用 SQL 也全部停掉，此时发现 load 值已降低

总结

遇到此类问题可先查看日志，首先在（Clickhouse 日志 Zookeeper 日志）日志中看能否找到有用的信息，例如直接报错信息等，如果在日志中找不到太多有用的信息的话，可以从下面入手。

一般遇到 load 值比较高的情况时，基本上都是发生在查询上面。当遇到这种问题时可先查询带有 JOIN 的 SQL 语句是不是很多。随后通过 query_log 表中的一些字段去查询重要信息，通过对字段使用一些函数来获取有用的信息，如获取查询的 SQL，SQL 执行次数、执行时间等。

本次排查过程主要使用 query_log 表，下面为重要字段：

event_time — 查询开始时间.

query_duration_ms — 查询消耗的时间（毫秒）.

read_rows— 从参与了查询的所有表和表函数读取的总行数.

query — 查询语句.

Clickhouse query_log 表中所有字段

  • type (Enum8) — 执行查询时的事件类型。值:

    • 'QueryStart' = 1 — 查询成功启动.
    • 'QueryFinish' = 2 — 查询成功完成.
    • 'ExceptionBeforeStart' = 3 — 查询执行前有异常.
    • 'ExceptionWhileProcessing' = 4 — 查询执行期间有异常.

  • event_date (Date) — 查询开始日期.

  • event_time (DateTime) — 查询开始时间.

  • event_time_microseconds (DateTime64) — 查询开始时间（毫秒精度）.

  • query_start_time (DateTime) — 查询执行的开始时间.

  • query_start_time_microseconds (DateTime64) — 查询执行的开始时间（毫秒精度）.

  • query_duration_ms (UInt64) — 查询消耗的时间（毫秒）.

  • read_rows (UInt64) — 从参与了查询的所有表和表函数读取的总行数。包括：普通的子查询，IN 和 **JOIN** 的子查询。对于分布式查询 read_rows 包括在所有副本上读取的行总数。 每个副本发送它的 read_rows 值，并且查询的服务器 - 发起方汇总所有接收到的和本地的值。 缓存卷不会影响此值。

  • read_bytes (UInt64) — 从参与了查询的所有表和表函数读取的总字节数。包括：普通的子查询，IN 和 **JOIN** 的子查询。对于分布式查询 read_bytes 包括在所有副本上读取的字节总数。 每个副本发送它的 read_bytes 值，并且查询的服务器 - 发起方汇总所有接收到的和本地的值。 缓存卷不会影响此值。

  • written_rows (UInt64) — 对于 INSERT 查询，为写入的行数。 对于其他查询，值为 0。

  • written_bytes (UInt64) — 对于 INSERT 查询时，为写入的字节数。 对于其他查询，值为 0。

  • result_rows (UInt64) — SELECT 查询结果的行数，或 **INSERT** 的行数。

  • result_bytes (UInt64) — 存储查询结果的 RAM 量.

  • memory_usage (UInt64) — 查询使用的内存.

  • query (String) — 查询语句.

  • exception (String) — 异常信息.

  • exception_code (Int32) — 异常码.

  • stack_trace (String) — Stack Trace. 如果查询成功完成，则为空字符串。

  • is_initial_query (UInt8) — 查询类型。可能的值:

    • 1 — 客户端发起的查询.
    • 0 — 由另一个查询发起的，作为分布式查询的一部分.

  • user (String) — 发起查询的用户.

  • query_id (String) — 查询 ID.

  • address (IPv6) — 发起查询的客户端 IP 地址.

  • port (UInt16) — 发起查询的客户端端口.

  • initial_user (String) — 初始查询的用户名（用于分布式查询执行）.

  • initial_query_id (String) — 运行初始查询的 ID（用于分布式查询执行）.

  • initial_address (IPv6) — 运行父查询的 IP 地址.

  • initial_port (UInt16) — 发起父查询的客户端端口.

  • interface (UInt8) — 发起查询的接口。可能的值:

    • 1 — TCP.
    • 2 — HTTP.

  • os_user (String) — 运行 clickhouse-client 的操作系统用户名.

  • client_hostname (String) — 运行 clickhouse-client 或其他 TCP 客户端的机器的主机名。

  • client_name (String) — clickhouse-client 或其他 TCP 客户端的名称。

  • client_revision (UInt32) — clickhouse-client 或其他 TCP 客户端的 Revision。

  • client_version_major (UInt32) — clickhouse-client 或其他 TCP 客户端的 Major version。

  • client_version_minor (UInt32) — clickhouse-client 或其他 TCP 客户端的 Minor version。

  • client_version_patch (UInt32) — clickhouse-client 或其他 TCP 客户端的 Patch component。

  • http_method (UInt8) — 发起查询的 HTTP 方法。可能值:

    • 0 — TCP 接口的查询.
    • 1 — GET
    • 2 — POST

  • http_user_agent (String) — The UserAgent The UserAgent header passed in the HTTP request。

  • quota_key (String) — 在 quotas 配置里设置的 “quota key” （见 keyed).

  • revision (UInt32) — ClickHouse revision.

  • ProfileEvents (Map(String, UInt64))) — Counters that measure different metrics. The description of them could be found in the table 系统。活动

  • Settings (Map(String, String)) — Names of settings that were changed when the client ran the query. To enable logging changes to settings, set the log_query_settings 参数为 1。

  • thread_ids (Array(UInt64)) — 参与查询的线程数.

  • Settings.Names (Array（String)) — 客户端运行查询时更改的设置的名称。 要启用对设置的日志记录更改，请将 log_query_settings 参数设置为 1。

  • Settings.Values (Array（String)) — Settings.Names 列中列出的设置的值

feidodo网络
关注
JVM 问题排查分析下篇（案例实战）
KimmKing的技术博客
09-22 500
GC 问题排查实战案例 这一部分，我们来看一个实际的案例。 假设我们有一个提供高并发请求的服务，系统使用 Spring Boot 框架，指标采集使用 MicroMeter，监控数据上报给 Datadog 服务。 当然，Micrometer支 持将数据上报给各种监控系统，例如：AppOptics、Atlas、Datadog、Dynatrace、Elastic、Ganglia、Graphite、Hum...
服务器添加二级域名网站教程,服务器添加二级域名
weixin_29594291的博客
08-10 1280
服务器添加二级域名 内容精选换一换本节介绍网站使用华为云CDN做内容分发加速，且网站域名解析至中国大陆节点服务器的网站备案场景。如图1所示：① 企业A在华为云CDN添加加速域名(www.picture.example.com)，为网站中的图片进行加速处理。② 用户通过网站域名(www.example.com)访问企业A的网站。③ CDN判断响应速度最快的节点是CDN节点1如果密码丢失、或创建时未设...
如何快速排查机器负载过高的问题
qq_41342577的博客
03-22 3529
问题 机器突然莫名其妙的很慢，负载很高，这时候需要如何排查问题出现在哪 步骤 1、首先使用 top ，查看整体的机器情况 2、从上一步可以看出cpu占用高，用户态和内核态都很高，负载也高，初步判断是否有脚本在跑，吃cpu资源，但是图中的在跑着的程序，%cpu这一项都不是很高，所以有点蹊跷 然后查看机器的读写情况，看看是不是由很多读写操作 3、使用sar -d 1 10 查看磁盘读写...
负载过高问题快速排查思路教程一
zcypaicom的博客
11-03 556
负载过高问题快速排查思路教程
Linux服务器CPU使用率或CPU负载较高问题的排查及解决方案
最新发布
陈万洲的专栏
08-02 2353
本文主要介绍当Linux系统ECS实例CPU使用率或CPU负载较高时，如何排查分析及常见案例说明。
关于服务器负载过高排查
qq_42727102的博客
06-23 1425
背景：在公司沙箱环境下，top~，发现一个命令占用 cpu 接近 100% 排查： top：得到哪个命令占 cpu 高 ps -ef | grep “xxx” 筛选出这个命令，得到其进程号 top -p 定位到此进程的线程 pstack 进程号 | grep 线程号 定位问题所在 最后：排查出来是后台代码问题~~mq无数据，重复取 ...
oracle 数据库负载高分析
胡威的技术博客
06-12 7385
数据库负载高故障排查处理： 问题描述：查看数据库负载高达20左右，大量进程占用cpu较高 问题分析：多个单进程占用cpu较高，一般为索引失效，sql复杂查询数据量大或存在锁行，锁表等 ，分析数据库dwr报告： 发现大量的行级锁，已经锁等待占用cpu较高，查询数据库锁：select t2.username,t2.sid,t2.serial#,t2.logon_time,event from
MySQL高负载排查方法最佳实践（15/16）
pengpengsays
04-11 1819
top 是一款 Linux 系统下经常被用来做性能分析的工具，它可以实时动态的展示进程，线程的资源使用情况，在 top 工具展示监控指标里，运维人员最关心的是 cpu 和 mem 的使用情况。当服务器有特别多的 CPU 核，有时候看 CPU 汇总信息，发现 CPU 的 idle 很高，但是上面跑的应用程序却很慢，这个时候就需要看看每个核的资源试用情况了。可以很清楚看到是 10850 线程消耗了 CPU 资源，剩下的就根据操作系统的里线程 ID，去 MySQL 数据库里排查，此线程正在执行的操作。
JAVA应用生产问题排查步骤
Socesoft888的博客
11-24 668
JAVA应用生产问题排查步骤 学会这篇文章里面的命令并熟练使用，出去面试就可以说自己有5年工作经验并且精通JVM了。本篇文章中介绍的命令绝对是JAVA程序员平时工作中经常使用的并且必须会的命令，如果你不会你就是没有工作经验的人。如果你不会，那么在别人眼中你肯定就是菜鸟一个，所以本篇文章中的命令，你必须学会并且熟练使用。 注意:本篇文章内容基于JDK版本: java version “1.6.0_113” Java™ SE Runtime Environment (build 1.6.0_113-b0
7000+字，30+张图！Java线上故障排查思路全部总结在这里了
Java大将军的博客
10-13 339
线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的，基本上出问题就是 df、free、top 三连，然后依次 jstack、jmap 伺候，具体问题具体分析即可。 CPU 一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)...
Linux高负载排查最佳实践
pengpengsays
03-14 1919
在Linux系统中，经常会因为负载过高导致各种性能问题。那么如何进行排查，其实是有迹可循，而且模式固定。本次就来分享一下，CPU占用过高、磁盘IO占用过高的排查方法。
服务器负载分析及问题排查
醒 木
11-08 2655
序言 平常的工作中，在衡量服务器的性能时，经常会涉及到几个指标，load、cpu、mem、qps、rt等。每个指标都有其独特的意义，很多时候在线上出现问题时，往往会伴随着某些指标的异常。大部分情况下，在问题发生之前，某些指标就会提前有异常显示。 对于这些指标的理解和查看、异常解决等，是程序员们重要的必备技能。本文，主要来介绍一下一个比较重要的指标——机器负载（Load），主要涉及负载的定义、查看负载方式、负载飙高排查思路等。 什么是负载 In UNIX computing, the system load
【Oracle生产运维】数据库服务器高负载排查处理
qq_34595089的博客
06-11 1170
在Oracle数据库运维工作中，经常会遇到Oracle数据库服务器平均负载（load average）突然异常升高，如果放任不管，严重的情况下会出现数据库宕机、服务器重启等重大故障。因此，当发现数据库服务器平均负载异常高的时候，必须予以重视，并立即开展处理工作。很多刚工作或者是没这方面处理经验的同学可能遇到这种情况就会开始慌张，不知从何下手，无法快速定位出引起负载异常的原因。下面介绍我在工作中常用的排查思路供大家参考。截图的结果皆在实验环境中截取，与实际生产环境有较大出入，只作为操作演示。
线上服务 CPU 负载过高问题排查
Senn · 森
10-12 1419
CPU 负载过高，在开发过程中每个人都或多或少遇到，在系统未部署正式环境时，看日志或打断点总会有办法解决掉。但总有些BUG的出现会给你意外惊喜，即使已在测试环境做了尽可能多的测试，依旧无法避免，其中有一种就是服务器CUP突然异常负载过高。本文重点叙述在线上环境排查该问题思路。 定位问题服务 CPU 负载过高，给用户的直观感受就是服务卡顿，响应时间边长，甚至严重一点整个服务网页崩溃，无法工作。特别是我们目前基于容器的部署并没有设置容器最大可用CPU数，整个服务器也没有部署系统资源监控时，这种问题一旦发生，就会
Top load average 高如何排查
喝醉酒的小白
05-05 4705
lscpu是一个Linux/Unix命令，用于显示系统的CPU架构信息，包括CPU型号、CPU架构、CPU核心数量、CPU频率、CPU缓存信息等等。输出结果中包括进程的所有信息，包括父进程ID、会话ID、进程组ID、用户ID、CPU占用率、内存占用率、启动时间、命令等信息。该命令会输出系统的CPU架构信息，包括CPU型号、CPU架构、CPU核心数量、CPU频率、CPU缓存信息等等。两者都是用于列出当前运行的进程信息的命令，但是在不同的操作系统中有不同的用法和输出格式。
线上负载过高排查(top/vmstat/ifstat/free/df)
wuhuagu_wuhuaguo的博客
03-06 1535
总结的Linux+JDK命令操作相关的笔记。
网站导致服务器负载高,网站访问慢，服务器负载高-系列查找问题方法
weixin_42497772的博客
08-12 820
如果以后出现报警各网站无法ping通，或者服务器负载过高，可通过以下几条途径查找原因：1,查看访问日志，查看是否有访问异常，如有，过滤ＩＰ，进行ＩＰ封装cat access.log | awk ‘{print $1}’ | sort | uniq –c | sort –n >/tmp/ip.txtnetstat -ntu | awk ‘{print $5}‘ | cut -d: -f1 | ...
mysql负载过高的排查思路
09-16
排查MySQL负载过高的思路有以下几点： 1. 首先，通过top命令查看服务器负载，确定是CPU负载还是IO负载。 2. 使用MySQL命令查看当前连接数和执行的SQL语句，以确定是否有某些变态SQL语句引起负载过高。 3. 检查MySQL...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值