应用卡顿排查

最新推荐文章于 2024-10-06 20:42:07 发布
最新推荐文章于 2024-10-06 20:42:07 发布
阅读量441 收藏 7
点赞数 5
分类专栏： java 文章标签： mysql spring linux spring boot
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010597819/article/details/140745983
版权

DB监控日志分析


=====================================
2024-07-17 08:17:14 0x70000ad1d000 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 26 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 157588 srv_active, 0 srv_shutdown, 414143 srv_idle
srv_master_thread log flush and writes: 0
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 54185811
OS WAIT ARRAY INFO: signal count 42852408
RW-shared spins 0, rounds 0, OS waits 0
RW-excl spins 0, rounds 0, OS waits 0
RW-sx spins 0, rounds 0, OS waits 0
Spin rounds per wait: 0.00 RW-shared, 0.00 RW-excl, 0.00 RW-sx
------------
TRANSACTIONS
------------
Trx id counter 24056146
Purge done for trx's n:o < 24056144 undo n:o < 0 state: running but idle
History list length 10
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421915039639648, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421915039638856, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421915039638064, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421915039637272, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421915039636480, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421915039635688, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421915039634896, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421915039634104, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421915039633312, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421915039631728, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421915039630936, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 24056144, ACTIVE 1 sec inserting
mysql tables in use 1, locked 1
470 lock struct(s), heap size 73848, 932 row lock(s), undo log entries 462
MySQL thread id 3633, OS thread handle 123145476378624, query id 56338839 localhost 127.0.0.1 root update
insert into ...
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (read thread)
I/O thread 4 state: waiting for i/o request (read thread)
I/O thread 5 state: waiting for i/o request (read thread)
I/O thread 6 state: waiting for i/o request (write thread)
I/O thread 7 state: waiting for i/o request (write thread)
I/O thread 8 state: waiting for i/o request (write thread)
I/O thread 9 state: waiting for i/o request (write thread)
Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,
 ibuf aio reads:, log i/o's:
Pending flushes (fsync) log: 1; buffer pool: 18446744073709550954
480660392 OS file reads, 748418099 OS file writes, 389306125 OS fsyncs
0 pending preads, 1 pending pwrites
3768.33 reads/s, 12420 avg bytes/read, 4624.80 writes/s, 2474.45 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 212, seg size 214, 18577 merges
merged operations:
 insert 571158, delete mark 40, delete 2
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 0 buffer(s)
3540.71 hash searches/s, 35850.93 non-hash searches/s
---
LOG
---
Log sequence number          1426648439620
Log buffer assigned up to    1426648439620
Log buffer completed up to   1426648439620
Log written up to            1426648434688
Log flushed up to            1426648433220
Added dirty pages up to      1426648439620
Pages flushed up to          1426608267533
Last checkpoint at           1426579212054
Log minimum file id is       435629
Log maximum file id is       435650
321089617 log i/o's done, 2048.22 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 0
Dictionary memory allocated 664749
Buffer pool size   8191
Free buffers       794
Database pages     9121
Old database pages 3386
Modified db pages  4434
Pending reads      0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 56807157, not young 3499263268
113.15 youngs/s, 33258.07 non-youngs/s
Pages read 480669063, created 50966002, written 336378679
3768.43 reads/s, 196.81 creates/s, 1998.69 writes/s
Buffer pool hit rate 976 / 1000, young-making rate 0 / 1000 not 215 / 1000
Pages read ahead 4.87/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 9121, unzip_LRU len: 1142
I/O sum[268957]:cur[4079], unzip sum[132574]:cur[1124]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=65185, Main thread ID=0x70000953a000 , state=sleeping
Number of rows inserted 257319875, updated 79695629, deleted 39, read 548172909
0.00 inserts/s, 573.98 updates/s, 0.00 deletes/s, 2346.91 reads/s
Number of system rows inserted 1378, updated 19177, deleted 803, read 123917
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

从 InnoDB 日志的输出中分析，以下是一些可能导致 MySQL 卡住的原因和解决方案：

关键日志分析

  1. Transactions:
---TRANSACTION 24056144, ACTIVE 1 sec inserting
mysql tables in use 1, locked 1
470 lock struct(s), heap size 73848, 932 row lock(s), undo log entries 462
MySQL thread id 3633, OS thread handle 123145476378624, query id 56338839 localhost 127.0.0.1 root update
insert into ...

这个活动事务正在进行一个插入操作，并且锁定了 470 个结构，包含 932 个行锁。虽然日志显示该事务只活动了 1 秒，但如果这种情况频繁发生，并且插入操作需要大量锁，可能会导致资源竞争和性能问题。

  1. Pending flushes:
Pending flushes (fsync) log: 1; buffer pool: 18446744073709550954

这个数字 18446744073709550954 表示在缓冲池中有大量的页面需要被刷新，这是一个异常高的数字。通常这是由于缓冲池的页面没有及时写入磁盘造成的。

可能原因

  1. 锁争用：频繁的锁争用可能导致事务等待，虽然没有检测到死锁，但长时间的锁等待也会造成线程卡住。
  2. 缓冲池压力：缓冲池中有大量的页面需要被刷新，但刷新速度跟不上页面的修改速度，可能会导致 I/O 瓶颈。
  3. 磁盘 I/O：日志显示有大量的 I/O 操作，如果磁盘性能较差或 I/O 资源不足，可能导致线程等待磁盘操作完成。

解决方案

  1. 增加缓冲池大小：当前缓冲池大小为 8191 页（约 128MB），建议增加 innodb_buffer_pool_size，例如调整为 8GB 或更高，以减少磁盘 I/O 压力。
SET GLOBAL innodb_buffer_pool_size = 8589934592; -- 8GB
  1. 优化插入操作：考虑批量插入操作，减少每次插入的行数，并确保插入操作不会锁定过多行。
INSERT INTO basic_measure (id, quote_date, stock_type, stock_code, create_time, update_time, body)
VALUES (...);
  1. 检查磁盘性能：确保磁盘有足够的 I/O 带宽，并且没有其他进程占用大量 I/O 资源。如果可能，考虑使用 SSD 来提高磁盘 I/O 性能。
  2. 监控与调优：使用工具如 pt-query-digest 分析查询性能，找出慢查询并进行优化。
  3. 调整 MySQL 配置：以下是一些推荐的 MySQL 配置项，用于提升性能和减少锁争用：
SET GLOBAL innodb_log_file_size = 268435456; -- 256MB
SET GLOBAL innodb_flush_log_at_trx_commit = 2; -- 提高日志写入性能，风险是可能丢失最近 1 秒的事务

通过这些措施，可以逐步找出导致 MySQL 线程卡住的问题，并有效地提高数据库的性能和稳定性。如果问题依然存在，可能需要进一步的分析和专业的数据库调优支持。

评估现有配置

假设 innodb_buffer_pool_size 设置为 134217728 字节（128MB），这是一个相对较小的配置，通常适用于内存有限或测试环境。对于生产环境，尤其是高负载的应用程序，建议增加缓冲池大小。

DB配置

判断 innodb_buffer_pool_size 是否合理是确保 MySQL 数据库性能的一个重要步骤。innodb_buffer_pool_size 是 InnoDB 存储引擎的一个关键配置参数，它决定了 InnoDB 用于缓存数据和索引的内存大小。一个合理的 innodb_buffer_pool_size 可以显著提升数据库的性能，以下是如何判断和优化这个参数的详细指南。

1. 监控 innodb_buffer_pool_size 的使用情况

使用以下 SQL 语句来查看当前 innodb_buffer_pool_size 的使用情况：

SHOW ENGINE INNODB STATUS;

从输出中查看以下部分：

  • Buffer pool size: 当前 buffer pool 的大小。
  • Free buffers: 当前 buffer pool 中空闲的页数。
  • Database pages: 当前 buffer pool 中的数据页数。
  • Pages read 和 Pages written: 读写的页面数量。

如果你的 innodb_buffer_pool_size 设置合理，你应该看到 Free buffers 比较高，并且 Database pages 和 Pages read 的数量应该比较平衡。

2. 计算合理的 innodb_buffer_pool_size

