CEPH踩坑指南----1.Ceph关于too few PGs per OSD的问题

最新推荐文章于 2025-06-10 10:02:54 发布
最新推荐文章于 2025-06-10 10:02:54 发布
阅读量2.4k 收藏 2
点赞数
CC 4.0 BY-SA版权
分类专栏： Ceph 文章标签： ceoh踩坑 ceph
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/yujia_666/article/details/108181670
在Ceph集群中，创建池后发现集群状态为warn，因每个OSD上的PG数少于最小要求30个。通过调整pool的pg_num和pgp_num至128，完成数据均衡并恢复集群健康状态。

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

 

在一个ceph集群中，操作创建一个池后，发现ceph的集群状态处于warn状态，信息如下

检查集群的信息

查看看池

[root@serverc ~]# ceph osd pool ls

images   #只有一个池

[root@serverc ~]# ceph osd tree

复制代码

ID CLASS WEIGHT  TYPE NAME        STATUS REWEIGHT PRI-AFF 
-1       0.13129 root default                             
-5       0.04376     host serverc                         
 2   hdd 0.01459         osd.2        up  1.00000 1.00000      #9块osd状态up in状态
 3   hdd 0.01459         osd.3        up  1.00000 1.00000 
 7   hdd 0.01459         osd.7        up  1.00000 1.00000 
-3       0.04376     host serverd                         
 0   hdd 0.01459         osd.0        up  1.00000 1.00000 
 5   hdd 0.01459         osd.5        up  1.00000 1.00000 
 6   hdd 0.01459         osd.6        up  1.00000 1.00000 
-7       0.04376     host servere                         
 1   hdd 0.01459         osd.1        up  1.00000 1.00000 
 4   hdd 0.01459         osd.4        up  1.00000 1.00000 
 8   hdd 0.01459         osd.8        up  1.00000 1.00000

复制代码

重现错误

[root@serverc ~]# ceph osd pool create images 64 64

[root@serverc ~]# ceph osd pool application enable images rbd

[root@serverc ~]# ceph -s

复制代码

 cluster:
    id:     04b66834-1126-4870-9f32-d9121f1baccd
    health: HEALTH_WARN
            too few PGs per OSD (21 < min 30)
  services:
    mon: 3 daemons, quorum serverc,serverd,servere
    mgr: servere(active), standbys: serverd, serverc
    osd: 9 osds: 9 up, 9 in
  data:
    pools:   1 pools, 64 pgs
    objects: 8 objects, 12418 kB
    usage:   1005 MB used, 133 GB / 134 GB avail
    pgs:     64 active+clean

复制代码

 [root@serverc ~]# ceph pg dump

复制代码

dumped all
version 1334
stamp 2019-03-29 22:21:41.795511
last_osdmap_epoch 0
last_pg_scan 0
full_ratio 0
nearfull_ratio 0
PG_STAT OBJECTS MISSING_ON_PRIMARY DEGRADED MISPLACED UNFOUND BYTES   LOG DISK_LOG STATE        STATE_STAMP                VERSION REPORTED UP      UP_PRIMARY ACTING  ACTING_PRIMARY LAST_SCRUB SCRUB_STAMP                LAST_DEEP_SCRUB DEEP_SCRUB_STAMP           
1.3f          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.871318     0'0    33:41 [7,1,0]          7 [7,1,0]              7        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.3e          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.867341     0'0    33:41 [4,5,7]          4 [4,5,7]              4        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.3d          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.871213     0'0    33:41 [0,3,1]          0 [0,3,1]              0        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.3c          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.859216     0'0    33:41 [5,7,1]          5 [5,7,1]              5        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.3b          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.870865     0'0    33:41 [0,8,7]          0 [0,8,7]              0        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.3a          2                  0        0         0       0      19  17       17 active+clean 2019-03-29 22:17:34.858977   33'17   33:117 [4,6,7]          4 [4,6,7]              4        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.39          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.871027     0'0    33:41 [0,3,4]          0 [0,3,4]              0        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.38          1                  0        0         0       0      16   1        1 active+clean 2019-03-29 22:17:34.861985    30'1    33:48 [4,2,5]          4 [4,2,5]              4        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.37          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.861667     0'0    33:41 [6,7,1]          6 [6,7,1]              6        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.36          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.860382     0'0    33:41 [6,3,1]          6 [6,3,1]              6        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.35          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.860407     0'0    33:41 [8,6,2]          8 [8,6,2]              8        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.34          0                  0        0         0       0       0   2        2 active+clean 2019-03-29 22:17:34.861874    32'2    33:44 [4,3,0]          4 [4,3,0]              4        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.33          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.860929     0'0    33:41 [4,6,2]          4 [4,6,2]              4        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
1.32          0                  0        0         0       0       0   0        0 active+clean 2019-03-29 22:17:34.860589     0'0    33:41 [4,2,6]          4 [4,2,6]              4        0'0 2019-03-29 21:55:07.534833             0'0 2019-03-29 21:55:07.534833 
…………                          
1 8 0 0 0 0 12716137 78 78                             
sum 8 0 0 0 0 12716137 78 78 
OSD_STAT USED  AVAIL  TOTAL  HB_PEERS          PG_SUM PRIMARY_PG_SUM 
8         119M 15229M 15348M [0,1,2,3,4,5,6,7]     22              6 
7         119M 15229M 15348M [0,1,2,3,4,5,6,8]     22              9 
6         119M 15229M 15348M [0,1,2,3,4,5,7,8]     23              5 
5         107M 15241M 15348M [0,1,2,3,4,6,7,8]     18              7 
4         107M 15241M 15348M [0,1,2,3,5,6,7,8]     18              9 
3         107M 15241M 15348M [0,1,2,4,5,6,7,8]     23              6 
2         107M 15241M 15348M [0,1,3,4,5,6,7,8]     19              6 
1         107M 15241M 15348M [0,2,3,4,5,6,7,8]     24              8 
0         107M 15241M 15348M [1,2,3,4,5,6,7,8]     23              8 
sum      1005M   133G   134G

