磁盘IO高和线程切换过高性能压测案例分析

案例现象:

压力测试的时候,发现A请求压力80tps后,cpu占用就非常高了(24核的机器,每个cpu占用率全面飙到80%以上),且设置的检查点没有任何报错。

1、top命令如下:

2、 了解了一下后台实现逻辑:大体是这样的:服务器接到请求后,会再到另一台kv服务器请求数据,拿回来数据后,根据用户的机器码做个性化运算,最后将结果返回给客户端,期间会输出一些调试log。

查了下,kv服务器正常,说明是本机服务服务器的问题。具体用vmstat命令看一下异常的地方。

3、 从图中可以直观的看出,bi、bo、in、cs这四项的值都很高,根据经验,bi和bo代表磁盘io相关、in和cs代表系统进程相关。一个一个解决吧,先看io。

4、 用iostat –x命令看了下磁盘读写,果然,磁盘慢慢给堵死了。

5、 看了下过程,只有写log操作才能导致频繁读写磁盘。果断关闭log。重新打压试下。

6、 Bi和bo降到正常值了,说明磁盘的问题解决了。但是上下文切换数竟然达到了每秒40万次!好可怕~

7、 只知道上下文切换数很大,怎么知道是在哪些进程间切换呢?

到网上搜了一个脚本,这个脚本用来统计特定时间内进程切换的top20并打印出来。

#! /usr/bin/env stap
#
#
global csw_count

global idle_count

probe scheduler.cpu_off {

csw_count[task_prev, task_next]++

idle_count+=idle
}

function fmt_task(task_prev, task_next)

{

return sprintf("%s(%d)->%s(%d)",

task_execname(task_prev),

task_pid(task_prev),

task_execname(task_next),

task_pid(task_next))

}

function print_cswtop () {

printf ("%45s %10s\n", "Context switch", "COUNT")

foreach ([task_prev, task_next] in csw_count- limit 20) {

printf("%45s %10d\n", fmt_task(task_prev, task_next), csw_count[task_prev, task_next])

}

printf("%45s %10d\n", "idle", idle_count)

delete csw_count

delete idle_count

}
probe timer.s($1) {

print_cswtop ()

printf("--------------------------------------------------------------\n")

}

保存成cs.stp后,用stap cswmon.stp 5命令执行下。

8、发现是discover进程在反复和系统进程进行切换。从此消耗了大量资源。

9、从网上查了下减少切换进程的一些方法:

开发随后改了下:将线程数开大了一倍,控制在一个进程中。

重新打压了一下。发现上下文切换数降低到25万次左右。

此时的性能数据可以达到每秒260次左右,远远高于之前的80次。已经达到可以上线的需求。

但是由于页面中断书和上下文切换数还是很高,后续还是需要优化

时间: 2024-09-29 22:06:30

磁盘IO高和线程切换过高性能压测案例分析的相关文章

MYSQL数据库服务磁盘IO高问题分析与优化

压力测试过程中,如果因为资源使用瓶颈等问题引发最直接性能问题是业务交易响应时间偏大,TPS逐渐降低等.而问题定位分析通常情况下,最优先排查的是监控服务器资源利用率,例如先用TOP 或者nmon等查看CPU.内存使用情况,然后在排查IO问题,例如网络IO.磁盘IO的问题. 如果是磁盘IO问题,一般问题是SQL语法问题.MYSQL参数配置问题.服务器自身硬件瓶颈导致IOPS吞吐率问题. 今天主要是讲解MYSQL 参数配置不合理导致在高并发下磁盘IO问题,而MYSQL整体监控优化方案后面会整理<如何轻

一次磁盘IO高的问题处理

问题现象: 开发测试环境的kubernetes master服务器,磁盘读写速率很高,达200多M/s,IOPS超过8000/S,系统操作出现卡顿(还好硬盘是SSD,否则系统早卡死掉了),截图如下: 解决思路: 1.使用iotop查看IO高的进程,并kill,问题依旧 2.重启系统后正常,但一段时间后问题重现 3.查看内存,发现物理内存已基本使用完,并且在大量使用swap,因此问题原因可以确定: IO高是因为进程大量使用swap交换页所导致!!! 注:因为是开发测试环境,没有部署监控.分配的资源

