磁盘负载指标 %iowait, await, %util 的正确理解

最新推荐文章于 2024-06-24 12:32:11 发布
最新推荐文章于 2024-06-24 12:32:11 发布
阅读量2.9w 收藏 85
点赞数 19
文章标签： linux 操作系统 储存器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/mrsate/article/details/105372924
版权

说明

%iowait, await, %util 是用来衡量硬盘负载的三个指标, 但是这几个指标通常容易被误解, 实际上, 这三个指标单纯的高, 并不一定能说明相应的磁盘有问题或者有瓶颈, 而是需要结合具体执行 IO 操作的程序的执行方式, 综合的来判断指标高的原因.

关于 await, %util 的计算方式可以参照:
linux iostat 输出详解

总结

%iowait:

最容被误解的参数, 实际上这是一个非常宏观的系统指标, 其表示 "CPU空闲 并且 有未完成的IO " 这种状态在一个采样周期里的占比, 一般来说当一个进程进行同步的 IO 操作时, 进程将会被挂起, CPU 将会空闲, 等待 IO 完成, 这时候如果没有其它进程占用 CPU 此时的状态将会被计入 iowait 的统计时间以内. 但是 CPU 空闲也只是当前进程空闲, 空闲出来的 CPU 是可以进行其它操作的, 如果此时 %iowait 较高, 只能说明在等待 IO 完成的时间里系统没有其它进程来占用 CPU 了, 而 IO 未完成, 有可能只是单纯的 IO size 比较大, 完成需要较长时间, 并不一定是 IO 有问题.

而且如果等待 IO 完成时系统有其它繁忙的进程占用了 CPU, 那么无论此时 IO 完成时间多长(即使是IO完全卡死), %iowait 也会非常的低, 因为此时CPU不空闲了, 因为 %iowait 只是反映 "CPU空闲 并且 有未完成的IO " 这种状态时间的占比, 两个条件缺少一个都不会计入 iowait 的时间.

await

每个I/O的平均耗时, 包括在内核 IO 队列内的时间和在存储设备上执行此 IO 的时间, 所以 await 高可能有两个原因, 一是 IO 在 IO queue 里耗时较长, 另一个就是由于 IO 在存储设备上执行的时间比较长, 而 IO 在 IO queue 里耗时较长可能是由于程序一次并发了过多的 IO, 让 IO 在 queue 排队, IO 在存储设备上执行的时间比较长也有可能时 IO 本身就比较大, 例如在硬盘上写 1KB 文件, 耗时一定是比 1MB的时间短的, 所以 await 高, 还要结合业务本身的特点判断 await 高的原因

%util

这个反映 IO queue, 中存在 IO 在采样周期里的占比, 只要 IO queue 中存在 IO, 就会被计入到 %util 的时间内, 无论是 1 个 IO 或者 100 个IO, 并且也只计算 IO 存在于 queue 里面的时间, 所以此时即使磁盘压力较大, 但是 IO queue 中并没有排队的 IO 那么 %util 也不会高(例如每次 IO size 都比较大), 或者有些程序进行顺序 IO, 完成几个再发下一个, 并且 IO size 并不大, 此时即使磁盘压力较小 %util 也会比较高

测试

环境和命令

使用 fio 模拟客户端, 通过不同的 fio 引擎和不同的队列深度配置来模拟顺序的和并发的 IO

环境如下

[root@centos-76-c1~]# uname -a
Linux centos-76-c1 5.5.7-1.el7.elrepo.x86_64 #1 SMP Fri Feb 28 12:21:58 EST 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@centos-76-c1~]# cat /etc/redhat-release 
CentOS Linux release 7.6.1810 (Core) 
[root@centos-76-c1~]# fio --version
fio-3.1

使用 iostat -mx 1 10000 sdb 来模监控 %iowait, await , %util 具体数值

