XFS为例 讨论NVMe SSD测试注意事项

本文通过使用fio工具对浪潮NF5280M5服务器上的PBlaze5C916 NVMe SSD进行128K顺序读写及4K随机读写测试,展示了在xfs文件系统下NVMe SSD的性能表现。测试结果表明,xfs对读带宽的影响大于写带宽,4K随机读写分别达到85万和20万IOPS。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

之前一篇《测给你看!异步I/O模式下NVMe SSD性能有多高》文章,介绍了同步I/O和异步I/O模式下NVMe SSD性能的差异,更高性能的存储设备也需要更高的压力才能显示其性能优势。在真实的企业系统中,NVMe SSD更多见于经由文件系统被应用使用。相较于裸盘性能的测试,文件系统环境中的NVMe SSD测试更为复杂,也更有价值,本文也将对NVMe SSD在文件系统场景中测试需要注意的问题进行解读。

服务器:浪潮 NF5280M5

CPU:Intel(R) Xeon(R) Gold 5115

操作系统:CentOS 7.4

测试工具:FIO 3.13

被测NVMe SSD产品:PBlaze5 C916 NVMe SSD(3.2T)

文件系统:xfs

在测试之前我们会将被测的PBlaze5 NVMe SSD格式化为xfs文件系统。测试工具使用了fio,因此解读也与fio的测试流程和结果保持一致。测试内容包含128K顺序读写负载下的吞吐量和4k随机读写负载下的IOPS,最常见的测试场景也最容易说明问题。

在测试之前我们会将被测的PBlaze5 NVMe SSD格式化为xfs文件系统。测试工具使用了fio,因此解读也与fio的测试流程和结果保持一致。测试内容包含128K顺序读写负载下的吞吐量和4k随机读写负载下的IOPS,最常见的测试场景也最容易说明问题。

128K顺序读/写测试

首先使用fio执行一个128k顺序读命令。

fio -name=test -thread -ioengine=libaio -direct=1 -directory=/nvme0n1 -rw=read -bs=128K -numjobs=1 -iodepth=256 -size=3200G  -group_reporting

命令开始执行就可以看到测试文件写盘(Laying out IO file)的状态。文件写完成之后才会开始正式的读测试,并记录结果,这与写测试的流程不一样,下文会提到。接下来进行顺序写预处理。

fio -name=test -thread -ioengine=libaio -direct=1 -directory=/nvme0n1 -rw=write -bs=128K -numjobs=1 -iodepth=256 -runtime=10800 -time_based -size=3200G  -group_reporting

全盘顺序写三个小时。

Attention
预处理很重要。经过长时间的擦写,NVMe SSD的GC等功能会被触发,这时也更接近于盘在生产环境中的真实性能,测试过程中一定要保证NVMe SSD被写满的状态否则会造成性能偏高的现象,预处理的作用也在于此在刚才顺序预处理中完成Laying out IO file过程便可以看作对盘的预处理。至此执行的两条命令都会对NVMe SSD进行大规模的写,预处理工作也随之完成。

接下来是正式的128K顺序读/写性能测试。首先是顺序读测试:

fio -name=test -thread -ioengine=libaio -direct=1 -directory=/nvme0n1 -rw=read -bs=128K -numjobs=1 -iodepth=256 -runtime=600 -time_based -size=3200G  -group_reporting

完成读测试之后就是顺序写测试:

fio -name=test -thread -ioengine=libaio -direct=1 -directory=/nvme0n1 -rw=write -bs=128K -numjobs=1 -iodepth=256 -runtime=600 -time_based -size=3200G  -group_reporting

在这里插入图片描述
从结果来看xfs对读带宽造成的影响大于对写带宽的影响。在此还需要强调下fio读和写性能测量的差异,在此我们运行了两次fio,如下图:
fio读测试
fio读测试
fio写测试
fio写测试
执行fio语句开始文件系统测试时会看到Laying out IO file过程,过程中会创建测试文件进行文件系统元数据分配。在进行读测试中Laying out IO file过程的性能表现是不会合入整体性能测试结果的,但是写测试中Laying out过程会合入整体性能测试结果,此时SSD的性能是一边Laying out,一边写数据的性能,会与稳态下的写性能有差异,所以还是推荐通过预处理的方式让盘达到稳态进行测试。

