时间:2021-07-01 10:21:17 帮助过:6人阅读
- <code>优化不总是对一个单纯的环境进行!还很可能是一个复杂的已投产的系统。
- 优化手段本来就有很大的风险,只不过你没能力意识到和预见到!
- 任何的技术可以解决一个问题,但必然存在带来一个问题的风险!
- 对于优化来说解决问题而带来的问题控制在可接受的范围内才是有成果。
- 保持现状或出现更差的情况都是失败!
- 稳定性和业务可持续性通常比性能更重要!
- 优化不可避免涉及到变更,变更就有风险!
- 优化使性能变好,维持和变差是等概率事件!
- 优化不能只是数据库管理员担当风险,但会所有的人分享优化成果!
- 所以优化工作是由业务需要驱使的!!!</code>
- <code>安全优化(业务持续性)
- 性能优化(业务高效性)</code>
- <code>优化范围:
- 存储、主机和操作系统:
- 主机架构稳定性
- I/O规划及配置
- Swap
- OS内核参数
- 网络问题
- 应用程序:(Index,lock,session)
- 应用程序稳定性和性能
- SQL语句性能
- 串行访问资源
- 性能欠佳会话管理
- 数据库优化:(内存、数据库设计、参数)
- 内存
- 数据库结构(物理&逻辑)
- 实例配置</code>
- <code># Linux 7操作系统
- # 内存使用达到100%-30%(70%)时候,才会时候swap
- cat /proc/sys/vm/swappiness
- 30
- # 修改不使用 swap
- echo 0 >/proc/sys/vm/swappiness 的内容改成0(临时)
- vi /etc/sysctl.conf
- # 添加:
- vm.swappiness=0
- # 使配置生效
- sysctl -p
- 这个参数决定了Linux是倾向于使用swap,还是倾向于释放文件系统cache。在内存紧张的情况下,数值越低越倾向于释放文件系统cache。
- 当然,这个参数只能减少使用swap的概率,并不能避免Linux使用swap。
- 修改MySQL的配置参数innodb_flush_method,开启O_DIRECT模式
- 这种情况下,InnoDB的buffer pool会直接绕过文件系统cache来访问磁盘,但是redo log依旧会使用文件系统cache。
- 值得注意的是,Redo log是覆写模式的,即使使用了文件系统的cache,也不会占用太多</code>
- <code>[root@localhost ~]# iostat -xz 1
- Linux 3.10.0-693.el7.x86_64 (localhost.localdomain) 08/29/2019 _x86_64_ (2 CPU)
- avg-cpu: %user %nice %system %iowait %steal %idle
- 0.02 0.00 0.05 0.00 0.11 99.81
- Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
- xvda 0.00 0.01 0.78 0.10 2.21 0.70 6.59 0.00 0.36 0.20 1.54 0.14 0.01
- dm-0 0.00 0.00 0.18 0.09 0.47 0.69 8.68 0.00 0.94 0.46 1.94 0.17 0.00
- dm-1 0.00 0.00 0.17 0.00 0.67 0.00 8.02 0.00 0.08 0.08 0.00 0.08 0.00
- # 现象说明
- 1. IO 高 cpu us 也高, 属于正常现象
- 2. CPU us高 IO很低, MySQL 不在做增删改查,有可能是存储过程,函数,排序,分组,多表连接
- 3. Wait,SYS 高, IO低: IO出问题了,锁等待过多的几率比较大.
- IOPS:每秒磁盘最多能够发生的IO次数,这是个定值。 频繁小事务,IOPS很高,达到阈值,可能IO吞吐量没超过IO最大吞吐量.无法新的IO了,存储规划有问题.</code>
MySQL 优化 (一)
标签:出现 code nic 技术 x86_64 图片 使用 mysql 优化 %s