“每个节点20,000 IOPS具有5 ms的延迟的良好性能。” 对于OLTP-否

撰写本文的原因是对我们如何测试VMware vSAN ... CROC的非常有价值的评论。 这篇评论值得，但其中有一句话是我十多年来一直在努力。 存储管理员，虚拟化者和集成商一遍又一遍地重复：“延迟5毫秒是一个很好的指标。” 即使十年的5毫秒数字也不会改变。 我从备受推崇的管理员那里听到了不少于十二次的现场直播。 不那么受人尊敬-数十次，还有我在互联网上阅读过多少次...不，不，不。 对于5 ms的OLTP负载，尤其是通常测量的负载，这是史诗般的失败。 我不得不多次解释其原因，这一次我决定以可重用的方式收集我的想法。

我必须马上说，上述文章中没有此类错误，而是该短语起到了触发作用。

典型开始

本文描述的所有内容均适用于用于典型业务OLTP的常见DBMS。 我最有使用MS SQL Server的经验，但是至少对于PostgeSQL，Oracle和Sybase，许多观点和结论也将保持不变。

性能DBMS通常对每个人都不满意。 如果大型系统中有一个DBMS-突然之间几乎总是存在-那么这个DBMS就是一个瓶颈。 好吧，否则，如果您开始优化其他所有内容，它将立即成为瓶颈。 因此，客户来了，以一种人类的声音说：“救命！保存！他们为服务器和存储设备支付了NNNNNNNN美元，但是速度并没有增加！哦，管理员成立了，供应商也进行了咨询，但仍然不动。” 如果系统的开发人员符合Lavrov的定义（我们可以在不提供确切报价的情况下进行操作），并且操作和维护专家“通过重新引导服务器来应对事件”，那么问题通常是简单且自命不凡的：没有索引，歪斜的查询，致命的配置错误（文档使用粗体显示）它说： “你不能这样做！” ），过多的锁，死锁和其他简单明了的废话。 有很多这样的情况，大多数但不是全部。 如果系统在复杂性或负载方面已经超过了一些看不见的限制，那么它将死于这些问题或进入下一个层次。

在此级别上，服务器不再位于目录的下方，磁盘不再位于服务器内部，而是在存储系统中，开发人员了解索引，管理员已经了解PowerShell，IT经理开始说出SLA和RPO / RTO之类的精明词汇。 在此级别出现一个有趣的情况：

• DBMS是一个瓶颈。
• 服务器似乎在所有方面都足够。
• 可以通过编程方式进一步改进DBMS，但这很困难（要么切换到更昂贵的许可证，要么切换到“ Shipilev曲线的红色区域”进行优化）
• 磁盘系统价格昂贵，而且似乎已经进行了某种配置。

但是没有 没有捕获到鳄鱼，没有椰子生长，并且系统性能与旧服务器相同或更低。 我查看sys.dm_os_waitsats并在顶部看到WRITELOG ， PAGEIOLATCH_SH和PAGEIOLATCH_EX ，平均等待时间为5+ ms。 好吧，典型的说句：“嘿，管理员和DBA，这里有一个磁盘系统-瓶颈”，然后开始播放大约5毫秒的老歌：

• SLA有5毫秒
• 是的，我们有一个20,000 IOPS的团
• 供应商告诉我们，所有数据库文件都可以位于一个分区上
• 我们具有虚拟化和超融合功能，我们无法在数据库下分配单独的磁盘
• 根据我们的数据，服务器利用率为5％
• 一切都根据建议进行配置
• 您的数据库不需要太多的性能，它不需要超过300 IOPS（并且我们有20,000 IOPS的存储架）

顺便说一下，以上所有内容，不仅涉及“其”服务器，还涉及云服务和虚拟化。 它有一堆自己的细节，但是典型的临床情况是差不多的：适度优化的数据库，聪明的开发和维护人员，处理器和内存的储备，进一步投资的“消耗”几乎为零。

所以在这里。 关于“ 5 ms”的整首歌都是胡说八道。 如果您自己这样说，请阅读本文。 如果他们这样对您说，请准备论点。 以前，当我听到这些话时，我很生气，但不再生气。 我就像《银河系漫游指南》中带有矮牵牛的那个锅一样，只有一个念头：“好吧，再次……”。

谁该怪？

为什么数据库这么慢？ 好吧，似乎具有2-3 GHz频率的20-64个内核的典型服务器能够执行50-1500亿次简单操作，并且最大（综合）数据库测试显示，此类计算机上每秒只有10,000-50000个事务。 y！ 嗯，这是每笔交易从一百万到十亿个可能的交易。 这不只是很多，还有很多意义。
这样的间接费用使交易需要ACID 。