基本原则
  1. 总内存的 70% 到 80%：
    • 对于数据库服务器，推荐将总内存的 70% 到 80% 分配给 innodb_buffer_pool_size。这意味着如果你的服务器有 32GB 的内存，你可以将 innodb_buffer_pool_size 设置为 22GB 到 25GB。
    • 注意：如果你的服务器还运行了其他应用程序或服务，分配给 innodb_buffer_pool_size 的内存应该减少。
  2. 大于活跃数据集的大小：
    • 确保 innodb_buffer_pool_size 足够大，以缓存活跃数据集。如果 innodb_buffer_pool_size 过小，InnoDB 将需要频繁地从磁盘读取数据，导致性能下降。

3. 监控和调整 innodb_buffer_pool_size

常用监控指标
  1. Buffer Pool Hit Rate：

查看 buffer pool 命中率来判断缓存的效率：

SHOW STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW STATUS LIKE 'Innodb_buffer_pool_reads';

计算命中率：

Buffer Pool Hit Rate = 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)
  • 高命中率（接近 1）表示 buffer pool 足够大。
  • 低命中率（远低于 1）表示 buffer pool 可能需要增大。
  1. 缓冲区的读取和写入情况：
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_write_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_writes';

通过这些数据，可以检查 Buffer Pool 的效率：

  • Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests < 0.1 表示缓存命中率很高。
  • 如果 Innodb_buffer_pool_reads 比 Innodb_buffer_pool_read_requests 大，说明 innodb_buffer_pool_size 可能不足。
  1. IO Wait Time：

查看是否有较高的 IO 等待时间。

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_flushed';

高的值可能表明需要调整 innodb_buffer_pool_size 或磁盘 IO 性能有问题。

4. 调整 innodb_buffer_pool_size

根据监控的结果来调整 innodb_buffer_pool_size：

SET GLOBAL innodb_buffer_pool_size = <new_value>;

例如：

SET GLOBAL innodb_buffer_pool_size = 24G;

为了使更改生效，需要重启 MySQL 服务：

sudo systemctl restart mysql
# 或者
sudo service mysql restart

5. 实际配置示例

以下是一个示例配置，适用于高负载的数据库服务器：

[mysqld]
innodb_buffer_pool_size = 24G
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_io_capacity = 2000

总结

innodb_buffer_pool_size 的合理性直接影响到 MySQL 的性能。一个合理的配置可以减少磁盘I/O，提高查询性能，优化数据库操作。以下是判断 innodb_buffer_pool_size 是否合理的步骤：

  1. 监控使用情况：
    • 查看 SHOW ENGINE INNODB STATUS 和相关状态变量。
  2. 计算和配置：
    • 按照内存总量的 70% 到 80% 来配置 innodb_buffer_pool_size。
  3. 调整：
    • 基于实际监控数据和性能测试结果来调整 innodb_buffer_pool_size。

DB配置分析

Buffer Pool Size 和使用情况

  • Buffer pool size: 8191 (单位是页，通常每页大小是 16KB，所以总大小是 8191 * 16KB = 131056 KB ≈ 128 MB)
  • Free buffers: 794
  • Database pages: 9121
  • Old database pages: 3386
  • Modified db pages: 4434

分析：

  • Buffer Pool Size 约为 128 MB，这对于现代高负载的 MySQL 实例来说可能过小。通常，innodb_buffer_pool_size 需要更大才能缓存足够的数据和索引，特别是在有大量数据和高并发情况下。
  • Free buffers 和 Database pages 数量表明 Buffer Pool 有一定的空闲空间，但这些空闲空间的比例也表明缓存可能不够大。详情见后续的专项分析
  • Pages made young 和 Non-young pages 的比例表明有大量的页面在 Buffer Pool 中，但 Buffer pool hit rate 高达 976 / 1000，说明缓存命中率很好。

2. Buffer Pool Hit Rate

  • Buffer pool hit rate: 976 / 1000

这个值表示 Buffer Pool 的命中率很高，接近于 1，这表明 innodb_buffer_pool_size 可能在当前负载下是足够的，但要注意这是一个衡量当前状态的指标，可能会随着负载的增加或数据量的变化而改变。

3. 读写操作

  • Reads/s: 3768.43
  • Writes/s: 1998.69
  • Creates/s: 196.81