磁盘IO过高时的处理办法

针对系统中磁盘IO负载过高的指导性操作 主要命令:echo deadline > /sys/block/sda/queue/scheduler 注:以下的内容仅是提供参考,如果磁盘IO确实比较大的话,是数据库,可以进行读写分离或者分库操作,减小磁盘压力,文件的话,可以利用raid来减轻压力 一)I/O调度程序的总结: 1)当向设备写入数据块或是从设备读出数据块时,请求都被安置在一个队列中等待完成.2)每个块设备都有它自己的队列.3)I/O调度程序负责维护这些队列的顺序,以更有效地利用介质.I/O

Linux统系统开发12 Socket API编程3 TCP状态转换 多路IO高并发select poll epoll udp组播 线程池

[本文谢绝转载原文来自http://990487026.blog.51cto.com] Linux统系统开发12 Socket API编程3 TCP状态转换 多路IO高并发select  poll  epoll udp组播 线程池 TCP 11种状态理解: 1,客户端正常发起关闭请求 2,客户端与服务端同时发起关闭请求 3,FIN_WAIT1直接转变TIME_WAIT 4,客户端接收来自服务器的关闭连接请求 多路IO转接服务器: select模型 poll模型 epoll模型 udp组播模型 线

记一次性能测试:mysql占用磁盘IO过高 的解决过程

在一次性能测试时,发现mysql的cpu使用率不高,但是磁盘io很高, 一开始考虑是mysql的慢日志比较多,但是查看后发现慢日志并不多,而且只有一台mysql. 进入实例,查看sync_binlog变量 mysql> show variables like '%sync_binlog%' -> ; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | sync_binlog | 1 |

JDB2导致磁盘io使用率高

前几天碰到jbd2进程占用大量的磁盘io,用iotop查看到的情况大致如下: 系统版本:CentOS6.5-64bit 经查为ext4文件系统的一个bug: 先给出解决方案,处理此问题的优先级为: 1.yum update kernel 用yum升级系统内核,重启之后查看是否有效: 2.缓解方法:修改commit值,降低文件系统提交次数或者禁用barrier特性: 建议文件系统参数为:defaults,noatime,nodiratime,barrier=0,data=writeback,com

【好书摘要】性能优化中CPU、内存、磁盘IO、网络性能的依赖

系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长期和持续的过程,不 是说现在优化了,测试了,以后就可以一劳永逸了,也不是说书本上的优化就适合眼下正在运行的系统,不同的系统.不同的硬件.不同的应用优化的重点也不同. 优化的方法也不同.优化的参数也不同.性能监测是系统优化过程中重要的一环,如果没有监测.不清楚性能瓶颈在哪里,怎么优化呢?所以找到性能 瓶颈是性能监测的目的,也是系统优化的关键.系统由若干子系统构成,通常修改一个子系

linux性能优化cpu 磁盘IO MEM

系统优化是一项复杂.繁琐.长期的工作,优化前需要监测.采集.测试.评估,优化后也需要测试.采集.评估.监测,而且是一个长期和持续的过程,不 是说现在优化了,测试了,以后就可以一劳永逸了,也不是说书本上的优化就适合眼下正在运行的系统,不同的系统.不同的硬件.不同的应用优化的重点也不同. 优化的方法也不同.优化的参数也不同.性能监测是系统优化过程中重要的一环,如果没有监测.不清楚性能瓶颈在哪里,怎么优化呢?所以找到性能 瓶颈是性能监测的目的,也是系统优化的关键.系统由若干子系统构成,通常修改一个子系

linux查看磁盘io的几种方法

怎样才能快速的定位到并发高是由于磁盘io开销大呢?可以通过三种方式: 第一种:用 top 命令 中的cpu 信息观察 Top可以看到的cpu信息有: Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3% us, 1.0% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si 具体的解释如下: Tasks: 29 total 进程总数 1 running 正在运