mysql压力测试在京东云ssd云盘（tpccmysql压测）

最新推荐文章于 2022-08-05 09:30:00 发布
最新推荐文章于 2022-08-05 09:30:00 发布
阅读量456 收藏
点赞数
文章标签： 数据库
一、环境：京东云Centos6.8 ，cpu16核,内存32G，SAS 3G,转速未知 ，SSD云盘300G
     mysql 版本是：5.7.20 ，默认rpm安装,单实例。
     压测工具是：tpcc-mysql5.0
mysql压力测试在京东云ssd云盘
首先加载数据，加载10个warehouse,现在数据库tpcc1000有9张表，warehouse10条记录，stock表有100万，item表有10万，order_line299万，new_orders11万，orders30万，  customer30万。
  1. 现在数据库tpcc1000有9张表，warehouse10条记录，stock表有100万，item表有10万，order_line1186万，new_orders11万，orders118万，  customer30万,查看一下实际表空间的大小：
  2. [mysql@mysql3 mysql1]$ ls -lhS tpcc1000/
  3. total 2.3G
  4. -rw-r----- 1 mysql mysql 1.6G Jan 5 18:51 order_line.ibd
  5. -rw-r----- 1 mysql mysql 352M Jan 5 18:51 stock.ibd
  6. -rw-r----- 1 mysql mysql 188M Jan 5 18:51 customer.ibd
  7. -rw-r----- 1 mysql mysql 96M Jan 5 18:51 history.ibd
  8. -rw-r----- 1 mysql mysql 68M Jan 5 18:51 orders.ibd
  9. -rw-r----- 1 mysql mysql 17M Jan 5 17:47 item.ibd
  10. -rw-r----- 1 mysql mysql 13M Jan 5 18:51 new_orders.ibd
  11. -rw-r----- 1 mysql mysql 96K Jan 5 18:51 district.ibd
  12. -rw-r----- 1 mysql mysql 96K Jan 5 18:51 warehouse.ibd
  13. -rw-r----- 1 mysql mysql 9.2K Jan 5 17:44 customer.frm
  14. -rw-r----- 1 mysql mysql 9.0K Jan 5 17:44 stock.frm
  15. -rw-r----- 1 mysql mysql 8.8K Jan 5 17:44 order_line.frm
  16. -rw-r----- 1 mysql mysql 8.8K Jan 5 17:44 district.frm
  17. -rw-r----- 1 mysql mysql 8.7K Jan 5 17:44 warehouse.frm
  18. -rw-r----- 1 mysql mysql 8.7K Jan 5 17:44 orders.frm
  19. -rw-r----- 1 mysql mysql 8.7K Jan 5 17:44 history.frm
  20. -rw-r----- 1 mysql mysql 8.5K Jan 5 17:44 item.frm
  21. -rw-r----- 1 mysql mysql 8.5K Jan 5 17:44 new_orders.frm
  22. -rw-r----- 1 mysql mysql 65 Jan 5 17:40 db.opt

二、测试一下云盘的iops。

点击(此处)折叠或打开

  1. 在京东云上面的高效云盘测试，首先测试云盘的SSD的iops随机读写是4144
  2. [root@mysql3 data]# fio --name=myjob --filename=/dev/vdb --ioengine=libaio --direct=1 --bs=4k --rw=randrw --iodepth=32 --runtime=60
  3. myjob: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
  4. fio-2.0.13
  5. Starting 1 process
  6. Jobs: 1 (f=1): [m] [100.0% done] [1408K/1332K/0K /s] [352 /333 /0 iops] [eta 00m:00s]
  7. myjob: (groupid=0, jobs=1): err= 0: pid=10136: Fri Jan 5 16:31:42 2018
  8.   read : io=999840KB, bw=16578KB/s, iops=4144 , runt= 60310msec
  9.     slat (usec): min=2 , max=191 , avg= 6.23, stdev= 3.63
  10.     clat (usec): min=177 , max=727001 , avg=3576.38, stdev=23287.21
  11.      lat (usec): min=208 , max=727011 , avg=3583.03, stdev=23287.50
  12.     clat percentiles (usec):
  13.      | 1.00th=[ 270], 5.00th=[ 302], 10.00th=[ 322], 20.00th=[ 350],
  14.      | 30.00th=[ 374], 40.00th=[ 394], 50.00th=[ 418], 60.00th=[ 438],
  15.      | 70.00th=[ 466], 80.00th=[ 502], 90.00th=[ 572], 95.00th=[ 660],
  16.      | 99.00th=[150528], 99.50th=[171008], 99.90th=[246784], 99.95th=[350208],
  17.      | 99.99th=[399360]
  18.     bw (KB/s) : min= 680, max=81632, per=100.00%, avg=16654.07, stdev=29344.48
  19.   write: io=976.74MB, bw=16584KB/s, iops=4145 , runt= 60310msec
  20.     slat (usec): min=2 , max=768 , avg= 8.32, stdev= 6.68
  21.     clat (usec): min=126 , max=730161 , avg=4122.61, stdev=24096.23
  22.      lat (usec): min=360 , max=730172 , avg=4131.36, stdev=24096.59
  23.     clat percentiles (usec):
  24.      | 1.00th=[ 482], 5.00th=[ 540], 10.00th=[ 580], 20.00th=[ 620],
  25.      | 30.00th=[ 660], 40.00th=[ 692], 50.00th=[ 724], 60.00th=[ 756],
  26.      | 70.00th=[ 788], 80.00th=[ 836], 90.00th=[ 932], 95.00th=[ 1080],
  27.      | 99.00th=[154624], 99.50th=[175104], 99.90th=[248832], 99.95th=[350208],
  28.      | 99.99th=[399360]
  29.     bw (KB/s) : min= 720, max=81520, per=100.00%, avg=16658.87, stdev=29264.19
  30.     lat (usec) : 250=0.12%, 500=40.73%, 750=36.85%, 1000=17.52%
  31.     lat (msec) : 2=2.07%, 4=0.16%, 10=0.03%, 20=0.04%, 50=0.64%
  32.     lat (msec) : 100=0.01%, 250=1.75%, 500=0.10%, 750=0.01%
  33.   cpu : usr=2.24%, sys=8.53%, ctx=142694, majf=0, minf=24
  34.   IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
  35.      submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
  36.      complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
  37.      issued : total=r=249960/w=250039/d=0, short=r=0/w=0/d=0

  39. Run status group 0 (all jobs):
  40.    READ: io=999840KB, aggrb=16578KB/s, minb=16578KB/s, maxb=16578KB/s, mint=60310msec, maxt=60310msec
  41.   WRITE: io=976.74MB, aggrb=16583KB/s, minb=16583KB/s, maxb=16583KB/s, mint=60310msec, maxt=60310msec

  43. Disk stats (read/write):
  44.   vdb: ios=250022/250028, merge=0/0, ticks=881619/1016273, in_queue=1902612, util=99.90%