读操作的速率远高于写操作和创建操作，这可能是因为读取操作频繁，可能表明数据库有大量的读请求或者数据访问量大。

4. 页面相关信息

  • Modified db pages: 4434 (这表明 Buffer Pool 中有大量被修改的页面)
  • Pages read ahead: 4.87/s 和 Random read ahead: 0.00/s

这个数据表明 Buffer Pool 在进行页面读取时表现正常。Read ahead 的数据表明读取策略可能不完全依赖于预读操作。

5. I/O 操作

  • Pending reads: 0
  • Pending writes: LRU 0, flush list 0, single page 0

这表明没有挂起的 I/O 操作，I/O 操作在进行中，但没有明显的瓶颈。

6. Buffer Pool 的建议

如果你的服务器有足够的内存，以下是对 **innodb_buffer_pool_size** 的优化建议：

  • **增加 ****innodb_buffer_pool_size**：
    • 当前配置可能对于高负载情况下的性能优化不足。推荐将其增加到更多的内存，比如 2-4 GB 或更多，具体取决于你的数据集大小和服务器的总内存。
SET GLOBAL innodb_buffer_pool_size = 2G;
  • 重启 MySQL 服务以应用更改：
sudo systemctl restart mysql
# 或者
sudo service mysql restart

7. 其他优化建议

除了调整 innodb_buffer_pool_size 之外，以下参数也可能需要优化：

  • **innodb_log_file_size**：增加日志文件大小可以减少日志写入的频率。适当增大为 1G 或更大。
innodb_log_file_size = 1G
  • **innodb_flush_log_at_trx_commit**：设置为 2 可以减少磁盘 I/O，但可能会有少量的数据丢失风险。
innodb_flush_log_at_trx_commit = 2
  • **innodb_flush_method**：设置为 O_DIRECT 可以减少操作系统缓存的影响。
innodb_flush_method = O_DIRECT
  • **innodb_io_capacity**：适当增加可以提升 I/O 性能。设置为 2000 或更高的值。
innodb_io_capacity = 2000
innodb_flush_log_at_trx_commit
  • 0:
innodb_flush_log_at_trx_commit=0
  • 含义: 每秒将事务日志写入到日志文件中，不保证每次事务提交时都将日志刷到磁盘。
  • 性能: 最高性能，事务提交时不会等待磁盘操作，日志会被缓存在操作系统的页面缓存中，由操作系统在合适的时机写入磁盘。
  • 数据安全性: 最低，可能会在系统崩溃时丢失最多 1 秒的数据。
  • 1:
innodb_flush_log_at_trx_commit=1
  • 含义: 每次事务提交时，都会将事务日志写入到日志文件并立即刷到磁盘。
  • 性能: 性能较低，因为每次事务提交都需要等待 I/O 操作完成。
  • 数据安全性: 最高，确保事务日志在每次提交时都被持久化。
  • 2:
innodb_flush_log_at_trx_commit=2
  • 含义: 每次事务提交时将事务日志写入到日志文件中，但不保证日志会立即刷到磁盘。操作系统会定期将日志刷到磁盘。
  • 性能: 性能介于 0 和 1 之间，通常是性能和安全性的折中选择。
  • 数据安全性: 低于 1，但高于 0，可能会在系统崩溃时丢失最多 1 秒的数据。
innodb_io_capacity
  • 默认值:
innodb_io_capacity=200
  • 含义: 这是 InnoDB 引擎的默认 I/O 处理能力为每秒 200 次 I/O 操作。
  • 性能: 默认值适用于大多数常见的应用场景。如果你的数据库有较高的 I/O 负载，可能需要调整这个值。
  • 调整方法:
innodb_io_capacity=1000
  • 含义: 增加 I/O 处理能力，每秒 1000 次 I/O 操作。适用于具有高 I/O 需求的场景。

选择配置的依据

  • 高 I/O 需求:
    • 对于高负载的数据库环境，innodb_io_capacity 应该设置为一个较高的值，以提高 I/O 性能。
  • 低 I/O 需求:
    • 对于负载较轻的环境，使用默认值或设置较低的值可能是合理的。

总结