复制代码

由提示看出，每个osd上的pg数量小于最小的数目30个。是因为在创建池的时候，指定pg和pgs为64，由于是3副本的配置，所以当有9个osd的时候，每个osd上均分了64/9 *3=21个pgs,也就是出现了如上的错误 小于最小配置30个。从pg dump看出每块osd上的PG数，都小于30

集群这种状态如果进行数据的存储和操作，会发现集群卡死，无法响应io，同时会导致大面积的osd down。

解决办法

修改pool的pg数

[root@serverc ~]# ceph osd pool set images pg_num 128

set pool 1 pg_num to 128

 [root@serverc ~]# ceph -s

复制代码

 cluster:
    id:     04b66834-1126-4870-9f32-d9121f1baccd
    health: HEALTH_WARN
            Reduced data availability: 21 pgs peering
            Degraded data redundancy: 21 pgs unclean
            1 pools have pg_num > pgp_num
            too few PGs per OSD (21 < min 30)
 
  services:
    mon: 3 daemons, quorum serverc,serverd,servere
    mgr: servere(active), standbys: serverd, serverc
    osd: 9 osds: 9 up, 9 in
 
  data:
    pools:   1 pools, 128 pgs
    objects: 8 objects, 12418 kB
    usage:   1005 MB used, 133 GB / 134 GB avail
    pgs:     50.000% pgs unknown
             16.406% pgs not active
             64 unknown
             43 active+clean
             21 peering

复制代码

出现 too few PGs per OSD

继续修改PGS

[root@serverc ~]# ceph osd pool set images pgp_num 128

set pool 1 pgp_num to 128

 查看

复制代码

[root@serverc ~]# ceph -s
  cluster:
    id:     04b66834-1126-4870-9f32-d9121f1baccd
    health: HEALTH_WARN
            Reduced data availability: 7 pgs peering
            Degraded data redundancy: 24 pgs unclean, 2 pgs degraded
  services:
    mon: 3 daemons, quorum serverc,serverd,servere
    mgr: servere(active), standbys: serverd, serverc
    osd: 9 osds: 9 up, 9 in
  data:
    pools:   1 pools, 128 pgs
    objects: 8 objects, 12418 kB
    usage:   1005 MB used, 133 GB / 134 GB avail
    pgs:     24.219% pgs not active       #pg状态，数据在重平衡（状态信息代表的意义，请参考https://www.cnblogs.com/zyxnhr/p/10616497.html第三部分内容）
             97 active+clean
             20 activating
             9  peering
             2  activating+degraded
[root@serverc ~]# ceph -s
  cluster:
    id:     04b66834-1126-4870-9f32-d9121f1baccd
    health: HEALTH_WARN
            Reduced data availability: 7 pgs peering
            Degraded data redundancy: 3/24 objects degraded (12.500%), 33 pgs unclean, 4 pgs degraded
  services:
    mon: 3 daemons, quorum serverc,serverd,servere
    mgr: servere(active), standbys: serverd, serverc
    osd: 9 osds: 9 up, 9 in
  data:
    pools:   1 pools, 128 pgs
    objects: 8 objects, 12418 kB
    usage:   1005 MB used, 133 GB / 134 GB avail
    pgs:     35.938% pgs not active
             3/24 objects degraded (12.500%)
             79 active+clean
             34 activating
             9  peering
             3  activating+degraded
             2  active+clean+snaptrim
             1  active+recovery_wait+degraded 
  io:
    recovery: 1 B/s, 0 objects/s
