Description
1. 问题现象
新安装创建的Oracle数据库， 发现I/O读写性能很差。试图删除数据文件重新建库，发现删除操作接近hung住，CPU占有率非常高。重启后，重复该操作，问题依旧。
2． 问题研究
在该环境中，通过fsmap命令检查这些数据文件，发现每个文件都有超过1百万的碎片（fragments/extents），如图1。
#fsmap -A filenames > DATA_A_100.map
#head DATA_A_100.map Volume Extent Type File Offset Dev Offset Extent Size Inode# lvback Data 0 1340298723328 8192 89 lvback Data 8192 1340301475840 32768 89 lvback Data 40960 1340301574144 32768 89 lvback Data 73728 1340301737984 32768 89 lvback Data 106496 1340301869056 32768 89 lvback Data 139264 1340302032896 32768 89 .. # tail DATA_A_100.map … lvback Data 34358591488 1615039954944 32768 89 lvback Data 34358624256 1615040053248 32768 89 lvback Data 34358657024 1615040151552 32768 89 lvback Data 34358689792 1615020269568 8192 89 #cat DATA_A_100.map|wc 1029127 6174766 78213657 |
图 1 异常文件fsmap 命令输出
2.1 背景知识
VxFS（Veritas File System）是一种基于扩展的日志记录（extent-based ,logging）文件系统。一个扩展（extent）就是文件系统中一块连续的空间，对应存储上连续的物理块。当向一个文件写入数据时，就会给它分配一个extent；当对该文件的数据进行修改时，修改的数据会存储在之前分配好的extent中；当对该文件进行追加时，会试图在文件存储的结尾扩展已有的extent。这样还是一个extent，只不过长度加长了。一个扩展（extent）包含一个起始地址（Offset） 和一个长度信息（Extent Size）。
如果再次给该文件新分配空间时，和之前给该文件分配的空间不连续，比如中间空间被其他文件占用，这时就要创建一个新的扩展（extent）。文件元数据（Meta data）中会记录新extent的起始位置和长度。通过指针链接去访问这些数据。Extent越多，文件的碎片情况就越严重，访问时性能受到的影响也越大。
这种基于扩展(extent-based)文件系统，每个扩展（extent）包含多个连续数据块，因而可以通过尽量少的I/O调用，来满足上层应用的大SIZE的连续读写，如READ-AHAED，FLUSH-BEHIND。最终大大提高文件系统的吞吐率。
VxFS的设计主要用于满足高性能和高可用性的大量数据处理的文件环境。
在VxFS中，fsmap 这个命令的作用就是显示一个文件的extent信息。
|
图 2 正常文件fsmap 命令输出
在命令fsmap中， -A这个选项的含义是显示报告所有的数据extent的详细信息。同时报告设备偏移量和文件的inode号。更多用法可以参考fsmap manual手册。
如图2显示，使用fsmap命令检查文件test的数据（data）段的extent信息。输出的各项含义如下：
第一列 Volume : 显示extent所在的对应逻辑卷信息（VxFS文件都创建在VxVM的逻辑卷之上）。
第二列 Extent Type: extent 类型。可以是Data数据信息，或者是Meta元数据信息。
第三列 File Offset: extent对应在文件中的（逻辑）偏移量位置。
第四列 Dev Offset: 该extent对应在设备上的偏移量位置。
第五列 Extent Size: extent的大小，也就是extent的长度。
第五列 Inode# : 文件的inode号，每个文件有唯一一个inode信息。
图2中显示的文件是新创建的一个普通文件，只有一个extent，数据是连续的。
图1中显示的文件是一个有多个extent的Oracle数据文件，一共有1029127个extent。 说明碎片情况很严重。另外值得注意的是，绝大部分extent的size都是一样的，且很有规律。说明应该是特定软件产生的数据文件。
2.2 环境详细情况
在图2的场景中，该数据文件所在目录是用于存放Oracle 数据库迁移时临时数据，共有1千多个数据文件，平均大小32G，总计35 T左右。每个文件有一百万以上的extent, 总共就有超过了10亿个扩展(extent)，这是巨量的碎片。当执行每一个删除文件的操作时，需要从元数据中检索到每个扩展(extent)信息并做删除标记，之后还要把这些碎片空间回收。如此巨大的meta data数据量操作，是一定会消耗大量的CPU资源并且体现为hung住。
2.3 产生碎片的原因
经检查，这些数据文件之所以有巨量的扩展(extent)，原因是，产生这些Oracle数据文件时，采用了Oracle RMAN并行写入的方式，即多个数据文件在同时不停的追加，并没有事先为这些文件预留连续空间。因此，数据在写入下层介质时，不是连续的一个整体，频繁分配新的extent，导致产生巨量extent，最终引发文件读写性能问题。
#/usr/bin/bash i=1 while [ $i -le 30 ] do dd if=/dev/zero bs=1024k count=100 >> ./test01 dd if=/dev/zero bs=1024k count=100 >> ./test02 let i=i+1 done |
图3 交替追加数据到两个文件的脚本
# fsmap -A ./test01 Volume Extent Type File Offset Dev Offset Extent Size Inode# fssvol01 Data 0 23068672 10485760 8203 fssvol01 Data 10485760 100663296 94371840 8203 fssvol01 Data 104857600 402653184 104857600 8203 fssvol01 Data 209715200 603979776 104857600 8203 fssvol01 Data 314572800 872415232 104857600 8203 fssvol01 Data 419430400 1140850688 104857600 8203 fssvol01 Data 524288000 1409286144 104857600 8203 fssvol01 Data 629145600 1677721600 104857600 8203 fssvol01 Data 734003200 1946157056 104857600 8203 … |
图4交替追加数据后文件的extent情况
我们尝试使用图3所用脚本，模拟客户情形， 执行后产生的文件extent情况如图4，extent数目就很多。
3. 问题解决
文件碎片问题，首选解决方案是做碎片整理。每个文件系统都会提供碎片整理工具（VxFS也提供此功能）。碎片整理是个在线工具，是在不影响应用程序运行的前提下，完成碎片的整合（文件extent数目减少，extent的长度加长）。由于做碎片整理需要逐个扫描文件，并挪动extent里的真实数据，运行的时间比较长，系统负载在该段时间也会加重。
最简单的方法还是要在数据文件创建时预先分配连续磁盘空间，比如在创建Oracle数据文件时使用Veritas的ODM机制（具体实现，这里并不详细阐述）。
4. 有关extent的参数
由于在实际应用中，文件数据不可避免的会被修改，追加，删除。想保持非常理想的extent数目是比较困难的，但一般情况下都不会出现很明显的影响性能的情况。另外VxFS系统会智能的考虑这些情况的，比如初始分配第一个extent的大小时，可以修改设置参数（initial_extent_size）。当不断创建新extent时，VxFS会进一步加大下一个extent分配的大小，但不能超过max_seqio_extent_size。具体这些参数的含义可以参见vxtune手册。
参考文献：
[1] Storage Foundation Cluster File System High Availability 7.1 Administrator's Guide -Linux https://www.veritas.com/content/support/en_US/doc/119764174-119764186-1
[2]fsmap manual 手册：：https://sort.veritas.com/public/documents/vie/7.1/linux/manualpages/html/man/file_system/html/man1/fsmap.1.html
[3]vxtune manual手册：https://sort.veritas.com/public/documents/vie/7.1/linux/manualpages/html/man/file_system/html/man1m/vxtunefs.1m.html
此内容是否有用？
翻译内容
请注意，本文档是英文翻译版本，可能是机器翻译的结果。本文档翻译并发布后，原始版本可能另有更新。华睿泰不保证翻译版本的准确性和完整性。若要了解本知识库文章的最新信息，请参考英文版本。