深入了解服务器性能：如何进行io测试？ (服务器 io 测试)

深入了解服务器性能：如何进行IO测试？

随着业务需求不断增加，大型公司不得不依赖越来越多的服务器来支撑他们的运营。但是，这些服务器的硬件规格、性能和瓶颈是复杂的问题。IO测试是评估服务器性能和找到性能瓶颈的有力工具，是服务器调试和优化的核心步骤之一。

本文将深入探讨IO测试的各个方面、如何选择适当的工具以及如何解释测试结果，以帮助管理员更好地理解IO测试，并做出更准确的结论。

什么是IO测试？

IO测试可以测试服务器的存储(磁盘/闪存)系统性能。该测试旨在测量磁盘读取和写入操作的速度。随着服务器负载的增加，IO测试的重要性也越来越大。找到存储瓶颈并正确配置存储系统，可以大大提高服务器性能和可靠性。

常见的IO测试工具：

常见的IO测试工具是fio、IOzone、Bonnie++等。下面是一些IO测试工具的介绍和用途。

1. fio (Flexible I/O Tester)

fio是一个功能丰富的IO测试工具，可用于测试顺序、随机、混合的读写操作。它允许您指定测试参数，例如队列深度、块大小、更大IO深度、随机/顺序访问、工作负载方式等。fio的多种测试方法可适应各种I/O场景，包括块设备、网络存储等。

2. IOzone

IOzone是一个综合性的文件系统基准测试工具，包括随机访问、顺序访问、读取、写入等测试。它在不同工作负载下测试服务器的性能，并包括IPC测试、网络测试等。

3. Bonnie++

Bonnie++是另一个常用的文件系统性能测试工具。它可以进行各种IO测试，包括随机和顺序访问模式下的读写性能评估。 Bonnie++允许用户指定块大小、文件大小等参数，广泛应用于测试多种文件系统和存储设备。

选择合适的IO测试工具：

选择适合您环境的工具后，再考虑如何配置测试参数。此前，需要了解每个测试工具的优缺点，以便确定如何分配资源、如何分配测试负载、如何编写测试脚本以及如何分析测试结果。因此，在开始IO测试之前，您需要了解以下关键因素。

1.测试目的

需要考虑主要测试目的。例如，某些测试工具更适合测试磁盘并发性，而另一些更适合测试内存缓存。测试目的会影响IO测试的大部分方面，例如测试脚本的编写、测试过程中的资源分配和测试结果的分析方式。

2.测试负载和测试参数

各种工具使用不同的测试负载和测试参数，您需要了解测试工具的各种负载类型和测试参数，以便选择适合您需要的测试负载和测试参数。例如，您可能需要测试随机小块写入，同时需要测试顺序大块读取。在此情况下，fio可能比Bonnie++更适合您部署。

3.测试环境

测试工具的功能也受限于测试环境。例如，fio可以适应本地磁盘和网络存储的各种测试用例，但不支持云存储测试。同样地，IOzone可以在本地和网络存储上进行测试，但它的配置要求比fio更高。

解释测试结果

当您成功运行IO测试并获得结果后，接下来需要进行结果分析。与工具的选择和配置一样，分析测试结果是整个IO测试的关键部分。以下是一些解释测试结果的指南。

1.测试结果

IO测试结果通常包括IOPS、带宽、延迟和吞吐量等指标。了解每个指标的含义对于正确分析结果非常重要。例如，IOPS是每秒钟可以处理多少IO操作，延迟是等待IO操作被处理的时间。

2.瓶颈

测试结果还能指出服务器中的可能瓶颈。例如，IO测试结果可能显示磁盘IO花费了大量CPU时间，这表明CPU成为了性能瓶颈。

3.影响结果的因素

当测试结果出现问题时，需要排除可能影响测试结果的因素。例如，其他任务、I/O负载、内存使用情况等，这些因素会影响测试结果。确保您的测试环境在测试期间稳定，以获得可靠的测试结果。

结论

通过正确进行IO测试并研究测试结果，您可以更好地了解您的服务器的性能瓶颈和存储方案。通过选择适合您需求的工具、配置测试负载和测试参数，以及正确解释测试结果，您可以使您的服务器性能更佳、更高效地运行。

