解决vSphere的存储性能问题之存储队列

介绍

vSphere的存储队列是什么,需要改变吗?

更多信息

我们都不得不在我们的生活中等待一次或两次排队,排队等候只是一个生活的元素。在存储领域,这是真实的;存储I / O有大量的队列,他们必须等待。在这篇文章中,我们分析了在虚拟化存储堆栈的不同队列,讨论何时,如何,以及为什么要修改它们。

队列是必要的,但主要它们被用来允许共享的资源,并允许并发流。通过使用队列,vSphere是能够让多个虚拟机共享一个单一的资源。队列还允许应用程序同时在一个LUN上有多个活动的I / O请求,它提供了并发性,并提高了性能。但这里有一个权衡,如果你允许太多的并发,底层的资源可能会饱和。为了防止一个虚拟机或一台主机出现底层资源的饱和,队列需要设置尺寸/限制来规定可以一次发送I / O请求的数量限制。

在一个虚拟化的环境中有多个队列。在堆栈的顶部,有guest OS内部使用的各种存储队列。这包括由应用程序本身和存储装置内部使用来宾OS驱动程序创建和使用的队列。在的vSphere软件堆栈内的虚拟化层,有三个主要的队列。一个世界队列(每个虚拟机有一个队列),适配器队列(主机中的每一个HBA有一个队列),以及设备/LUN队列(每个LUN,每个适配器有一个队列)。最后,在存储堆栈底部的有存储装置的队列,例如前端存储端口具有可用于所有传入在该端口上的I / O的一个队列。

在调查存储性能问题和瓶颈的时候,你应该调查从应用程序和客户操作系统到存储阵列的各个级别的存储堆栈的排队情况。在这篇文章中,我将只讨论在vSphere存储堆栈中的队列。

对于大多数用户,默认的三个主要队列的队列大小在vSphere是普遍合适的,不需要任何调整。但是,对于那些在他们的环境中具有一个高层次整合或非常密集的存储工作负载的客户,一些在vSphere中的队列可能需要进行调整,以获得最佳性能。下图显示了在vSphere的三个主要队列,其典型的默认队列大小。正如你可以看到,I / O请求流入每个虚拟机队列中,然后流入每个HBA队列,最后适配器队列中的I / O流入每个LUN队列。从默认的尺寸,你可以看到每个虚拟机能够发出32个并发I / O请求,而下方的适配器队列是相当大的,通常可以接受所有的I / O请求,但在它下面的LU??N队列通常本身只有大小为32。这意味着,如果多个虚拟机共享一个LUN,LUN队列可能不够大,不足以支持所有的共享LUN的虚拟机所发送的并发I / O请求。

为什么虚拟机队列和LUN队列的设置只有32?设置限制的原因是为了防止一个虚拟机或vSphere主机,窃取所有的存储性能,用它自己的I / O请求占据了存储,所谓的“吵闹的邻居”问题。例如,一个存储阵列LUN可以由多个vSphere主机共享,通过限制每个vSphere主机在这个LUN上只有32个并发I / O,一个vSphere主机会饱和整个LUN而其他主机却挨饿的风险大大减少了。

然而,任意设置硬盘的限制是上世纪的处事方式。今天使用的功能,如存储I / O控制(SIOC),vSphere通过??一个更优雅的和公平的机制也可以减轻虚拟机和vSphere主机遇到吵闹的邻居的风险。因此,今天,如果你都注意到,您的设备队列,不断提高他们的最高限额,我们建议增加设备/ LUN的深度和使用SIOC,以帮助减轻任何潜在的吵闹的邻居问题。一个快速的小纸条,SIOC通过修改设备/ LUN队列的深度来控制存储工作负载,但SIOC不可以增加设备队列的深度以超出设定了的最大值。所以,在工作负荷需要更大的队列的时候,你需要自己调节队列的最大值,然后让SIOC在需要的时候减少它。

为什么要增加设备队列?增加了设备队列的原因是存储阵列通常是更有效的,如果它可以一次看到多个I / O请求。存储阵列知道越多的I / O,它更有效维护他们。这是因为存储阵列可以重新排列所要求的I / O块和利用I / O块的接近。例如,如果虚拟机要求在存储主轴上彼此非常接近的2块,存储阵列可获得第一个块,然后迅速收集第二个块,当主轴上的存储头正好“在附近” 。如果队列深度设置为1和存储阵列只能看到一个I / O请求,当磁盘头是“在附近”时,它不能有效地收集其他的I / O块,因为存储阵列不知道下一个你会想要什么块。

