ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Greenplum中关于实例数的问题

Greenplum中关于实例数的问题

原创 Linux操作系统 作者:esena 时间:2012-03-29 16:24:17 0 删除 编辑
文中观点为作者的个人观点、不代表官方、如需更多帮助,请联系Pivotal官方·转载必须注明出处

    本文中所述的实例数并非指整个GP系统的Postgres实例个数,因为其受Host数量影响最大,本文讨论的是单个Host的Instance数量。
这个问题好像很简单,但很值得思考。
   有些人会想当然的认为,Instance越多性能就越好,作者不否定这一观点的合理性,但其具有显著的局限性,下面详细说明,单Host
上Instance数量的影响。
   在开始讲述作者的论点之前,先说说DCA(EMC的一体机设备)推荐的Instance配置数量。细心的使用者会发现,GP有很多可以修改的
参数配置,这些参数的缺省值都是极度适合DCA环境的(这也是很多自己折腾出来的硬件环境运行缺省配置的GP总是不太稳定的一个不可
忽略的因素),据此,作者断定,从初始化的Example配置文件可以看出,每个Host上配置6个Primary Instance是极度适合DCA的硬件环
境。不过所说的极度适合,不是指所有场景都是最佳配置,而是说,在绝大多数的生产环境中,这种配置是最适中的。
   作者曾经尝试过一个Host上配置8个、10个、12个、14个......甚至32个(32个的情况是在32Core机器上)。但当Instance数量过多时,
作者多次遇到初始完成之后的第一次启动失败,有时再次尝试启动是可以成功的,而有时会反复失败,有时会报这种错误信息:
'ssh_exchange_identification: Connection closed by remote host.'。这时需要考虑一下Instance数量的因素了。
   
通常,对于一个独立的SQL任务来说,GP的任何一个Instance只能利用一个CPU的Core做运算,而在处理并发任务时,Instance可以
获取多个CPU的Core做运算,GP的多任务是基于进程的,对多核利用也有优势。如果Instance数量过多,虽然在处理单任务时,可以得
到更多的计算资源,但瓶颈可能出在内存或者磁盘上,只有那些CPU敏感的场景才会有显著的性能提升。同时,其处理并发能力会明显降
低,当任务数量×Instance数量大于Core数量时,CPU处于切片状态,当LOAD÷Core数量越大,CPU的系统开销也越大,同时系统稳定性
也会逐渐降低。相反,如果Instance过少,可能无法完全利用磁盘和内存资源。
   综合来看,Instance数量最好满足以下几条:
   单个SQL任务就可以利用全部的磁盘资源,内存量由gp_vmem_protect_limit做相应调整
   能确保适当的并发承受能力,比如2~4个
   DCA的Instance数量与硬件资源的比例可以作为普适的参考
   例外:对于POC测试中的极限挑战不在本文所属范围

文中观点为作者的个人观点、不代表官方、如需更多帮助,请联系Pivotal官方·转载必须注明出处

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

上一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2012-03-29

  • 博文量
    18
  • 访问量
    89773