• 主体性-整个交易已完成，或者整个交易未完成。
• 一致性-在交易的入口和出口，系统处于一致状态
• 我这样 -交易看不到彼此的中间状态
• 耐久性-如果事务已成功完成（提交），则无论情况如何，所做的更改都必须保留在系统中。

顺便说一句，这些要求几乎在任何地方都无法满足，而且永远不会满足，而在分布式系统中根本就不会满足（CAP定理会干扰）。 对于我们的情况，“ D”要求最有可能比其他价格昂贵，此要求由所有常见OLTP DBMS的关键机制提供：WAL，预写日志（PostgeSQL），它也是事务日志（SQL Server），又名REDO日志（Oracle）。 这是-生产力的瓶颈，也是耐久性交易的基础。

什么是WAL？

让我们暂时忘记有关现代SSD和冷却存储系统的信息。 假设我们有一台服务器，它有一个或多个磁盘。
任何交易，甚至是插入一条记录，都至少有潜在的可能，但实际上几乎总是现实的非原子行为。 我们几乎总是需要不仅更改记录所在的页面，还需要更改索引页面（可能是服务页面）。 而且，在同一笔交易中，同一页可以更改很多次。 另外，其他交易可以与我们并行执行。 而且，时间相邻的交易会不断“拉”相同的页面。 如果我们等待将每个页面写到磁盘上再继续，这本质上就是持久性的要求，那么我们将不得不多次写入并等待在非易失性介质上完成每个记录。 没有缓存，没有队列中的操作重新安排，否则将没有完整性！ 此外，我们需要以某种方式注意哪些数据已经在固定交易中，哪些尚未（和之前的数据一样）。 为了理解-在这种模式下，典型的单个硬盘（HDD）可以提供50-100 IOPS，并且20年来一直保持不变。 一小笔交易将需要5-10次写入操作。 啊，是的，为了知道要录制什么，您必须阅读它。 即使是非常非常可写的OLTP系统，其读取量也比其写入量多3倍。 因此，我们的交易花费20-40 IO，这意味着每个磁盘需要0.2-0.8秒。
每秒2笔交易。 还不够吗 让我们尝试分散磁盘吗？ 哦，但是我们仍然需要等待，直到记录了上一个，并且最后没有并行性。 如何成为 让我们开始一个日志文件，在该文件中，我们将顺序记录所有写操作在数据库和事务标记中！ 优点：

• 有关操作的信息比记录整个页面要紧凑得多（典型的页面大小为8 KiB，写入日志的信息通常为0.5-1 KiB）。
• 日志中没有足够的关于事务的开始和固定的标签，而不必写关于是否将事务直接记录到页面上的记录。
• 每笔交易后都无法写入页面-少了好几倍。 读取/写入数据的过程与日志完全“无关”。
• 最主要的 如果我们将日志放在单独的磁盘上并按顺序写入记录，那么由于您不需要不断地重新放置磁盘头，即使在这种模式下的家用HDD也会压缩多达1000 IOPS，因为小事务“花费”了2-4个日志条目，那么你可以挤200-400 TPS
• 发生故障时，可以使用此类日志恢复数据文件的状态，并且如果取消事务，则可以回滚更改。

这样的日志称为预写日志/事务日志/ REDO日志。

万岁！ 太好了！ 每秒有2笔交易，现在变成300笔-提高了150倍。 而且要花多少钱？ 事实证明，价格很高：

• 在所有常见的DBMS中，日志记录都是严格一致的。 一个线程负责写入日志。 您有100个处理器吗？ 好酷 并且日志仍将写入一个线程。 队列的深度恰好是1。
• 仍然-没有操作系统缓存，没有操作排列。 耐久性要求仍然存在。 直写操作：直到光盘回答“我已写，我已将其写到表面，而不是写到高速缓存，是肯定的”，DBMS才能继续工作。
• 如果将日志文件放在数据磁盘上，那么顺序记录的几乎所有好处都将丢失。 而且-好的，如果服务器上有多个数据库，则有多个杂志磁盘。
• 事务回滚（至少在MS SQL Server中）-读取日志并从中恢复状态。 这与事务中的写操作数量一样多，甚至更多。 回滚很昂贵！

这种解释非常简单，“在手指上”。 这足以满足我们的主题要求。 WAL是确保事务性的关键，基本机制，它必须是直写的，访问是仅用于顺序记录的单线程，从存储的角度来看，队列深度为1。

对于以某种方式管理DBMS或DBMS基础结构或开发数据库的任何人，至少应该至少了解数据库中的预写日志记录主题。

WAL和SHD

