greenplum架构介绍，greenplum架构分析

今天小编为大家分享Windows系统下载、Windows系统教程、windows相关应用程序的文章，希望能够帮助到大家！

由于新版的KV、金山、瑞星都加入了对网页、插件、邮件的随机监控，无疑增大了系统负担。处理方式：基本上没有合理的处理方式，尽量使用最少的监控服务吧，者，升级你的硬件配备。

2、驱动没有经过认证，造成CPU资源占用100%

大量的测试版的驱动在网上泛滥，造成了难以发现的故障原因。处理方式：尤其是显卡驱动特别要注意，建议使用微软认证的或由官方发布的驱动，并且严格核对型号、版本。

大量的蠕虫病毒在系统内部迅速复制，造成CPU占用资源率据高不下。解决办法：用可靠的杀毒软件彻底清理系统内存和本地硬盘，并且打开系统设置软件，察看有无异常启动的程序。经常性更新升级杀毒软件和防火墙，加强防毒意识，掌握正确的防杀毒知识。

4、控制面板—管理工具—服务—RISING REALTIME MONITOR SERVICE点鼠标右键，改为手动。

5、开始->；运行->；msconfig->；启动，关闭不必要的启动项，重启。

svchost.exe是Windows XP系统的一个核心进程。svchost.exe不单单只出现在Windows XP中，在使用NT内核的Windows系统中都会有svchost.exe的存在。一般在Windows 2000中svchost.exe进程的数目为2个，而在Windows XP中svchost.exe进程的数目就上升到了4个及4个以上。

当安装了Windows XP的计算机做服务器的时候，收到端口 445上的连接请求时，它将分配内存和少量地调配 CPU资源来为这些连接提供服务。当负荷过重的时候，CPU占用率可能过高，这是因为在工作项的数目和响应能力之间存在固有的权衡关系。你要确定合适的 MaxWorkItems设置以提高系统响应能力。如果设置的值不正确，服务器的响应能力可能会受到影响，或者某个用户独占太多系统资源。

要解决此问题，我们可以通过修改注册表来解决：在注册表编辑器中依次展开[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanserver ]分支，在右侧窗口中新建一个名为“maxworkitems”的DWORD值。然后双击该值，在打开的窗口中键入下列数值并保存退出：

9、看看是不是Windows XP使用鼠标右键引起CPU占用100%

在资源管理器里面，当你右键点击一个目录或一个文件，你将有可能出现下面所列问题：

任何文件的拷贝操作在那个时间将有可能停止相应

所有的流输入/输出操作例如使用Windows Media Player听音乐将有可能是音乐失真成因：

当你在资源管理器里面右键点击一个文件或目录的时候，当快捷菜单显示的时候，CPU占用率将增加到100%，当你关闭快捷菜单的时候才返回正常水平。

方法一：关闭“为菜单和工具提示使用过渡效果”

2、在“控制面板”里面双击“显示”

3、在“显示”属性里面点击“外观”标签页

4、在“外观”标签页里面点击“效果”

5、在“效果”对话框里面，清除“为菜单和工具提示使用过渡效果”前面的复选框接着点击两次“确定”按钮。

方法二：在使用鼠标右键点击文件或目录的时候先使用鼠标左键选择你的目标文件或目录。然后再使用鼠标右键弹出快捷菜单。

一般情况下CPU占了100%的话我们的电脑总会慢下来，而很多时候我们是可以通过做一点点的改动就可以解决，而不必问那些大虾了。

当机器慢下来的时候，首先我们想到的当然是任务管理器了，看看到底是哪个程序占了较搞的比例，如果是某个大程序那还可以原谅，在关闭该程序后只要CPU正常了那就没问题；如果不是，那你就要看看是什幺程序了，当你查不出这个进程是什幺的时候就去google或者baidu搜。有时只结束是没用的，在xp下我们可以结合msconfig里的启动项，把一些不用的项给关掉。在2000下可以去下个winpatrol来用。

一些常用的软件，比如浏览器占用了很搞的CPU，那幺就要升级该软件或者干脆用别的同类软件代替，有时软件和系统会有点不兼容，当然我们可以试下xp系统下给我们的那个兼容项，右键点该。exe文件选兼容性。

svchost.exe有时是比较头痛的，当你看到你的某个svchost.exe占用很大CPU时你可以去下个aports或者fport来检查其对应的程序路径，也就是什幺东西在掉用这个svchost.exe，如果不是c:Windowssystem32（xp）或c:winntsystem32（2000）下的，那就可疑。升级杀毒软件杀毒吧。

