上周，我们发布了DelphixVersion3.0，它将Delphix数据库虚拟化技术扩展到Microsoft SQL Server和Oracle Real Application Clusters（RAC）。与以前的版本一样，我们服务器的最新版本包含了许多创新功能，这里可以找到一个全面的列表。在专注于推出新功能的同时，我们继续投资于提高服务器的性能。这篇文章致力于强调Delphix3.0的一些关键性能改进。增强的缓存ARC是自适应替换缓存，DelphixOS使用它来改善读取延迟。与传统存储相比，ARC中满足的访问通常要快一个数量级。Delphix3.0通过允许ARC在所有虚拟数据库（VDB）之间共享来增强缓存功能。这提高了弧空间的利用率，并减少了只读数据的平均延迟。共享ARC的性能改进源于两个主要组件。首先，在所有vdb之间共享弧可以提高弧空间的利用率。在Delphix2.7中，每个VDB都有自己的地址空间。这意味着，即使两个VDB正在读取相同的数据，它们也会在ARC中保留该数据的单独副本。这会降低弧空间的有效利用率。如果你的记忆只有10.0倍，那么你的记忆只有10.0倍。有效地使用内存会增加可以缓存的数据量。性能的第二个组成部分来自改进的延迟。通过在VDB之间共享地址空间，它们将开始看到共享缓存效果。例如，如果您有10个VDB，那么其中只有一个必须从磁盘读取其数据。其他人可以更快地从ARC读取数据。共享ARC的性能增益将取决于每个VDB从数据（参考位置）中获得的共享量加上在非共享场景中组合的所有VDB的工作集。我们通常会看到我们的客户在ARC上达到最大值，因此这个特性有望显示出良好的性能提升。为了展示这个特性的好处，我构建了一个实验，它是根据实际场景缩小的。我用DelphixBench运行一个共享弧与非共享弧的实验。非共享ARC模仿delphix2.7的行为。如您所见，对于这种情况，共享弧空间将使性能提高近30%。对于这个特定的工作负载，工作集大小约为9GB。我为Delphix虚拟设备配置了4GB内存。在客户环境中，工作集的大小通常大于可用的弧空间。在这个特定的实验中，好处来自弧空间的利用和vdb之间的预取，从而获得更好的平均延迟。请注意，此功能的改进与客户环境密切相关。你拥有的vdb越多，你看到的好处就越多，你从你购买的每一字节内存中获得的价值也就越大。更快的虚拟数据库资源调配供应VDB涉及从生产数据库创建快照的克隆，然后应用创建快照后的所有日志，以重新创建生产数据库的时间一致副本。提供VDB所需的时间与数据库的大小无关，但与需要恢复的日志活动量密切相关。提供快速和一致的资源调配时间将改进客户的工作流。在版本3.0中，我们减轻了对重做/日志活动的依赖性，以提供更好的资源调配时间。下表显示了使用Delphix版本2.7和3.0配置VDB所需的绝对时间。如您所见，资源调配时间与所用数据库的大小无关。您还将注意到，从2.7到3.0配置VDB所需的时间大大减少。这种收益来自于资源调配过程中的效率改进。 我们还减少了对工作负载类型或源数据库中日志活动量的依赖。上图显示了三种不同类型的数据库工作负载的资源调配时间大大减少。Redo/Log活动从读取繁重的工作负载增加到OLTP以写入繁重的工作负载。此增强功能旨在使VDB资源调配时间对用户更加可预测，从而提高产品的可用性。优化的复制服务工作流复制服务支持从一个Delphix服务器（源服务器）到另一个服务器（目标服务器）的连续用户数据复制。这是我们的HA/DR解决方案的重要组成部分。在3.0版中，我们完全修改了复制服务的工作流。内部实验表明，复制速度提高了近2倍。这源于对所用网络协议的改进以及对复制服务工作流的增强。客户将看到源和目标之间网络链接的利用率得到提高。更快的增量复制也意味着源delphix服务器的压力降低。结论我只谈到了3.0版中对服务器进行的一些重大性能增强。在应用程序堆栈和UI中添加了许多较小的特性，以提高服务器的总体响应能力。所有这些的最终目的是更好地为我们的客户提供产品的可用性。即使对软件功能进行了所有的创新，3.0将再次证明我们对提高性能的持续关注。