“从诞生开始”的存储制造商就面临DBMS。 对于数据库而言，企业购买了这些疯狂的昂贵复合物：从Dell-EMC，HP，日立和NetApp的街头价格存储中，在制定预算时，对于大多数高级管理人员来说都是眼泪汪汪的，除非他们当然会得到这个价格的一定百分比。 但是存在工程和市场冲突。 我将以Dell-EMC为例进行说明，但这仅仅是因为我记得他们在哪里有说明文件。

因此：

1. 单螺纹轴颈
2. 与CPU性能相比，直写日志（即延迟）是“永恒的”
3. OLTP负载是很多相对较小的事务，
4. 大多数其他DBMS负载以一种或另一种方式并行。

Amdahl的定律毫不留情地告诉我们，单线程低性能负载将使添加处理器无用，而性能将由日志决定。 而且，此刻我们不会对IOPS中的存储性能有所顾忌，只有延迟会变得很重要。
但是不要打折其他磁盘操作-读写数据文件和tempdb 。 阅读也是一种“等待”操作。 在从磁盘到内存读取数据页之前，处理器无法对其进行处理。 但是对于这些操作，可能会出现较大的队列和该队列中的操作排列：DBMS经常知道哪些页面要加载到内存中，哪些页面要转储，并放置大量队列以供一次读取。 由于在这种情况下，结束捆绑包的最后一个操作很重要，因此，在这种负载下，IOPS对我们而言比单个操作的延迟更为重要。 了解范围：典型OLTP系统中的读取操作为85％-95％。 是的，是的，是的，写操作要少一个数量级。

供应商存储工程师与DBMS供应商紧密合作，并且充分了解DBMS如何与磁盘子系统一起使用的所有技术细微差别。 DBMS的磁盘资源的正确计划，分区和分配是存储系统管理员的一项复杂而重要的能力。 相同的Dell-EMC甚至还具有用于对SQL Server进行分区建议的基本白皮书H14621和H12341-超过一百页。 y！ 这不是详细的Dock，这是最常见的白皮书！ 仍然有一堆特定的变量 （ h15142 ， h16389 ...那里有黑暗）。 VMware的“邻居”- 在VMware vSphere上构建Microsoft SQL Server紧随其后。 请注意，这些文档不仅对DBA而言，而且对基础架构和存储管理员而言也不是那么重要。
我还注意到，在所有这些文档中，都为数据，日志和tempdb剪切了单独的LUN。 是的，在最新文档的某处，他们巧妙地指出，对于全闪存解决方案，将日志分成物理上分开的介质是没有意义的，但是LUN仍然可以将它们分开切割。 如果转储数据并登录到一个LUN，那么从操作系统的角度来看，它将是一个IO队列。 并且会有一个问题。 延迟操作将立即增加一个数量级。 并且由于不可重定位的日志操作将出现在队列中，因此IOPS将滑到数据文件和tempdb 。 这不是“本世纪的发现”，而是使用数据库的基本事实。 全闪存的出现并没有过时或取消它。 是的，SSD的操作延迟比HDD的操作快一个数量级，但比内存的操作要慢几个数量级。 IO仍然是DBMS的瓶颈。
并且技术文档正确地强调了，在事务日志中，IOPS的数量并不重要，但重要的是最小的延迟（在现代，写的时间少于1毫秒）。

但是营销人员需要出售。 超融合！ 虚拟化！ 部署灵活性！ 重复数据删除！ 设置简单！ 很多很多IOPS！ 美丽的演讲，自信的声音，正式的服装。 但是，还有其他方法如何以6-7位数字的美元价格出售解决方案呢？ 为此，以某种方式忘记了可以从存储系统获得延迟或吞吐量，但不能同时获得两者，负载平衡器的某种许可证就像另一个架子，如果密集记录持续一个小时以上，则控制器的RAM这还不够，生产力将下降到“好像没有缓存”，培训客户的员工在第一年要再花费100,000卢布，好吧，这些技巧...

5毫秒

要么从阅读营销人员那里听到很多东西，要么从懒惰中听到，或者由于某种蟑螂而听到很多，但是由于某种原因，存储管理员经常这样做。 我们拿一个大架子，将它们全部组合成一个平面，将其切成精简配置的LUN，然后按LUN分配到服务器。 一两个，因为“系统分区已很好地重复数据删除”。 当我看到从SQL hell-hell-hell的磁盘子系统来看时，这首歌开始说“ 5毫秒是一个很好的指标”，“ 100000 IOPS”，“您的存储负载小于5％”

不行

