Cpu的Iowait time过高

最新推荐文章于 2025-07-01 22:19:37 发布
最新推荐文章于 2025-07-01 22:19:37 发布
阅读量1.8w 收藏 24
点赞数 4
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_32642039/article/details/78995617
本文介绍了一台Centos服务器遇到Iowaittime达到60%的问题，并详细记录了排查流程，包括使用top、iostat、iotop等工具定位问题磁盘及进程，最终通过调整MySQL配置解决了问题。

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

一、环境

1.服务器环境
Centos 7.3 16核64G AliCloud

2.问题
服务器的Iowait time达到60%

二、排查流程

1.通过top命令发现服务器的Iowait time非常高，严重影响服务器性能。

[root@zhangwan22222222 ~]# top
top - 15:07:40 up 2 days, 23:35, 10 users,  load average: 5.02, 5.72, 6.97
Tasks: 560 total,   1 running, 558 sleeping,   0 stopped,   1 zombie
%Cpu0  :  8.7 us,  1.7 sy,  0.0 ni, 80.6 id,  9.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 19.5 us,  1.7 sy,  0.0 ni, 78.5 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 38.3 us,  2.7 sy,  0.0 ni, 57.0 id,  2.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  5.3 us,  0.3 sy,  0.0 ni, 94.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  : 40.1 us,  3.3 sy,  0.0 ni, 52.5 id,  4.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  1.3 us,  0.3 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  : 25.2 us,  3.0 sy,  0.0 ni, 71.2 id,  0.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  2.0 us,  0.3 sy,  0.0 ni, 97.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu8  : 36.0 us,  3.0 sy,  0.0 ni, 60.7 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu9  : 11.3 us,  1.0 sy,  0.0 ni, 87.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu10 : 26.2 us,  2.7 sy,  0.0 ni, 70.8 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu11 :  8.7 us,  3.0 sy,  0.0 ni, 88.0 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu12 : 25.3 us,  2.3 sy,  0.0 ni, 72.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu13 :  1.7 us,  7.3 sy,  0.0 ni, 91.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu14 : 28.7 us,  5.3 sy,  0.0 ni, 64.0 id,  2.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu15 :  2.3 us,  1.0 sy,  0.0 ni, 96.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 65808484 total,   467080 free, 14657588 used, 50683816 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 50511032 avail Mem

2.定位问题磁盘

