资源供给：IO子系统之一

最新推荐文章于 2024-06-14 17:37:13 发布

cmy00028

最新推荐文章于 2024-06-14 17:37:13 发布

阅读量106

点赞数

文章标签：运维数据库

资源供给：IO子系统

简单案例描述：

某运营商的OCS实时计费系统实时计费效率不够，磁盘IO使用率100%。简单咨询了下其流程结构：11个并行查询进程的结果送到一个处理中心进行处理。开发生分析是磁盘IO处理能力不足，处理中心富余。我问了如果查询数据每秒100M返回是否可以达到处理效率，回答是肯定的。处理措施非常简单，改变并行查询为串行。在开发商简单修正之后，IO子系统获得足够的数据，使处理中心的效率无法支撑。

思考一下，为什么？在本案的处理中，我甚至都没有登录系统，登录数据库，当然也没有看AWR。IO子系统的资源不是无限的，特别磁盘是一个机械设备，当超过其负载的时候其响应时间会大幅增加。11个并行查询将产生1GB/s的读写要求，HBA卡，SAN Switch，EMC DMX4000都无法支撑如此巨大的数据库吞吐要求，IO子系统被塞死，响应时间大幅延迟。

IO子系统从性能优化的角度而言是最重要的资源，原因非常简单，IO子系统是系统主要处理构件中响应时间最差的部分，必须不断的优化使其可以和内存效率匹配。换句话说，从优化的角度，我们需要做以下几件事情：

（1）、我们需要让内存做更多的事情。

（2）、磁盘系统自身进行大量的缓存，同样是为了让内存做更多的事情。

（3）、磁盘系统自身要提高足够的吞吐量以支持短时间的缓冲失效。

我们来看看Oracle数据库的IO相关流程，假设为SAN存储架构：

Oracle Memory(Host memory) à Filesystem(LV) à HBA à SAN Switch à Array Disk Control à Array Buffer à Disk，以上链路中任何一个链路出现问题都会导致IO响应被延迟。

我们再来看看整个链路的速度：

Oracle memory(Host memory): 10ns~50ns

Filesystem: 通路，依赖于CPU能量的效率，穿过文件系统估计响应时间估计至少会从ns延迟到us级别。说的简单些，文件系统就是一个字典管理器，完成和lvm或者磁盘系统的映射。

LV：LVM是磁盘管理系统，使用户不需要直接和磁盘打交道，同样的你可以认为LVM是一个字典管理器，完成映射操作。自然再次降低了响应速度。

HBA卡：HBA卡比较简单，是一个简单的通路

SAN Switch：SAN swicth也比较简单，表现为一个简单的通路，特别在交换式结构中。

Disk Array control：磁盘系统的控制器，不仅仅是一个通路，在磁盘系统内部实现磁盘管理。

Disk Array cache: Disk, Array cache是磁盘系统性能的重要保证之一，使用户不需要访问磁盘就可以获得数据，使用户进程不需要等待直接写到磁盘就可以认为写操作完成。

Disk: Disk是数据的最终载体，最终的写入数据需要存储到这里，最初的获取数据需要从这里获取。

作为优化者，我们需要大致了解各个部件的状况，不需要很精确。我们需要知道，任何IT资源设备在达到资源限制的时候，其响应时间将大幅度降低。

CPU：一般每个CPU处理200M以上的数据，其带宽在6.4G以上

内存：50ns，一般完成完整的循环处理之后大约在us~20us，带宽一般在6.4GB以上。

HBA卡：2GB或者4GB，通路的损耗相对较小，一般可以达到其200M和400M的速度，IOPS几乎仅仅受带宽的影响，一般可以达到几十万甚至几百万的性能，很少会出现问题。

SAN交换机：SAN交换机和HBA卡类似，主要是一个通道功能，性能主要还是受限于带宽。对于SAN交换机来说，一般其带宽是共享的，比如2G的SAN SWICTH，16口去只提供16GB的总带宽容量，可能会出现问题。对于存储系统，永远不要输送超过其能力的输出是一个基本原则。

Disk Array Control：2GB,4GB，比较HBA卡和SAN Switch其损耗较高，大约可以获得180M和360M左右的吞吐量，大约在10万左右iops。

Disk array cache：内存

Disk：FC Disk，一般顺序读100M,200M,400M左右都速度，写速度可能要是在60%~70%左右，随机读处理速度大幅度下跌，一般在10~20M。Iops一般在150~250之间。可以看到如果仅仅考虑顺序读，Disk将和HBA卡，SAN Switch和Disk Control的效率相当，而我们一般来说一块FC Disk Control至少要加载10块以上的磁盘，甚至100多，200多块磁盘。