右击文件导致100%的CPU占用我们也会遇到，有时点右键停顿可能就是这个问题了。官方的解释：先点左键选中，再右键（不是很理解）。非官方：通过在桌面点右键-属性-外观-效果，取消“为菜单和工具提示使用下列过度效果（U）”来解决。还有某些杀毒软件对文件的监控也会有所影响，可以关闭杀毒软件的文件监控；还有就是对网页，插件，邮件的监控也是同样的道理。

一些驱动程序有时也可能出现这样的现象，最好是选择微软认证的或者是官方发布的驱动来装，有时可以适当的升级驱动，不过记得最新的不是最好的。

CPU降温软件，由于软件在运行时会利用所以的CPU空闲时间来进行降温，但Windows不能分辨普通的CPU占用和降温软件的降温指令之间的区别，因此CPU始终显示100%，这个就不必担心了，不影响正常的系统运行。

在处理较大的word文件时由于word的拼写和语法检查会使得CPU累，只要打开word的工具-选项-拼写和语法把“检查拼写和检查语法”勾去掉。

单击avi视频文件后CPU占用率高是因为系统要先扫描该文件，并检查文件所有部分，并建立索引；解决办法：右击保存视频文件的文件夹-属性-常规-高级，去掉为了快速搜索，允许索引服务编制该文件夹的索引的勾。

1、dllhost进程造成CPU使用率占用100%

特征：服务器正常CPU消耗应该在75%以下，而且CPU消耗应该是上下起伏的，出现这种问题的服务器，CPU会突然一直处100%的水平，而且不会下降。查看任务管理器，可以发现是DLLHOST.EXE消耗了所有的CPU空闲时间，管理员在这种情况下，只好重新启动IIS服务，奇怪的是，重新启动IIS服务后一切正常，但可能过了一段时间后，问题又再次出现了。

有一个或多个ACCESS数据库在多次读写过程中损坏，微软的MDAC系统在写入这个损坏的ACCESS文件时，ASP线程处于BLOCK状态，结果其它线程只能等待，IIS被死锁了，全部的CPU时间都消耗在DLLHOST中。

安装“一流信息监控拦截系统”，使用其中的“首席文件检查官IIS健康检查官”软件，

启用“查封我号锁模块”，设置：

监控的目录，请指定您的主机的文件所在目录：

监控生成的日志的文件保存位置在安装目录的log目录中，文件名为：logblock.htm

停止IIS，再启动“首席文件检查官IIS健康检查官”，再启动IIS，“首席文件检查官IIS健康检查官”会在logblock.htm中记录下最后写入的ACCESS文件的。

过了一段时间后，当问题出来时，例如CPU会再次一直处100%的水平，可以停止IIS，检查logblock.htm所记录的最后的十个文件，注意，最有问题的往往是计数器类的ACCESS文件，例如：“**COUNT.MDB”，“**COUNT.ASP”，可以先把最后十个文件或有所怀疑的文件删除到回收站中，再启动IIS，看看问题是否再次出现。我们相信，经过仔细的查找后，您肯定可以找到这个让您操心了一段时间的文件的。

找到这个文件后，可以删除它，或下载下来，用ACCESS2000修复它，问题就解决了。

2、svchost.exe造成CPU使用率占用100%

在win.ini文件中，在[Windows]下面，“run=”和“load=”是可能加载“木马”程序的途径，必须仔细留心它们。一般情况下，它们的等号后面什幺都没有，如果发现后面跟有路径与文件名不是你熟悉的启动文件，你的计算机就可能中上“木马”了。当然你也得看清楚，因为好多“木马”，如“AOL Trojan木马”，它把自身伪装成command.exe文件，如果不注意可能不会发现它不是真正的系统启动文件。

在system.ini文件中，在[BOOT]下面有个“shell=文件名”。正确的文件名应该是“explorer.exe”，如果不是“explorer.exe”，而是“shell= explorer.exe程序名”，那幺后面跟着的那个程序就是“木马”程序，就是说你已经中“木马”了。