[root@zhangwan22222222 xc]# iostat -x 2 5
Linux 3.10.0-514.26.2.el7.x86_64 (zhangwan22222222)     01/07/2018  _x86_64_    (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          33.53    0.00    5.00   25.59    0.00   35.89

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda              25.03  1022.15 4257.57  734.19 196186.95  9116.98    82.26    15.91    3.18    3.16    3.33   0.16  79.69
dm-0              0.00     0.00    0.00    0.00     0.00     0.00    21.14     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.67    0.00    0.63    1.75    0.00   87.96

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               4.00    92.50  680.00  113.50 36380.00   856.00    93.85     1.61    2.03    2.27    0.60   0.40  31.60
dm-0              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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.60    0.00    0.69    0.34    0.00   92.37

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    76.00   94.00   96.00  4070.00   690.00    50.11     0.24    1.25    1.74    0.78   0.42   8.05
dm-0              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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          37.27    0.00    4.78    1.97    0.00   55.97

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00   679.50  185.50  986.50  9398.00  6804.00    27.65     1.10    0.94    2.17    0.71   0.34  40.05
dm-0              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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          56.36    0.00    6.56    2.16    0.00   34.92

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00  1031.00  105.50 1325.00  5252.00 10276.00    21.71     1.08    0.75    2.00    0.65   0.30  42.60
dm-0              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

上边的例子中，iostat 会每2秒更新一次，一共打印5次信息， -x 的选项是打印出扩展信息

第一个iostat 报告会打印出系统最后一次启动后的统计信息，这也就是说，在多数情况下，第一个打印出来的信息应该被忽略，剩下的报告，都是基于上一次间隔的时间。

在上面的例子中，vda的%util 是42.60%，说明了有进程正在写入到vda磁盘中。

3.查看哪个进程占用的I/O过高

使用iotop，ps，lsof
iotop

Total DISK READ :      51.40 M/s | Total DISK WRITE :      25.98 M/s
Actual DISK READ:      51.44 M/s | Actual DISK WRITE:      28.12 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                
29746 be/4 mysql      50.51 M/s  122.75 K/s  0.00 % 40.81 % mysqld --basedir=/us~ysql.sock --port=3306
  375 be/3 root        0.00 B/s   30.69 K/s  0.00 % 20.85 % [jbd2/vda1-8]

我没有记录当时的数据，这是解决后的。当时统计出来大量占用io读写的是mysql和[jbd2/vda1-8]

4.使用ps命令定位问题io进程

我们每5秒获取一次，一共获取10次。

[root@zhangwan22222222 xc]# for x in `seq 1 1 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done
D   375 [jbd2/vda1-8]
----
D   375 [jbd2/vda1-8]
----
D   375 [jbd2/vda1-8]
D  2747 sendmail: w0784B99002747 localhost [127.0.0.1]: DATA
----
D   375 [jbd2/vda1-8]
----
D   375 [jbd2/vda1-8]
----
D   375 [jbd2/vda1-8]
D  2878 php /web/phalcontest_2/task/run main main 24
----
D   375 [jbd2/vda1-8]
----
----
D   375 [jbd2/vda1-8]
----
----

D的状态一般是I/O出现了问题，说明进程在等待I/O，可以是磁盘I/O，网络I/O或者其他，详细：
https://blog.xupeng.me/2009/07/09/linux-uninterruptible-sleep-state/

到这里我们已经可以发现是pid为375的jbd2/vda1-8进程的问题。

5.lsof -p可以定位到进程写入的文件

[root@zhangwan22222222 xc]# lsof -p 375
COMMAND   PID USER   FD      TYPE DEVICE SIZE/OFF NODE NAME
jbd2/vda1 375 root  cwd       DIR  253,1     4096    2 /
jbd2/vda1 375 root  rtd       DIR  253,1     4096    2 /
jbd2/vda1 375 root  txt   unknown                      /proc/375/exe

这里定位到文件我不知道如何利用，但是我们已经知道了问题进程。

三、解决

1.

使用iotop发现这个进程 jdb2/sdb1-8 使用率高达40%到90%。

2.修改mysql参数

（1）第一步

修改sync_binlog=1为sync_binlog=10
因为sync_binlog=1导致事务写入太频繁，改为10后Iowait time明显下降。

可能还有个参数innodb_flush_log_at_trx_commit也会影响io性能，我设置的这个值是2，所以就没有修改

以下摘自网络：

sync_binlog”：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：

sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。

sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。

从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

这里的解决方法转自：
http://www.cnblogs.com/z-books/p/7324949.html

（2）第二步
这一步要根据自己服务器的情况修改,多核cpu可以通过这两个参数更有效的利用cpu性能

innodb_write_io_threads = 32
#脏页写的线程数，加大该参数可以提升写入性能.mysql5.5以上才有。
innodb_read_io_threads = 16
#读取
十月鱼
关注
cpu的iowait指标解释及示例
zhaoxin1989的博客
04-01 1495
cpu的iowait指标，in_iowait，nr_iowait，iowait高的场景，top里的idle
oracle数据库iowait高,CPU-IOWAIT分析
weixin_34859739的博客
04-14 2192
某系统的备DB的CPU iowait[6%]高于其他机器无影响：一般iowait在20%才会影响到业务背景说明：此场地使用的是一主两备的架构。主库使用的是sas盘，两台备库使用的是sata盘此场地使用的是一主两备的架构。主库使用的是sas盘，两台备库使用的是sata盘实际使用过程中采取级联的方式，主库同步数据给一台备库，这台备库再同步给另外一台备库就导致其中一台备库数据读写频繁，IOWAIT偏高服...
cpu iowait偏高故障处理
GGB_GG的博客
01-21 1814
vmstat 可以观察到 b（block的进程，也叫不可中断进程）一直维持在8， 正好符合 cpu的upload的数值。也可以观察到 cpu的iowait数值和 top中的一致。pidstat -d 虽然可以观察到进程的 读写io情况，也可以观察到进程的 cpu 使用情况（cpu的统计中 缺少iowait 指标），无法关联。至此，可以看到，iowait值 在 20左右的时候，net的 收流量一直有 几十兆，所以怀疑的重心就转移到网络上来。所以，希望找到cpu的负载和io设备的统计，可以同时查看的工具。
iowait过高问题查找及解决方案
一摩尔自由的博客
12-08 4325
一、iostat和iowait详细解说-查看磁盘瓶颈一、iostat基础 　　%iowait并不能反应磁盘瓶颈 1、安装iostat 　　iostat的包名叫sysstat yum install sysstat -y 　　2、iowait实际测量的是cpu时间： %iowait = (cpu idle time)/(all cpu time) 　　说明：高速cpu会造成很高的iowait值，但这并不代表磁盘是系统的瓶颈。唯一能说明磁盘是系统瓶颈的方法，就是很高的read/write时间，一般来说超..
MySQL慢查询全解析：从日志分析到优化实战，一篇文章搞定！
最新发布
weixin_42148384的博客
07-01 922
MySQL慢查询是指执行时间过长或资源消耗过高的SQL查询，通常会影响数据库性能和系统响应速度。优化慢查询是提升数据库性能的关键手段。本文将从慢查询定义与影响、慢查询日志配置、日志分析工具、执行计划（EXPLAIN）​、常见慢查询原因及优化策略等方面进行详解。
生产磁盘busy、cpu-wait高排查
sunxj1222的博客
07-11 1611
1、分析：磁盘busy--->io慢--->cpu-wait增高 2、使用工具 a、iostat -x：查询磁盘读写速度 注：lsblk查看磁盘对应关系 b、ps -eo state,pid,cmd | grep "^D" ：查看哪些进程处于等待磁盘的状态 c、top ：查看cpu-wait 参考：https://blog.youkuaiyun.com/donglynn/ar...
CPU平均负载过高检查（iowait负载高）
热门推荐
settng style
06-23 1万+
简单介绍了怎么测试CPU负载和CPU负载过高好如何检测
IOWAIT 异常
心中天堂的专栏
01-16 1112
调试和分析IOWAIT高的异常过程
CPU-IOWAIT分析
binshaizhen2524的博客
08-02 5159
某系统的备DB的CPU iowait[6%]高于其他机器无影响：一般iowait在20%才会影响到业务背景说明：此场地使用的是一主两备的架构。主库使用的是sas盘，两台备库使用的是sata盘此场地使用的是一主两备的架构。主库使用的是sas盘，两台备库使用的是sata盘实际使用过程中采取级联的方式，主库同步数据给一台备库，这台备库再同步给另外一台备库就导致其中一台备库数据读写频...
LINUX CPU iowait一般性问题分析
有莘不破的博客
04-17 2051
LINUX上遇到iowait问题的一般性排查手段
cpu逐渐增高_性能分析（4）- iowait 使用率过高案例
weixin_32691913的博客
01-14 1819
性能分析小案例系列，可以通过下面链接查看哦https://www.cnblogs.com/poloyy/category/1814570.html前言前面两个案例讲的都是上下文切换导致的 CPU 使用率升高这一篇就来讲讲等待 I/O 导致的 CPU 使用率升高的案例进程状态详解进程状态https://www.cnblogs.com/poloyy/p/13413770.html不可中断状态当 iow...
Iowait 的成因、对系统影响及对策
09-21
什么是 iowait？ 顾名思义，就是系统因为 io 导致的进程 wait。再深一点讲就是：这时候系统在做 io ，导致 没有进程在干活，cpu 在执行 idle 进程空转，所以说 iowait 的产生要满足两个条件，一是进 程在等 io ，二是等 io 时没有进程可运行
解决cpu io waitTime100%
keyboard专栏
07-11 4797
今天收到了阿里云的ECS短信报警，内存占用率到90%，因为已经报警好几天，已经要迁移ECS机器，所以就没有在意。直到看到ZABBIX的监控的报警，显示cpu io waitTime 异常，看来问题需要解决才行。 使用iotop命令查看那个进程是引起cpu io waitTime的罪魁祸首，发现kswapd0 占用了99.99% kswapd0 是个什么东西？ Linux uses k...
top命令显示iowait (wa)非常高时怎么排查
02-19 995
当top命令显示非常高时，表示系统正在等待 I/O 操作完成。要确定是磁盘 I/O 还是网络 I/O 导致的等待，可以使用以下工具和方法进行进一步排查。
sync_supers 线程造成 CPU user time 达到80%
weixin_34109408的博客
05-17 533
起因：zabbix 报警数据库服务器 CPU使用率突然高于80% 使用 top 命令查看CPU使用情况，cpu user time达到80%多，而没有看到占CPU多的进程 使用 ps aux 查看CPU使用情况，发现 sync_supers 占用大量CPU资源 使用命令 kill -STOP 25683 暂停进程，CPU使用率恢复正常 参考博文：https://blog.youkuaiyun.com/zjj...
CPU iowait是什么意思
Tom098的博客
03-03 916
举个例子，当服务器要访问网络文件系统（比如storage server通过NFS方式让客户端访问），由于网络的问题或者远端server性能问题导致响应慢，而当前服务器又有大量进程、线程要访问这个远端文件系统，当这些进程、线程在某个时刻都处于等待IO的状态，这是这个CPU时间片就会被统计到iowait中。我们直到，在cpu运行进程、线程时，遇到IO操作，因为IO读写通常比较慢，CPU通常可以阻塞线程，转去执行其他线程，做其他事情。等IO完成之后，通过中断，再通知CPU继续执行之前的线程。
iowait高
ang639
02-22 5115
当时场景是VM上iowait和%util都是100%。 物理机稍微好点， iowait 30%~50%, %util也近100% 后面实在不行就对物理机进行重启，启动进不去系统，准备重装时发现硬盘灯有黄灯。由于有raid，把坏硬盘拔掉，就工作正常了。 中间定位iowait的过程涉及命令有: # iostat -x 1 Linux 2.6.32-220.el6.x86_64 (SN
CPU用户时间百分比
付聪
11-01 1142
在计算机系统中，"CPU用户时间百分比（CPU User Time）"是一个性能监控指标，它描述了CPU在用户模式下执行的累积时间与总的CPU时间的比例。这个指标可以帮助我们了解系统在执行用户态程序时的负载情况。
cpu iowait百分比差大
03-12
<think>好的，我现在要解决用户关于Linux系统中CPU iowait百分比差异大的问题。首先，我需要理解iowait究竟是什么。根据之前的知识，iowait表示CPU在等待I/O操作完成时的空闲时间百分比。当这个值很高时，说明系统可能在等待磁盘、网络或其他I/O设备，导致CPU无法执行其他任务。 接下来，用户提到iowait百分比差异大，可能是指不同时间段或不同CPU核心之间的差异较大。这可能由多种因素引起。首先，我需要分析可能的原因，比如是否有某些进程在进行大量的I/O操作，或者磁盘性能不足，或者存在资源争用的情况。 然后，我需要考虑如何诊断这个问题。常用的工具包括top、iostat、iotop、vmstat和pidstat等。例如，使用iostat可以查看各设备的I/O负载情况，而iotop可以查看具体进程的I/O使用情况。另外，检查磁盘的健康状况和使用率也很重要，比如使用df -h查看磁盘空间，smartctl检查磁盘健康。 此外，系统配置也可能影响iowait。比如I/O调度算法的选择，不同的调度算法对不同的工作负载有不同效果。还有文件系统的调整，如noatime选项可以减少元数据更新带来的I/O开销。对于RAID阵列，条带大小和缓存策略的设置也会影响性能。 在解决方案方面，可能需要优化应用程序的I/O模式，比如减少小文件的频繁读写，使用批量写入或异步I/O。增加硬件资源如使用SSD替换HDD，或者优化内核参数如调整vm.dirty_ratio和vm.dirty_background_ratio来管理写回缓存。 最后，需要验证解决方案的有效性。通过持续监控iowait的变化，确认优化措施是否有效。同时，引用相关文档，比如Red Hat的性能调优指南，可以提供更权威的建议。 现在，我需要将这些思考整理成结构化的回答，确保涵盖原因、诊断方法、解决方案和验证步骤，并生成相关问题供用户进一步参考。</think>### CPU iowait百分比差异大的原因及解决方法 #### 1. **iowait的定义** iowait表示CPU在等待I/O操作（如磁盘读写、网络请求）完成时的空闲时间百分比。高iowait值通常意味着系统存在I/O瓶颈，导致CPU无法执行其他任务[^1]。 --- #### 2. **可能原因分析** - **I/O密集型进程**：某些进程频繁读写磁盘或网络（如数据库、日志服务）。 - **磁盘性能不足**：机械硬盘（HDD）或慢速存储设备导致I/O延迟。 - **资源争用**：多进程/线程同时访问同一磁盘或文件。 - **配置问题**：文件系统未优化、I/O调度算法不匹配或RAID配置不当。 - **硬件故障**：磁盘损坏或网络设备异常。 --- #### 3. **诊断方法** ##### 工具使用： 1. **`iostat`**：查看设备级I/O负载 ```bash iostat -x 2 5 # 每2秒输出一次，共5次，观察%util和await值 ``` - `%util > 70%`表示设备接近饱和。 - `await`值高说明I/O响应时间长。 2. **`iotop`**：定位高I/O进程 ```bash iotop -o # 显示活跃I/O进程 ``` 3. **`vmstat`**：全局I/O状态 ```bash vmstat 1 # 查看bi（块读）、bo（块写）频率 ``` 4. **`pidstat`**：进程级I/O统计 ```bash pidstat -d 1 # 显示各进程的kB_rd/s和kB_wr/s ``` 5. **磁盘健康检查**： ```bash smartctl -a /dev/sda # 检查磁盘SMART状态 df -h # 查看磁盘空间使用率 ``` --- #### 4. **解决方案** ##### A. 优化应用程序 - **减少小文件频繁读写**：合并写入操作或使用内存缓存。 - **异步I/O**：使用`libaio`或非阻塞I/O模型（如Node.js、Nginx）。 - **数据库调优**：调整日志刷新频率（如MySQL的`innodb_flush_log_at_trx_commit`）。 ##### B. 硬件/存储优化 - **更换SSD**：随机读写性能提升10倍以上。 - **RAID优化**：RAID 10比RAID 5更适合写密集场景。 - **分离高负载设备**：将日志、数据库分盘存储。 ##### C. 系统配置调整 - **I/O调度算法**： ```bash echo deadline > /sys/block/sda/queue/scheduler # 适用于机械硬盘 echo kyber > /sys/block/nvme0n1/queue/scheduler # 适用于NVMe SSD ``` - **文件系统参数**： 在`/etc/fstab`中添加`noatime,nodiratime`减少元数据更新。 - **内核参数调优**： ```bash sysctl -w vm.dirty_ratio=10 # 减少脏页最大阈值 sysctl -w vm.dirty_background_ratio=5 # 提前触发写回 ``` ##### D. 其他措施 - **限流I/O密集型进程**： ```bash ionice -c 3 -p <PID> # 将进程I/O优先级设为最低 ``` - **使用cgroup限制I/O带宽**： ```bash systemctl set-property <service> BlockIOReadBandwidth="/dev/sda 10M" ``` --- #### 5. **验证效果** - **持续监控**：通过`dstat`或`grafana+Prometheus`观察iowait变化。 - **对比测试**：优化前后使用`fio`进行基准测试： ```bash fio --name=test --ioengine=libaio --rw=randread --bs=4k --numjobs=4 --runtime=60 --time_based ``` ---
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值