（从底层到上层的优化）
一、存储层的优化：
使用RAID 1+0，不使用RAID 5/或RAID 6
raid磁盘使用介意8块盘为一组lun。
切忌跑数据库服务器禁用liunx的软lvm。（严重影响性能）
阵列卡配备CACHE及BBU模块，作为写CACHE的基础支撑
注意：BBU：是阵列卡cache的供电模块，里面是多个电池组成的电池组。
设置写策略为WB，或者FORCE WB，千万别用WT策略
1、wb = write back：
从os提交io写请求到磁盘里，首先会传到阵列卡里，阵列卡会先把io写请求放到cache里，然后在从cache里异步的写入磁盘里。
注意：os认为io提交完成了，其实数据并没有完全写盘，而是在cache中，如果BBU电量低于百分之15，则会切换wt模式，此时io压力负载会相当的高。
2、FORCE WB：不论电量多少，都强制写到cache里面。
注意：如果阵列卡的BBU模块损坏或者没电，写入策略又设置成force WB，那os发送io写请求，还会写入cache里。此时如果机器停电，阵列卡cache里的数据则会丢失。
3、wt = write through ：不写cache 直接写磁盘。
关闭预读，没必要预读，那点宝贵的CACHE用来做写缓存（强烈推荐）
关闭物理磁盘cache策略，防止丢数据
注意：服务器断电时，由于阵列卡的cache有BBU模块供电，能够将cache里的数据写入到磁盘，但是磁盘的cache没有供电机制，一旦停电，磁盘cache里的数据会丢失。
使用高转速硬盘，不使用低转速盘
或者使用SSD及PCIe-SSD盘
基于SSD设备调整系统内核参数：
通过调整 /sys/block/sdx/queue/read_ahead_kb 来控制系统内核中预读策略的大小为16KB（具体多少要看平均每次IO读大小，16kb是经验值），通过适当预读提高整体性能。
注意：把预读出来的块放到内存里面，这样可以有效提高，顺序IO读的效率，视情况而定。
大量的IO请求数必定会产生庞大数量的中断请求，因此需要在每个核上绑定不同的中断号策略，避免单歌核心的cpu负载过高。
中断:内核跟io打交道的时候，是通过驱动连接，因此再跟驱动交互的时候就会产生中断问题（因为cpu和内存比磁盘的速度要快）
======================================================
二、BIOS的优化：
System Profile（系统配置）选择Performance Per Watt Optimized(DAPC)，发挥最大功耗性能，而不是节能模式（高运算节点禁用）。
注意：在节能模式下，服务器低频性能转高频性能时，容易出现bug，导致服务器功耗发挥不起来。
Memory Frequency（内存频率）选择Maximum Performance（最佳性能）
C1E，允许您在处理器处于闲置状态时启用或禁用处理器切换至最低性能状态，建议关闭（默认启用）
C States（C状态），允许您启用或禁用处理器在所有可用电源状态下运行，建议关闭（默认启用）
CPU优先选择主频高（运算能力），其次选择核数多的（可以多线程并发处理，使用多实例）。
注意：由于mysql是单进程，多线程的工作模式，所以更多的是依赖于高主频的cpu，如果是多实例，可以选择核心多的，来提高运算性能
如果有硬盘大于2T，选择UEFI（新版BIOS），不使用老版本BIOS。
用更多内存来消除IO瓶颈的影响（多实例时，需要更多内存）。
注意：磁盘的运算速度肯定不如内存或者cpu的处理速度快，即便是SSD或者PCIE-SSD。所以需要更多的内存来支撑，缓解过多的iops。
======================================================
三、操作系统的优化：（/proc/sys/vm/）
vm.swappiness
减少使用swap的概率，vm.swappiness设置为0表示尽量少swap，100表示尽量将不活跃（inactive）的内存页交换出去。
注意：
RHEL 7以下，推荐设置为0，RHEL 7以上谨慎设置不高于5 ~ 10，减少使用swap的概率
RHEL 7以下，如果设置为0，有可能会导致OOM发生，要慎重。
千万不要跟vm.hugepages这个参数一起使用，否则很容易导致oom或者其他的坑。切忌！（有待测试)
vm.dirty_ratio = 5或者10 （经验值）
注释：规定百分比值。当脏数据组成达到系统内存总数的这个百分比值后开始写下脏数据（pdflush），默认值为20。
不高于30，一定要比dirty_background_ratio大，避免I/O子系统hang住
vm.dirty_background_ratio = 5或者10 （经验值）
注释：规定百分比值。当脏数据组成达到系统内存总数的这个百分比值后开始在后端写下脏数据（pdflush），默认值为10。如果超过10%，就会把所有IO阻塞住，直接进行刷盘操作。此时会产生大量的io阻塞。
vm.overcommit_memory = 1
注释：
规定决定是否接受超大内存请求的条件。这个参数有三个可能的值：
0 — 默认设置。内核执行启发式内存过量使用处理，方法是估算可用内存量，并拒绝明显无效
的请求。遗憾的是因为内存是使用启发式而非准确算法计算进行部署，这个设置有时可能会造
成系统中的可用内存超载。
1 — 内核执行无内存过量使用处理。使用这个设置会增大内存超载的可能性，但也可以增强大
量使用内存任务的性能。
2 — 内存拒绝等于或者大于总可用 swap 大小以及 overcommit_ratio 指定的物理 RAM 比例
的内存请求。如果您希望减小内存过度使用的风险，这个设置就是最好的。
io scheduler（优先使用deadline，如果是SSD，则使用noop）
提高调度器请求队列：echo 4096 > /sys/block/sdX/queue/nr_requests
注意：当有大量度请求的时候，系统的请求队列值会过高，这时候需要提高请求队列值。有点类似mysql中的back_log或者thread_cache_size参数，都是把队列池加大一点，让一部分队列先放进来，而不是让他们在外面一直的等待，队列进来后做快速请求，等请求完后在把这个队列快速处理掉。
调整文件系统时：首选xfs，其次是ext4
注意：XFS相比ext3和ext4在高io负载下提高IOPS能力表现更佳。在普通负载时这两个文件系统可能会相当，甚至可能会弱点。
mount参数：noatime, nodiratime, nobarrier
注意：
noatime, nodiratime：不记录文件/目录的最后访问时间（基本没有意义，无用）
nobarrier：现在的很多文件系统会在数据提交时强制底层设备刷新cache，避免数据丢失，称之为write barriers。
但是，其实我们数据库服务器底层存储设备要么采用RAID卡，RAID卡本身的电池可以掉电保护；要么采用Flash卡，它也有自我保护机制，保证数据不会丢失。所以我们可以安全的使用nobarrier挂载文件系统。
本文转自 emma_cql 51CTO博客，原文链接:http://blog.51cto.com/chenql/1958938