在注册表中的情况最复杂，通过regedit命令打开注册表编辑器，在点击至：“HKEY-LOCAL-MACHINESoftwareMicrosoftWindowsCurrentVersionRun”目录下，查看键值中有没有自己不熟悉的自动启动文件，扩展名为EXE，这里切记：有的“木马”程序生成的文件很像系统自身文件，想通过伪装蒙混过关，如“Acid Battery v1.0木马”，它将注册表“HKEY-LOCAL-MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun”下的Explorer键值改为Explorer=“C:Windowsexpiorer.exe”，“木马”程序与真正的Explorer之间只有“i”与“l”的差别。当然在注册表中还有很多地方都可以隐藏“木马”程序，如：“HKEY-CURRENT-USERSoftwareMicrosoftWindowsCurrentVersionRun”、“HKEY-USERS****SoftwareMicrosoftWindowsCurrentVersionRun”的目录下都有可能，最好的办法就是在“HKEY-LOCAL-MACHINESoftwareMicrosoftWindowsCurrentVersionRun”下找到“木马该病毒也称为”Code Red II（红色代码2）“病毒，与早先在西方英文系统下流行”红色代码“病毒有点相反，在国际上被称为VirtualRoot（虚拟目录）病毒。该蠕虫病毒利用Microsoft已知的溢出漏洞，通过80端口来传播到其它的Web页服务器上。受感染的机器可由黑客们通过Http Get的请求运行scripts/root.exe来获得对受感染机器的完全控制权。

当感染一台服务器成功了以后，如果受感染的机器是中文的系统后，该程序会休眠2天，别的机器休眠1天。当休眠的时间到了以后，该蠕虫程序会使得机器重新启动。该蠕虫也会检查机器的月份是否是10月或者年份是否是2002年，如果是，受感染的服务器也会重新启动。当Windows NT系统启动时，NT系统会自动搜索C盘根目录下的文件explorer.exe，受该网络蠕虫程序感染的服务器上的文件explorer.exe也就是该网络蠕虫程序本身。该文件的大小是8192字节，VirtualRoot网络蠕虫程序就是通过该程序来执行的。同时，VirtualRoot网络蠕虫程序还将cmd.exe的文件从Windows NT的system目录拷贝到别的目录，给黑客的入侵敞开了大门。它还会修改系统的注册表项目，通过该注册表项目的修改，该蠕虫程序可以建立虚拟的目录C或者D，病毒名由此而来。值得一提的是，该网络蠕虫程序除了文件explorer.exe外，其余的操作不是基于文件的，而是直接在内存中来进行感染、传播的，这就给捕捉带来了较大难度。

”程序的文件名，再在整个注册表中搜索即可。

我们先看看微软是怎样描述svchost.exe的。在微软知识库314056中对svchost.exe有如下描述：svchost.exe是从动态链接库（DLL）中运行的服务的通用主机进程名称。

其实svchost.exe是Windows XP系统的一个核心进程。svchost.exe不单单只出现在Windows XP中，在使用NT内核的Windows系统中都会有svchost.exe的存在。一般在Windows 2000中svchost.exe进程的数目为2个，而在Windows XP中svchost.exe进程的数目就上升到了4个及4个以上。所以看到系统的进程列表中有几个svchost.exe不用那幺担心。

svchost.exe到底是做什幺用的呢？

首先我们要了解一点那就是Windows系统的中的进程分为：独立进程和共享进程这两种。由于Windows系统中的服务越来越多，为了节约有限的系统资源微软把很多的系统服务做成了共享模式。那svchost.exe在这中间是担任怎样一个角色呢？

svchost.exe的工作就是作为这些服务的宿主，即由svchost.exe来启动这些服务。svchost.exe只是负责为这些服务提供启动的条件，其自身并不能实现任何服务的功能，也不能为用户提供任何服务。svchost.exe通过为这些系统服务调用动态链接库（DLL）的方式来启动系统服务。

svchost.exe是病毒这种说法是任何产生的呢？

因为svchost.exe可以作为服务的宿主来启动服务，所以病毒、木马的编写者也挖空心思的要利用svchost.exe的这个特性来迷惑用户达到入侵、破坏计算机的目的。

如何才能辨别哪些是正常的svchost.exe进程，而哪些是病毒进程呢？

svchost.exe的键值是在“HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionSvchost”，如图1所示。图1中每个键值表示一个独立的svchost.exe组。

