Greenplum中关于实例数的问题

文中观点为作者的个人观点、不代表官方、如需更多帮助，请联系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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11022757/viewspace-719829/