• 对于WAL /事务日志为5毫秒的分区上的OLTP系统，这是无效的指示器。 在“几乎商品”的铁片上，价格便宜1000倍（换句话说：一千），现在的正常指示值为0.1-0.3毫秒。 明天-0.01毫秒。 不需要像2008年HDD那样的速度，而只需要以整个莫斯科公寓的价格为代价。 没有“可维护性”值得。
• 供应商是否写明事务日志对IOPS的要求不高，可以将其放在HDD上吗？ 是的，是的。 但是为此，所有这些磁盘都必须没有 传染 除了编写日志外，DBMS也没有完成任务。 这样一来，存储系统就会在数据进入非易失性存储器后立即响应服务器写入的数据（这比将要写入的时间要早​​得多）
• 真正的OLTP数据库的精简磁盘是邪恶的。
• 对于WAL，在队列深度为10或20的情况下可以挤出多少IOPS绝对是没有意义的。
• 对于WAL，这绝对不是操作系统中IO队列“仅约1”的指示。 她不会了。
• 不，DBA和DB开发人员不是“无法正确配置为写入WAL并行程序的啄木鸟” （管理员的真实意见）
• 风扇考虑回收的逻辑“由于我们在一个分区中歪曲配置的系统无法实现10,000 IOPS，因此必须将其从高端阵列转移到中端范围” –这是不正确的逻辑。
• 如果40核服务器的处理器负载为2.5％，这并不意味着它没有任何事可做，而是最有可能意味着存在某种阻止其他所有人的任务。

当在开发人员的笔记本电脑上加载一些数据需要5分钟，而在具有1个TiB RAM和100万美元的存储空间的第40台核服务器上执行一个小时的相同任务时，即使是最有耐心的客户也会对成本的可行性产生疑问。

怎么办

管理员提示和DBA

对于OLTP，停止计数“回收”和IOPS。 另外，我注意到-完全不要考虑具有大队列深度的IOPS：即使在数据分区上，大队列通常也具有短脉冲串或不影响OLTP实际性能的东西。

通过LUN共享磁盘空间不是DBA的想法。 该数据库具有几个不同的磁盘子系统负载配置文件。 至少可以区分以下内容：

• 处理数据文件。 通常，这是使用8/64 KiB的随机块进行读写。 读数80-95％。 出现队列：在服务期间，散装期间，效率低下或大量请求时以及检查点期间。 性能受阅读反应的影响。 重要的是，“直通” 8/64 KiB块的对齐方式要穿过整个存储系统。
• 使用tempdb与使用数据文件相同，但是读数通常为40-75％，写响应能力可能很重要。 在现代MS SQL系统中，该数据库的加载能力比数据数据库强几倍。 在非群集DBMS配置中，此部分应从任何存储复制中排除。 重新启动服务后其内容仍将被销毁。
• 处理存档数据/ DWH。 读数接近100％。 一个读取块的大小通常为64 KiB。 连续读取大量请求，因此队列最多可以跳转到1000个或更多。
• 处理事务日志。 读取仅用于维护（备份，复制等），应用程序性能仅受写入影响。 以0.5-64 KiB为单位记录。 没有队列，在一个线程中。 延迟对于应用程序至关重要。
• 备份和还原。 从数据库的角度来看，读取的是大块数据（通常为1 MiB）。 重要的是，在某些情况下，此负载可以承受通道/总线（FC和以太网）以及存储处理器的性能。 备份一台服务器可能会影响相同SAN / SHD的其他服务器的性能。
• 使用应用程序文件：这些是日志，默认跟踪，二进制文件等。 该负载很少会变得很重要，并且仅在系统启动时才重要。

还有其他类型的负载，但是它们有点外来（例如，可能以FileStream目录的形式在数据库中存储了文件的存储库）。 所有这些类型的负载都有不同的（通常是相互冲突的）磁盘需求。 如果它们全部堆积在一个分区上，则不仅会降低性能，而且失去理解系统速度下降原因的能力非常重要，而且您也失去了仅改进需要改进而无需全局改进/升级存储的机会。 因此，主要建议：

, " " . .

• , . Dell/EMC SQL Server .
• . "" (, NUC c SSD, , ). --, .
• DBA, - ( 200 ).
• (etrolaster ), , , . +0,5 , 0,2, 0,7 3 .
• , . tempdb , , , RCSI 12 .
• Latency throughput. , " ", . throughput latency, . .

MS SQL Server

MS SQL, bottleneck , - :

1. . 这是正确的。 . 1000 5-30 1000 INSERT . , , , , " — ".
2. tempdb " ". . , , .
3. , BULK INSERT . , "Simple" "Bulk logged". , , Simple/Bulk logged Full . — The Data Loading Performance Guide , . ( ETL, OLTP) We Loaded 1TB in 30 Minutes with SSIS, and So Can You
4. SQL Server Delayed Transaction Durability — , .
5. SQL Server In-Memory OLTP . , .
6. , , AlwaysOn .

***

仅此而已。 . 20000 IOPS 5 latency 4-16 OLTP. OLTP , .