微软还为我们提供了一种察看系统正在运行在svchost.exe列表中的服务的方法。以Windows XP为例：在“运行”中输入：cmd，然后在命令行模式中输入：tasklist/svc。系统列出如图2所示的服务列表。图2中红框包围起来的区域就是svchost.exe启动的服务列表。如果使用的是Windows 2000系统则把前面的“tasklist/svc”命令替换为：“tlist-s”即可。如果你怀疑计算机有可能被病毒感染，svchost.exe的服务出现异常的话通过搜索svchost.exe文件就可以发现异常情况。一般只会找到一个在：“C:WindowsSystem32”目录下的svchost.exe程序。如果你在其它目录下发现svchost.exe程序的话，那很可能就是中毒了。

还有一种确认svchost.exe是否中毒的方法是在任务管理器中察看进程的执行路径。但是由于在Windows系统自带的任务管理器不能察看进程路径，所以要使用第三方的进程察看工具。

上面简单的介绍了svchost.exe进程的相关情况。总而言之，svchost.exe是一个系统的核心进程，并不是病毒进程。但由于svchost.exe进程的特殊性，所以病毒也会千方百计的入侵svchost.exe。通过察看svchost.exe进程的执行路径可以确认是否中毒。

3、Services.exe造成CPU使用率占用100%

在基于 Windows 2000的计算机上，Services.exe中的 CPU使用率可能间歇性地达到100%，并且计算机可能停止响应（挂起）。出现此问题时，连接到该计算机（如果它是文件服务器或域控制器）的用户会被断开连接。您可能还需要重新启动计算机。如果 Esent.dll错误地处理将文件刷新到磁盘的方式，则会出现此症状。

要解决此问题，请获取最新的 Microsoft Windows 2000 Service Pack。有关其它信息，请单击下面的文章编号，以查看 Microsoft知识库中相应的文章：

260910如何获取最新的 Windows 2000 Service Pack

Microsoft提供了受支持的修补程序，但该程序只是为了解决本文所介绍的问题。只有计算机遇到本文提到的特定问题时才可应用此修补程序。此修补程序可能还会接受其它一些测试。因此，如果这个问题没有对您造成严重的影响，Microsoft建议您等待包含此修补程序的下一个 Windows 2000 Service Pack。

要立即解决此问题，请与“Microsoft产品支持服务”联系，以获取此修补程序。有关“Microsoft产品支持服务”电话号码和支持费用信息的完整列表，请访问 Microsoft Web站点：

注意:特殊情况下，如果 Microsoft支持专业人员确定某个特定的更新程序能够解决您的问题，可免收通常情况下收取的电话支持服务费用。对于特定更新程序无法解决的其它支持问题和事项，将正常收取支持费用。

4、正常软件造成CPU使用率占用100%

首先，如果是从开机后就发生上述情况直到关机。那幺就有可能是由某个随系统同时登陆的软件造成的。可以通过运行输入“msconfig”打开“系统实用配置工具”，进入“启动”选项卡。接着，依次取消可疑选项前面的对钩，然后重新启动电脑。反复测试直到找到造成故障的软件。或者可以通过一些优化软件如“优化大师”达到上述目的。另：如果键盘内按键卡住也可能造成开机就出现上述问题。

如果是使用电脑途中出项这类问题，可以调出任务管理器（WINXP CTRL+ALT+DEL WIN2000 CTRL+SHIFT“ESC），进入”进程“选项卡，看”CPU“栏，从里面找到占用资源较高的程序（其中SYSTEM IDLE PROCESS是属于正常，它的值一般都芨撸？？淖饔檬歉嫠叩鼻澳憧捎玫腃PU资源是多少，所以它的值越高越好）通过搜索功能找到这个进程属于哪个软件。然后，可以通过升级、关闭、卸载这个软件或者干脆找个同类软件替换，问题即可得到解决。

5、病毒、木马、间谍软件造成CPU使用率占用100%

出现CPU占用率100%的故障经常是因为病毒木马造成的，比如震荡波病毒。应该首先更新病毒库，对电脑进行全机扫描。接着，在使用反间谍软件Ad—Aware，检查是否存在间谍软件。论坛上有不少朋友都遇到过svchost.exe占用CPU100%，这个往往是中毒的表现。

svchost.exe Windows中的系统服务是以动态链接库（DLL）的形式实现的，其中一些会把可执行程序指向svchost.exe，由它调用相应服务的动态链接库并加上相应参数来启动服务。正是因为它的特殊性和重要性，使它更容易成为了一些病毒木马的宿主。