IO测试是一项重要的管理任务，可以评估服务器性能和找到性能瓶颈。虽然IO测试需要一些技术知识和测试工具的选择，但可以使管理员了解服务器存储性能以及找到性能瓶颈。通过进行正确的IO测试并分析测试结果，管理员可以更好地理解服务器性能，并做出更准确的结论。

相关问题拓展阅读：

• 如何对API进行负载测试与调优（一）
• 如何解决磁盘io造成的系统卡顿问题

如何对API进行负载测试与调优（一）

本文由Donny译自 3scale.com 的 《How to load test & tune performance on your API》

这几年API的作用不断演化，以前API还只是用来做内部系统之间的集成点，但现在API已成为一个公司的核心系统，一个构建于Web和移动端应用之上的核心系统。

当API仅只用来处理后台的任务（例如生成报告），那么性能差点也不是问题。但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。这种关键性的角色变化表明了一个重要的观点：那就是API的性能真的很重要。

如果API数据源响应快，前端的应用程序的设计好点或差点影响不大，要是响应慢如蜗牛，前端的设计再出色也是然并卵。现在我们的客户端应用展羡旅示的数据源可能都是来自多个API响应内容的聚合，性能对这种微服务构架来说真的非常重要。

可以毫不夸张的说出色的性能就是你API提供的更好功能。我们知道向目标改进的唯一正确的方法就是找到问题的关键点，或者叫关键路径，并不断迭代测量和调整你的架构系统，直到系统达到预定的目标。对于API来说，测量和提高性能的过程就是负载与压力测试的过程。

本文将重点介绍如何对你的API进行负载压力测试。我们会以一个简单的、未测过的例子开始，然后再添加一个访问控制层，要确保一切都经过严格测试，做好处理真实流量的准备工作。OK，开始吧！

首先我们要明确要测试什么，可以是对你所有的API接口，或者是对单个API接口，或是对需要排除故障或改进的API接口的常规测试。

本文的其部分，我们将使用一个示例API。这是一个棋牌类游戏的Node.js API。它有三个API接口：

/question – 返回一个随机黑牌

/answer – 返回一个随机白牌

/pick – 返回一对随机的问题与答案

你测试用的负荷情况越和真实环境的越类似，你的负载测试就越有用。如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致，那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。

所以，你应该先从收集你兄册凳API的使用数据开始。你可以直接从你的API服务日志或者从其他你在用的应用性能工具（例如New Relic）中获取数据。在对你的API进行之一次测试之前，你应该对以下问题做到心中有数：

（1）每秒请求数的平均吞吐量（Average throughput in requests per second）

（2）峰值吞吐量（您在某段时间内获得的更大流量是多少？）（Peak throughput）

（3）API各接口的吞吐量分布情况（有没有一些接口的流量远姿野超其他接口？）

（4）用户的吞吐量分布情况（少数用户产生大多数的流量，或者是更均匀分布？）

另外还需要考虑的一个关键点是，在测试期间将要模拟的流量会是怎样的，主要考虑点是：

（1）重复负载生成（Repetitive load generation）

（2）模拟流量模式

（3）真实流量

通常我们更好以最简单的方法开始测试，然后逐步演化到更为接近真实环境的测试。我们可以先用重复负载生成来做为API接口的之一个测试，这样不仅可以验证我们的测试环境是否稳定，更重要的是可以让我们找到API能承受的更大吞吐量，这样我们就可以知道API可以达到的性能上限是多少。

找到你的API性能上限值后，你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。使用真实流量来测试是最理想的，但实际操作不太可行。要模拟真实流量比较难，也太花时间。所以我们有一个折中点的方法：先研究你的流量分析数据，并做一个简单的概率模拟。比如你有100个API接口（提示：原文endpoint在这里我译为接口，翻译成端点也可以，不过译成接口感觉更容易理解），你检查了上个月的使用情况，发现80%的流量来自20个接口，其中3个接口占用了50%的流量。那么你就可以创建一个遵循这种概率的请求列表，并提供给你的负载测试工具。这样做就相对快多了，并且它相对比较接近你真实负载，可以显示出你实际环境中可能遇到的问题。

