本帖最后由 la19850302 于 2010-02-24 09:20 编辑
回复 9# 5sky
可以, 篇幅有限,我针对几个比较严重的问题列出测试结果,也是我正在力图解决的问题
1 稳定性和可靠性:平均无故障时间等指标是说明系统的可靠性的。
cluster的核心宗旨是为了解决高可用问题,所以这稳定可靠性对cluster是最高准则.要让系统稳定可靠,就应该对系统的出错机率、性能劣化趋势有足够的了解.
具体问题: | 测试原因 | a
mysql-cluster 重启非常慢的问题 | 随着数据量的增大,数据节点的重启时间随着数据量的增大而增加,这个特性影响以下方面:
1 重新配置数据节点参数
2 需重启数据节点的其他重要操作 | b
ndbd进程消耗巨大内存,大量内存
目前未知用途,回收困难 | NDB数据全部存放在内存中,如果在上线前无法估算系统使用的内存,而任其无法预测的增长,那么系统毫无稳定性可言,实际因为内存问题导致系统crash的各类bug层出不穷 | c
各类目前无法解决的bug | 测试这段时间,极少的数据量情况下Mysql节点自重启多次,单个数据节点失败每周一次,错误日志抽象深涩,严重bug举例: Bug# |
下面是内存超额分配的测试, 系统内存越大超支使用表现越严重
初始化 ndbd --initial | [config] noofreplicas=2 DataMemory=500M IndexMemory=250M | ndbd进程实际分配内存1.0g | 疑点一 DataMemory+IndexMemory=750M< 实际使用1.0g | 插入总量在140M的数据后(根据原理估算到的所有节点DataMemory+IndexMemory总量,这个有做过测试,估算结果基本正确),进程使用内存增加到1.1g | 疑点二:已经预分配DataMemory+IndexMemory的还没用完,这么小的数据量为何还需分配100M的内存.用到哪里了? |
2 性能
这里我不将测试方案贴出来,主要从数据量,访问类型(查询或更新),并发这3个方面做的对比测试,在粗放的参数配置下(即只针对cluster的主要参数做调整配置,不可能精细的测试每个参数不同值下的性能),相同的硬件配置,性能不及innodb的1/10. 当然,性能测试不是重点,这项任务弹性很大,需要投入更多的时间.同时,软硬件环境不同,这个结果的参考性意义也不大,但纵观讨论cluster性能的文章,其性能情况一点也不乐观,话说到这里,想到cluster用了这么多内存,我又忍不住想骂了. 3 管理成本: 1 文件系统:数据节点空间消耗非常大,同样不可预测的文件大小.对于cluster的文件系统结构和作用,只在NDB API第5章中简单的介绍了下,实际情况下空间使用多的过分,完全不知道为什么这么的文件空间. 2 备份方式:NDB有自己的备份命令,简单测试过,备份时间较长,备份文件较大,恢复方式更加恶心,居然要对每个数据节点进行恢复操作. 3 自带管理工具使用文档简陋.对这些工具命令参数和输出内容的说明很少,使用不便 总结:在一个以高可用为最高目标的系统里,如此贫乏的技术支持,以及尚不成熟的产品质量,实在难以让人接受. | 
免费注册
楼主: la19850302
发表于 2010-02-23 16:54