[root@centos-76-c1~]# iostat -mx 1 10000 sdb
Linux 5.5.7-1.el7.elrepo.x86_64 (centos-76-c1) 	03/05/2020 	_x86_64_	(1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.46    0.00    0.78   12.33    0.00   85.43

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.66    0.60  263.41     0.01     1.17     9.20    21.27   81.06    7.02   81.23   0.16   4.23

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.00    0.00    0.00  100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

......

%iowait

%iowait 与 CPU 本身的关系

找一个 CPU 空闲的时期

[root@centos-76-c1~]# top -n 1
top - 17:38:33 up  1:02,  3 users,  load average: 0.00, 0.10, 0.12
Tasks: 136 total,   1 running,  81 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   977804 total,   696812 free,   105696 used,   175296 buff/cache
KiB Swap:  1572860 total,  1572860 free,        0 used.   697424 avail Mem

随便增加一些负载差不多的普通负载, 观察此时的 iowait

[root@centos-76-c1~]# fio --name=randwrite --rw=randwrite --bs=16k --size=1G --runtime=60 --ramp_time=20 --ioengine=sync --numjobs=1 --filename=/dev/sdb --direct=1 --group_reporting 
randwrite: (g=0): rw=randwrite, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=sync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][r=0KiB/s,w=1472KiB/s][r=0,w=92 IOPS][eta 00m:00s]
randwrite: (groupid=0, jobs=1): err= 0: pid=7724: Thu Mar  5 17:56:42 2020
  write: IOPS=86, BW=1390KiB/s (1423kB/s)(81.5MiB/60004msec)
    clat (usec): min=2917, max=48358, avg=11505.79, stdev=4808.19
     lat (usec): min=2918, max=48359, avg=11506.34, stdev=4808.19
.....

iowait 达到了 99%

......
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    1.00   99.00    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00  101.00     0.00     1.58    32.00     0.94    9.86    0.00    9.86   1.02  10.30

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.00  100.00    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00   97.96     0.00     1.53    32.00     0.97   10.41    0.00   10.41   1.02  10.00
......

此时增加一个十分耗费 CPU 的计算圆周率的命令, 计算 50000 位的圆周率

[root@centos-76-c1~]# time echo "scale=50000; 8*a(1)" | bc -l -q

此时 CPU 利用率已经非常高

[root@centos-76-c1~]# top -n 1
top - 17:59:21 up  1:22,  3 users,  load average: 0.21, 0.17, 0.09
Tasks: 138 total,   2 running,  81 sleeping,   0 stopped,   0 zombie
%Cpu(s):100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   977804 total,   696652 free,   105816 used,   175336 buff/cache
KiB Swap:  1572860 total,  1572860 free,        0 used.   697288 avail Mem

这是可以看到 %iowait 直接变成了 0.00

......
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
         100.00    0.00    0.00    0.00    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00   66.00     0.00     1.03    32.00     0.66   10.48    0.00   10.48   1.98  13.10

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          99.01    0.00    0.99    0.00    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00   69.31     0.00     1.08    32.00     0.66   10.11    0.00   10.11   2.00  13.86
......
总结

通过上面的测试可以证明 %iowait 是一个十分宏观的一个参数, 系统其他服务对 CPU 的利用会直接影响这个数值, 如果 CPU 利用率够高, 即使此时 IO 完全卡死, 此时 %iowait 可能也很低. %iowait 即使很高, 实际上硬盘的压力可能也不大.

await

await 和 iodepth 的关系

使用 fio 模拟客户端, 固定大小的 io 请求, 通过配置不同的 --iodepth= --iodepth_batch_submit= --iodepth_low= 来实现不同并发度的 IO

[root@centos-76-c1~]# fio --name=randwrite --rw=randwrite --bs=4k --size=1G --runtime=60 --ramp_time=20 --ioengine=libaio --iodepth=<iodepth> --iodepth_batch_submit=<iodepth> --iodepth_low=<iodepth>  --numjobs=1 --filename=/dev/sdb --direct=1 --group_reporting
测试结果
iodepthIOPSBWavgqu-szawait
190363KiB/s0.203.03
43371349KiB/s2.176.51
1611684676KiB/s10.007.50
6418287317KiB/s47.9718.33
25618517424KiB/s252.03300 ~ 500
102417236963KiB/s270.84300 ~ 600
总结

随着并发度越来越高, 达到了本机 IO 能承受的 IO 的上限, 大量 IO 在存储集群里面排队, 可以看到 await 随着 IO 在队列中排队时间的增大而逐渐增大

await 和 iosize 的关系