6、explorer.exe进程造成CPU使用率占用100%

在system.ini文件中，在[BOOT]下面有个”shell=文件名“。正确的文件名应该是”explorer.exe“，如果不是”explorer.exe“，而是”shell= explorer.exe程序名“，那幺后面跟着的那个程序就是”木马“程序，就是说你已经中”木马“了。

在注册表中的情况最复杂，通过regedit命令打开注册表编辑器，在点击至：”HKEY-LOCAL-MACHINESoftwareMicrosoftWindowsCurrentVersionRun“目录下，查看键值中有没有自己不熟悉的自动启动文件，扩展名为EXE，这里切记：有的”木马“程序生成的文件很像系统自身文件，想通过伪装蒙混过关，如”Acid Battery v1.0木马“，它将注册表”HKEY-LOCAL-MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun“下的

Explorer键值改为Explorer=”C:Windowsexpiorer.exe“，”木马“程序与真正的Explorer之间只有”i“与”l“的差别。当然在注册表中还有很多地方都可以隐藏”木马“程序，如：”HKEY-CURRENTUSERSoftwareMicrosoftWindowsCurrentVersionRun“、”HKEYUSERS****SoftwareMicrosoftWindowsCurrentVersionRun“的目录下都有可能，最好的办法就是在”HKEYLOCALMACHINESoftwareMicrosoftWindowsCurrentVersionRun“下找到”木马“程序的文件名，再在整个注册表中搜索即可。

7、超线程导致CPU使用率占用100%

这类故障的共同原因就是都使用了具有超线程功能的P4 CPU。我查找了一些资料都没有明确的原因解释。据一些网友总结超线程似乎和天网防火墙有冲突，可以通过卸载天网并安装其它防火墙解决，也可以通过在BIOS中关闭超线程功能解决。

8、AVI视频文件造成CPU使用率占用100%

在Windows XP中，单击一个较大的AVI视频文件后，可能会出现系统假死现象，并且造成exploere.exe进程的使用率100%，这是因为系统要先扫描该文件，并检查文件所有部分，建立索引。如果文件较大就会需要较长时间并造成CPU占用率100%。解决方法：右键单击保存视频文件的文件夹，选择”属性—>常规—>高级“，去掉”为了快速搜索，允许索引服务编制该文件夹的索引“前面复选框的对钩即可。

现在的杀毒软件一般都加入了，对网页、邮件、个人隐私的即时监空功能，这样无疑会加大系统的负担。比如：在玩游戏的时候，会非常缓慢。关闭该杀毒软件是解决得最直接办法。

10、处理较大的Word文件时CPU使用率过高

上述问题一般还会造成电脑假死，这些都是因为WORD的拼写和语法检查造成的，只要打开WORD的”工具—选项“，进入”拼写和语法“选项卡，将其中的”键入时检查拼写“和”键入时检查语法“两项前面的复选框中的钩去掉即可。

最近对离线数仓体系进行了扩容和架构改造，也算是一波三折，出了很多小插曲，有一些改进点对我们来说也是真空地带，通过对比和模拟压测总算是得到了预期的结果，这方面尤其值得一提的是郭运凯同学的敬业，很多前置的工作，优化和应用压测的工作都是他完成的。 

整体来说，整个事情的背景是因为服务器硬件过保，刚好借着过保服务器替换的机会来做集群架构的优化和改造。 

在之前也总结过目前存在的一些潜在问题，也是本次部署架构改进的目标：

1）之前的GP segment数量设计过度，因为资源限制，过多考虑了功能和性能，对于集群的稳定性和资源平衡性考虑有所欠缺，在每个物理机节点上部署了10个Primary,10个Mirror，一旦1个服务器节点不可用，整个集群几乎无法支撑业务。

2）GP集群的存储资源和性能的平衡不够，GP存储基于RAID-5,如果出现坏盘，磁盘重构的代价比较高，而且重构期间如果再出现坏盘，就会非常被动，而且对于离线数仓的数据质量要求较高，存储容量相对不是很大，所以在存储容量和性能的综合之上，我们选择了RAID-10。

3)集群的异常场景的恢复需要完善，集群在异常情况下（如服务器异常宕机，数据节点不可用，服务器后续过保实现节点滚动替换）的故障恢复场景测试不够充分，导致在一些迁移和改造中，相对底气不足，存在一些知识盲区。