[root@serverc ~]# ceph -s
  cluster:
    id:     04b66834-1126-4870-9f32-d9121f1baccd
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum serverc,serverd,servere
    mgr: servere(active), standbys: serverd, serverc
    osd: 9 osds: 9 up, 9 in
  data:
    pools:   1 pools, 128 pgs
    objects: 8 objects, 12418 kB
    usage:   1050 MB used, 133 GB / 134 GB avail
    pgs:     128 active+clean
  io:
    recovery: 1023 kB/s, 0 keys/s, 0 objects/s
[root@serverc ~]# ceph -s
  cluster:
    id:     04b66834-1126-4870-9f32-d9121f1baccd
    health: HEALTH_OK             #数据平衡完毕，集群状态恢复正常
  services:
    mon: 3 daemons, quorum serverc,serverd,servere
    mgr: servere(active), standbys: serverd, serverc
    osd: 9 osds: 9 up, 9 in
  data:
    pools:   1 pools, 128 pgs
    objects: 8 objects, 12418 kB
    usage:   1016 MB used, 133 GB / 134 GB avail
    pgs:     128 active+clean
  io:
    recovery: 778 kB/s, 0 keys/s, 0 objects/s

复制代码

注：这里是实验环境，pool上也没有数据，所以修改pg影响并不大，但是如果是生产环境，这时候再重新修改pg数，会对生产环境产生较大影响。因为pg数变了，就会导致整个集群的数据重新均衡和迁移，数据越大响应io的时间会越长。具体请参考https://www.cnblogs.com/zyxnhr/p/10543814.html，对PG的状态参数有详细的解释，同时，在生产环境，修改PG，如果不影响业务，要考虑到各个方面，比如在什么时候恢复，什么时间修改pgs，请参考

参考资料：

https://my.oschina.net/xiaozhublog/blog/664560