使用 fio 模拟客户端, 固定大小的 io iodept, 通过配置不同的 --bs=<block_size> 来实现不同<block_size>的 IO (block_size 即一次读写的文件的大小)

[root@centos-76-c1~]# fio --name=randwrite --rw=randwrite --bs=<block_size>  --size=1G --runtime=60 --ramp_time=20 --ioengine=libaio --iodepth=1 --iodepth_batch_submit=1 --iodepth_low=1  --numjobs=1 --filename=/dev/sdb --direct=1 --group_reporting
测试结果
block_sizeIOPSBWavgrq-szavgqu-szawait
4KiB90364KiB/s8.000.252.93
16KiB691120KiB/s32.000.649.75
64KiB301948KiB/s128.000.8430.11
256KiB113004KiB/s512.000.9389.90
1MiB44168KiB/s2048.001.14227.00
4MiB14531KiB/s2048.00 - 2560.003.46902.75
16MiB05206KiB/s2048.00 - 2560.0012.502223.40
总结

可以看到随着 block_size 即 一次读写的文件的大小不断增加, await 也逐渐增加, 实际上此时 IO 并不能说 IO 是瓶颈, 或者 IO 延时过高, 只是单纯的完成大 IO 耗时更长

%util

%util 与 IO 的关系

使用 fio 分别测试不同 iosize 的同步 IO

[root@centos-76-c1~]# fio --name=randwrite --rw=randwrite --bs=4K --size=1G --runtime=60 --ramp_time=20 --ioengine=sync --numjobs=4 --filename=/dev/sdb --direct=1 --group_reporting --sync=1
randrw: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=sync, iodepth=1

...
fio-3.1
Starting 4 processes
Jobs: 2 (f=2): [E(0),w(4)][100.0%][r=0KiB/s,w=1081KiB/s][r=0,w=270 IOPS][eta 00m:00s]
randrw: (groupid=0, jobs=4): err= 0: pid=8310: Thu Mar  5 19:24:57 2020
  write: IOPS=292, BW=1169KiB/s (1197kB/s)(68.5MiB/60004msec)

......

......
Davg-cpu:  %user   %nice %system %iowait  %steal   %idle
         100.00    0.00    0.00    0.00    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00  325.00     0.00     1.27     8.00     2.17    7.18    0.00    7.18   1.17  38.10

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          99.00    0.00    1.00    0.00    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00  309.00     0.00     1.21     8.00     2.28    7.87    0.00    7.87   1.08  33.40
......

[root@centos-76-c1~]# fio --name=randwrite --rw=randwrite --bs=1m --size=1G --runtime=60 --ramp_time=20 --ioengine=sync --numjobs=4 --filename=/dev/sdb --direct=1 --group_reporting --sync=1
randwrite: (g=0): rw=randwrite, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=sync, iodepth=1
...

fio-3.1
Starting 4 processes
Jobs: 3 (f=3): [w(3),_(1)][58.2%][r=0KiB/s,w=4096KiB/s][r=0,w=4 IOPS][eta 00m:59s]
randwrite: (groupid=0, jobs=4): err= 0: pid=8396: Thu Mar  5 19:32:23 2020
  write: IOPS=4, BW=4407KiB/s (4513kB/s)(261MiB/60647msec)
    clat (msec): min=406, max=1552, avg=928.17, stdev=188.99
     lat (msec): min=406, max=1552, avg=928.21, stdev=188.99
......

......


Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00    5.00     0.00     5.00  2048.00     3.77  753.40    0.00  753.40   2.00   1.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          99.01    0.00    0.99    0.00    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00     0.00    0.00    3.96     0.00     3.96  2048.00     3.40  860.50    0.00  860.50   2.00   0.79

…

总结

可以看到当 IO size 较小时, 硬盘即使压力不大( sdb 为 ssd ) %util 也达到了 30% , 后来当 IO size 为 1M 时磁盘实际负载并不会比之前低, 但是 %util 却很低, 这与要是由于不同 size 的 IO 造成内核 IO queue 里面停留时间不同造成的, 和硬盘本身的负载并没有直接的关系

