本篇文章给大家谈谈服务器io高，以及io方式中使计算机工作程度最高对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。
一、磁盘io请求过高造成的io瓶颈怎么解决
具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的*能急速下降了。
为什么当磁盘IO成瓶颈之后,数据库的*能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的*能有非常明显的分界点，原因是什么？
相信大部分做数据库运维的朋友，都遇到这种情况。数据库在前一天*能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个最简单的insert操作，需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？
dba此时心中有无限的疑惑，到底是什么原因呢?磁盘IO*能变差了？还是业务运维人员反馈的流量压根就不对？还是数据库内部出问题？昨天不是还好好的吗？
当数据库出现响应时间不稳定的时候，我们在操作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO.数据库服务器如果存在大量的写IO,*能一般都是正常跟稳定的，但只要存在少量的读IO,则*能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于在线交易的数据库系统来说，大概*能就雪崩了。为什么操作系统上看到的磁盘读IO跟写IO所带来的*能差距这么大呢？
如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。
在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。
咱们先来提问题。buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。
提问.数据页不在buffer bool里面该怎么办？
回答：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool,图片中显示
buffer_read_page函数栈的顶层是pread64(),调用了操作系统的读函数。
buf_read_page的代码
如果去读文件，则需要等待物理读IO的完成，如果此时IO没有及时响应，则存在堵塞。这是一个同步读的操作，如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer中，无法使用该数据页，必须等待操作系统完成IO.
再接着上面的回答提问：
当第二会话线程执行sql的时候，也需要去访问相同的数据页，它是等待上面的线程将这个数据页读入到缓存中，还是自己再发起一个读磁盘的然后加载到buffer的请求呢？代码告诉我们，是前者，等待第一个请求该数据页的线程读入buffer pool。
试想一下，如果第一个请求该数据页的线程因为磁盘IO瓶颈，迟迟没有将物理数据页读入buffer pool,这个时间区间拖得越长，则造成等待该数据块的用户线程就越多。对高并发的系统来说，将造成大量的等待。等待数据页读入的函数是buf_wait_for_read，下面是该函数相关的栈。
通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。
再继续扩展问题：如果会话线程A经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致*。
由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。
再回头来看上面的问题，mysql数据库出现*能下降时，可以看到操作系统有读IO。原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写操作是不堵塞执行sql的会话线程的。所以，即使看到操作系统上有大量的写IO，数据库的*能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size,基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在操作系统上基本看不到读的IO。当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool,则数据库的*能则开始下降，当出现大量的读IO，数据库的*能会非常差。
二、io方式中使计算机工作程度最高
异步IO方式使计算机工作程度最高。
异步IO方式是一种高效的输入/输出处理方式，它能够使计算机在处理输入/输出操作时达到最高的工作程度。在这种方式下，计算机可以同时进行多个操作，而不是在等待一个操作完成后才开始下一个操作。这样可以充分利用计算机的多核处理器和高速存储设备，提高计算机的吞吐量和响应速度。
首先，异步IO方式采用事件驱动的方式处理输入/输出操作。当一个操作完成时，计算机会触发一个事件，通知相关程序进行下一步处理。这样，程序可以在等待操作完成的同时执行其他任务，而不是被阻塞在那里。这种事件驱动的方式可以有效地隐藏输入/输出延迟，提高程序的并发*和响应速度。
其次，异步IO方式支持并发处理多个操作。在传统的同步IO方式下，计算机需要等待一个操作完成后才能开始下一个操作。而在异步IO方式下，计算机可以同时启动多个操作，并在它们完成后触发相应的事件。这样，即使有大量的输入/输出操作需要处理，计算机也能够高效地处理它们，而不会出现资源闲置的情况。
例如，在一个Web服务器中，当有多个客户端同时发起请求时，服务器可以使用异步IO方式来处理这些请求。服务器可以同时接收这些请求，并将它们放入一个事件队列中。然后，服务器可以继续处理其他任务，而不是被阻塞在等待请求完成的过程中。当其中一个请求完成时，服务器会触发一个事件，通知相应的处理程序进行处理。这样，服务器可以高效地处理大量的并发请求，提高吞吐量和响应速度。
三、高io适合什么场景
高IO型实例：适用于对磁盘读写和时延要求高的 I/O密集型应用场景，如云数据库 MongoDB、群集化数据库等。
选择合适的配置很重要，配置低了带不动业务会造成客户损失，配置选得太高服务器贵造成*能浪费，对自身需求清晰、选择适合自己的配置才是最优解。
入门配置：适用于起步阶段的个人网站。如：个人*客等小型网站。
基础配置：适合有一定访问量的网站或应用。如：较大型企业官网、小型电商网站。
普及配置：适合常使用云计算等一定计算量的需求。如：门户网站、SaaS软件、小型 App。
专业配置：适用于并发要求较高的应用及适合对云服务器网络及计算*能有一定要求的应用场景。如：大型门户、电商网站、游戏 App。
个人网站之类的需求 1核1G– 1核2G这个范围就够用了，企业级还需按场景细分服务器实例类型。
具体场景实例类型选择:
需求场景很多，每个业务的侧重点不一样，所以云服务器也衍生出很多变型。目前市场上各个厂商的实例类型多种多样，叫法可能不一样，但都大同小异。
四、MYSQL数据库服务器高iowait如何优化
一个数据库服务器高iowait的优化案例
1.开发反馈某一测试环境sql运行缓慢，而在其他测试环境该sql运行很快。两个环境其配置相同，均只部署了mysql服务器。
2.执行top命令发现sql运行缓慢的机器上磁盘iowait较sql运行较快的机器高出很多。推测这是导致sql运行缓慢的主因，因为该sql是要读取表，表较大，且要扫描的行数较多。
3.到底是什么导致机器iowait高呢，执行iotop发现消耗io的进程主要是mysql，而且主要是mysql上的读操作。
4.想必是有其他高频运行的查询语句不停从某大表中查询数据，且查询时可能使用不到索引，要扫描的表行数较多，从而导致高频io操作，致使其他需io操作的sql运行缓慢。
5.究竟是什么sql引起的呢？开启了general log，发现收集到的语句太多，且不能很好定位到高开销的sql。
6.开启slow log,long_query_time置为1，来捕获慢查询，同时使用pt-ioprofile用来追踪mysql数据文件中哪些文件上的io消耗比较多。
7.综合slow log(可使用pt-query-digest进行聚合)和pt-ioprofile的结果发现确实是两条典型的需要扫描全表的且对应的表非常大的sql频繁执行导致了磁盘的高io。
8.那么剩下的问题便是优化表或者查询了。最简单的是通过建合适的索引来提升查询*能，减少表扫描行数，需要继续榨取*能的话就是优化sql的写法，调整表结构，调整参数配置来解决了。
9.先从收益最大的方法入手，先评估sql语句，根据语句中的条件查看各个字段的数据分布情况，通过explain等评估在字段上创建索引或多列联合索引的合理*，并创建合适的索引。
10.最后发现建好索引后原来需要扫全表的语句通过索引可有效减少扫描行数，继而io操作减少了，服务器的iowait讲题，原来反馈的运行较慢的sql运行速度得以提升，但还是不够理想。
11.最后通过在该慢语句对应的表建索引，并修正where条件中使用错误的值类型极大的提升了sql语句运行速度，且服务器整体IO消耗大大降低。
12.可通过pt-query-digest聚合优化后mysql server产生的slow log以及使用pt-ioprofile分析优化后mysql数据文件io占用情况，可了解到优化前后的差异情况。