4）集群版本过低，功能和性能上存在改进空间。毕竟这个集群是4年前的版本，底层的PG节点的版本也比较旧了，在功能上和性能上都有一定的期望，至少能够与时俱进。

5）操作系统版本升级，之前的操作系统是基于CentOS6，至少需要适配CentOS 7。

6）集群TPCH压测验收，集群在完成部署之后，需要做一次整体的TPCH压测验收，如果存在明显的问题需要不断调整配置和架构，使得达到预期的性能目标。

此外在应用层面也有一些考虑，总而言之，是希望能够解决绝大多数的痛点问题，无论是在系统层面，还是应用层面，都能上一个台阶。

明确了目标，就是拆分任务来规划设计了，在规划设计方面主要有如下的几个问题：

1）Greenplum的版本选择，目前有两个主要的版本类别，一个是开源版（Open Source distribution）和Pivotal官方版，它们的其中一个差异就是官方版需要注册，签署协议，在此基础上还有GPCC等工具可以用，而开源版本可以实现源码编译或者rpm安装，无法配置GPCC。综合来看，我们选择了开源版本的6.16.2，这其中也询问了一些行业朋友，特意选择了几个涉及稳定性bug修复的版本。

2）数据集市的技术选型，在数据集市的技术选型方面起初我是比较坚持基于PostgreSQL的模式，而业务侧是希望对于一些较为复杂的逻辑能够通过GP去支撑，一来二去之后，加上我咨询了一些行业朋友的意见，是可以选择基于GP的方案，于是我们就抱着试一试的方式做了压测，所以数据仓库和和数据集市会是两个不同规模体量的GP集群来支撑。

3）GP的容量规划，因为之前的节点设计有些过度，所以在数量上我们做了缩减，每台服务器部署12个segment节点，比如一共12台服务器，其中有10台服务器是Segment节点，每台上面部署了6个Primary,6个Mirror，另外2台部署了Master和Standby，就是即（6+6）*10+2，整体的配置情况类似下面的模式。

4）部署架构方案选型，部署架构想起来比较容易，但是落实起来有很多的考虑细节，起初考虑GP的Master和Standby节点如果混用还是能够节省一些资源，所以设计的数据仓库和数据集市的部署架构是这样考虑的，但是从走入部署阶段之后，很快就发现这种交叉部署的模式是不可行的，或者说有一些复杂度。

除此之外，在单个GP集群的部署架构层面，还有4类方案考虑。

 方案1：Master,Standby和segment混合部署

 方案2：Master,Standby和segment独立部署，整个集群的节点数会少一些

 方案3：Segment独立部署，Master,Standby虚拟机部署

 方案4：最小化单节点集群部署（这是数据集市最保底的方案） 

这方面存在较大的发挥空间，而且总体来说这种验证磨合的成本也相对比较高，实践给我上了一课，越是想走捷径，越是会让你走一些弯路，而且有些时候的优化其实我也不知道改怎么往下走，感觉已经无路可走，所以上面这4种方案其实我们都做了相关的测试和验证。

在整体规划之上，我设计了如下的部署架构图，每个服务器节点有6个Primary,6个Mirror,服务器两两映射。

按照官方文档的建议和具体的配置情况，我们对内核参数做了如下的配置：

vm.dirty_expire_centisecs= 500

vm.dirty_writeback_centisecs= 100

vm.dirty_background_ratio= 0# See System Memory

vm.dirty_background_bytes= 1610612736

kernel.sem= 500 2048000 200 4096

1）首先是配置/etc/hosts，需要把所有节点的IP和主机名都整理出来。 

# yum install-y apr apr-util bzip2 krb5-devel  zip

# rpm-ivh open-source-greenplum-db-6.16.2-rhel7-x86_64.rpm

5）配置两个host文件，也是为了后面进行统一部署方便，在此建议先开启gpadmin的sudo权限，可以通过gpssh处理一些较为复杂的批量操作

6）通过gpssh-exkeys来打通ssh信任关系，这里需要吐槽这个ssh互信，端口还得是22，否则处理起来很麻烦,需要修改/etc/ssh/sshd_config文件

7）较为复杂的一步是打包master的Greenplum-db-6.16.2软件，然后分发到各个segment机器中，整个过程涉及文件打包，批量传输和配置，可以借助gpscp和gpssh，比如gpscp传输文件，如下的命令会传输到/tmp目录下

