第九章 操作系统和硬件优化

• Mysql服务器性能受制于系统最薄弱的环节，磁盘大小，可用内存，cpu资源网络以及连接他们的组件，都会限制住Mysql的性能。
• mysql中一方面的缺陷常常会将压力施加在另一个系统之上。例如没有内存的时候，可能会刷出缓存来腾出空间，这时候会导致io过高，所以再发现问题的时候，要尽量注意深沉次的问题。
• 低延时收益于更快的cpu，高吞吐收益于更多的cpu。
• mysql还有很多后台工作，那些工作也能受益于多cpu。
• 备库更多需要io而不是cpu，因为主库备份到备库会使串行任务。
• cpu的电源管理技术会根据cpu的压力而动态的改变CPU的时钟速度，但是有突发的短查询，会有一段时间来决定cpu是否应该变化，从而导致查询变慢，性能波动。
• 配置大量内存的最大原因不是因为内存中可以保存大量的数据，而是为了减少io。
• 随机io从缓存中的收益更大。因为顺序io比随机io快，相比之下，随机读写来说，使用内存比使用io快得多。存储引擎中，一个随机读意味着存储引擎必须执行索引操作，通常从b树查找，而连续通常遍历一个简单的数据结构如链表。
• 如果有足够的内存，就可以完全的避免磁盘读取操作，但是写操作是必须的，但是可以延迟写操作，集中处理，减少io。如多次写入，一次刷新，io合并。这也是预写日志策略的原因，通过连续写来优化随机io。
• 工作集是程序真正使用的数据。MySQL中的工作集包括数据和索引，以缓存单位来计数，一个缓存单位是存储引擎工作的数据最小单位。
• Innodb在默认情况下是16kb，如果要缓存单行数据，事实上，他是缓存了存在该列的页，也就是缓存了16kb的数据。加上索引，可能达到32kb甚至更多。
• 增加内存并不能真正解决所有的问题，有时候需要加强io，比如存在大量写操作。

从传统磁盘读取数据的过程分为3步

1. 移动读取磁头到磁盘表面的正确位置上。
2. 等待磁盘旋转，所有所需的数据在读取磁头下。
3. 等待磁盘旋转过去，读取磁头读取所需数据。

顺序读主要集中在第3步，而随机读主要集中在1，2步。

• 固态存储虽然有更好的随机读写和顺序读写，也更加支持并发，但是也存在缺陷，需要经常GC而且写入前需要擦除操作还会磨损整个块（SLC技术100000个写周期存储小，MLC10000个写周期存储大）。
• 闪存一开始使用特别快，后面会因为垃圾回收而逐渐变慢，最后稳定下来。
• 像innodb日志文件这样的顺序写的工作负载，闪存不能提供多少成本和性能优势。
• 如果将mysql的磁盘换成固态，需要调整的配置有：

1. 增加io线程数，增加并发。
2. 加大日志。
3. 禁止预读。
4. 配置刷新算法。
5. 禁用双写，因为有些闪存设备支持原子写入。保证数据不会出错。

mysql创建了多种类型的文件：

1. 数据和索引文件。
2. 事务日志文件。
3. 二进制日志文件。
4. 常规日志。
5. 临时文件和临时表。

• 使用多个卷存放这些数据能帮助解决io负载高的问题。但是需要额外的磁盘，成本太高而效果一般。
• 二进制日志和数据文件分离的真正又是可以减少同时丢失数据和日志文件的可能性。
• 如果存储系统能保证足够安全，利用多磁盘建立一个RAID比使用多磁盘要好得多。
• 运行不正常的网络也是主要的性能瓶颈之一。
• 有用的服务器监控工具

1. vmstat 注意swap两列应该都是0，说明没有进行内存交换，cpu中的us是cpu使用率。system中的cs是上下文切换次数。不超过100000不担心。procs中的r代表多少进程在等cpu，b多少进程在等io。超过5个需要注意。
2. iostat 查看io
3. mpstat 查看cpu