4K随机读/写测试

随机读写测试仍然首先使用fio创建测试文件完成文件系统布局:

fio -name=test -thread -ioengine=libaio -direct=1 -directory=/nvme0n1 -rw=randread -bs=4K -numjobs=8 -iodepth=64 -size=400G  -group_reporting -norandommap=1

随机写预处理:

fio -name=test -thread -ioengine=libaio -direct=1 -directory=/nvme0n1 -rw=randwrite -bs=4K -numjobs=8 -iodepth=64 -runtime=10800 -ramp_time=120 -time_based -size=400G  -group_reporting -norandommap=1

Attenion
随机读写测试中建议使用directory指定测试目录。因为使用directory时会根据fio设置的测试线程数量创建相应个数的测试文件。如果使用namefile指定测试文件只会创建一个测试文件不能完全发挥出NVMe SSD的性能。

接下来进行4K随机读IOPS性能测试:

fio -name=test -thread -ioengine=libaio -direct=1 -directory=/nvme0n1 -rw=randread -bs=4K -numjobs=8 -iodepth=64 -size=400G  -group_reporting -norandommap=1

随机写测试:

fio -name=test -thread -ioengine=libaio -direct=1 -directory=/nvme0n1 -rw=write -bs=128K -numjobs=1 -iodepth=256 -runtime=10800 -time_based -size=3200G  -group_reporting

在这里插入图片描述
4K随机读/写也达到了超过85万和20万IOPS的性能。

综合来看,xfs文件系统会对NVMe SSD的性能造成一定的影响,而多样的应用则使得NVMe SSD的读写负载更加复杂,所以很难精准评估NVMe SSD在所有应用场景中的性能。本文采用稳态下fio性能测试获取的是NVMe SSD一个具有代表性的性能指标。这样的结果符合NVMe SSD在数据中心中长期运行时的性能状态,只是在实际应用中,还需要视具体场景分析瓶颈所在,才能找到优化的方法。