gpscp-f/usr/local/greenplum-db/conf/hostlist/tmp/greenplum-db-6.16.2.tar.gz=:/tmp

或者说在每台服务器上面直接rpm-ivh安装也可以。

8）Master节点需要单独配置相关的目录，而Segment节点的目录可以提前规划好，比如我们把Primary和Mirror放在不同的分区。 

mkdir-p/data1/gpdata/gpdatap1

mkdir-p/data1/gpdata/gpdatap2

mkdir-p/data2/gpdata/gpdatam1

mkdir-p/data2/gpdata/gpdatam2

9）整个过程里最关键的就是gpinitsystem_config配置了，因为Segment节点的ID配置和命名，端口区间都是根据一定的规则来动态生成的，所以对于目录的配置需要额外注意。

gpinitsystem-c gpinitsystem_config-s 【standby_hostname】

其中文件gpinitsystem_config的主要内容如下：

declare-a DATA_DIRECTORY=(/data1/gpdata/gpdatap1  /data1/gpdata/gpdatap2/data1/gpdata/gpdatap3/data1/gpdata/gpdatap4/data1/gpdata/gpdatap5/data1/gpdata/gpdatap6)

declare-a MIRROR_DATA_DIRECTORY=(/data2/gpdata/gpdatam1  /data2/gpdata/gpdatam2/data2/gpdata/gpdatam3/data2/gpdata/gpdatam4/data2/gpdata/gpdatam5/data2/gpdata/gpdatam6)

MACHINE_LIST_FILE=/usr/local/greenplum-db/conf/seg_hosts

整个过程大约5分钟~10分钟以内会完成，在部署过程中建议要查看后端的日志查看是否有异常，异常情况下的体验不是很好，可能会白等。

集群部署中还是有很多细节的问题，太基础的就不提了，基本上就是配置，目录权限等问题，我提另外几个：

1）资源配置问题，如果/etc/security/limits.conf的资源配置不足会在安装时有如下的警告：

2）网络问题，集群部署完成后可以正常操作，但是在查询数据的时候会抛出错误，比如SQL是这样的，看起来很简单：select count(*) from customer,但是会抛出如下的错误：

这个问题的主要原因还是和防火墙配置相关，其实不光需要配置INPUT的权限，还需要配置OUTPUT的权限。 

对于数据节点可以开放略大的权限，如：

-A INPUT-p all-s xxxxx   -j ACCEPT

-A OUTPUT-p all-s xxxxx  -j ACCEPT

3）网络配置问题，这个问题比较诡异的是，报错和上面是一样的，但是在排除了防火墙配置后，select count(*) from customer；这样的语句是可以执行的，但是执行的等待时间较长，比如表lineitem这表比较大，过亿的数据量，,在10个物理节点时，查询响应时间是10秒，但是4个物理节点，查询响应时间是在90秒，总体删感觉说不过去。

为了排查网络问题，使用gpcheckperf等工具也做过测试，4节点和10节点的基础配置也是相同的。

gpcheckperf-f/usr/local/greenplum-db/conf/seg_hosts-r N-d/tmp

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4

::1      localhost localhost.localdomain localhost6 localhost6.localdomain6

#127.0.0.1    test-dbs-gp-128-230

xxxxx.128.238 test-dbs-gp-svr-128-238

xxxxx.128.239 test-dbs-gp-svr-128-239

其中127.0.0.1的这个配置在segment和Master,Standby混部的情况是存在问题的，修正后就没问题了，这个关键的问题也是郭运凯同学发现的。

集群的故障测试是本次架构设计中的重点内容，所以这一块也是跃跃欲试。

整体上我们包含两个场景，服务器宕机修复后的集群恢复和服务器不可用时的恢复方式。

第一种场景相对比较简单，就是让Segment节点重新加入集群，并且在集群层面将Primary和Mirror的角色互换，而第二种场景相对时间较长一些，主要原因是需要重构数据节点，这个代价基本就就是PG层面的数据恢复了，为了整个测试和恢复能够完整模拟，我们采用了类似的恢复方式，比如宕机修复使用了服务器重启来替代，而服务器不可用则使用了清理数据目录，类似于一台新配置机器的模式。

select* from gp_segment_configuration where status!='u';

select* from gp_segment_configuration where status='u'

重构数据节点的过程中，总体来看网络带宽还是使用很充分的。

select* from gp_segment_configuration where status='u'