您可以监视,并检查当前的各种队列的队列深度,以及他们如何积极被使用。

要确定存储适配器的队列深度:

1。在ESX主机或ESXi shell(技术支持模式)中的服务控制台运行esxtop命令。

2。按D。

3。按F,然后选择队列统计F.

4。AQLEN列的值是存储适配器的队列深度。这是适配器驱动程序配置为支持的ESX VMkernel活动命令的最大数量。

要确定存储设备队列深度:

1。在ESX主机或ESXi shell(技术支持模式)中的服务控制台运行esxtop命令。

2。按U。

3。按F,然后选择队列统计F.

4。DQLEN列的值是存储设备的队列深度。这是适配器驱动程序配置为支持的ESX VMkernel活动命令的最大数量。

如果你不断地发现,您的设备/ LUN队列报告100%“主动/满”的,则它可能是一个指示,你的设备上的队列,或底层的存储有瓶颈。

另一个有趣的内容是在VMware ESX / ESXi中控制LUN队列深度的限制。

你在每个设备设置QFullSampleSize和QFullThreshold。

运行以下ESXCLI命令。

esxcli storage core device set --device  device_name --queue-full-threshold  Q --queue-full-sample-size S

在重新启动后设置是持久性的。

您可以通过使用相应的列表命令检索设备的值。

esxcli storage core device list

该命令支持可选的 - 设备参数。

esxcli storage core device list --device device

在早期版本中的推荐值是相同的。

QFullSampleSize:

•对于3PAR,NetApp和IBM XIV存储阵列,QFullSampleSize值设置为32。

•对于其他存储阵列,请联系您的存储供应商。

QFullThreshold:

•对于3PAR存储阵列中,设置QFullThreshold值4。

•对于NetApp和IBM XIV存储阵列,设置QFullThreshold值设置为8。

•对于其他存储阵列,请联系您的存储供应商。

vSphere的一个功能,从存储阵列和设备/ LUN队列中来检测队列满的警告,这样vSphere发出的I / O请求的数量减少了。此功能默认情况下是关闭的,但根据您的存储供应商的最佳实践,应该启用。

总之,有很多虚拟化存储堆栈和队列,这些队列有各种不同的默认大小。对于大多数环境中,你并不需要调整队列。然而,对于I / O密集??型工作负载,产生了大量的并发I / O请求或高度整合的环境中,它可能是有益的调整,使存储阵列可以更有效地处理传入的I / O请求。使用SIOC和其他队列调节功能,可以减轻一些潜在的风险增加了vSphere的队列,但它始终是最好的做法进行测试和评估他们在生产中实施前后的变化,避免过度或不必要的修改,如果你没有注意到的队列队列满的瓶颈。

原文地址:https://www.cnblogs.com/Anderson-An/p/11689512.html

时间: 2024-10-09 10:21:25

解决vSphere的存储性能问题之存储队列的相关文章

android系统手机存储性能优化

一.存储性能增强之:路在何方? 二.存储性能增强之:emmc标准演进优化存储性能 三.存储性能增强之:wrapfs代替fuse,优化内置sdcard性能 四.存储性能增强之:f2fs代替ext4,优化data用户空间性能 五.存储性能增强之:新型io调度机制ROW 仅以此文总结2014年在存储性能方面的优化,及作为未来优化方向的指引!

一种更高查询性能的列存储方式MaxMinT 第一部分

简介本文描述了一种列存储方式和对应的查询方法,这种存储方式具有更好的查询性能和更小的存储空间. And查询 本文先用直观的图形方式展示and查询时的方式,这也是算法要解决的问题核心.通常在OLAP数据查询时,需要进行and处理,例如你需要获取 year = 2017 and customer = 13 的数据,这在列存储中实际是对值 year的2017这个列和 customer的13列进行and操作,而这些列一般都使用位图的方式存储.市面上有很多位图的存储方式,比如WAH, EWAH, Conc

软件对存储性能的影响​