MrSate
关注
  • 19
    点赞
  • 踩
  • 85
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
iostat 中的 %util 指标说明
02-11 3273
判断磁盘极限性能误区：只通过iostat 中的 %util 指标确定磁盘是否达到带宽或iops极限 背景： 在判断磁盘是否达到极限性能时，总有人通过 iostat -x 中的 %util 指标来确认磁盘是否带宽带宽或IOPS瓶颈，其实这是不对的，特做如下说明： 结论： iostat 中的 %util 基本已经没有任何作用了，svctm也没什么参考意义 磁盘是否达到真正极限瓶颈，需要参考通过fio等工具压测出的极限带宽和IOPS值 %util与硬盘设备饱和度 %u...
磁盘I/O %util特别高
eagle89的专栏
03-21 2108
磁盘I/O %util特别高
JavaScript ES6特性
最新发布
weixin_43717498的博客
06-24 268
从 let 和 const 到 async/await，这些新特性不仅提升了代码的可读性，还极大地简化了常见的编程任务。随着 ECMAScript 2015 (ES6) 及其后续版本的发布，JavaScript 语言引入了许多新特性，使得编写代码变得更加简洁、高效和易于维护。// 输出 [1, 2, 3, 4, 5, 6]console.log(greet());// 输出 1 2 3。
性能问题诊断-服务器磁盘%util较高
junior77的专栏
10-19 2528
性能问题诊断篇- 服务器磁盘
IOSTAT中关于%util，svctm存在的陷阱及解决办法
热门推荐
老代——Oracle不仅是工作，更是兴趣
08-06 2万+
在写瓶颈确认之IO瓶颈确认之第一篇这篇博客以前，自认为对IO情况确认还是没问题的。 在写博客时，对以前理解并不确切的地方进行了深入了解。 在经过理解后，发现之前并不是不确切，而是有部分理解错误的地方，现在特意在上一篇的基础上整改一篇出来，而不是进行直接在原基础修改，就是希望可以给大家提个醒，也给自己提个醒。 Device: rrqm/s wrqm/s r/s
Linux下IO监控与分析 --转载
qq_36150038的博客
07-05 255
转自 https://www.cnblogs.com/quixotic/p/3258730.html 近期要在公司内部做个Linux IO方面的培训, 整理下手头的资料给大家分享下 各种IO监视工具在Linux IO 体系结构中的位置 源自 Linux Performance and Tuning Guidelines.pdf 1 系统级IO监控 iostat 　　iostat -xd...
linux运维指标,iostat 中的 %util 指标说明
weixin_36242382的博客
05-14 3658
判断磁盘极限性能误区：只通过iostat 中的 %util 指标确定磁盘是否达到带宽或iops极限背景：在判断磁盘是否达到极限性能时，总有人通过 iostat -x 中的 %util 指标来确认磁盘是否带宽带宽或IOPS瓶颈，其实这是不对的，特做如下说明：结论：iostat 中的 %util 基本已经没有任何作用了，svctm也没什么参考意义磁盘是否达到真正极限瓶颈，需要参考通过fio等工具压测出...
Linux下使用iostat监测IO状态.docx
10-25
### Linux下使用iostat监测IO状态 #### 一、iostat简介及基本使用 ...同时，通过深入理解iostat的输出结果，我们还可以进一步分析磁盘负载、IO等待时间等关键指标，从而更好地管理和调整系统资源。
Centos系统性能指标.pdf
10-26
监控磁盘I/O的工具如free展示了物理内存、缓冲区和缓存的使用情况，而sar工具提供了await、svctm和%util等关键指标，这些指标反映了I/O操作的等待时间、服务时间和利用率。 监控工具如vmstat和sar能够帮助我们实时...
iostat来对linux硬盘IO性能进行检测
08-26
2. `%iowait`：CPU等待I/O操作完成所占的百分比，这是衡量I/O压力的重要指标。 3. `%idle`：CPU空闲的百分比，如果这个值较低，可能意味着系统I/O负载较大。 4. `rrqm/s`和`wrqm/s`：每秒合并的读和写请求次数，合并...
GBase8s监控指标调研文档.doc
01-22
磁盘I/O Busy Rate（%util）是衡量磁盘负载的关键指标，通过`iostat`命令可以获取。%util表示磁盘一秒内用于I/O操作的时间占比，数值接近100%意味着I/O请求过于频繁，系统可能面临满负荷运行，存在磁盘瓶颈的风险。...
基于Tensorflow:CPU性能分析
12-20
4. `%iowait`：CPU空闲等待I/O操作完成的时间占比，如果这个值过高，可能是磁盘I/O成为系统性能瓶颈。 5. `%steal`：在虚拟化环境中，CPU被用于服务其他虚拟机的时间占比。 6. `%idle`：CPU空闲时间占比，如果很高，...
iostat中 %util高 应用延迟高
weixin_33753845的博客
04-14 1526
    经过长时间监控，发现iostat 中的%util居高不下，一直在98%上下，说明带宽占用率极高，遇到了瓶颈。    且读写速度很慢，经过排查，发现是HBA卡出现问题，更换后，用dd if命令测试，磁盘的读写速度均得到了10倍以上的提升。    但更换HBA卡后，虽然读写速度上去了，但应用还是有延迟，数据库日志中SQL语句都在毫秒级别，最后重启服务器，后正常。    虽然不清楚为什么，但却是...