根据你的监控数据，当前的 innodb_buffer_pool_size 可能过小。虽然当前 Buffer Pool Hit Rate 较高，但在高负载情况下可能会遇到性能瓶颈。建议增加 innodb_buffer_pool_size 并根据实际负载和数据量进行调整。同时，关注其他相关配置和硬件性能也很重要。

Free buffers 和 Database pages

详细解释

1. Free Buffers 和 Database Pages 的含义
  • Free Buffers: 这是当前 Buffer Pool 中可用的空闲页面数量。这些页面可以被用来存储新的数据或索引。
  • Database Pages: 这是当前 Buffer Pool 中实际存储的数据库页面数量，包括正在使用的页面和空闲页面。
2. 如何看待这些指标
1. Free Buffers 和 Database Pages 比例
Free buffers       794
Database pages     9121
  • Free Buffers 是 Buffer Pool 中的空闲页面，794 页是可用于新数据的空间。
  • Database Pages 是 Buffer Pool 中实际使用的页面，9121 页中包含了数据和索引。

比例计算:

Free Buffers / Database Pages ≈ 794 / 9121 ≈ 0.09

这个比例大约是 0.09，表示 Buffer Pool 中的空闲页面占总页面数量的比例较小。这可能表明：

  • Buffer Pool 可能不够大: 如果 Free Buffers 占比过低，说明 Buffer Pool 的容量可能不足，不能有效地缓存数据库的热数据。
  • 负载可能很高: 频繁的读写操作会不断地使用和释放 Buffer Pool 中的页面，导致 Free Buffers 较少。
2. 理解比例不好的原因
  • 比例不好: Free Buffers 和 Database Pages 的比例不理想意味着 Buffer Pool 中空闲空间不足，可能会导致缓存未能充分利用，从而降低性能。
  • 比例问题: 理想的情况下，Free Buffers 应该占有一定比例，这样可以保证在数据的高并发读写中，Buffer Pool 有足够的空间来处理新的数据请求。如果这个比例过低，说明 Buffer Pool 可能正在满负荷运作。

实际例子分析

假设你有一个 1 GB 的 Buffer Pool，理想情况下你应该有一定的空闲页面来处理新的数据请求。下面是几个实际的场景：

  • 正常情况:
    • Free Buffers 占 Buffer Pool 页数的 10% 到 20% 是比较理想的。
    • 在你的情况中，Free Buffers 占比仅 0.09，远低于这个标准，这可能表示 Buffer Pool 太小，无法有效地处理数据操作。
  • 负载情况:
    • 如果你的数据库负载很高（高并发读写），即使 Free Buffers 有一定数量，比例也可能很低。

其他指标的影响

除了 Free Buffers 和 Database Pages 的比例，以下几个指标也对 innodb_buffer_pool_size 的合理性有影响：

  • **Buffer Pool Hit Rate**: 高命中率说明大部分数据都在 Buffer Pool 中，但不能单独作为 Buffer Pool 大小的唯一依据。
  • **Pages Read Ahead**** 和 ****Random Read Ahead**: 如果 Pages Read Ahead 比较高，可能表明 Buffer Pool 空间不足，需要更多的页面预读。
  • **Modified DB Pages**: 如果大量页面被修改但未刷新，可能表示 Buffer Pool 大小不足，导致页面经常需要更新。

图示说明

以下图示可以帮助你理解 Free Buffers 和 Database Pages 的比例问题：

Buffer Pool描述理想状态不足的状态
Free Buffers当前 Buffer Pool 的空闲空间数量充足不足
Database Pages当前 Buffer Pool 中的数据库页面总数一定比例低比例
比例Free Buffers / Database Pages理想值低于理想值

调整建议

为了提高性能，建议增加 innodb_buffer_pool_size 以便有更多的空闲空间来处理数据操作。以下是一些增加 innodb_buffer_pool_size 的指导原则：

  • 增加到 1-2 倍的当前大小: 如果当前是 128 MB，建议将其增加到 1 GB 或更高。
  • 监控性能指标: 在增加 innodb_buffer_pool_size 后，继续监控 Free Buffers 和 Database Pages 的比例、Buffer Pool Hit Rate 和 I/O 操作 以确保配置的有效性。

结论