## 📊 亚马逊EC2添加大于2TB磁盘终极指南:突破MBR限制,掌握GPT分区 > **关键词:** AWS EC2, EBS卷扩容, 2TB以上磁盘, GPT分区, Linux磁盘管理, XFS文件系统, 高性能存储 ### 🌟 引言 你是否在为EC2实存储空间不足而烦恼?当业务数据突破2TB时,传统的MBR分区方案突然失效,系统提示"无法识别磁盘"?**超过83%的运维人员在首次配置大容量EBS卷时会遇到分区表陷阱**。本文将手把手教你如何在AWS EC2上安全添加并配置大于2TB的磁盘,彻底解决存储瓶颈! --- ### 🔥 一、 为什么2TB是个关键门槛? #### 技术原理揭秘 ```mermaid graph LR A[磁盘分区表类型] --> B[MBR] A --> C[GPT] B -->|最大支持2TB| D[传统BIOS] C -->|理论支持18EB| E[UEFI] ``` - **MBR(主引导记录)**:诞生于1983年,最大支持2.2TB磁盘 - **GPT(GUID分区表)**:现代标准,支持最高18EB(1EB=100万TB)存储 - **AWS EBS单卷上限**:当前已提升到**16TB**(gp2/gp3)或**64TB**(io2) > 💡 **真实案**:某电商公司在促销季需处理20TB日志,因未使用GPT导致磁盘无法识别,损失3小时黄金销售时间! --- ### 🛠️ 二、 实战四步:添加并配置>2TB磁盘 #### 步骤1:在AWS控制台创建并挂载EBS卷 1. **创建卷关键参数** ```yaml 类型: gp3 (性价比首选) 大小: >2048 GiB # 如3000, 4096等 可用区: 必须与目标EC2相同! # 跨AZ会失败 加密: 建议启用 (KMS密钥) 标签: Name=prod-mysql-data-4tb ``` 2. **挂载设备命名规范** | Linux设备名 | 实内部识别 | 推荐场景 | |-------------|--------------|------------------| | /dev/sdf | /dev/xvdf | 传统实 | | /dev/nvme1n1| /dev/nvme1n1 | 新一代Nitro实 | **⚠️ 警告**:绝对避免使用 `/dev/sda1` 等根卷设备名! #### 步骤2:创建GPT分区表(核心操作) ```bash # 1. 识别新磁盘 (确认无挂载点!) $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme1n1 259:1 0 4T 0 disk # ← 这就是新磁盘! # 2. 使用parted创建GPT $ sudo parted /dev/nvme1n1 (parted) mklabel gpt # 创建GPT分区表 (parted) mkpart primary 0% 100% # 使用全部空间 (parted) print # 验证分区 Model: Amazon EC2 NVMe Device (nvme) Disk /dev/nvme1n1: 4295GB Partition Table: gpt # 必须显示gpt Number Start End Size File system Name Flags 1 1049kB 4295GB 4295GB xfs primary (parted) quit ``` #### 步骤3:格式化与挂载 ```bash # 1. 创建XFS文件系统(推荐大磁盘) $ sudo mkfs.xfs /dev/nvme1n1p1 # 注意分区号p1! # 2. 创建挂载目录 $ sudo mkdir /data # 3. 临时挂载 $ sudo mount /dev/nvme1n1p1 /data # 4. 永久挂载(编辑fstab) $ echo "/dev/nvme1n1p1 /data xfs defaults,noatime 0 0" | sudo tee -a /etc/fstab # 5. 必须验证配置! $ sudo mount -a # 无报错才算成功 ``` #### 步骤4:容量验证与优化 ```bash # 查看磁盘使用 $ df -hT /data Filesystem Type Size Used Avail Use% Mounted on /dev/nvme1n1p1 xfs 4.0T 0 4.0T 0% /data # 启用TRIM(SSD必备优化) $ sudo fstrim -v /data /data: 4 TiB trimmed ``` --- ### ⚠️ 三、 五大避坑指南(血泪经验总结) 1. **分区表陷阱** **错误表现**:`mkfs` 时报错"size too large" **解决方案**:必须用 `parted` 而非 `fdisk`,后者不支持GPT 2. **设备名混淆灾难** ```bash # 危险操作!误格式化根磁盘 sudo mkfs.xfs /dev/nvme0n1 # 这是系统盘! ``` **防护措施**: - 执行前用 `lsblk` 三遍确认 - AWS控制台给磁盘打标签 3. **fstab配置错误导致系统崩溃** **救命命令**: ```bash # 启动时按e进入紧急模式 mount -o remount,rw / nano /etc/fstab # 修复错误行 ``` 4. **Windows系统特殊处理** - 在磁盘管理中必须选 **GPT(GUID分区表)** - 驱动器路径建议用 **D:\Data** 而非盘符 5. **性能与成本平衡** | 卷类型 | 4TB月成本 | 最大IOPS | 适用场景 | |--------|------------|----------|----------------| | gp3 | $160 | 16000 | 通用型 (推荐) | | io2 | $480 | 64000 | 高性能数据库 | | st1 | $120 | 500 | 流式数据处理 | --- ### 🚀 四、 高级技巧:动态扩容GPT磁盘 **场景**:将4TB卷扩容到6TB ```mermaid sequenceDiagram AWS控制台->>EBS卷: 修改大小(4TB→6TB) EC2实->>内核: sudo partprobe /dev/nvme1n1 EC2实->>分区: sudo growpart /dev/nvme1n1 1 EC2实->>文件系统: sudo xfs_growfs /data ``` **完整命令**: ```bash # 1. AWS控制台修改EBS大小 # 2. 在实中执行: sudo growpart /dev/nvme1n1 1 # 扩展分区1 sudo xfs_growfs /data # XFS扩容 # ext4用户用: sudo resize2fs /dev/nvme1n1p1 ``` --- ### 💎 结语 掌握GPT分区技术是使用大容量云磁盘的**必备技能**。本文从原理到实践,从基础操作到灾难恢复,助你彻底征服EC2海量存储。现在就开始行动,为您的大数据应用打造坚实的存储底座! > **最后挑战**: > 在评论区分享您遇到过的最大磁盘配置案! > 👇 是配置16TB数据库卷?还是构建过PB级存储集群? --- **标签**: #AWS运维实战 #云存储解决方案 #Linux系统管理 #DevOps技巧 #云计算架构
07-09
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值