遇到问题---ceph---ceph的rbd命令没反应卡住
直到世界的尽头
05-15 7945
情况 ceph的rbd命令没反应卡住 使用命令查看健康状态 ceph -s 如下图: 原因 undersized+degraded+peered 集群处于不健康的状态，所以禁止了io读写。 有两种可能一种是osd的节点不够副本的设置数量，比如设置了3副本但是只有2个osd。 另一个可能是 pg的num不够，会报错too few PGs per OSD (21 &lt;...
使用ceph-deploy 2.0.0 部署ceph 12.2.5集群
热门推荐
for_tech的博客
05-10 1万+
1. 环境 1.1 硬件 4台 Linux虚拟机： server0, server1, server2, server3 每台有两块磁盘 ： /dev/vdb, /dev/vdc 每台有两块网卡 ：eth0, ens9 1.2 软件 linux版本： CentOS 7.2.1511 内核版本 ： 3.10.0-327.el7.x86_64 ceph版本： 12.2.5...
分布式存储中HDFS与Ceph两者的区别是什么，各有什么优势？
liinux-Talk is cheap,show me the code.
11-30 3065
过去两年，我的主要工作都在Hadoop这个技术栈中，而最近有幸接触到了Ceph。我觉得这是一件很幸运的事，让我有机会体验另一种大型分布式存储解决方案，可以对比出HDFS与Ceph这两种几乎完全不同的存储系统分别有哪些优缺点、适合哪些场景。 对于分布式存储，尤其是开源的分布式存储，站在一个SRE的角度，我认为主要为商业公司解决了如下几个问题： 可扩展，满足业务增长导致的海量数据存储需求； ...
too few PGs per OSD (20 < min 30)
weixin_30527551的博客
05-07 506
ceph osd pool set replicapool pg_num 150 ceph osd pool set replicapool pgp_num 150 转载于:https://www.cnblogs.com/mhc-fly/p/9004802.html
ceph 14.2.22 设置 deep-scrubbed 深度清洗
最新发布
mixboot
06-10 311
设置 deep-scrubbed 深度清洗
021 Ceph关于too few PGs per OSD的问题
weixin_30553065的博客
03-31 364
在一个ceph集群中，操作创建一个池后，发现ceph的集群状态处于warn状态，信息如下 检查集群的信息 查看看池 [root@serverc ~]# ceph osd pool ls images #只有一个池 [root@serverc ~]# ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWE...
HEALTH_WARN too few PGs per OSD (16 ＜ min 30）
a13568hki的博客
07-19 317
执行ceph –s 发现集群状态并非ok，具体信息如下： $ sudo ceph -s cluster 257faba1-f259-4164-a0f9-1726bd70b05a health HEALTH_WARN too few PGs per OSD (16 < min 30) monmap e1: 1 mons at {bdc217=192.168.13.217:6789/0} election epoch 2, quo
osd max backfills
mixboot
12-29 1359
ceph version # ceph -v ceph version 13.2.10 mimic (stable) osd max backfills # ceph daemon osd.0 config show | grep osd_max_backfills 一个OSD允许的最大backfills数 "osd_max_backfills": "1", # ceph daemon osd.0 config show | grep osd_recovery_max_active 同一时间内活
【Ceph】Ceph错误记录 Ceph 运维手册
小鱼菜鸟的博客
07-22 2318
Ceph 运维手册 第一部分：常用操作 - 12. 日志和调试 - 《Ceph 运维手册》 - 书栈网 · BookStack 分布式存储ceph运维操作 (摘抄自：https://www.cnblogs.com/mm2021/p/15121746.html) —、统一节点上ceph.conf 文件 如果是在admin节点修改的ceph.c...
2021-06-01 ceph 状态码报错解决
cc012812的博客
06-01 886
ceph 状态码ceph 状态码报错解决 ceph 状态码报错解决 undersized The placement group has fewer copies than the configured pool replication level. 副本数大于节点数，增加节点可以解决 为了满足HA的要求，OSD需要分散在不同的节点上，这里拷贝数量为3，则需要有三个OSD节点来承载这些OSD，如果三个OSD分布在两个OSD节点上，则依然可能会出现”active+undersized”的状态。 这与默认的
ceph安装问题
weixin_34255055的博客
05-06 1304
ceph-deploy安装 Yum priorities pluginLoaded plugins: fastestmirror Loaded plugins: fastestmirror, priorities yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm ...
ceph -s集群报错too many PGs per OSD
添经地翼的博客
03-17 6530
背景集群状态报错，如下：# ceph -s cluster 1d64ac80-21be-430e-98a8-b4d8aeb18560 health HEALTH_WARN <-- 报错的地方 too many PGs per OSD (912 > max 300) monmap e1: 1 mons at {node1=109.105.11
health HEALTH_WARN too few PGs per OSD (16 min 30)
二哈欢乐多的博客
12-19 1890
health HEALTH_WARN too few PGs per OSD (16 min 30) health HEALTH_WARN too few PGs per OSD (16 &amp;amp;lt; min 30) 执行ceph –s 发现集群状态并非ok，具体信息如下： $ sudo ceph -s cluster 257faba1-f259-4164-a0f9-1726bd70b05a hea...
HEALTH_WARN too few PGs per OSD (21 ＜ min 30）解决方法
wangchaoqi1985的博客
03-30 264
HEALTH_WARN too few PGs per OSD (21 < min 30）解决方法
ceph pg数量调整
xiongwenwu的专栏
12-30 8529
1.计算合适的pg数 关于pg数值的合理值的计算参考 http://ceph.com/pgcalc/ 。但是请谨记，在你真正还是调整pg前，请确保集群状态是健康的。 2.调整前确保状态ok 如果 ceph -s 命令显示的集群状态是OK的，此时就可以动态的增大pg的值。 注意： 增大pg有几个步骤，同时必须比较平滑的增大，不能一次性调的太猛。对于生产环境格外注意。
解决too many PGs per OSD的问题
Cvd 的博客
12-26 2965
创建的pool过多或者pool指定的pg过多时处理
HEALTH_WARN too few PGs per OSD (16 < min 30）
weixin_34150503的博客
04-22 399
2019独角兽企业重金招聘Python工程师标准>>> ...
国庆长假诱惑多，运维开发有压力，ceph存储有大坑，学习无止境~！
zrc_xiaoguo的博客
10-03 367
终归是上了年纪，工作上的中年危机像狂风暴雨般席卷而来，尽管运维开发本不是自己的主业，但工作岗位的需求，自己也有那么一点点追求，所以就埋头开干，上了贼船，上了船才发现船员们要么划得比我快，要么溜得比我快，我还没适应过来，感觉又要被风浪推进大海，总归一句上船不容易，在船上待着也不容易，下了船更不容易（略3000字）~~~~~运维的坑基本上无法使用武功秘籍填补，只能旁敲侧击的学习，茫然中上来做个标记，唉，不说了，我先重启一下试试~~~~！
Ceph蹚坑笔记 - (2)
JeegnChen的博客
03-08 3951
Ceph RGW里的一些坑
ceph_health_status > 1
02-26
<think>好的，我现在需要解释一下用户提到的“ceph_health_status > 1”是什么意思。首先，我得回忆一下Ceph存储系统的健康状态机制。Ceph通常用状态码来表示集群的健康状况，对吧？ 我记得Ceph的健康状态有三个主要状态：HEALTH_OK、HEALTH_WARN和HEALTH_ERR。对应的状态码应该是0、1和2。所以当用户提到“ceph_health_status > 1”时，应该是指状态码大于1，也就是HEALTH_ERR的情况。这个时候集群处于错误状态，需要立即处理。 接下来，我需要确认这个信息是否正确。查阅一下Ceph的官方文档或者相关资料，确认状态码的对应关系。比如，在Ceph的命令行工具中，执行`ceph health`会返回状态信息，而通过`ceph health detail`可以查看详细信息。状态码0表示OK，1是WARN，2是ERR，所以当状态码大于1时，确实是ERR的情况。 然后，用户可能需要了解为什么会发生这种情况，以及如何解决。可能的原因包括OSD（对象存储守护进程）宕机、存储空间不足、数据不一致、硬件故障等。解决方法通常包括检查日志，查看具体的错误信息，恢复OSD，清理空间，或者进行数据修复。 还需要考虑用户的使用场景。可能用户是在监控系统中设置了警报，当状态码超过1时触发报警。这时候解释清楚状态码的含义和应对措施就很重要了。同时，用户可能希望了解如何通过命令行或API获取状态码，以及如何处理返回的结果。 另外，是否存在其他可能的误解？例如，是否有其他工具或脚本使用不同的状态码定义？但根据Ceph的标准，应该是0、1、2这三个值。所以“>1”应该特指ERR状态。 总结起来，回答应该包括状态码的含义，可能的原因，解决步骤，以及检查健康状况的命令示例。确保用中文清晰表达，避免专业术语过多，必要时举例说明。</think>`ceph_health_status > 1` 表示 **Ceph 存储集群的健康状态处于严重异常（`HEALTH_ERR`）**，需要立即处理。以下是详细解释： --- ### **Ceph 健康状态码的含义** Ceph 通过状态码表示集群健康状况： - **0 (`HEALTH_OK`)**：集群完全健康，无异常。 - **1 (`HEALTH_WARN`)**：存在警告（如性能下降、容量接近阈值），需关注但无需立即行动。 - **2 (`HEALTH_ERR`)**：严重错误（如数据丢失、服务中断），必须立即修复。 当状态码 **>1** 时，表示集群处于 `HEALTH_ERR` 状态。 --- ### **常见原因** 1. **OSD 故障** - 对象存储守护进程（OSD）宕机或磁盘损坏。 - 检查命令：`ceph osd status` 2. **存储空间不足** - 集群容量接近或达到上限（如 `near full` 或 `full`）。 - 检查命令：`ceph df` 3. **数据不一致** - 副本数不足（如 `PG_DEGRADED`）或数据恢复失败。 - 检查命令：`ceph pg stat` 4. **网络或硬件故障** - 节点间通信中断、硬盘故障等。 5. **元数据损坏** - Monitor 或元数据服务器（MDS）出现问题。 --- ### **解决步骤** 1. **查看详细错误信息** 运行 `ceph health detail` 或 `ceph -s` 获取具体错误描述。 ```bash ceph health detail ``` 2. **修复 OSD 问题** - 重启故障 OSD：`systemctl restart ceph-osd@<osd_id>` - 替换损坏的硬盘后重新加入集群。 3. **清理存储空间** - 删除无用数据或扩展集群容量。 - 调整 PG 数量（若提示 `too few PGs per OSD`）。 4. **恢复数据副本** - 触发数据恢复：`ceph pg repair <pg_id>` 5. **检查 Monitor 和网络** - 确保所有 Monitor 节点正常：`ceph mon stat` - 验证节点间网络连通性。 --- ### **示例命令** ```bash # 查看集群摘要状态 ceph -s # 检查 OSD 状态 ceph osd tree # 查看存储空间使用情况 ceph df # 列出所有异常 PG（Placement Group） ceph pg dump_stuck inactive ``` --- ### **监控与预防** - **设置告警**：通过 Prometheus + Grafana 监控 Ceph 指标（如 `ceph_health_status`）。 - **定期维护**：更新 Ceph 版本、清理冗余数据、检查硬件健康度。 若问题复杂，建议参考 [Ceph 官方文档](https://docs.ceph.com/) 或联系运维团队。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值