最后，如果你拿到你要测试的API的真实访问日志，你就可以用它们来做最接近客观现实的测试。我们待会儿要讨论的大部分负载测试工具，都是接收一个请求列表作为输入文件。你可以用你的访问日志，稍微做一个格式调整就可以匹配每个测试工具所需的格式。搞定这个你就可以在测试环境中轻松重现你的生产流量。

好了，你清楚了你要测试什么鬼了，准备工作的最后一步就是配置好你的测试环境。你需要一个专用的测试环境。如果你不怕被你老板骂的话，或者比较任性，你也可以直接在你的生产环境中进行性能测试，不过出问题别说哥事先没跟你说清楚哈。

如果您已经设好一个预生产或沙箱环境，并且你的API也在上面运行了，那么你就万事俱备了。因为本文要用示例API，我们会在AWS的服务实例上设置我们的环境。

在我们的例子中，我们使用一个简单的API，不需要从磁盘读取或在内存中保存大型数据集。我们选择Linux C4.large 实例就够了。

注意：我们对比过其他相似处理资源数但内存更大的AWS实例，但实际测试中内存大部分没使用，所以我们选了C4.large

接下来，我们将一个配好的负载测试实例（服务器）运行起来，这只是一个运行模拟测试程序的服务器，它会通过从多个并发连接重复发送请求到我们的API服务器。你需要模拟的负载越高，机器的性能就要求越高。再次，这也是一个CPU密集型工作负载。这里我们选择具有4个虚拟核，16个 ECU的优化处理器的 c4.xlarge AWS服务器

我们选择在相同的可用区内部署所有实例（API服务器与测试服务器在同一个区/机房），这样可以将外部因素对我们测试结果的影响降到最小。

我们有一个沙箱环境来运行我们的API，同时也有另一台服务器准备开始负载测试。如果这是你之一次做性能测试，你一定会想知道什么是更好的方法。在本节中，我们将会分享我们如何选择工具，同时也会介绍一下目前市面上一些公认比较好的工具。

JMeter

在人们意识当中，首当翘楚的估计是 Apache JMeter ，这是一个开源的Java程序，他关键的特性就是提供一个强大而完善的创建测试计划的GUI。测试计划由测试组件组成，测试组件定义了测试的每一个部分，例如：

（1）用来注入负载测试的线程

（2）参数化测试中使用的HTTP请求

（3）可添加侦听器，象widget测试组件那样，可以以不同的方式显示测主式结果

优点：

（1）它是功能性负载测试的更好工具。你可以设定条件来为复杂的用户流建模，还可以创建断言来验证行为。

（2）轻松模拟复杂的http请求，比如请求前的登录验证或文件上传

（3）可扩展性强，有很多社区插件可以修改或扩展内置的行为

（4）开源并且免费

缺点：

（1）GUI学习曲线陡峭，一大堆的选项，在你运行之一个测试之前你得了解大量的概念。

（2）测试高负载时，操作步骤很麻烦。你需要先使用GUI工具来生成XML测试计划，然后在非GUI模式下导入测试计划运行测试，因为GUI会消耗掉本用于生成负载的大量资源。你还需要注意所有的侦听器（收集数据与展示测量的组件）哪些要被禁用或启用，因为它们也很耗资源。测试结束后后，你需要将原始结果数据导入GUI以才能查看结果。

（3）如果你的目标是测试一段时间内的持续吞吐量（例如在60秒内每秒请求1000次），那么很难找到正确的并发线程数量和计时器来求出一个比较稳定的数值。

JMeter只是我们在开始测试时用的工具，我们很快开始寻找其他替代方案。原因是，如果你的目标是在Web应用上压力测试复杂的用户流，那么JMeter可能是更好的工具，但如果你只是需要在一些HTTP API接口上进行性能测试，那用它就是杀鸡用牛刀了。

Wrk

Wrk 是一款和传统的 Apache Benchmark （最初用来做Apache服务器的测试工具）非常相似的工具。wrk和ab完全不同于JMeter：

（1）一切都是可以通过命令行工具配置和执行的。

