- 浏览: 999754 次
- 性别:
- 来自: 上海
文章分类
- 全部博客 (1441)
- 软件思想&演讲 (9)
- 行业常识 (250)
- 时时疑问 (5)
- java/guava/python/php/ruby/R/scala/groovy (213)
- struct/spring/springmvc (37)
- mybatis/hibernate/JPA (10)
- mysql/oracle/sqlserver/db2/mongdb/redis/neo4j/GreenPlum/Teradata/hsqldb/Derby/sakila (268)
- js/jquery/jqueryUi/jqueryEaseyUI/extjs/angulrJs/react/es6/grunt/zepto/raphael (81)
- ZMQ/RabbitMQ/ActiveMQ/JMS/kafka (17)
- lucene/solr/nuth/elasticsearch/MG4J (167)
- html/css/ionic/nodejs/bootstrap (19)
- Linux/shell/centos (56)
- cvs/svn/git/sourceTree/gradle/ant/maven/mantis/docker/Kubernetes (26)
- sonatype nexus (1)
- tomcat/jetty/netty/jboss (9)
- 工具 (17)
- ETL/SPASS/MATLAB/RapidMiner/weka/kettle/DataX/Kylin (11)
- hadoop/spark/Hbase/Hive/pig/Zookeeper/HAWQ/cloudera/Impala/Oozie (190)
- ios/swift/android (9)
- 机器学习&算法&大数据 (18)
- Mesos是Apache下的开源分布式资源管理框架 (1)
- echarts/d3/highCharts/tableau (1)
- 行业技能图谱 (1)
- 大数据可视化 (2)
- tornado/ansible/twisted (2)
- Nagios/Cacti/Zabbix (0)
- eclipse/intellijIDEA/webstorm (5)
- cvs/svn/git/sourceTree/gradle/jira/bitbucket (4)
- jsp/jsf/flex/ZKoss (0)
- 测试技术 (2)
- splunk/flunm (2)
- 高并发/大数据量 (1)
- freemarker/vector/thymeleaf (1)
- docker/Kubernetes (2)
- dubbo/ESB/dubboX/wso2 (2)
最新评论
Greenplum性能调优
以目前的使用体验的话,Greenplum(以下简称GP)的实时性确实比较高,从存储层到计算层,数据吞吐效率比类Hadoop生态圈的sql工具要好得多。
伴随性能的提升,同时加深的是gp对硬件的要求。
就目前的GP集群的硬件配置情况来说:
5台22线程,64G内存,2T硬盘,千兆网卡机器(整体情况是110线程,320GB内存,disk IO 150MB/s,网络 IO 150MB/s)
与现今的Spark集群相比(10台22线程,128G内存,30T硬盘,千兆网卡),sql查询性能提高50%-300%。以下是水星线上任务在GP和spark上运行
的对比表:
-------------------------------------------------------------------------------------------
Sql1: select count(*) from mercury.url_keyword where (keyword rlike '汽车' or keyword rlike '宝马') ;
-------------------------------------------------------------------------------------------
Sql2: select count(1) from mercury.mds_mercury_gid_dsp_c where dt='work' and Cbehe=1 and Cbiddingx=1;
--------------------------------------------------------------------------------------------
Sql3: select count(1) from mercury.url_tag_raw where dt='work' and tiyu=1 and keji=1;
-------------------------------------------------------------------------------------------
Sql4: select D.view_cnt,count(*) as gid_cnt
from (
select if(C.cnt<30,C.cnt,20) as view_cnt
from (
select B.gid,count(*) as cnt
from
(select url,keyword from url_keyword where (keyword rlike '汽车' or keyword rlike '宝马')) A
join mercury.sds_mercury_gid_cid_url B
on A.url=B.url group by B.gid
) C
) D group by D.view_cnt;
Sql
spark用时
gp用时
Gp提升%
Sql1 132s 3s 40倍
Sql2 131s 90s 30%
Sql3 3s 3s 0%
Sql4 30s 18s 30%
分析下可能的原因:
1.spark集群使用的远程HDFS数据,数据传输有很大的延迟。
2.spark虽然使用RRD策略实现数据的存储和IO,但是Spark本身还是一个离线的计算模型,
期间存在典型的输出文件的存储和大量的网络传输,相比于MPP(GP计算模型)有很大的缺陷。
这其实也是离线框架和在线框架最本质的区别。
3.在数据库层面,spark-sql框架接入的是hive数据,而hive是一个非结构行数据库,优点在
于大数据量的存储,在数据索引,数据存储结构,元数据信息等方面还收集的不够完善。
而GP是基于postgrel数据库,具有很强的DML和DQL能力,在数据索引和存储方面更优秀。
Greenplum的参数配置记录:
一共5台计算节点,每个节点部署3个segment(postgrel实例)服务,每个segment分配5线程,20G内存。
使用任务队列:目前水星使用mercury队列,设置并行数:ACTIVE_STATEMENTS=5
设置优先级:PRIORITY=MAX
eg: CREATE RESOURCE QUEUE adhoc WITH (ACTIVE_STATEMENTS=3,PRIORITY=MAX);
使用mercury用户:单作业使用内存:set statement_mem = '4GB';
最大使用内存:set max_statement_mem = '10GB';
使用Pivotal Optimizer:set optimizer to on;
不使用groupagg:set enable_groupagg to off;
eg: create user u1 with resource queue mercury;
alter user u1 set statement_mem to '2GB';
alter user u1 set optimizer to on;
系统参数配置:
gp_resqueue_memory_policy = 'eager_free' --提早回收前期阶段的内存
gp_vmem_protect_limit = 19968 --每个segment的分配内存
gp_resqueue_priority_cpucores_per_segment = 4 --每个segment的分配线程数
shared_buffers = 1GB --segment用作磁盘读写的内存缓冲区
work_mem = 4GB --segment用作sort,hash操作的内存大小
maintenance_work_mem = 10GB --segment用于VACUUM,CREATE INDEX等操作的内存大小
effective_cache_size = 10GB --segment能使用的缓存大小
max_connections = 1200 --最大连接数
max_prepared_transactions = 300 --最大预连接数
eg: gpconfig -c gp_resqueue_memory_policy -v eager_free -m eager_free
gpconfig -c work_mem -v 4GB
gpconfig -c max_connections -v 1200 -m 800
Greenplum调优方法:
1.调整表的分布键,常用于join和where条件的列作为分布键,最典型的例子是两张做join的表都用需要连接的列作为分布键。
2.周期使用VACUUM ANALYZE命令维护数据库的统计信息。
3.一般不使用Index,对于需要使用的表如果分布键是粗粒度的使用BitMap索引,如果是细粒度的使用BTree索引。
4.一般使用Pivotal Query Optimizer,在使用Legacy Query Optimizer的时候,使用explain analyze命令查看执行计划,优化不合适的operator。
5.避免大表的broadcast,多使用ANALYZE TABLE.命令。
6.看实际情况多使用enable_hashagg和enable_hashjoin。
7.用group by代替distinct.
8.在多表左连接时,小表放在左边。内连接时调整连接顺序尽量少的把数据带向上层连接。
9.多使用explain analyze看看执行计划。
explain anaylze命令介绍:
example:select count(1) from mercury.mds_mercury_gid_dsp_c where dt='work' and Cbehe=1 and Cbiddingx=1;
除此之外还有以下操作:
Hash Join
HashAggregate
Redistribute Motion
Broadcast Motion等
并发测试:
同时运行5个数据量100G的任务,集群负载情况:
cpu负载良好,存在瓶颈的是磁盘读写和网络读写。但是即使在这样的情况下,执行平时20s的任务延迟也不会太高,执行23秒也就结束了。对于10s内完成的任务如本文的sql1和sql3基本没有影 响。
但是集群的瓶颈也是很明显的,上图中的bjlg-49p122-greenplum-01节点的磁盘读速率已经到达了上限。另一方面,在内存上瓶颈依然存在,我目前还不清楚上图中的内存使用为什么显示还很少。但是从另一个图表中可以看到内存已经过载了(Used(MBytes)):
而空闲时段的内存情况是这样的:
其实硬件方面瓶颈最严重的是disk IO和network IO,下面是每台机器的IO评测情况:
disk IO:
写最大也只有140MB/s,读最大260MB/s.
Network IO:
,100MB/s左右的网络传输速率对于一个要支持大数据量的在线计算框架来说瓶颈很明显。
下图是一个大Join任务在shuffle阶段的瓶颈,cpu和内存正在空闲状态等待数据的传输:
综上所诉,现在集群存在的问题:
1.网络IO低,目前使用的千兆网卡。
2.磁盘IO低,对于本地读取需求的任务影响大。
3.现有的业务数据所有都存在hdfs,如果需要迁移到GP,不是太效率。
调研结论:
针对现有的硬件条件和数据存储情况,建议迁移实时性要求高的短作业到GP上跑,不建议迁移长时间的批处理作业。
伴随性能的提升,同时加深的是gp对硬件的要求。
就目前的GP集群的硬件配置情况来说:
5台22线程,64G内存,2T硬盘,千兆网卡机器(整体情况是110线程,320GB内存,disk IO 150MB/s,网络 IO 150MB/s)
与现今的Spark集群相比(10台22线程,128G内存,30T硬盘,千兆网卡),sql查询性能提高50%-300%。以下是水星线上任务在GP和spark上运行
的对比表:
-------------------------------------------------------------------------------------------
Sql1: select count(*) from mercury.url_keyword where (keyword rlike '汽车' or keyword rlike '宝马') ;
-------------------------------------------------------------------------------------------
Sql2: select count(1) from mercury.mds_mercury_gid_dsp_c where dt='work' and Cbehe=1 and Cbiddingx=1;
--------------------------------------------------------------------------------------------
Sql3: select count(1) from mercury.url_tag_raw where dt='work' and tiyu=1 and keji=1;
-------------------------------------------------------------------------------------------
Sql4: select D.view_cnt,count(*) as gid_cnt
from (
select if(C.cnt<30,C.cnt,20) as view_cnt
from (
select B.gid,count(*) as cnt
from
(select url,keyword from url_keyword where (keyword rlike '汽车' or keyword rlike '宝马')) A
join mercury.sds_mercury_gid_cid_url B
on A.url=B.url group by B.gid
) C
) D group by D.view_cnt;
Sql
spark用时
gp用时
Gp提升%
Sql1 132s 3s 40倍
Sql2 131s 90s 30%
Sql3 3s 3s 0%
Sql4 30s 18s 30%
分析下可能的原因:
1.spark集群使用的远程HDFS数据,数据传输有很大的延迟。
2.spark虽然使用RRD策略实现数据的存储和IO,但是Spark本身还是一个离线的计算模型,
期间存在典型的输出文件的存储和大量的网络传输,相比于MPP(GP计算模型)有很大的缺陷。
这其实也是离线框架和在线框架最本质的区别。
3.在数据库层面,spark-sql框架接入的是hive数据,而hive是一个非结构行数据库,优点在
于大数据量的存储,在数据索引,数据存储结构,元数据信息等方面还收集的不够完善。
而GP是基于postgrel数据库,具有很强的DML和DQL能力,在数据索引和存储方面更优秀。
Greenplum的参数配置记录:
一共5台计算节点,每个节点部署3个segment(postgrel实例)服务,每个segment分配5线程,20G内存。
使用任务队列:目前水星使用mercury队列,设置并行数:ACTIVE_STATEMENTS=5
设置优先级:PRIORITY=MAX
eg: CREATE RESOURCE QUEUE adhoc WITH (ACTIVE_STATEMENTS=3,PRIORITY=MAX);
使用mercury用户:单作业使用内存:set statement_mem = '4GB';
最大使用内存:set max_statement_mem = '10GB';
使用Pivotal Optimizer:set optimizer to on;
不使用groupagg:set enable_groupagg to off;
eg: create user u1 with resource queue mercury;
alter user u1 set statement_mem to '2GB';
alter user u1 set optimizer to on;
系统参数配置:
gp_resqueue_memory_policy = 'eager_free' --提早回收前期阶段的内存
gp_vmem_protect_limit = 19968 --每个segment的分配内存
gp_resqueue_priority_cpucores_per_segment = 4 --每个segment的分配线程数
shared_buffers = 1GB --segment用作磁盘读写的内存缓冲区
work_mem = 4GB --segment用作sort,hash操作的内存大小
maintenance_work_mem = 10GB --segment用于VACUUM,CREATE INDEX等操作的内存大小
effective_cache_size = 10GB --segment能使用的缓存大小
max_connections = 1200 --最大连接数
max_prepared_transactions = 300 --最大预连接数
eg: gpconfig -c gp_resqueue_memory_policy -v eager_free -m eager_free
gpconfig -c work_mem -v 4GB
gpconfig -c max_connections -v 1200 -m 800
Greenplum调优方法:
1.调整表的分布键,常用于join和where条件的列作为分布键,最典型的例子是两张做join的表都用需要连接的列作为分布键。
2.周期使用VACUUM ANALYZE命令维护数据库的统计信息。
3.一般不使用Index,对于需要使用的表如果分布键是粗粒度的使用BitMap索引,如果是细粒度的使用BTree索引。
4.一般使用Pivotal Query Optimizer,在使用Legacy Query Optimizer的时候,使用explain analyze命令查看执行计划,优化不合适的operator。
5.避免大表的broadcast,多使用ANALYZE TABLE.命令。
6.看实际情况多使用enable_hashagg和enable_hashjoin。
7.用group by代替distinct.
8.在多表左连接时,小表放在左边。内连接时调整连接顺序尽量少的把数据带向上层连接。
9.多使用explain analyze看看执行计划。
explain anaylze命令介绍:
example:select count(1) from mercury.mds_mercury_gid_dsp_c where dt='work' and Cbehe=1 and Cbiddingx=1;
除此之外还有以下操作:
Hash Join
HashAggregate
Redistribute Motion
Broadcast Motion等
并发测试:
同时运行5个数据量100G的任务,集群负载情况:
cpu负载良好,存在瓶颈的是磁盘读写和网络读写。但是即使在这样的情况下,执行平时20s的任务延迟也不会太高,执行23秒也就结束了。对于10s内完成的任务如本文的sql1和sql3基本没有影 响。
但是集群的瓶颈也是很明显的,上图中的bjlg-49p122-greenplum-01节点的磁盘读速率已经到达了上限。另一方面,在内存上瓶颈依然存在,我目前还不清楚上图中的内存使用为什么显示还很少。但是从另一个图表中可以看到内存已经过载了(Used(MBytes)):
而空闲时段的内存情况是这样的:
其实硬件方面瓶颈最严重的是disk IO和network IO,下面是每台机器的IO评测情况:
disk IO:
写最大也只有140MB/s,读最大260MB/s.
Network IO:
,100MB/s左右的网络传输速率对于一个要支持大数据量的在线计算框架来说瓶颈很明显。
下图是一个大Join任务在shuffle阶段的瓶颈,cpu和内存正在空闲状态等待数据的传输:
综上所诉,现在集群存在的问题:
1.网络IO低,目前使用的千兆网卡。
2.磁盘IO低,对于本地读取需求的任务影响大。
3.现有的业务数据所有都存在hdfs,如果需要迁移到GP,不是太效率。
调研结论:
针对现有的硬件条件和数据存储情况,建议迁移实时性要求高的短作业到GP上跑,不建议迁移长时间的批处理作业。
发表评论
-
Mysql中DATE_SUB 使用方法结合查询一天内,一周内,一月内的信息实例讲解
2018-02-07 09:05 722在对数据查询或菜单时经常要对指定的时间或时间段进行查询,例 ... -
MySQL里获取当前week、month、quarter的start_date/end_date
2018-02-06 13:51 629select curDate(); #获取当前日 ... -
查看数据库
2018-01-28 20:38 491---mysql查看用户名和密码 select Hos ... -
数据导入到数据库
2018-01-09 20:23 402数据导出当数据量大时最好是dump文件,sql文件过大不好执行 ... -
使用数据库客户端工具Oracle SQL Developer加载第三方驱动连接mysql的方法
2018-02-28 09:20 1190用Oracle SQL Developer时遇到no oc ... -
数据连接符
2018-02-28 09:32 467不同的数据库中字符串连接符不同,下面列举几种数据库的连接符 ... -
commit
2018-01-08 10:12 0刚接触SQLSERVER,刚才insert了一条记录,为什么 ... -
Redis操作命令总结
2017-10-25 12:43 1642redis-cli 中。 使用命令 ... -
PostgreSQL中表名、字段名大小写问题
2017-10-21 20:59 0学习hibernate的时候,数据库用了PostgreSQL ... -
怎么解决Greenplum中用pg
2018-07-19 09:51 432基本思路是为ns1.table1设置分布策略:root登陆 ... -
mysql unrecognized service问题解决
2017-10-21 20:34 0unrecognized 英 [ʌnˈrekəgna ... -
Oracle创建视图、通过视图创建表
2017-10-21 19:11 1088创建视图: [sql] view plain c ... -
PostgreSQL中表名、字段名大小写问题
2017-10-19 10:48 1242如果有视图依赖该表则该表不能删除 学习hibern ... -
关于性能测试几个名词概念的说明
2017-10-11 10:05 396什么是性能测试 在一定的负载下,系统的响应时间 ... -
数据库性能优化详解
2017-10-11 09:59 6721.数据库访问优化法则 要正确的优化SQL,我们需 ... -
Oracle怎样把varchar2型转成number型
2017-09-23 11:13 1593varchar2型转成number型的前提条件是varch ... -
oracle中字符串的大小比较,字符串与数字的比较和运算
2017-09-23 11:08 2568Oracle比较字符串是根据ASCII码来的,第一个字母的 ... -
greenplum 程序开发优化原则
2017-09-22 14:07 661greenplum 程序开发优化原则 1、批量数据处理后, ... -
PostgreSQL 时序最佳实践 - 证券交易系统数据库设计 - 阿里云RDS PostgreSQL最佳实践
2017-09-22 01:06 1209PostgreSQL , 证券 , 时序数据 , JSON ... -
PostgreSQL 时序最佳实践
2017-09-21 12:26 1089以股票交易为例,一共 ...
相关推荐
第四节课 Greenplum 快速调优.pdf
CPIC-Greenplum-调优汇总CPIC-Greenplum-调优汇总CPIC-Greenplum-调优汇总CPIC-Greenplum-调优汇总CPIC-Greenplum-调优汇总CPIC-Greenplum-调优汇总CPIC-Greenplum-调优汇总
2.1 系统资源3 2.2 硬件问题4 2.3 资源管理5 2.3.2 设置临时的内存大小6 2.3.3 当发生数据溢出时添加内存的大小 6 2.3.4 受影响
该内容较为全面,详细的讲解有关greenplum调优的官方指导,不适合初级入门人员,需要有一定基础的人员,最好会一点英文。
Greenplum数据查询性能测试报告,包括架构介绍,数据查询分析测试报告,单表和多表join的测试性能分析
阐述了对GreenPlum数据库性能的分析
GreenPlum6官方文档中文翻译,如下为节选: 有关配置,管理和监控Greenplum数据库安装以及...这一节的内容是Greenplum数据库的性能管理,其中包含了如何监 控,以及如何通过配置工作量来进行资源调用的优先级管理。
greenplum 简介及数据库对比 。 greenplum hive infobright 对比。
2.1 查看原始表的大小行数与结构 2 2.2 同步语句2 2.3 查看 cpu 与内存的使用情况3 2.3.1 查看 Master CPU 与内存使用情况3
greenplum数据库jdbc驱动下载 版本:greenplum-jdbc-5.1.4.jar
Greenplum是一个面向数据仓库应用的...进入大数据时代以后,Greenplum的性能在TB级别数据量的表现上非常优秀,单机性能相比Hadoop要快上好几倍;在功能和语法上,要比Hadoop上的SQL引擎Hive好用很多,普通用户更加容易上手
greenplum_jdbc
零经验安装Greenplum(足够).
gp 常见数据瓶颈SQL优化
该资源为greenplum/postfresql数据库驱动,版本:greenplum-1.0.jar,有需要可执行下载~
Greenplum是一个面向数据仓库应用的...进入大数据时代以后,Greenplum的性能在TB级别数据量的表现上非常优秀,单机性能相比Hadoop要快上好几倍;在功能和语法上,要比Hadoop上的SQL引擎Hive好用很多,普通用户更加容易上手.
基于Greenplum官方文档的中文版手册,超级实用,文档结构清晰。Greenplum数据库的最佳实践
Greenplum的安装(体验版centos+Greenplum).
greenplum管理员手册,使用greenplum数据必备