优化命令之iostat命令
qq_45088125的博客
06-10 780
iostat主要用于监控系统设备的IO负载情况，根据这个可以看出当前系统的写入量和读取量，CPU负载和磁盘负载。iostat 主要用于输出磁盘IO 和 CPU的统计信息。iostat属于sysstat软件包。可以用yum install sysstat 直接安装。 2、命令参数 3、示例 3.1 显示所有设备的负载情况 cpu属性值说明备注： 如果%iowait的值过高，表示硬盘存在I/O瓶颈，%idle值高，表示CPU较空闲，如果%idle值高但系统响应慢时，有可能是CPU等待分配内存，此时应加大内
云主机磁盘I/O %util飙高排查
木简熙的博客
03-29 1951
linux 磁盘io util%飙高原因定位与分析
如何理解 iowait
fengye_csdn的博客
04-16 9335
Linux中，%iowait 过高可能是个问题，严重的时候，它能使服务停止， 但问题是，多高才算高？ 什么时候应该担心呢？ 本文将讨论 iowait 的含义、相关的统计数据、原理以及 iowait的瓶颈问题 什么是 iowait Linux 中的解释 Show the percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request. iowait .
Linux iowait到底是什么含义
GetnextWindow的专栏
07-08 730
IOwait 一个迷之参数，top/iostat/mpstat/sar 都会统计的关键数据，字面理解是系统等待IO的时间，经常用于反映系统IO压力。IOwait时候CPU在干什么？什么时间才算IOwait，到底在wait什么？
理解 %IOWAIT (%WIO)
永远在学习Linux之路上
05-11 8945
%iowait 是 “sar -u” 等工具检查CPU使用率时显示的一个指标，在Linux上显示为 %iowait，在有的Unix版本上显示为 %wio，含义都是一样的,这个指标常常被误读，很多人把它当作I/O问题的征兆，我自己每隔一段时间就会遇到对 %iowait 紧张兮兮的客户，不得不费尽唇舌反复解释，事实上这个指标所含的信息量非常少，不能单独用来判断系统有没有I/O问题，在此我们详细探讨一下
案例分析：磁盘I/O %util特别高
老叶茶馆
04-21 5541
*GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。一、背景简介作为一个DBA难免不了会遇到性能问题，那么我们遇到性能问题该如何进行排查呢？例如我们在高并发的业务下，出现业务响应慢，处理时间长我们又该如何入手进行排查。本篇文章将分析io高的情况下如何分析及定位。二、环境复现环境配置：本次测试使用128C_512G_4TSSD服务器配置，MySQ...
磁盘的await不高但是iowait 高
05-24
磁盘的await指的是磁盘I/O请求的平均等待时间，而iowait是CPU在等待磁盘I/O操作完成时所花费的时间。如果磁盘的await不高但是iowait高，这通常意味着有很多磁盘I/O请求在等待完成，但是CPU的负载很低，没有足够的工作来占据CPU时间。这种情况可能是由于应用程序的瓶颈或者系统配置问题导致的。为了进一步分析问题，可以使用工具如iostat、vmstat和sar等来收集系统性能数据。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值