（2）配置少但强大，只有基本生成HTTP负载的必要几项配置

（3）性能强悍

然而，和传统ab工具相比还是有几个优势的地方，主要是：

（1）多线程，所以能利用多核处理器的优势，更容易生成更高的负载

（2）利用Lua脚本很容易进行扩展默认的行为

不好的地方，主要是生成的默认报告在内容与格式上都受到限制（仅文本，无绘图）。当你的目标是找到你的API可以处理的更大负载量，那么wrk是你更佳选择工具。wrk用起来很快就可以上手。

Vegeta

Vegeta 是一款开源命令行工具，但它采用的方式不同于我们以前所见的工具。它专注于如何达到与维持每秒请求数速率。也就是说它侧重在测试支撑每秒X次请求时API会有怎样的服务行为，当你有实际的数据或对你将要达到的峰值流量有个估算时就非常有用，你可以用于验证你的API是否能满足你的需求。

SaaS 工具

正如你之前所看到的，运行一个简单的负载测试需要准备好配置环境。最近有些产品提供负载测试服务。我们试过两个， Loader.io 和 Blazemeter （话外：阿里也有性能测试工具 PTS ，老外估计没试过）。

注意：我们只试了这两个工具的免费版，所以得到的测试结果仅适用于免费版的限定。

Blazemeter

这个产品和我们前面提到的JMeter一样有同样的毛病：如果你只需要用在高负载测试，你需要在GUI界面上创建测试计划，然后在另一个运行非GUI模式的JMeter中导入这些计划。Blazemeter允许你上传JMeter的测试计划到他们的云端并运行，但可惜的是免费版只能设置50个并发用户。

Loader.io

它是一款 SendGrid 出品的简单而强大的云负载测试服务工具。它有你所需要的功能和漂亮的可视报告。 Loader.io 的免费版还是不错的，每秒最多可以有10000次请求的吞吐量，你基本上就可以用它来运行一个真实的负载测试。

我们推荐使用多个工具，以便可以多重检查我们的测试结果，不同的工具有不同的功能与方法，可以更多方面地反映测试结果。

我们先尝试找到我们的API可以承受的更大吞吐量。在这个吞吐量下，我们的API服务达到更大CPU利用率，同时不会返回任何错误或超时。这个吞吐量就可作为我们后面测试要用的每秒请求数。

同样，重要的是要注意到：CPU是限制因素之一，但你也还必须清楚地知道哪些资源会成为你API的性能瓶颈。

我们有必要在API服务器上安装一些工具，以便我们在测试过程中监控资源的利用率情况。我们使用  Keymetrics.io  和  PM2  模块。

我们的Node.js应用运行了一个非常简单的HTTP 服务。Node.js是单线程设计的，但为了利用c4.large AWS实例中提供的双核，我们使用PM2的集群功能来运行应用程序的两个工作进程。

由于我们的API是完全无状态的，所以很容易使用PM2的 核心集群模块（PM2在内部直接使用）。PM2提供的集群功能提供了不错的快捷命令来start/stop/reload应用程序，也可以监控进程。

我们先使用Loader.io对API进行测试。以下是持续30秒，每秒10,000次请求的测试结果，10000次请求是Loader.io免费版中允许的更大吞吐量。

在测试期间，我们观察到API服务器的CPU处理器在测试期间只有几次达到100％的容量。

这表示我们的API可能还可以处理更高的吞吐量。我们接下来通过运行wrk进行第二次测试证实了这一点。我们的目标就是要将我们的API服务器性能推到极限。

wrk -t 4 -cd 60 –latency –timeout 3s

这里是我们对这个测试做了多次重复测试的结果：

Running 1m test @

4 threads and 1000 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 62.23ms 30.85ms 1.35s 99.39%

Req/Sec 4.07k 357.61 5.27k 94.29%

Latency Distribution

50% 60.04ms

75% 63.85ms

90% 64.17ms

99% 75.86ms

requests in 1.00m, 189.89MB read

Requests/sec: 16206.04

Transfer/sec: 3.16MB