Free Buffers 和 Database Pages 的比例 是一个衡量 Buffer Pool 空间利用情况的指标。如果这个比例很低，说明 Buffer Pool 可能不足以处理当前的数据库负载。基于你的数据，当前的 Buffer Pool 可能不够大，需要进行适当的调整来提高性能。

分析IO瓶颈

1. 使用 iostat 工具

iostat 是一个常用的工具，可以帮助你查看CPU负载和设备IO统计信息。

iostat -dx 2 10

这个命令会每隔2秒显示一次统计信息，共10次。

磁盘性能
  • 现代SSD的读写速度通常在500MB/s到3500MB/s之间，而传统HDD的速度在100MB/s左右。
  • 如果你的磁盘是SSD，10MB/s的IO通常不会是瓶颈。
  • 如果是HDD，10MB/s的持续读写可能会导致一些延迟，但仍然在可接受范围内。
分析瓶颈的指示
  • 高 **tps** 值：如果每秒的IO请求数很高，但磁盘的吞吐量（MB/s）并没有相应增加，说明存在大量小IO操作，可能导致IO瓶颈。
  • 高 **await** 时间：如果IO请求的平均等待时间（在Linux上为await）很长，说明IO子系统可能存在瓶颈。
  • 高 **avgqu-sz** 值：如果请求队列的平均长度很长，说明磁盘设备处理不过来所有的IO请求，可能存在IO瓶颈。
  • 高 **%util** 值：如果磁盘设备的利用率接近100%，说明磁盘设备已经处于满负荷状态，可能存在IO瓶颈。

2. 使用 vm_stat 工具

vm_stat 可以显示虚拟内存的统计信息，这对于分析内存和磁盘IO之间的关系非常有用。

vm_stat 2

这个命令会每隔2秒显示一次统计信息

分析瓶颈的指示

查看页面换入和换出的频率，判断是否存在内存不足导致的磁盘IO瓶颈。

分析步骤

  1. 通过 **iostat** 和 **vm_stat** 检查IO操作的速度和等待时间：重点关注 await（平均等待时间）和 svctm（平均服务时间）的数值，如果等待时间过长，说明可能存在IO瓶颈。
    1. 在Linux上使用iostat -x命令可以得到svctm（Service Time）。它表示每个IO操作所花费的平均时间（以毫秒为单位）。如果svctm值很高，说明每个IO操作处理时间较长，可能存在IO瓶颈。
    2. 查看虚拟内存统计：查看页面换入和换出的频率，判断是否存在内存不足导致的磁盘IO瓶颈。
