第 1 章 概述篇
针对四大方向
CPU
Memory
IO
Network
基本参考标准
针对四大方向
CPU
Memory
IO
Network
基本参考标准
# vmstat 1
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
procs memory
swap
io
system cpu
r b swpd free buff cache
si so bi bo
in cs us sy wa id
1 0 138592 17932 126272 214244 0 0 1 18
109 19 2 1 1 96
0 0 138592 17932 126272 214244 0 0 0 0
105 46 0 1 0 99
安装监控工具 yum -y install sysstat
表 1.1. 监控系统性能工具
表 1.1. 监控系统性能工具
安装监控工具 yum -y install sysstat
表 1.1. 监控系统性能工具
Tool
|
Description
|
Base
|
Repository
|
vmstat
|
all purpose performance tool
|
yes
|
yes
|
mpstat
|
provides statistics per CPU
|
no
|
yes
|
sar
|
all purpose performance monitoring tool
|
no
|
yes
|
iostat
|
provides disk statistics
|
no
|
yes
|
netstat
|
provides network statistics
|
yes
|
yes
|
dstat
|
monitoring statistics aggregator
|
no
|
in most distributions
|
iptraf
|
traffic monitoring dashboard
|
no
|
yes
|
netperf
|
Network bandwidth tool
|
no
|
In some distributions
|
ethtool
|
reports on Ethernet interface configuration
|
yes
|
yes
|
iperf
|
Network bandwidth tool
|
no
|
yes
|
tcptrace
|
Packet analysis tool
|
no
|
yes
|
strace
|
查看相关进程读写的数据
|
|
|
第 2 章 CPU篇
CPU调度优先级
Interrupts(中断)高于Kernel(System) Processes(内核处理过程)高于User Processes(用户进程)
上下文切换
Linux 内核的系统在一个双核心处理器上,是报告显示为两个独立的处理器.
CPU调度优先级
Interrupts(中断)高于Kernel(System) Processes(内核处理过程)高于User Processes(用户进程)
上下文切换
Linux 内核的系统在一个双核心处理器上,是报告显示为两个独立的处理器.
一个线程要么就是获得时间额度或已抢先获得一些具有较高优先级(比如硬件中断),其中较高优先级的线程将从区域重新放置回处理器的队列中.这种线程的转换关系就是我们提到的上下文切换.
每次内核的上下文切换,资源被用于关闭在CPU寄存器中的线程和放置在队列中.系统中越多的上下文切换,在处理器的调度管理下,内核将得到更多的工作.
运行队列
每个CPU 都维护一个线程的运行队列
CPU 利用率
User Time(译注:用户进程时间)
System Time(译注:内核线程以及中断时间)
Wait IO(译注:IO 请求等待时间)
Idle(译注:空闲)
每次内核的上下文切换,资源被用于关闭在CPU寄存器中的线程和放置在队列中.系统中越多的上下文切换,在处理器的调度管理下,内核将得到更多的工作.
运行队列
每个CPU 都维护一个线程的运行队列
CPU 利用率
User Time(译注:用户进程时间)
System Time(译注:内核线程以及中断时间)
Wait IO(译注:IO 请求等待时间)
Idle(译注:空闲)
CPU 性能监控
Run Queues - 每个处理器应该运行队列不超过1-3个线程.
Run Queues - 每个处理器应该运行队列不超过1-3个线程.例子,一个双核处理器应该运行队列不要超过6 个线程。
CPU Utiliation - 如果一个CPU 被充分使用,利用率分类之间均衡的比例应该是:
65% - 70% User Time
30% - 35% System Time
0% - 5% Idle Time
Context Switches - 上下文切换的数目直接关系到CPU 的使用率,如果CPU 利用率保持在上述均衡状态时,大量的上下文切换是正常的.
Run Queues - 每个处理器应该运行队列不超过1-3个线程.
Run Queues - 每个处理器应该运行队列不超过1-3个线程.例子,一个双核处理器应该运行队列不要超过6 个线程。
CPU Utiliation - 如果一个CPU 被充分使用,利用率分类之间均衡的比例应该是:
65% - 70% User Time
30% - 35% System Time
0% - 5% Idle Time
Context Switches - 上下文切换的数目直接关系到CPU 的使用率,如果CPU 利用率保持在上述均衡状态时,大量的上下文切换是正常的.
vmstat 工具的使用
vmstat 运行1秒间隔的示例:
# vmstat 1
procs ———–memory———- —swap– —–io—- –system– —-cpu—-
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 104300 16800 95328 72200 0 0 5 26 7 14 4 1 95 0
0 0 104300 16800 95328 72200 0 0 0 24 1021 64 1 1 98 0
0 0 104300 16800 95328 72200 0 0 0 0 1009 59 1 1 98 0
vmstat 运行1秒间隔的示例:
# vmstat 1
procs ———–memory———- —swap– —–io—- –system– —-cpu—-
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 104300 16800 95328 72200 0 0 5 26 7 14 4 1 95 0
0 0 104300 16800 95328 72200 0 0 0 24 1021 64 1 1 98 0
0 0 104300 16800 95328 72200 0 0 0 0 1009 59 1 1 98 0
Field
|
Description
|
r
|
The amount of threads in the run queue. These are threads that are runnable, but the CPU is not available to execute them. 当前运行队列中线程的数目.代表线程处于可运行状态,但CPU 还未能执行.
|
b
|
This is the number of processes blocked and waiting on IO requests to finish. 当前进程阻塞并等待IO 请求完成的数目
|
in
|
This is the number of interrupts being processed. 当前中断被处理的数目
|
cs
|
This is the number of context switches currently happening on the system. 当前kernel system中,发生上下文切换的数目
|
us
|
This is the percentage of user CPU utilization. CPU 利用率的百分比
|
sys
|
This is the percentage of kernel and interrupts utilization. 内核和中断利用率的百分比
|
wa
|
This is the percentage of idle processor time due to the fact that ALL runnable threads are blocked waiting on IO. 所有可运行状态线程被阻塞在等待IO 请求的百分比
|
id
|
This is the percentage of time that the CPU is completely idle. CPU 空闲时间的百分比
|
mpstat 工具的使用
mpstat 命令给出的CPU 利用率统计值大致和 vmstat 一致,但是 mpstat 可以给出基于单个处理器的统计值.
# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006
mpstat 命令给出的CPU 利用率统计值大致和 vmstat 一致,但是 mpstat 可以给出基于单个处理器的统计值.
# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006
05:17:31 PM CPU %user %nice %system %idle intr/s
05:17:32 PM all 0.00 0.00 3.19 96.53 13.27
05:17:32 PM 0 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 1 1.12 0.00 12.73 86.15 13.27
05:17:32 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 3 0.00 0.00 0.00 100.00 0.00
第 3 章 内存篇
Virtual Memory Pages 在X86架构中,每个虚拟内存页为 4KB。
内存分页是指内核会定期将内存中的数据同步到硬盘,这个过程就是Memory Paging。
PFRA 就是OS 内核用来回收并释放内存空间的算法.PFRA 选择哪个内存页被释放是基于内存页类型的.页类型有以下几种:
Unreclaimable –锁定的,内核保留的页面
Swappable –匿名的内存页
Syncable –通过硬盘文件备份的内存页
Discardable –静态页和被丢弃的页
除了第一种(Unreclaimable)之外其余的都可以被PFRA进行回收.
05:17:32 PM all 0.00 0.00 3.19 96.53 13.27
05:17:32 PM 0 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 1 1.12 0.00 12.73 86.15 13.27
05:17:32 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 3 0.00 0.00 0.00 100.00 0.00
第 3 章 内存篇
Virtual Memory Pages 在X86架构中,每个虚拟内存页为 4KB。
内存分页是指内核会定期将内存中的数据同步到硬盘,这个过程就是Memory Paging。
PFRA 就是OS 内核用来回收并释放内存空间的算法.PFRA 选择哪个内存页被释放是基于内存页类型的.页类型有以下几种:
Unreclaimable –锁定的,内核保留的页面
Swappable –匿名的内存页
Syncable –通过硬盘文件备份的内存页
Discardable –静态页和被丢弃的页
除了第一种(Unreclaimable)之外其余的都可以被PFRA进行回收.
kswapd
kswapd 进程负责确保内存空间总是在被释放中.它监控内核中的pages_high和pages_low阀值.如果空闲内存的数值低于 pages_low,则每次 kswapd 进程启动扫描并尝试释放32个free pages.并一直重复这个过程,直到空闲内存的数值高于 pages_high.
kswapd 进程负责确保内存空间总是在被释放中.它监控内核中的pages_high和pages_low阀值.如果空闲内存的数值低于 pages_low,则每次 kswapd 进程启动扫描并尝试释放32个free pages.并一直重复这个过程,直到空闲内存的数值高于 pages_high.
kswapd 进程完成以下几个操作:
如果该页处于未修改状态,则将该页放置回空闲列表中。
如果该页处于已修改状态并可备份回文件系统,则将页内容写入到磁盘。
如果该页处于已修改状态但没有任何磁盘备份,则将页内容写入到swap device。
第 4 章 IO篇
磁盘I/O 子系统是Linux 系统中最慢的部分
Linux 内核就是要最低程度的降低I/O 数.
# /usr/bin/time -v date
如果该页处于未修改状态,则将该页放置回空闲列表中。
如果该页处于已修改状态并可备份回文件系统,则将页内容写入到磁盘。
如果该页处于已修改状态但没有任何磁盘备份,则将页内容写入到swap device。
第 4 章 IO篇
磁盘I/O 子系统是Linux 系统中最慢的部分
Linux 内核就是要最低程度的降低I/O 数.
# /usr/bin/time -v date
Linux,类似多数的UNIX 系统,使用一个虚拟内存层来映射硬件地址空间.当一个进程被启动,内核先扫描CPU caches和物理内存.如果进程需要的数据在这2个地方都没找到,就需要从磁盘上读取,此时内核过程就是major page fault(MPF).MPF 要求磁盘子系统检索页并缓存进RAM.
一旦内存页被映射进内存的buffer cache(buff)中,内核将尝试从内存中读取或写入,此时内核过程就是minor page fault(MnPF).与在磁盘上操作相比,MnPF 通过反复使用内存中的内存页就大大的缩短了内核时间.
一旦内存页被映射进内存的buffer cache(buff)中,内核将尝试从内存中读取或写入,此时内核过程就是minor page fault(MnPF).与在磁盘上操作相比,MnPF 通过反复使用内存中的内存页就大大的缩短了内核时间.
在Linux 内核中,memory pages有3种,分别是:
1,Read Pages - 这些页通过MPF 从磁盘中读入,而且是只读.这些页存在于Buffer Cache中以及包括不能够修改的静态文件,二进制文件,还有库文件.当内核需要它们时,将读取到内存中.如果内存不足,内核将释放它们回空闲列表中.程序再次请求时,则通过MPF 再次读回内存.
2,Dirty Pages - 这些页是内核在内存中已经被修改过的数据页.当这些页需要同步回磁盘上,由pdflush 负责写回磁盘.如果内存不足,kswapd (与pdflush 一起)将这些页写回到磁盘上并释放更多的内存.
3,Anonymous Pages - 这些页属于某个进程,但是没有任何磁盘文件和它们有关.他们不能和同步回磁盘.如果内存不足,kswapd 将他们写入swap 分区上并释放更多的内存(”swapping” pages).
1,Read Pages - 这些页通过MPF 从磁盘中读入,而且是只读.这些页存在于Buffer Cache中以及包括不能够修改的静态文件,二进制文件,还有库文件.当内核需要它们时,将读取到内存中.如果内存不足,内核将释放它们回空闲列表中.程序再次请求时,则通过MPF 再次读回内存.
2,Dirty Pages - 这些页是内核在内存中已经被修改过的数据页.当这些页需要同步回磁盘上,由pdflush 负责写回磁盘.如果内存不足,kswapd (与pdflush 一起)将这些页写回到磁盘上并释放更多的内存.
3,Anonymous Pages - 这些页属于某个进程,但是没有任何磁盘文件和它们有关.他们不能和同步回磁盘.如果内存不足,kswapd 将他们写入swap 分区上并释放更多的内存(”swapping” pages).
监控 I/O
每个I/O 请求到磁盘都需要若干时间.主要是因为磁盘的盘边必须旋转,机头必须寻道.磁盘的旋转常常被称为”rotational delay”(RD),机头的移动称为”disk seek”(DS).一个I/O 请求所需的时间计算就是DS加上RD.磁盘的RD 基于设备自身RPM 单位值(译注:RPM 是Revolutions Perminute的缩写,是转/每分钟,代表了硬盘的转速).一个RD 就是一个盘片旋转的半圆.如何计算一个10K RPM设备的RD 值呢:
10000 RPM / 60 seconds (10000/60 = 166 RPS)
转换为 166分之1 的值(1/166 = 0.006 seconds/Rotation)
单位转换为毫秒(6 MS/Rotation)
旋转半圆的时间(6/2 = 3MS) 也就是 RD
加上平均3 MS 的寻道时间 (3MS + 3MS = 6MS)
加上2MS 的延迟(6MS + 2MS = 8MS)
1000 MS / 8 MS (1000/8 = 125 IOPS)
每次应用程序产生一个I/O,在10K RPM磁盘上都要花费平均 8MS.在这个固定时间里,磁盘将尽可能且有效率在进行读写磁盘.IOPS 可以计算出大致的I/O 请求数,10K RPM 磁盘有能力提供120-150 次IOPS.评估IOPS 的效能,可用每秒读写I/O 字节数除以每秒读写IOPS 数得出.
结论
当CPU 有等待I/O 情况时,那说明磁盘处于超负荷状态.
计算你的磁盘能够承受多大的IOPS 数.
确定你的应用是属于随机或者顺序读取磁盘.
监控磁盘慢需要比较wait time(await) 和 service time(svctm).
监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.
每个I/O 请求到磁盘都需要若干时间.主要是因为磁盘的盘边必须旋转,机头必须寻道.磁盘的旋转常常被称为”rotational delay”(RD),机头的移动称为”disk seek”(DS).一个I/O 请求所需的时间计算就是DS加上RD.磁盘的RD 基于设备自身RPM 单位值(译注:RPM 是Revolutions Perminute的缩写,是转/每分钟,代表了硬盘的转速).一个RD 就是一个盘片旋转的半圆.如何计算一个10K RPM设备的RD 值呢:
10000 RPM / 60 seconds (10000/60 = 166 RPS)
转换为 166分之1 的值(1/166 = 0.006 seconds/Rotation)
单位转换为毫秒(6 MS/Rotation)
旋转半圆的时间(6/2 = 3MS) 也就是 RD
加上平均3 MS 的寻道时间 (3MS + 3MS = 6MS)
加上2MS 的延迟(6MS + 2MS = 8MS)
1000 MS / 8 MS (1000/8 = 125 IOPS)
每次应用程序产生一个I/O,在10K RPM磁盘上都要花费平均 8MS.在这个固定时间里,磁盘将尽可能且有效率在进行读写磁盘.IOPS 可以计算出大致的I/O 请求数,10K RPM 磁盘有能力提供120-150 次IOPS.评估IOPS 的效能,可用每秒读写I/O 字节数除以每秒读写IOPS 数得出.
结论
当CPU 有等待I/O 情况时,那说明磁盘处于超负荷状态.
计算你的磁盘能够承受多大的IOPS 数.
确定你的应用是属于随机或者顺序读取磁盘.
监控磁盘慢需要比较wait time(await) 和 service time(svctm).
监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.
第 5 章 网络(Network)篇
iptraf 工具( http://iptraf.seul.org),提供了每个网卡吞吐量的仪表盘.
#iptraf -d eth0
图 5.1. Monitoring for Network Throughput
iptraf 工具( http://iptraf.seul.org),提供了每个网卡吞吐量的仪表盘.
#iptraf -d eth0
图 5.1. Monitoring for Network Throughput
案例学习 - 性能监控之循序渐进
# vmstat 1 10
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 249844 19144 18532 1221212 0 0 7 3 22 17 25 8 17 18
0 1 249844 17828 18528 1222696 0 0 40448 8 1384 1138 13 7 65 14
0 1 249844 18004 18528 1222756 0 0 13568 4 623 534 3 4 56 37
2 0 249844 17840 18528 1223200 0 0 35200 0 1285 1017 17 7 56 20
分析:
不会是内存不足导致,因为swapping 始终没变化(si 和 so).尽管空闲内存不多(free),但swpd 也没有变化.
CPU 方面也没有太大问题,尽管有一些运行队列(procs r),但处理器还始终有50% 多的idle(CPU id).
有太多的上下文切换(cs)以及disk block从RAM中被读入(bo).
CPU 还有平均20% 的I/O 等待情况.
从以上总结出,这是一个I/O 瓶颈.
# vmstat 1 10
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 249844 19144 18532 1221212 0 0 7 3 22 17 25 8 17 18
0 1 249844 17828 18528 1222696 0 0 40448 8 1384 1138 13 7 65 14
0 1 249844 18004 18528 1222756 0 0 13568 4 623 534 3 4 56 37
2 0 249844 17840 18528 1223200 0 0 35200 0 1285 1017 17 7 56 20
分析:
不会是内存不足导致,因为swapping 始终没变化(si 和 so).尽管空闲内存不多(free),但swpd 也没有变化.
CPU 方面也没有太大问题,尽管有一些运行队列(procs r),但处理器还始终有50% 多的idle(CPU id).
有太多的上下文切换(cs)以及disk block从RAM中被读入(bo).
CPU 还有平均20% 的I/O 等待情况.
从以上总结出,这是一个I/O 瓶颈.
# iostat -x 1
Linux 2.4.21-40.ELsmp (mail.example.com) 03/26/2007
avg-cpu: %user %nice %sys %idle
avg-cpu: %user %nice %sys %idle
30.00 0.00 9.33 60.67
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 7929.01 30.34 1180.91 14.23 7929.01 357.84 3964.50 178.92 6.93 0.39 0.03 0.06 6.69
/dev/sda1 2.67 5.46 0.40 1.76 24.62 57.77 12.31 28.88 38.11 0.06 2.78 1.77 0.38
/dev/sda2 0.00 0.30 0.07 0.02 0.57 2.57 0.29 1.28 32.86 0.00 3.81 2.64 0.03
/dev/sda3 7929.01 24.58 1180.44 12.45 7929.01 297.50 3964.50 148.75 6.90 0.32 0.03 0.06 6.68
分析:
看上去只有/dev/sda3 分区很活跃,其他分区都很空闲.
差不多有1200 读IOPS,磁盘本身是支持200 IOPS左右(译注:参考之前的IOPS 计算公式).
有超过2秒,实际上没有一个读磁盘(rkb/s).这和在vmstat 看到有大量I/O wait是有关系的.
大量的read IOPS(r/s)和在vmstat 中大量的上下文是匹配的.这说明很多读操作都是失败的.
结论:
从以上总结出,部分应用程序带来的读请求,已经超出了I/O 子系统可处理的范围.
使用top 来查找系统最活跃的应用程序
# top -d 1
11:46:11 up 3 days, 19:13, 1 user, load average: 1.72, 1.87, 1.80
176 processes: 174 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 12.8% 0.0% 4.6% 0.2% 0.2% 18.7% 63.2%
cpu00 23.3% 0.0% 7.7% 0.0% 0.0% 36.8% 32.0%
cpu01 28.4% 0.0% 10.7% 0.0% 0.0% 38.2% 22.5%
cpu02 0.0% 0.0% 0.0% 0.9% 0.9% 0.0% 98.0%
cpu03 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0%
Mem: 2055244k av, 2032692k used, 22552k free, 0k shrd, 18256k buff
1216212k actv, 513216k in_d, 25520k in_c
Swap: 4192956k av, 249844k used, 3943112k free 1218304k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14939 mysql 25 0 379M 224M 1117 R 38.2 25.7% 15:17.78 mysqld
4023 root 15 0 2120 972 784 R 2.0 0.3 0:00.06 top
1 root 15 0 2008 688 592 S 0.0 0.2 0:01.30 init
2 root 34 19 0 0 0 S 0.0 0.0 0:22.59 ksoftirqd/0
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.05 events/0
14939 mysql 25 0 379M 224M 1117 R 38.2 25.7% 15:17.78 mysqld
4023 root 15 0 2120 972 784 R 2.0 0.3 0:00.06 top
1 root 15 0 2008 688 592 S 0.0 0.2 0:01.30 init
2 root 34 19 0 0 0 S 0.0 0.0 0:22.59 ksoftirqd/0
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.05 events/0
从以上总结出,似乎就只有mysql 进程在请求资源,因此可以推论它就是导致问题的关键.
现在已经确定是mysql 在发出读请求,使用strace 来检查它在读请求什么.
# strace -p 14939
现在已经确定是mysql 在发出读请求,使用strace 来检查它在读请求什么.
# strace -p 14939
Process 14939 attached - interrupt to quit
read(29, “\3\1\237\1\366\337\1\222%\4\2\0\0\0\0\0012P/d”, 20) = 20
read(29, “ata1/strongmail/log/strongmail-d”…, 399) = 399
_llseek(29, 2877621036, [2877621036], SEEK_SET) = 0
read(29, “\1\1\241\366\337\1\223%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 400) = 400
从以上总结出,所有的读IOPS 都是mysql 进程在执行某些读查询时产生的.
使用mysqladmin 命令,来查找是哪个慢查询导致的.
# ./mysqladmin -pstrongmail processlist
read(29, “\3\1\237\1\366\337\1\222%\4\2\0\0\0\0\0012P/d”, 20) = 20
read(29, “ata1/strongmail/log/strongmail-d”…, 399) = 399
_llseek(29, 2877621036, [2877621036], SEEK_SET) = 0
read(29, “\1\1\241\366\337\1\223%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 400) = 400
从以上总结出,所有的读IOPS 都是mysql 进程在执行某些读查询时产生的.
使用mysqladmin 命令,来查找是哪个慢查询导致的.
# ./mysqladmin -pstrongmail processlist
+—-+——+———–+————+———+——+———-+—————————————-
| Id | User | Host | db | Command | Time | State | Info
+—-+——+———–+————+———+——+———-+—————————————-
| 1 | root | localhost | strongmail | Sleep | 10 | |
| 2 | root | localhost | strongmail | Sleep | 8 | |
| 3 | root | localhost | root | Query | 94 | Updating | update `failures` set
`update_datasource`=’Y’ where database_id=’32′ and update_datasource=’N’ and |
| 14 | root | localhost | | Query | 0 | | show processlist
分析:
MySQL 数据库里,似乎在不断的运行table update查询.
基于这个update 查询,数据库是对所有的table 进行索引.
结论:
从以上总结出,MySQL里这些update 查询问题,都是在尝试对所有table 进行索引.这些产生的读请求正是导致系统性能下降的原因.
| Id | User | Host | db | Command | Time | State | Info
+—-+——+———–+————+———+——+———-+—————————————-
| 1 | root | localhost | strongmail | Sleep | 10 | |
| 2 | root | localhost | strongmail | Sleep | 8 | |
| 3 | root | localhost | root | Query | 94 | Updating | update `failures` set
`update_datasource`=’Y’ where database_id=’32′ and update_datasource=’N’ and |
| 14 | root | localhost | | Query | 0 | | show processlist
分析:
MySQL 数据库里,似乎在不断的运行table update查询.
基于这个update 查询,数据库是对所有的table 进行索引.
结论:
从以上总结出,MySQL里这些update 查询问题,都是在尝试对所有table 进行索引.这些产生的读请求正是导致系统性能下降的原因.
转载于:https://blog.51cto.com/17610376/495836