select* from gp_segment_configuration where status='u' and role!=preferred_role;

select* from gp_segment_configuration where status='u' and role!=preferred_role;

经过测试，重启节点到数据修复，近50G数据耗时3分钟左右

对于优化问题，是本次测试中尤其关注，而且争议较多的部分。 

首先在做完初步选型后，数仓体系的部署相对是比较顺利的，采用的是第一套方案。

数据集市的集群部分因为节点相对较少，所以就选用了第二套方案

实际测试的过程，因为配置问题导致TPCH的结果没有达到预期。

所以这个阶段也产生了一些疑问和怀疑，一种就是折回第一种方案，但是节点数会少很多，要不就是第三种采用虚拟机的模式部署，最保底的方案则是单节点部署，当然这是最牵强的方案。

这个阶段确实很难，而在上面提到的修复了配置之后，集群好像突然开悟了一般，性能表现不错，很快就完成了100G和1T数据量的TPCH测试。

在后续的改造中，我们也尝试了第三套方案，基于虚拟机的模式，通过测试发现，远没有我们预期的那么理想，在同样的数据节点下，Master和Standby采用物理机和虚拟机，性能差异非常大，这个是出乎我们预料的。比如同样的SQL,方案3执行需要2秒，而方案2则需要80秒，这个差异我们对比了很多指标，最后我个人理解差异还是在网卡部分。

所以经过对比后，还是选择了方案2的混合部署模式。

此外整个过程的TPCH也为集群的性能表现提供了参考。比如方案2的混合部署模式下，有一条SQL需要18秒，但是相比同类型的集群，可能就只需要2秒钟左右，这块显然是存在问题的。 

在排除了系统配置，硬件配置的差异之后，经典的解决办法还是查看执行计划。

# explain analyze select count(*)from customer;

Aggregate  (cost=0.00..431.00 rows=1 width=8)(actual time=24792.916..24792.916 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=0.00..431.00 rows=1 width=1)(actual time=3.255..16489.394 rows=150000000 loops=1)

         ->  Seq Scan on customer  (cost=0.00..431.00 rows=1 width=1)(actual time=0.780..1267.878 rows=4172607 loops=1)

   (slice0)    Executor memory: 680K bytes.

   (slice1)    Executor memory: 218K bytes avg x 36 workers, 218K bytes max(seg0).

Memory used:  2457600kB

Optimizer: Pivotal Optimizer(GPORCA)

# explain analyze select count(*)from customer;                            

Aggregate  (cost=0.00..842.08 rows=1 width=8)(actual time=1519.311..1519.311 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=0.00..842.08 rows=1 width=8)(actual time=634.787..1519.214 rows=36 loops=1)

         ->  Aggregate  (cost=0.00..842.08 rows=1 width=8)(actual time=1473.296..1473.296 rows=1 loops=1)

               ->  Seq Scan on customer  (cost=0.00..834.33 rows=4166667 width=1)(actual time=0.758..438.319 rows=4172607 loops=1)

   (slice0)    Executor memory: 176K bytes.

   (slice1)    Executor memory: 234K bytes avg x 36 workers, 234K bytes max(seg0).

Memory used:  2457600kB

Optimizer: Pivotal Optimizer(GPORCA)

很明显执行计划是被误导了，而误导的因素则是基于统计信息，这个问题的修复很简单：

但是深究原因，则是在压测时，先是使用了100G压测，压测完之后保留了原来的表结构，直接导入了1T的数据量，导致执行计划这块没有更新。

此外也做了一些集群配置层面的优化，比如对缓存做了调整。 

gpconfig-c statement_mem-m 2457600-v 2457600

gpconfig-c gp_vmem_protect_limit-m 32000-v 32000

1）10个物理节点，（6+6）*10+2

tpch_1t=# select count(*)from customer;

   count   

tpch_1t=# select count(*)from lineitem;

   count    

# select count(*)from customer;

   count  

# select count(*)from lineitem;

   count   

# select count(*)from customer;

   count  

# select count(*)from lineitem;

   count   

4）TPCH在不通架构模式下的性能比对，有19个查询模型，有个别SQL逻辑过于复杂暂时忽略，也是郭运凯同学整理的列表。

wwW.Xtw.Com.cN系统网专业的PC、手机系统开发下载平台，HarmonyOS系统、安卓、OS、windows电脑重装系统在线下载安装,操作系统平台技术学习,攻略教程,技术交流。