参数优化,iostat详解

如何对一个生产系统进行性能的初步诊断，从OS层面进行IO、CPU、内存、网络IO进行初步诊断。
1.负载在哪个地方
2.瓶颈在哪个地方

---

iostat 1 -x

• %user：cpu给用户的实际工作时间，图中是16%。
• %system：系统层面高的话，一般都是I/O过高导致的。
• %iowait：系统瓶颈。43%的时间在等待，被浪费了。一般>25%就有问题了。
• %nice和%steal：一般都是0。nice是调整io后的
• %idle：空闲的时间。一般>25%就认为很好了。
• rrqm/s：每秒合并的读请求。此值大，说明系统里有严重的全表扫描。
• wrqm/s：每秒合并的写请求。此值大，说明系统出现严重的批量
• insert（因为有主键，所以insert的时候很可能由于主键的依次递增而批量insert。insert总是插入相邻的数据块）。
• r/s：每秒读的次数。
• w/s：每秒写的次数。 二者相加就是IOPS！
• rsec/s：每秒读的扇区数。
• wsec/s：每秒写的扇区数。二者相加就是吞吐量（每秒传输多少M）
• avgrg-sz：每秒请求扇区的大小。
• avgqu-sz：平均请求队列的长度。前边排队的请求个数（每次进来后要等待2.85个请求的时间）
• await：每一个IO请求的处理的平均时间（微秒、毫秒）[即IO的响应时间]。await=avgqu-sz * svctm
• svctm：平均每次实际的服务时间（毫秒）。
• %util：繁忙度。在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，所以该参数暗示了设备的繁忙程度。

此值高的话，先看IO，如果IO为0或者很低，就找存储工程师，他的硬盘出问题了。如果IO也很高，可能就是操作造成的IO很忙。

PS：avgrq-sz/avgqu-sz/2 –》每个请求扫描多少扇区（单位是KB，因为/2了）

---

os层面的问题：

• IO繁忙
• 写繁忙：svctm
  
  • ①降低IO：日志写、page写
  • ②提升io性能（主要是写功能）（闪卡、raid卡）
• 与写功能相关的状态值
  
  • status
  • write
  • log（redo log、binlog）
  • flush
  • fsync
  • 【监控项：flush、write、fsync（绕过系统缓存，直接fsyncs）、innodb_flush_log_at_trx_commit（0,1,2）】
• 变量variables
  
  • 事务提交相关
  • binlog相关
• redo log size、redo log buffer
• 脏数据大小、比例
  
  • innodb_max_dirty_pages_pct=75

---

优化的分类：

• ①参数优化
• ②索引优化
• ③SQL优化
• ④分库分表分区优化

---

参数优化

• 1.从OS层面查看系统目前的负载点和性能瓶颈。
  
  • 负载点主要在写上。
  • 性能的瓶颈点，也主要在写上。
• 2.从数据库层面分析一下，负载点主要在数据库的哪些组件上。
  
  • show global status，查询 GLOBAL_STATUS表
• 3.调整哪些参数可以提升对应的性能。
• 4.调整参数，压力测试，看一下效果。

=====步骤
1.tpcc压力测试的同时iostat 1 -x。发现，读少，写多。系统的写压力很大。
2.mysql层面监控一下，这些写压力都来自于哪些组件。（日志写，page写）