结果表明，我们的预感被证实：它达到16,206请求/秒，同时保持合理的延迟，第99百分位只有75.86毫秒。 我们将这作为我们的基准更大吞吐量，因为这一次我们看到了API服务器的更大容量处理能力：

我们刚看到用一个简单的方式来找出你的API可承受的更大流量负载，同时在这过程中我们介绍并讨论了我们看到的一些工具。

请继续关注本文的第二部分，我们将介绍如何控制流量，不要让随随便便一个客户端就可以轻松搞跨您的API。 我们将展示如何通过在架构前端添加代理来确保我们的API的性能不受影响。

本文译自： How to load test & tune performance on your API

如何解决磁盘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，数据库的性能会非常差。

1，原因1：内存不够了:

排查：按下ctrl+alt+delete打开任务管理器查看下内存是不是快到百分之百了。

解决：①关闭几告毕个不用的程序

②增加物理内存，也就是买个更大的内存条

③增加虚拟内存（方法我的另一篇经验里面有介绍）

2，cpu使用率

排查：按下ctrl+alt+delete打开任务管理器查看下cpu使用率是不是快到百分之百了。

解决：①关困友明闭几个不用的程序

②更换个更nb的cpu，买个i3 i5 i7的cpu也不是很贵

③把电脑砸了，换个新的

3，硬盘读写

排查：下载个鲁大师之类的可以检查硬盘的软件查看下是不是硬盘有汪告很多的瑕疵，坏道等

解决：①尝试用硬盘修复软件修复一下试试

②换个新硬盘，推荐固态硬盘

③把电脑砸了，换个新的

4，硬件温度

排查：利用鲁大师，360管家，安全管家，金山毒霸之类的可以查看下硬件温度是不是过高解决：①关机冷却一会在使用

②关闭一些耗cpu过高的软件

③把电脑砸了，换个新的

5，是否中毒

排查：利用杀毒软件查杀下病毒

解决：①利用杀毒软件查杀下病毒

②把电脑砸了，换个新的

6，系统问题

排查：不是很好排查

解决：①电脑里没有多少重要资料的话就重装了吧

②把电脑砸了，换个新的，额或者送给我你再买个新的

通过部署更多磁盘改高提升IO性能，或者部署价格昂贵的光纤存储，锋颂甚至是利用SSD硬盘。然而，当前企业购买大容量存储主要用于性能，而非容量。因此，需要提升存储的IO。

虚拟化遇到的更大的瓶颈是IO瓶颈，进一步导致虚拟环境中存储成本猛增，虚拟化经应用性能不足等等。如何才能很好的解决这些问题?而不是简单地用磁盘叠加来解决。CPU的响应越来越快，然而，从存储的角度上来看，如果后端银盘没有很大的变化的话，哪怕升级到再高的存储也没有用。

FUSION—IO如何解决虚拟化的IO瓶颈?

FUSION—IO 成立于2023年，去年在纳斯达克上市。IBM、HP等都是我们的合作伙伴。

FUSION—IO 的架构其实很SAN是一样的，我们把SAN架构放到一个很小的PCIE卡上。我们跟独立的SAN存储是没有任何区别的。并且提供了5个9的可靠性。

FUSION—IO具有以下三大银歼郑亮点：30多万IOPS，这需要上千块磁盘进行堆彻；低功耗；支持广泛的应用平台：包括主流的数据库、SAP等等。

比如上次双十一，淘宝的促销活动，一天成交200亿人民币，他们的核心数据库全部是架设在我们的卡上，所以我们再高负载的数据库或应用平台上具有很好的表现。

FUSION—IO可以支持所有的操作系统，包括VMware、SUSIE、Windows等。为虚拟机无缝提供IOPS。而且可以支持刀片服务器，刀片版本的卡可以直接插入到到片中。

FUSION—IO解决VDI的启动风暴。在一台server上可以支持6000个桌面。可以把卡插在Hypervisor的机器上，然后把OS image直接放到卡上就可以。此外，FUSION—IO还提供了IO sphere管理软件。

服务器 io 测试的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于服务器 io 测试,深入了解服务器性能：如何进行io测试？,如何对API进行负载测试与调优（一）,如何解决磁盘io造成的系统卡顿问题的信息别忘了在本站进行查找喔。