三、所有参数不改变，默认安装，以此作为压力测试的基准线，进行对比分析，同时附上iostat 和压测结果

点击(此处)折叠或打开

  1. 测试1 基准测试线。使用mysql5.7.20，所有的参数不改变，默认安装，开始压测，做为基准线。
  2. [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w10 -c64 -r60 -l180 -ftpcc_mysql_20180102.log
  3. ***************************************
  4. *** ###easy### TPC-C Load Generator ***
  5. ***************************************
  6. option h with value 'localhost'
  7. option d with value 'tpcc1000'
  8. option u with value 'tpcc_user'
  9. option p with value 'tpcc_password'
  10. option w with value '10'
  11. option c with value '64'
  12. option r with value '60'
  13. option l with value '180'
  14. option f with value 'tpcc_mysql_20180102.log'
  15. <Parameters>
  16.      [server]: localhost
  17.      [port]: 3306
  18.      [DBname]: tpcc1000
  19.        [user]: tpcc_user
  20.        [pass]: tpcc_password
  21.   [warehouse]: 10
  22.  [connection]: 64
  23.      [rampup]: 60 (sec.)
  24.     [measure]: 180 (sec.)

  26. RAMP-UP TIME.(60 sec.)


  29. <Raw Results>
  30.   [0] sc:35014 lt:1 rt:0 fl:0
  31.   [1] sc:35002 lt:0 rt:0 fl:0
  32.   [2] sc:3501 lt:0 rt:0 fl:0
  33.   [3] sc:3497 lt:0 rt:0 fl:0
  34.   [4] sc:3501 lt:0 rt:0 fl:0
  35.  in 180 sec.

  37. <Raw Results2(sum ver.)>
  38.   [0] sc:35014 lt:1 rt:0 fl:0
  39.   [1] sc:35015 lt:0 rt:0 fl:0
  40.   [2] sc:3501 lt:0 rt:0 fl:0
  41.   [3] sc:3497 lt:0 rt:0 fl:0
  42.   [4] sc:3501 lt:0 rt:0 fl:0

  44. <Constraint Check> (all must be [OK])
  45.  [transaction percentage]
  46.         Payment: 43.47% (>=43.0%) [OK]
  47.    Order-Status: 4.35% (>= 4.0%) [OK]
  48.        Delivery: 4.34% (>= 4.0%) [OK]
  49.     Stock-Level: 4.35% (>= 4.0%) [OK]
  50.  [response time (at least 90% passed)]
  51.       New-Order: 100.00% [OK]
  52.         Payment: 100.00% [OK]
  53.    Order-Status: 100.00% [OK]
  54.        Delivery: 100.00% [OK]
  55.     Stock-Level: 100.00% [OK]

  57. <TpmC>
  58.                  11671.667 TpmC
  59. iostat 统计信息
  60. avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              17.86    0.00    5.91    9.87    0.02   66.34
    Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    vda               0.00     0.00    0.00    0.12     0.00     1.00     8.00     0.00    3.00    0.00    3.00   3.00   0.04
    vdb               0.00 19211.00    0.00 6432.75     0.00 202909.00    31.54    11.59    1.80    0.00    1.80   0.15  95.75



四、更改几个核心参数，可以看到tps大幅度提高到1217(75035/60).

点击(此处)折叠或打开

  1. 测试2：增加参数，tps大幅增加，是有原因的，增大了内存
  2. innodb_buffer_pool_size = 22938M
    innodb_buffer_pool_instances = 8
    skip-name-resolve
    transaction_isolation=READ-COMMITTED
  3. innodb_log_file_size = 512M
    innodb_log_buffer_size = 128M
    innodb_log_files_in_group=5
    innodb_temp_data_file_path=ibtmp1:512M:autoextend
  4. [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w10 -c64 -r60 -l180 -ftpcc_mysql_20180102.log
  5. ***************************************
  6. *** ###easy### TPC-C Load Generator ***
  7. ***************************************
  8. option h with value 'localhost'
  9. option d with value 'tpcc1000'
  10. option u with value 'tpcc_user'
  11. option p with value 'tpcc_password'
  12. option w with value '10'
  13. option c with value '64'
  14. option r with value '60'
  15. option l with value '180'
  16. option f with value 'tpcc_mysql_20180102.log'
  17. <Parameters>
  18.      [server]: localhost
  19.      [port]: 3306
  20.      [DBname]: tpcc1000
  21.        [user]: tpcc_user
  22.        [pass]: tpcc_password
  23.   [warehouse]: 10
  24.  [connection]: 64
  25.      [rampup]: 60 (sec.)
  26.     [measure]: 180 (sec.)

  28. RAMP-UP TIME.(60 sec.)

  30. MEASURING START.

  32. <Raw Results>
  33.   [0] sc:219107 lt:0 rt:0 fl:0
  34.   [1] sc:219072 lt:0 rt:0 fl:0
  35.   [2] sc:21909 lt:0 rt:0 fl:0
  36.   [3] sc:21908 lt:0 rt:0 fl:0
  37.   [4] sc:21912 lt:0 rt:0 fl:0
  38.  in 180 sec.

  40. <Raw Results2(sum ver.)>
  41.   [0] sc:219108 lt:0 rt:0 fl:0
  42.   [1] sc:219108 lt:0 rt:0 fl:0
  43.   [2] sc:21909 lt:0 rt:0 fl:0
  44.   [3] sc:21911 lt:0 rt:0 fl:0
  45.   [4] sc:21912 lt:0 rt:0 fl:0

  47. <Constraint Check> (all must be [OK])
  48.  [transaction percentage]
  49.         Payment: 43.47% (>=43.0%) [OK]
  50.    Order-Status: 4.35% (>= 4.0%) [OK]
  51.        Delivery: 4.35% (>= 4.0%) [OK]
  52.     Stock-Level: 4.35% (>= 4.0%) [OK]
  53.  [response time (at least 90% passed)]
  54.       New-Order: 100.00% [OK]
  55.         Payment: 100.00% [OK]
  56.    Order-Status: 100.00% [OK]
  57.        Delivery: 100.00% [OK]
  58.     Stock-Level: 100.00% [OK]

  60. <TpmC>
  61.                  73035.664 TpmC
iostat 统计数据
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          74.08    0.00   11.53    1.19    0.01   13.19
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     0.75    0.00    0.50     0.00     5.00    20.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00  5584.00    0.00 1509.38     0.00 28306.00    37.51     1.43    0.95    0.00    0.95   0.49  73.60

五、测试3，增加参数innodb_io_capacity,按照理论，tps应该增加的，但是反而下降。
  1. 测试3：增加参数，主要增加innodb_io_capacity，按照理论，tps应该增加的，但是反而下降10000，具体查看下，看看是有没有锁。
  2. innodb_io_capacity = 10000
    innodb_io_capacity_max = 20000
    innodb_flush_neighbors = 0
    innodb_write_io_threads = 8
    innodb_read_io_threads = 8
    innodb_purge_threads = 4
    innodb_page_cleaners = 4
    innodb_open_files = 65535
    innodb_max_dirty_pages_pct = 50
  3. [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w10 -c64 -r60 -l180 -ftpcc_mysql_20180102.log
  4. ***************************************
  5. *** ###easy### TPC-C Load Generator ***
  6. ***************************************
  7. option h with value 'localhost'
  8. option d with value 'tpcc1000'
  9. option u with value 'tpcc_user'
  10. option p with value 'tpcc_password'
  11. option w with value '10'
  12. option c with value '64'
  13. option r with value '60'
  14. option l with value '180'
  15. option f with value 'tpcc_mysql_20180102.log'
  16. <Parameters>
  17.      [server]: localhost
  18.      [port]: 3306
  19.      [DBname]: tpcc1000
  20.        [user]: tpcc_user
  21.        [pass]: tpcc_password
  22.   [warehouse]: 10
  23.  [connection]: 64
  24.      [rampup]: 60 (sec.)
  25.     [measure]: 180 (sec.)

  27. RAMP-UP TIME.(60 sec.)

  29. MEASURING START.

  31. <Raw Results>
  32.   [0] sc:201891 lt:0 rt:0 fl:0
  33.   [1] sc:201850 lt:0 rt:0 fl:0
  34.   [2] sc:20190 lt:0 rt:0 fl:0
  35.   [3] sc:20187 lt:0 rt:0 fl:0
  36.   [4] sc:20186 lt:0 rt:0 fl:0
  37.  in 180 sec.

  39. <Raw Results2(sum ver.)>
  40.   [0] sc:201895 lt:0 rt:0 fl:0
  41.   [1] sc:201884 lt:0 rt:0 fl:0
  42.   [2] sc:20190 lt:0 rt:0 fl:0
  43.   [3] sc:20189 lt:0 rt:0 fl:0
  44.   [4] sc:20187 lt:0 rt:0 fl:0

  46. <Constraint Check> (all must be [OK])
  47.  [transaction percentage]
  48.         Payment: 43.47% (>=43.0%) [OK]
  49.    Order-Status: 4.35% (>= 4.0%) [OK]
  50.        Delivery: 4.35% (>= 4.0%) [OK]
  51.     Stock-Level: 4.35% (>= 4.0%) [OK]
  52.  [response time (at least 90% passed)]
  53.       New-Order: 100.00% [OK]
  54.         Payment: 100.00% [OK]
  55.    Order-Status: 100.00% [OK]
  56.        Delivery: 100.00% [OK]
  57.     Stock-Level: 100.00% [OK]

  59. <TpmC>
  60.                  67297.000 TpmC
iostat 的统计信息
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          70.27    0.00   11.00    1.60    0.01   17.12
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     1.33    0.00    2.00     0.00    13.33    13.33     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00  8142.89    0.00 2545.33     0.00 42552.89    33.44     5.40    2.12    0.00    2.12   0.31  77.98
这次tps下降了。所以我们要恢复原来的参数。把这些参数清除继续下面的测试

六、增加并发连接到128个
  1. 测试4.参数不调整，但是增加并发连接到128个。看tps77476，没有很大的提高，并发可以撑得住。对系统影响较小
  2. [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w10 -c128 -r60 -l180 -ftpcc_mysql_20180102.log
  3. ***************************************
  4. *** ###easy### TPC-C Load Generator ***
  5. ***************************************
  6. option h with value 'localhost'
  7. option d with value 'tpcc1000'
  8. option u with value 'tpcc_user'
  9. option p with value 'tpcc_password'
  10. option w with value '10'
  11. option c with value '128'
  12. option r with value '60'
  13. option l with value '180'
  14. option f with value 'tpcc_mysql_20180102.log'
  15. <Parameters>
  16.      [server]: localhost
  17.      [port]: 3306
  18.      [DBname]: tpcc1000
  19.        [user]: tpcc_user
  20.        [pass]: tpcc_password
  21.   [warehouse]: 10
  22.  [connection]: 128
  23.      [rampup]: 60 (sec.)
  24.     [measure]: 180 (sec.)
  25. RAMP-UP TIME.(60 sec.)
  26. MEASURING START.

  28. STOPPING THREADS................................................................................................................................
  29. <Raw Results>
  30.   [0] sc:232429 lt:0 rt:0 fl:0
  31.   [1] sc:232379 lt:0 rt:0 fl:0
  32.   [2] sc:23247 lt:0 rt:0 fl:0
  33.   [3] sc:23246 lt:0 rt:0 fl:0
  34.   [4] sc:23246 lt:0 rt:0 fl:0
  35.  in 180 sec.

  37. <Raw Results2(sum ver.)>
  38.   [0] sc:232430 lt:0 rt:0 fl:0
  39.   [1] sc:232417 lt:0 rt:0 fl:0
  40.   [2] sc:23247 lt:0 rt:0 fl:0
  41.   [3] sc:23246 lt:0 rt:0 fl:0
  42.   [4] sc:23246 lt:0 rt:0 fl:0

  44. <Constraint Check> (all must be [OK])
  45.  [transaction percentage]
  46.         Payment: 43.47% (>=43.0%) [OK]
  47.    Order-Status: 4.35% (>= 4.0%) [OK]
  48.        Delivery: 4.35% (>= 4.0%) [OK]
  49.     Stock-Level: 4.35% (>= 4.0%) [OK]
  50.  [response time (at least 90% passed)]
  51.       New-Order: 100.00% [OK]
  52.         Payment: 100.00% [OK]
  53.    Order-Status: 100.00% [OK]
  54.        Delivery: 100.00% [OK]
  55.     Stock-Level: 100.00% [OK]

  57. <TpmC>
  58.                  77476.336 TpmC
  59. iostat 统计信息
  60. avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              78.48    0.00   11.64    0.77    0.00    9.11
    Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    vda               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
    vdb               0.00  6027.25    0.00 1488.25     0.00 59964.00    40.29     1.41    0.95    0.00    0.95   0.45  67.21

七、开启二进制日志功能，以及刷盘方式，对tps影响都是巨大的。这个结论也可以理解，不停的写二进制日志。假如整个数据库只用innodb一种引擎，又写二进制日志，又写innodb日志，不是重复吗？但是在线日志对数据库的性能影响是绝对巨头的，甚至可以认为是决定性的。

点击(此处)折叠或打开

  1. 测试5：增加参数，表示开启二进制日志功能，tps性能大幅下跌到17523，我查看binlog日志，有个1.1Gbinlog.000001，还有一个276M的binlog.0000002日志文件。所有的性能损耗在写二进制日志文件上。测试6：如果sync_binlog变为0，我的tps测试结果为44691.332 TpmC 。所以说不控制的话，tps应该有提高，提高效果还是很明显的哦。
  2. server_id=1
  3. binlog_format=row
  4. log_bin = binlog
  5. sync_binlog=1
  6. [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w10 -c64 -r60 -l180 -ftpcc_mysql_20180102.log
  7. ***************************************
  8. *** ###easy### TPC-C Load Generator ***
  9. ***************************************
  10. option h with value 'localhost'
  11. option d with value 'tpcc1000'
  12. option u with value 'tpcc_user'
  13. option p with value 'tpcc_password'
  14. option w with value '10'
  15. option c with value '64'
  16. option r with value '60'
  17. option l with value '180'
  18. option f with value 'tpcc_mysql_20180102.log'

  20. <Raw Results>
  21.   [0] sc:52564 lt:5 rt:0 fl:0
  22.   [1] sc:52560 lt:0 rt:0 fl:0
  23.   [2] sc:5257 lt:0 rt:0 fl:0
  24.   [3] sc:5257 lt:0 rt:0 fl:0
  25.   [4] sc:5258 lt:0 rt:0 fl:0
  26.  in 180 sec.

  28. <Raw Results2(sum ver.)>
  29.   [0] sc:52565 lt:5 rt:0 fl:0
  30.   [1] sc:52571 lt:0 rt:0 fl:0
  31.   [2] sc:5258 lt:0 rt:0 fl:0
  32.   [3] sc:5257 lt:0 rt:0 fl:0
  33.   [4] sc:5258 lt:0 rt:0 fl:0

  35. <Constraint Check> (all must be [OK])
  36.  [transaction percentage]
  37.         Payment: 43.47% (>=43.0%) [OK]
  38.    Order-Status: 4.35% (>= 4.0%) [OK]
  39.        Delivery: 4.35% (>= 4.0%) [OK]
  40.     Stock-Level: 4.35% (>= 4.0%) [OK]
  41.  [response time (at least 90% passed)]
  42.       New-Order: 99.99% [OK]
  43.         Payment: 100.00% [OK]
  44.    Order-Status: 100.00% [OK]
  45.        Delivery: 100.00% [OK]
  46.     Stock-Level: 100.00% [OK]

  48. <TpmC>
  49.                  17523.000 TpmC
八、把数据量增加到50个warehouse.这个时候，数据量是这样的：
现在数据库tpcc1000有 9张表，warehouse10条记录，stock表有500万，item表有10万，order_line1499万，new_orders45万，orders150万，  customer150万,查看一下实际表空间的大小3.9G：

  1. [root@mysql3 ~]# ll /data/mysql1/tpcc1000/ -hS
  2. total 3.9G
  3. -rw-r----- 1 mysql mysql 1.7G Jan 10 11:13 stock.ibd
  4. -rw-r----- 1 mysql mysql 1.1G Jan 10 11:40 order_line.ibd
  5. -rw-r----- 1 mysql mysql 920M Jan 10 11:22 customer.ibd
  6. -rw-r----- 1 mysql mysql 108M Jan 10 11:22 history.ibd
  7. -rw-r----- 1 mysql mysql 68M Jan 10 11:40 orders.ibd
  8. -rw-r----- 1 mysql mysql 20M Jan 10 11:40 new_orders.ibd
  9. -rw-r----- 1 mysql mysql 17M Jan 10 11:03 item.ibd
  10. -rw-r----- 1 mysql mysql 144K Jan 10 11:13 district.ibd
  11. -rw-r----- 1 mysql mysql 96K Jan 10 11:11 warehouse.ibd
  12. -rw-r----- 1 mysql mysql 9.2K Jan 10 11:01 customer.frm
  13. -rw-r----- 1 mysql mysql 9.0K Jan 10 11:01 stock.frm
  14. -rw-r----- 1 mysql mysql 8.8K Jan 10 11:01 order_line.frm
  15. -rw-r----- 1 mysql mysql 8.8K Jan 10 11:01 district.frm
  16. -rw-r----- 1 mysql mysql 8.7K Jan 10 11:01 warehouse.frm
  17. -rw-r----- 1 mysql mysql 8.7K Jan 10 11:01 orders.frm
  18. -rw-r----- 1 mysql mysql 8.7K Jan 10 11:01 history.frm
  19. -rw-r----- 1 mysql mysql 8.5K Jan 10 11:01 item.frm
  20. -rw-r----- 1 mysql mysql 8.5K Jan 10 11:01 new_orders.frm
  21. -rw-r----- 1 mysql mysql 67 Jan 8 16:28 db.opt
九、来做一个压测，这里要说明一下测试7参数配置和测试6配置一样。从结果来看，增加数据量，对tps影响不大。主要参数如下：
innodb_buffer_pool_size = 22938M
innodb_buffer_pool_instances = 8
skip-name-resolve
transaction_isolation=READ-COMMITTED
innodb_log_file_size = 512M
innodb_log_buffer_size = 128M
innodb_log_files_in_group=5
innodb_temp_data_file_path=ibtmp1:512M:autoextend
#autocommit=0
server_id=1
binlog_format=row
log_bin                 = binlog
sync_binlog=0
  1. 测试7.增加warehouse到50个
  2. [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w50 -c128 -r30 -l90 -ftpcc_mysql_20180102.log
  3. ***************************************
  4. *** ###easy### TPC-C Load Generator ***
  5. ***************************************
  6. option h with value 'localhost'
  7. option d with value 'tpcc1000'
  8. option u with value 'tpcc_user'
  9. option p with value 'tpcc_password'
  10. option w with value '50'
  11. option c with value '128'
  12. option r with value '30'
  13. option l with value '90'
  14. option f with value 'tpcc_mysql_20180102.log'
  15. <Parameters>
  16.      [server]: localhost
  17.      [port]: 3306
  18.      [DBname]: tpcc1000
  19.        [user]: tpcc_user
  20.        [pass]: tpcc_password
  21.   [warehouse]: 50
  22.  [connection]: 128
  23.      [rampup]: 30 (sec.)
  24.     [measure]: 90 (sec.)

  26. RAMP-UP TIME.(30 sec.)


  29. <Raw Results>
  30.   [0] sc:83245 lt:2 rt:0 fl:0
  31.   [1] sc:83233 lt:3 rt:0 fl:0
  32.   [2] sc:8324 lt:0 rt:0 fl:0
  33.   [3] sc:8322 lt:0 rt:0 fl:0
  34.   [4] sc:8323 lt:0 rt:0 fl:0
  35.  in 90 sec.

  37. <Raw Results2(sum ver.)>
  38.   [0] sc:83245 lt:2 rt:0 fl:0
  39.   [1] sc:83250 lt:3 rt:0 fl:0
  40.   [2] sc:8324 lt:0 rt:0 fl:0
  41.   [3] sc:8322 lt:0 rt:0 fl:0
  42.   [4] sc:8323 lt:0 rt:0 fl:0

  44. <Constraint Check> (all must be [OK])
  45.  [transaction percentage]
  46.         Payment: 43.48% (>=43.0%) [OK]
  47.    Order-Status: 4.35% (>= 4.0%) [OK]
  48.        Delivery: 4.35% (>= 4.0%) [OK]
  49.     Stock-Level: 4.35% (>= 4.0%) [OK]
  50.  [response time (at least 90% passed)]
  51.       New-Order: 100.00% [OK]
  52.         Payment: 100.00% [OK]
  53.    Order-Status: 100.00% [OK]
  54.        Delivery: 100.00% [OK]
  55.     Stock-Level: 100.00% [OK]

  57. <TpmC>
  58.                  55498.000 TpmC
  59. iostat 统计
  60. avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              70.65    0.00   10.26    2.04    0.01   17.04
    Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    vda               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
    vdb               0.00 11602.88   27.00 1049.25  1300.00 100851.00    94.91     2.44    2.30    5.16    2.22   0.60  64.59
十、把warehouse 增加到500个，
把数据量增加到50个warehouse.这个时候，数据量是这样的：
现在数据库tpcc1000有 9张表，warehouse10条记录，stock表有5000万，item表有10万，order_line1.49亿，new_orders450万，orders1500万，  customer1500万,查看一下实际表空间的大小38G：

  1. [root@mysql3 ~]# ll /data/mysql1/tpcc1000/ -hS
  2. total 38G
  3. -rw-r----- 1 mysql mysql 17G Jan 10 16:11 stock.ibd
  4. -rw-r----- 1 mysql mysql 11G Jan 10 19:27 order_line.ibd
  5. -rw-r----- 1 mysql mysql 8.9G Jan 10 16:52 customer.ibd
  6. -rw-r----- 1 mysql mysql 988M Jan 10 16:52 history.ibd
  7. -rw-r----- 1 mysql mysql 608M Jan 10 19:27 orders.ibd
  8. -rw-r----- 1 mysql mysql 128M Jan 10 19:27 new_orders.ibd
  9. -rw-r----- 1 mysql mysql 17M Jan 10 15:03 item.ibd
  10. -rw-r----- 1 mysql mysql 9.0M Jan 10 16:11 district.ibd
  11. -rw-r----- 1 mysql mysql 144K Jan 10 16:10 warehouse.ibd
  12. -rw-r----- 1 mysql mysql 9.2K Jan 10 15:02 customer.frm
  13. -rw-r----- 1 mysql mysql 9.0K Jan 10 15:02 stock.frm
  14. -rw-r----- 1 mysql mysql 8.8K Jan 10 15:02 order_line.frm
  15. -rw-r----- 1 mysql mysql 8.8K Jan 10 15:02 district.frm
  16. -rw-r----- 1 mysql mysql 8.7K Jan 10 15:02 warehouse.frm
  17. -rw-r----- 1 mysql mysql 8.7K Jan 10 15:02 orders.frm
  18. -rw-r----- 1 mysql mysql 8.7K Jan 10 15:02 history.frm
  19. -rw-r----- 1 mysql mysql 8.5K Jan 10 15:02 item.frm
  20. -rw-r----- 1 mysql mysql 8.5K Jan 10 15:02 new_orders.frm
  21. -rw-r----- 1 mysql mysql 67 Jan 8 16:28 db.opt
十一、先做一个测试线，看看情况有报错，报错如下：
1461, 42000, Can't create more than max_prepared_stmt_count statements (current value: 16382)
1040, 08004, Too many connections
这个问题比较好解决，更改两个参数不报错了。set global  max_prepared_stmt_count=1048576;
压力测试结果出来了，是5700TpmC.明显，这个结果是非常低的。问题出在哪里呢？

  1. 测试8 数据量有38G，很大
  2. [root@mysql3 tpcc-mysql]# ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w500 -c512 -r10 -l10 -ftpcc_mysql_20180102.log
  3. ***************************************
  4. *** ###easy### TPC-C Load Generator ***
  5. ***************************************
  6. option h with value 'localhost'
  7. option d with value 'tpcc1000'
  8. option u with value 'tpcc_user'
  9. option p with value 'tpcc_password'
  10. option w with value '500'
  11. option c with value '512'
  12. option r with value '10'
  13. option l with value '10'
  14. option f with value 'tpcc_mysql_20180102.log'
  15. <Parameters>
  16.      [server]: localhost
  17.      [port]: 3306
  18.      [DBname]: tpcc1000
  19.        [user]: tpcc_user
  20.        [pass]: tpcc_password
  21.   [warehouse]: 500
  22.  [connection]: 512
  23.      [rampup]: 10 (sec.)
  24.     [measure]: 10 (sec.)

  26. RAMP-UP TIME.(10 sec.)

  28. <Raw Results>
  29.   [0] sc:949 lt:1 rt:0 fl:0
  30.   [1] sc:865 lt:0 rt:0 fl:0
  31.   [2] sc:85 lt:0 rt:0 fl:0
  32.   [3] sc:67 lt:0 rt:0 fl:0
  33.   [4] sc:57 lt:0 rt:0 fl:0
  34.  in 10 sec.

  36. <Raw Results2(sum ver.)>
  37.   [0] sc:949 lt:1 rt:0 fl:0
  38.   [1] sc:865 lt:0 rt:0 fl:0
  39.   [2] sc:85 lt:0 rt:0 fl:0
  40.   [3] sc:67 lt:0 rt:0 fl:0
  41.   [4] sc:57 lt:0 rt:0 fl:0

  43. <Constraint Check> (all must be [OK])
  44.  [transaction percentage]
  45.         Payment: 42.74% (>=43.0%) [NG] *
  46.    Order-Status: 4.20% (>= 4.0%) [OK]
  47.        Delivery: 3.31% (>= 4.0%) [NG] *
  48.     Stock-Level: 2.82% (>= 4.0%) [NG] *
  49.  [response time (at least 90% passed)]
  50.       New-Order: 99.89% [OK]
  51.         Payment: 100.00% [OK]
  52.    Order-Status: 100.00% [OK]
  53.        Delivery: 100.00% [OK]
  54.     Stock-Level: 100.00% [OK]

  56. <TpmC>
  57.                  5700.000 TpmC
  58. iostat 统计信息：
  59. avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              14.18    0.00    4.84   63.26    0.01   17.71
    Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    vda               0.00     0.38    0.12    0.88     2.00    10.00    12.00     0.00    0.12    0.00    0.14   0.12   0.01
    vdb               1.25 10116.38 2605.50  615.88 204808.00 86800.00    90.52    48.55   14.97   15.37   13.28   0.31  99.99
    这个比较有意思。你对比iostat,和以前测试相比，r/s由0变成了2605，w/s由1488变成了615，avgqu-sz变成了48，等待队列很多
    %util变成了99.99，io是满负荷的。这说明什么呢？写变少了，读大量增加。为什么呢？因为数据量变大了，查询耗时了。
    现在要解决的问题是，优化查询语句后再进行压力测试。

这个比较有意思。你对比iostat,和以前测试相比，r/s由0变成了2605，w/s由1488变成了615，avgqu-sz变成了48，等待队列很多
%util变成了99.99，io是满负荷的。这说明什么呢？写变少了，读大量增加。为什么呢？因为数据量变大了，查询耗时了。
现在要解决的问题是，优化查询语句后再进行压力测试。

十二、我开启了mysql的慢查询，分析哪些语句执行慢。摘录部分查询结果如下：

  1. # Query_time: 4.743248 Lock_time: 0.000053 Rows_sent: 0 Rows_examined: 0
  2. SET timestamp=1515661062;
  3. INSERT INTO orders (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) VALUES(3002, 4, 138, 2870, '2018-01-11 16:57:37', 7, 1);

  5. # Query_time: 3.139345 Lock_time: 0.000102 Rows_sent: 1 Rows_examined: 3001
  6. SET timestamp=1515661062;
  7. SELECT o_id, o_entry_d, COALESCE(o_carrier_id,0) FROM orders WHERE o_w_id = 345 AND o_d_id = 8 AND o_c_id = 1069 AND o_id = (SELECT MAX(o_id) FROM orders WHERE o_w_id = 345 AND o_d_id = 8 AND o_c_id = 1069);

  9. # Query_time: 4.433704 Lock_time: 0.000241 Rows_sent: 1 Rows_examined: 3002
  10. SET timestamp=1515661062;
  11. SELECT o_id, o_entry_d, COALESCE(o_carrier_id,0) FROM orders WHERE o_w_id = 408 AND o_d_id = 7 AND o_c_id = 760 AND o_id = (SELECT MAX(o_id) FROM orders WHERE o_w_id = 408 AND o_d_id = 7 AND o_c_id = 760);

  13. # Query_time: 7.391263 Lock_time: 0.000151 Rows_sent: 1 Rows_examined: 3003
  14. SET timestamp=1515661062;
  15. SELECT o_id, o_entry_d, COALESCE(o_carrier_id,0) FROM orders WHERE o_w_id = 253 AND o_d_id = 4 AND o_c_id = 1272 AND o_id = (SELECT MAX(o_id) FROM orders WHERE o_w_id = 253 AND o_d_id = 4 AND o_c_id = 1272)
我们看到，这里面慢查询都是发生在表orders，有执行7秒的，有执行4秒的，3秒的，有insert语句。我把这些语句单独拿到
mysql中执行，执行非常快。打印出执行计划，我看到了所有的语句都走了索引，而且每个语句执行速度很快。这个会是什么原因呢？我猜测是并发线程多，有锁住情况。但是mysql的查询是非阻塞的，插入也是非阻塞的，这又是什么原因呢？先做个验证：使用256个并发线程连接，看看有什么表现。
我们看到，这里面慢查询都是发生在表orders，有执行7秒的，有执行4秒的，3秒的，有insert语句。我把这些语句单独拿到
mysql中执行，执行非常快。打印出执行计划，我看到了所有的语句都走了索引，而且每个语句执行速度很快。这个会是什么原因呢？我猜测是并发线程多，有锁住情况。但是mysql的查询是非阻塞的，插入也是非阻塞的，这又是什么原因呢？先做个验证：使用256个并发线程连接，看看有什么表现。

十三、我先后做如下压测，后面附上tps: 当库存数量达到450的时候，性能急剧下降，不清楚mysql哪个指标受限制了。


  2. 测试9 ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w100 -c64 -r10 -l30 -ftpcc_mysql_20180104.log
  3. 33200.000 TpmC

  5. 测试10 ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w100 -c256 -r10 -l30 -ftpcc_mysql_20180104.log
  6. 32594.000 TpmC

  8. 测试11 ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w250 -c256 -r10 -l30 -ftpcc_mysql_20180104.log
  9. 30148.000 TpmC
  1. 测试12 ./tpcc_start -hlocalhost -dtpcc1000 -utpcc_user -ptpcc_password -w450 -c256 -r10 -l30 -ftpcc_mysql_20180104.log 
  2. 17996.000 TpmC
当库存数量达到450的时候，性能急剧下降，不清楚mysql哪个指标受限制了。


最后点评：




来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30393770/viewspace-2149755/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30393770/viewspace-2149755/

cll3830995
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MySQL服务器SSD性能问题分析与测试
anfu8428的博客
11-16 208
【问题】 我们有台HP的服务器，SSD在写IOPS约5000时，%util达到80%以上，那么这块SSD的性能究竟有没有问题，为解决这个问题做了下面测试。 【工具】 blktrace是linux下用来排查IO性能的工具。它可以记录IO经历的各个步骤，并计算出IO请求在各个阶段的消耗，下面是关键的一些步骤： Q2G – 生成IO请求所消耗的时间，包括remap和split的时间...
mysql latid1_mysql 高性能压力测试（总结了好久）
weixin_34418334的博客
01-19 1146
前言：根据业务需要，需测试mysql 性能和压力测试.这里我说下测试方法和 测试过程以及测试中出错的问题估计很多人 跟我一样 要测试mysql 的性能 压力，网上找了很多资料有很多，但是很乱，所以这里我做个总结，拿自己的真实服务器测试的。并且 想测多少数据 都能模拟出来！这里只介绍方法。MySQL从5.1.4版开始带有一个压力测试工具mysqlslap，通过模拟多个并发客户端访问mysql来执行测...
SAS vs SSD各种模式下MySQL TPCC OLTP对比测试结果
weixin_34206899的博客
12-05 102
在各种测试组合方案中，组合10(组合10：SSD * 2, RAID 0, XFS,WB,nobarrier,noop)的综合性能最高，因此以它为基准，其他方案与其对比，下表是各组合和组合10的对比：相应的对比线形图：测试环境：结语1. 在xfs文件系统模式下，SSD设备的性能是SAS设备性能的6 ~ 13倍，平均：9倍，在并发16线程时最高(和MySQL的内部机制有关)；2. SSD设备使用no...
mysql ssd tps 上不去_性能测试tps上不去，又是redis的坑，说多了都是泪啊
weixin_39580749的博客
02-26 215
前言：这是几个月前压测某项目登录接口时遇到的性能问题，虽然大家不一定会遇到，但是分析定位问题的思路还是可以参考一下。1、压测过程中，tps突然剧烈下降，且所有请求失败(下图绿线) 服务端错误日志，获取不到redis连接池(Could not get a resource from the pool)，另外，从下图可以看到，当前jedis版本是2.9.1 获取不到连接，可能是这四种情况：Timeou...
tpc-c测试环境搭建
hshopeful
01-26 2419
搭建TPC-C环境 一、准备 操作系统 :Linux, 内核版本2.6 需要软件：tpccuva-1.2.3, postgresql-8.1.15, gnuplot-4.2.5。 tccuva是实现标准TPC-C。 Postgresql是最稳定的开源sql数据库。 gunplot是一个数学软件，可以根据数据画出相应的函数图形。   二、安装 1.   创建用户 user
阿里云CentOS 7系统挂载SSD云盘的教程
09-15
最近在阿里云购买了块云盘，但悲催的发现阿里云购买的第2块云盘默认是不自动挂载的，需要手动配置挂载上。所以只能求助万能的百度了，通过查找网上的资料，和自己的实践终于将云盘挂载成功了，现在将步骤分享给大家...
苏宁云 苏宁云盘 v2.2.1
11-09
苏宁云是苏宁云商集团推出的一款面向广大用户提供上传空间和技术的信息存储空间服务产品，通过苏宁云服务技术为用户提供个人数据存储、同步、管理和分享等在线服务。苏宁云盘
加密云盘 隐形云加密云盘 v2.6.5
10-18
隐形云加密云盘是杭州奕锐电子有限公司和阿里云合作推出的一个敢放关键数据的云盘，隐形云的较大特点是用户数据先加密后上传，而数据的加密密钥由用户有效自主掌握。使用了奕
乌云极简云盘 1.0
05-01
乌云极简云盘是一个轻量级文件管理与共享系统，支持多用户，可充当网盘程序，程序无需数据库。安装步骤：1.建议安装在apache环境下，并确保.htaccess可用；2.解压文件至网站根目录。
蚂蚁金服OceanBase挑战TPCC | TPC-C基准测试之存储优化
阿里云云栖号
10-10 1338
蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引起业内广泛关注，为了更清楚的展示其中的技术细节，我们特意邀请 OceanBase 核心研发人员对本次测试进行技术解读，共包括五篇： 1）TPC-C基准测试介绍 2）OceanBase如何做TPC-C测试 3）TPC-C基准测试之SQL优化 4）TPC-C基准测试之数据库事务引擎的挑战 5）TPC-C基准测试之存储优化 TPC-C 规范...
tpcc-dbcp -- 基于java和apache dbcp实现的一个tpcc测试工具
Li_Xiang_996的博客
01-18 431
1. 关于tpcc-dbcp 之前学习mysql，经常使用percona开发的tpcc-mysql，模拟业务负载。但tpcc-mysql本身已经不更新了，只能支持mysql数据库，且数据加载时单线程的，大数据量装载数据非常慢。 所以最近花了些时间，参考了tpcc-mysql，用java和apache的数据库连接池(dbcp)，就有了tpcc-dbcp这样一个类tpcc-mysql的测试软件。相较于tpcc-mysql: - 支持多种数据库: MySQL, PostgreSQL, Oracle, DB2,
tpcC值计算方法
好记忆也需烂博客
05-03 7631
<br /><br /> 计算原则： <br /> 以单台服务器性能进行计算，即确保单台服务器工作的时候可以满足系统正常运行的需要；<br /><br /> 假设每天有1万人次来窗口办理业务，每人次办理一项业务。即以每日1万笔前台交易为例进行综合系数的推导：<br /><br /> 1. 假设每月前台交易数（未来5年内的设计指标）为220,000 （有些业务在月初、月末的处理量比较高，按月统计可以平衡此项差异）;<br /> 2. 每日前台交易数=220000/22=10,000 ，即每日 1万笔
数据库性能压测之TPC-C基准测试
TIME_1981的博客
08-05 8706
TPC-C是用商品批发业务混合了只读和读写等复杂事务来模拟OLTP场景。本文的目的是梳理TPC-C的特点以及工具使用，希望对同学们做TPC-C基准压测有所帮助。
tpcc-mysql 中tpcc-load初始化数据执行结果
yumushui的专栏
07-14 2040
今天在测试环境中，使用tpcc-mysql工具进行性能测试，
mysql压力测试在京东云ssd云盘sysbench版本
cll3830995的博客
01-11 134
一、环境：京东云Centos6.8，cpu16核,内存32G，SAS 3G,转速未知，SSD云盘300G mysql 版本是：5.7.20 ，默认rpm安装,单实例。 压测工具是：sysbench1....
Tpcc-MySQL对mysql数据库进行性能测试报告、分析及使用gnuplot生成图表展示
reblue520的专栏
03-31 647
TPC-C是专门针对联机交易处理系统（OLTP系统）的规范，一般情况下我们也把这类系统称为业务处理系统。 tpcc-mysql是percona基于TPC-C(下面简写成TPCC)衍生出来的产品，专用于MySQL基准测试。其源码放在launchpad上，用bazaar管理，项目地址：https://code.launchpad.net/~percona-dev/perconato...
mysql压测_MySQL压测--参数压测
weixin_33971453的博客
01-18 172
我们知道，MySQL为了保证数据的尽量不丢失，一般会把参数sync_binlog 和innodb_flush_log_at_trx_commit都设置为1，即双1原则，但是，凡是都有两面性，高安全和高性能往往是让人很难取舍的，需要根据你的实际业务需求进行抉择；1.测试背景首先分别了解一下这两个参数的官方解释:sync_binlogControlshowoftentheMySQLserve...
压测瓶颈在mysql_MySQL的性能基线收集及压力测试
weixin_30496999的博客
01-30 211
建立基线的作用：计算机科学中，基线是项目储存库中每个工件版本在特定时期的一个“快照”。比如我们现在有并发事物，那么在某时刻发起一个事物会产生当前数据的快照，那么这个快照就相当理解为一个基线，那么所谓的性能数据的基线就是正常数据收集后的一段时间或者业务数据的负载，将它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差...
华为云 mount 云盘
最新发布
08-18
您可以通过以下步骤将华为云云盘挂载到云服务器上： 1. 在华为云控制台中，导航到云硬盘服务（云硬盘 > 云硬盘）。 2. 创建一个云硬盘，并选择合适的存储类型和容量。 3. 在服务器列表中选择您要挂载云盘的云服务器...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值