存储系统的核心是软件,在磁盘存储时代,存储系统软件设计的好坏似乎对性能的影响并不是很大,很多存储软件的设计并不会去考虑计算机的体系架构,也不用去关心操作系统调度.内存拷贝等因素带来的性能影响.对于磁盘存储,事情的确是这样的,原因在于磁盘的性能远远低于CPU处理和访存性能.磁盘存储的性能瓶颈点就在于磁盘本身,因此过多的体系结构级别.竞争资源同步的优化,不会对存储性能带来显著优化. 在很久以前做过这方面的实践,当时觉得临界区的资源竞争会对IO性能造成影响,因此,对我们做的一套存储虚拟化系统进行锁资源

存储性能优化方向整理

0概述 0.1 存储性能优化指标 io速率:速率提升数值和百分比 iops:iops提升数值和百分比 0.2 优化方向概述 块存储优化方向:优化的工作,基本上都是在底层,上层只是一些配置. 这些底层的技术适用于ceph块设备,主要是ceph还有自身的一些配置.缓存方案可以拿过来用,在最后补充一下. 底层包括qemu/kvm/kernel三个层面,kernel又主要是filesystem.scsi和block这部分和存储关系最大,也是存储系统由上而下的三部分.我认为如果优化的话,主要工作在这几个方

性能优化——存储性能优化

核心知识点: 存储性能优化无非从磁盘类型.数据结构以及存储备份方式来进行,根据业务场景选择最合适的方案. 1.机械vsSSD(磁盘类型) a.机械:由于每次访问数据,都需要移动磁头臂,因此连续访问和随机访问性能差别比较大.快速顺序读写.慢速随机读写 b.SSD:使用硅晶体存储数据,因此像内存一样随机访问,功耗和噪音也比较小,但是可靠性和性价比有待提高. 2.B+树 vs LSM树(数据结构) a.为了优化磁盘的随机读写能力,文件系统或数据库系统会先将数据排序,保证数据更新.插入.删除之后依然有序

块存储性能

性能指标 衡量块存储产品的性能指标主要包括:IOPS.吞吐量和访问时延. IOPS IOPS是Input/Output Operations per Second,即每秒能处理的I/O个数,用于表示块存储处理读写(输出/输入)的能力.如果要部署事务密集型应用,典型场景比如数据库类业务应用,需要关注IOPS性能. 最普遍的IOPS性能指标是顺序操作和随机操作,如下表所示.   IOPS性能指标 描述 总 IOPS 每秒执行的I/O操作总次数. 随机读IOPS 每秒执行的随机读I/O操作的平均次数

[转帖]深度: NVMe SSD存储性能有哪些影响因素?

深度: NVMe SSD存储性能有哪些影响因素? http://www.itpub.net/2019/07/17/2434/ 之前有一个误解 不明白NVME 到底如何在队列深度大的情况下来提高性能, 现在看来是因为 比AHCI多了 多队列的控制来提高性能. 导读: NVMe SSD的性能时常捉摸不定,为此我们需要打开SSD的神秘盒子,从各个视角分析SSD性能影响因素,并思考从存储软件的角度如何最优化使用NVMe SSD,推进数据中心闪存化进程.本文从NVMe SSD的性能影响因素进行分析,并给出

ArrayList,Vector,LinkedList的存储性能和特征

ArrayListh和Vector都是采用数组的方式来存储数据,其中ArrayList是线程不安全的,Vector是线程安全,所以ArrayList的性能要比Vector的性能好一些,而LinkedList采用的双向链表来实现数据的存储,而且是线程不安全的,而且LinkedList提供了一些方法,使得LinkedList可以被当做栈和队列来使用.因为ArrayList和Vector采用的数组的方式来实现存储数据,所以查询数据比较快捷,但是进行数据增删操作比较慢些,但是LinkedList采用的事

IBM DS存储存储性能调优

ibm存储适用,其他存储有类似参数. 1.调整全局cache参数 1.1 start and stop cache flush:这两个参数影响控制器处理cache区域的操作,在这中情况下是按照先进先出的原则往磁盘上写数据.这只对打开了写cache的情况下适用. 在一般的情况下,在决大多数时候start的值大于stop的值.但是也有少量的情况下start等于stop的值.如start=stop=80%意味着,控制器的cache将不允许超过80%的部分用于写cache操作,在这种情况下,控制会尽可能