测试环境
服务器 192.168.1.1,192.168.1.2,192.168.1.3,192.168.1.4,192.168.1.5 CPU 1~3为Intel(R) Pentium(R) D CPU 2.80GHz, 4、5为Intel(R) Xeon(R) 3040 1.86GHz 操作系统 Centos 4.4 Cluster版本 5.1.27-ndb-6.3.17-cluster-gpl-log MySQL Cluster Server (GPL) 测试软件 sysbench
Cluster结构
192.168.1.1,192.168.1.2,192.168.1.3,192.168.1.4为data node,192.168.1.5为management node和sql node。192.168.1.4为第二台sql node,并运行sysbench。
Cluster中NoOfReplicas设为2,即每行数据储存两次,到两台data node上。
测试结果
测试是使用sysbench的oltp测试模式进行的,它的测试查询以事 务为单位,一个事务中包含了联机事务处理中常见的读和写操作。测试表的行数为100万,对1到128个线程并发做了测试。其中Innodb的测试数据作为 比较。innodb设置了足够大的buffer_pool,能够把整张表缓存到内存里。Cluster的测试中,除了内存选项,其他都是默认配置,在一个 测试中出现错误没有完成,是因为资源的限制导致错误,只是查询失败,集群并没有出现问题。
"2 data"的测试是使用2个data node的结果,NoOfReplicas同样是2,即两台数据节点中的内容完全相同。比较它和"4 data"的结果可以看出,虽然增加了节点,但由于增加了节点之间的通讯的消耗,查询的速度并没有提升反而下降。增加了节点的优势在于大并发量,当只有一 个sql node时,这个节点成为瓶颈,所以4个data node的优势没有表现出来。当使用两个sql node时,比较"2 data + 2 sql"和"4 data + 2 sql"就可看到使用更多的节点可以提高并发量。"4 data, disk"是使用硬盘的表格式测试,每个节点上表文件的大小为120M左右,用于缓存表内容的内存大小设置为64M,即表的内容不能完全缓存到内存中。这样在查询中需要硬盘的随机读写,使得查询的速度和并发量都有大幅下降。
线程数 innodb 2 data + 1 sql 2 data + 2 sql 4 data + 1 sql 4 data + 2 sql 4 data, disk
每秒事务数 | 1 | 202.05 | 95.52 | - | 46.75 | - | 16.02 |
平均响应时间(秒) | 0.0049 | 0.0105 | 0.0214 | 0.0624 |
每秒事务数 | 2 | 358.21 | 153.05 | - | 94.65 | - | 24.74 |
平均响应时间(秒) | 0.0056 | 0.0131 | 0.0211 | 0.0808 |
每秒事务数 | 4 | 539.47 | 249.31 | - | 187.92 | - | 46.08 |
平均响应时间(秒) | 0.0074 | 0.016 | 0.0213 | 0.0868 |
每秒事务数 | 8 | 616.36 | 340.24 | - | 295.99 | - | 83.07 |
平均响应时间(秒) | 0.013 | 0.0235 | 0.027 | 0.0962 |
每秒事务数 | 16 | 574.6 | 427.09 | - | 404.7 | - | 94.71 |
平均响应时间(秒) | 0.0278 | 0.0374 | 0.0395 | 0.1688 |
每秒事务数 | 32 | 538.16 | 431.75 | 413.09 | 421.8 | 491.55 | 97.42 |
平均响应时间(秒) | 0.0594 | 0.0741 | 0.0774 | 0.0758 | 0.065 | 0.3281 |
每秒事务数 | 64 | 497.74 | 390.83 | 401.09 | 385.5 | 498.05 | × |
平均响应时间(秒) | 0.1285 | 0.1637 | 0.1595 | 0.166 | 0.1294 |
每秒事务数 | 128 | 453.15 | - | 382.24 | - | 461.39 | - |
平均响应时间(秒) | 0.2824 | 0.3348 | 0.2782 |
表中"-"代表没有进行测试,"×"代表测试中出现错误。
分享到:
相关推荐
• 多线程的slave 获得更好的性能。 对于任何工作负载。 • 没有vip的主从故障转移操作或使用。No Master-Slave Failover(失效备援) Operations or Use of VIP • 热备份 故障转移期间没有停机时间(因为没有故障转移...
本次实验的目的主要是搭建Redis Cluster和TwemProxy Redis两种集群,分别对其进行性能测试,测试出集群性能的拐点,找出性能的瓶颈有哪些,并对两套集群进行比较,以便于在不同业务场景下择优选择。
### Redis Cluster 升级测试详解 #### 一、环境准备 在进行Redis Cluster的...此外,通过对各种特殊场景的测试,如大数据量下的主从切换和大量写入情况下的主从同步性能测试,能够进一步提高系统的鲁棒性和可靠性。
根据给定的文件信息,我们将深入探讨Sun Cluster 3.0的安装指南,这是一个由Sun Microsystems公司提供的集群解决方案,用于构建高可用性和高性能计算环境。Sun Cluster 3.0是Sun Microsystems在2000年发布的一个重要...
测试环节包括验证节点间的通信、数据插入和查询性能、故障切换和恢复能力等,确保集群在各种情况下的稳定运行。 总的来说,MySQL Cluster 提供了一种强大而灵活的分布式数据库解决方案,尤其适合需要高可用性和高...
MySQL Cluster 是一种高性能、高可用性且可扩展的集群解决方案,主要用于在无共享架构中部署内存中的数据库集群。这种架构允许使用低成本的硬件设备,同时不依赖特定的软件或硬件配置。 #### 二、MySQL Cluster 的...
Sun Cluster内置了故障检测机制,能自动检测硬件和软件故障。一旦检测到故障,会启动相应的故障恢复策略,如资源迁移或重启。管理员应熟悉各种故障场景下的处理流程,以减少业务中断时间。 六、性能调优 为了保持...
它为IT组织提供了一个经过预先测试和验证的配置模板,从而大大减少了规划、架构设计与实际部署所需的时间。 #### 二、Oracle VM Blade Cluster参考配置组成部分 Oracle VM Blade Cluster参考配置主要由以下几个关键...
- **检测慢节点:** 为了保持集群性能,需要定期检测慢节点,并采取措施提高其性能。 - **处理多主冲突:** 在多主复制环境下,可能出现冲突,需要有策略来解决这些冲突。 - **两节点集群:** 两节点集群是一种特殊...
4. **故障检测与恢复**:每个节点都会监控其他节点的状态,如果发现某节点失效,会触发故障转移过程。一个新的主节点会被选举出来接管失效节点的槽和数据。 **三、MySQL与Redis Cluster的结合** 在描述中提到,这...
MySQL Cluster 允许在单个集群中运行多个 MySQL 服务器,从而提供了一个强大的解决方案来应对高可用性和高性能的需求。 - **测试环境**:本文档基于 CentOS 4.6 系统进行了测试。 - **数据库版本**:使用的 MySQL ...
Oracle Solaris Cluster 4.10 是一个高度可用性解决方案,专为运行关键业务应用程序的企业设计。这个集群系统提供了一种方法来确保即使在硬件或软件故障时,服务也能持续运行,从而保证业务连续性和数据保护。Oracle...
对于网络故障,Redis Cluster提供了故障检测和自动故障转移机制,但有时可能需要人工干预,如手动确认故障节点的状态。 在压缩包中的HTML和PDF教程中,详细地讲解了这些步骤和操作,同时包含了一些示例代码,帮助你...
本案例将详细介绍如何在一个测试环境中搭建一个最小规模的MySQL Cluster集群,包含一个管理节点、两个数据节点和两个SQL节点。 **系统环境**: - 操作系统:Red Hat Enterprise Linux 6 - MySQL Cluster版本:...
6. 测试集群功能,确保所有节点能正常通信。 在安装过程中,务必遵循官方文档的指导,同时注意不同Linux发行版可能存在的差异。安装完成后,定期更新和维护这些包,以保持集群的最佳运行状态。 总之,安装Cluster ...
对于企业级应用而言,合理利用Weblogic Cluster可以极大地提高系统的稳定性和性能,同时简化运维工作,降低运营成本。在实际应用中,还需要结合具体的业务场景和技术需求来进行细致的设计和调优。