太阳伞下的阿呆
关注
专栏目录
Android 卡顿排查工具
jasenwan88的专栏
06-17 1667
Android 卡顿排查工具 Traceview 和 systrace 都是我们比较熟悉的排查卡顿的工具，从实现上这些工具分为两个流派。 第一个流派是 instrument。获取一段时间内所有函数的调用过程，可以通过分析这段时间内的函数调用流程，再进一步分析待优化的点。 第二个流派是 sample。有选择性或者采用抽样的方式观察某些函数调用过程，可以通过这些有限的信息推测出流程中的可疑点，然后再继续细化分析。 1. Traceview 吐槽的比较多的工具。它利用 Android ...
linux卡顿问题排查_LINUX云服务器访问慢卡顿怎样排查负载解决性能问题？
weixin_29000891的博客
12-29 968
如果Linux服务器突然访问卡顿变慢，负载暴增，如何在最短时间内找出Linux性能问题所在？万维景盛工程师邀请您来看Netflix性能工程团队的这篇博文，看它们通过十条命令在一分钟内对机器性能问题进行诊断。概述通过执行以下命令，可以在1分钟内对系统资源使用情况有个大致的了解。uptimedmesg | tailvmstat 1mpstat -P ALL 1pidstat 1iostat -xz 1...
Linux服务器卡顿如何排查
fen_dou_shao_nian的博客
11-25 1万+
一、背景 在一次测试中发现服务器非常卡顿，刚开始任务是网络问题导致，可是别人的服务却可以正常运行，于是进行了一些列排查。 二、排查步骤 2.1 查看内存使用情况 ## -g表示单位是G，-m 表示单位是m free -g 2.2 查看磁盘使用情况 df -h 查看磁盘的 已用 情况是否过高。 2.3 查看磁盘IO使用情况 ## 1 表示没1s刷新一下 iostat -x 1 ## 查看磁盘列表 lsblk 查看磁盘的io情况是否使用过高。 2.4 查看cpu使用情况 top ...
记一次oracle数据库瞬时卡顿排查过程
xiaofan23z的专栏
02-01 1361
(自动段指导)*识别有可用回收空间的段，并提出如何消除这当段中的碎片的建议，也可以手动运行 Segment Advisor 获取更多最新建议，或获取 Automatic segment Advisor 没有检查到的那些有可能做空间回收的段的建议。(自动优化器统计信息收集)**收集数库中所有无统计信息或仅有过时统计信息的 schema 对象的 Optmzer(优化)统计信息，SQL query optimizer(SQL 查询优化器)使用此任务收集的统言息提高 SQL 执行的性能。
06 | 卡顿优化（下）：如何监控应用卡顿？
qq_37756660的博客
08-05 1294
今天我们学习了卡顿监控的几种方法。随着技术的深入，我们发现了旧方案的一些缺点，通过不断地迭代和演进，寻找更好的方案。Facebook 的 Profilo 实现了快速获取 Java 堆栈，其实它参考的是 JVM 的 AsyncGetCallTrace 思路，然后适配 Android Runtime 的实现。systrace 使用的是 Linux 的 ftrace，Simpleperf 参考了 Linux 的 perf 工具。
Linux服务器出现异常和卡顿排查思路和步骤
热门推荐
DD-Blog
03-22 1万+
Linux服务器出现异常和卡顿有硬件和软件的原因，硬件没问题的情况可以通过 top命令、jps命令、 jmap分析堆内存配置信息和使用情况、 jstack分析线程的执行情况、 jstat查看各区域占堆百分比和服务日志去排查问题。
应用卡顿优化
u011371324的专栏
05-18 1275
对于卡顿分析，首先需要明确分析的因素，即影响卡顿有哪些点，是 CPU 繁忙，线程锁资源导致的阻塞，IO 耗时操作，还是内存吃紧等，然后再收集卡顿时相关信息，当前设备信息，当前运行状态，堆栈信息等，最后根据这些信息，以及结合具体的业务场景得到卡顿原因。 1.卡顿现象 对于卡顿现象，最直观体现在应用显示上。正常一个 App 不卡顿时，应该表现出页面显示比较稳定，没有跳变，丢帧；动画平稳流畅；用户交互反应灵敏。 通常条件下，人眼的识别连贯图像的速度是 24 帧/s，也就是 1000ms/24 帧，大约为 40ms
服务器卡顿排查方法
qq_22596931的博客
05-27 1426
原文：https://blog.csdn.net/weixin_39539399/article/details/83896748 背景：用户反馈系统好卡，进行系统排除，找到这篇帖子进行简单的学习。 一、查看服务器的内存和服务器核数大小 ①查看服务器内存大小 cat /proc/meminfo | grep MemTotal ②查看服务器核数 总核数 = 物理CPU个数 * 每...
服务器崩溃卡顿问题排查思路
李乾文的博客
07-12 2998
0x00 前言 本文讲述了服务器崩溃、卡顿时的排查思路。 0x00 前言 0x01 常见崩溃问题 (1) 首先看CPU、内存、和磁盘空间占用是否异常 (2) Session文件过多 (3) 日志文件过多 0x01 域名解析 0x02 Nginx服务 0x03 PHP服务 0x04 MySQL数据库
Java应用后端响应慢问题排查思路
djp304的博客
09-08 5168
java 应用后端响应慢排障
音视频测试、流媒体转发压测、音视频卡顿排查方法.zip
03-25
本文将深入探讨音视频测试的关键知识点，包括基础概念、测试目标、常见问题及解决策略，并结合流媒体转发压测和音视频卡顿排查方法，帮助软件测试工程师提升测试效率和质量。 一、音视频测试基础 1. 测试类型：音...
解码器添加摄像头画面卡顿5步建议排查方法
04-01
### 解码器添加摄像头画面卡顿的排查方法 在日常工作中，我们经常遇到解码器添加摄像头后出现画面卡顿的问题。这种情况不仅会影响监控效果，还可能延误重要信息的捕捉。针对这一现象，本文将根据提供的文件信息进行...
MySQL表的增删改查(基础)
weixin_63965017的博客
10-02 516
语法表名values(值，值......);值与列相匹配。
【MySQL】MySQL 数据库主从复制详解
人生苦短，睡觉要紧，睡醒再说
10-01 1218
MySQL 主从复制是实现高可用性和负载均衡的重要手段。通过合理配置和监控，可以显著提升数据库的可用性和性能，有效地管理数据同步，实现系统的弹性和鲁棒性。在实际应用中，应根据业务需求和系统架构来合理设计部署方案，并定期监控复制状态，以确保数据的一致性和完整性。了解主从复制的工作原理及其配置过程，对数据库管理员至关重要。希望本文能帮助您深入理解 MySQL 主从复制的相关知识。
基于微信小程序的生鲜订购小程序系统(SpringBoot+Vue+Uniapp+MySQL)
最新发布
源码好优多
10-06 1169
开发者不再需要手动配置大量的 XML 文件或繁琐的注解，框架提供了默认的配置，根据项目的依赖关系和约定，自动完成配置。系统测试主要是为了避免用户在使用时发生问题，增强用户体验感，为了不影响用户的使用，我们需要从多角度、多思路去考虑系统可能遇到的问题，通过不同的模拟场景来发现缺陷并解决问题。添加用户时，必填项不填，检验系统是否有非空检验；登录功能测试方案：当需要登入该系统时，通过账户密码等功能点进行验证，用户在输入时需要输入与数据库内存储的数据匹配的内容，当其中某项输入错误时系统将提示输入错误。
【mysql相关总结】
Charles D
09-30 330
数据库小的表,全表扫描效率更高，不用建索引。索引的类型1.普通索引：基本的索引，没有任何约束限制2.唯一索引：类似普通索引,有唯一约束性3.主键索引：特殊的唯一索引,不允许有空值4.组合索引：多个列组合创建索引5.外键索引：只有innodb可以使用6.全文索引：只有myisam可以使用，且只能对英文进行全文检索注意事项1.复合索引遵循前缀原则（最左匹配原则）2.like查询,%号不能在前面，否则索引失效3.如果or前面的条件有索引,也会失效。
docker容器mysql数据备份 mysql容器无法启动备份数据
zhangxu1998lq的博客
09-30 386
mysql是旧容器名 因为mysql的配置文件my.cnf的路径没有映射到服务器，我修改了配置文件，配置文件有错误导致，容器启动不了，一直restarting。nmysql是新容器名 mysql是旧容器名 mysql:5.7是我的镜像名。新容器正常启动，旧容器的数据都还在。
Python 3 和 MySQL(PyMySQL) 的完美结合
wjs2024的博客
10-02 600
PyMySQL 是一个纯 Python 编写的 MySQL 客户端库，它提供了与 MySQL 数据库进行交互的接口。PyMySQL 设计轻量、易于安装和使用，且完全兼容 MySQLdb 接口，使得从 MySQLdb 迁移变得非常简单。Python 3 和 PyMySQL 库的结合为开发人员提供了一种高效、简洁的方式来与 MySQL 数据库进行交互。通过本文的介绍，您应该能够理解如何安装 PyMySQL、建立数据库连接、执行 SQL 语句、处理查询结果以及处理可能出现的错误。
Mysql知识体系总结梳理
guitumanman的博客
09-30 892
那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。最后，事务B读取到的张三工资为8000的数据即为脏数据，事务B做了一次脏读。不可重复读的重点是修改：同样的条件，你读取过的数据，再次读取出来发现值不一样了幻读的重点在于新增或者删除：同样的条件，第 1 次和第 2 次读出来的记录数不一样。
某应用每天凌晨六点业务卡顿，有哪些排查方向？
06-11
业务卡顿可能由多种原因引起，以下是一些排查方向： 1. 系统资源：业务卡顿可能是由于系统资源不足引起的。可以检查系统资源使用情况，如 CPU、内存、磁盘等的占用率是否异常。 2. 网络：业务卡顿可能是由于网络...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值