网络安全心得体会100字（实用6篇）

  当我们阅读文章产生了理解或者感触时，我们可以用笔纸进行简单的记录。多写心得体会能够成为一个更有思想的人，可以借鉴的心得体会有哪些呢？下面是我为大家整理的“网络安全心得体会100字（实用6篇）”，欢迎大家阅读，希望对大家有所帮助。

网络安全心得体会100字（实用6篇）篇一

  一个综合设备维护员，讲究的就是快速反应，坚强支撑。对于网络安全维护首先就是要增强网络安全意识。严格要求自己，不断的提升个人的安全意识和维护素质。

  按照部门一贯倡导的“维护就是经营”的大经营观念，整个维护工作紧紧围绕以效益中心，加强对客户、对市场的支撑力度，全力作好后台支撑工作。

  逐步建立了金银牌大客户电路资料台帐，并结合金牌大客户使用数据电路的实际情况分别为其制作了客户电路应急预案。为了实现大客户等级化我中心安排对大客户电路用不同颜色的插塞来进行识别；为了体现对大客户单位的差异化服务，我班组定期对金牌大客户进行巡检，并按月制作大客户单位的网络运行报告。

  在日常的维护方面不要搞个人主义，团队力量是无限大的。讲究合作，高效。要加强网络设备安全的综合检视，对于故障处理要规范化，准确化。这就要求个人有很强的`业务能力和维护素质。因此个人要加强学习不断提高自己的业务水平和维护能力。

网络安全心得体会100字（实用6篇）篇二

  如今是“网罗”天下的时代。网络，你是普罗米修斯，偷走了宙斯的火焰，点燃了闪电，照亮了人类黎明前的黑暗，让拂晓的风声在耳畔回荡，世界因你而精彩。

  网络，你这个盗火者，你偷来了光明，却也带来了黑暗。还我隐私。这是一个张扬个性的时代，却也是个缺乏隐私的时代。人们被大数据一点点地剖析，肢解，百无一漏地暴露在公众视野之中。网络，你偷走了人类的遮羞布，让人成为赤裸裸的“透明人”!前不久爆出的“棱镜事件”，折射出信息安全的隐忧。高科技窃取我们的信息于无形之中，令人不战而栗。

  不久前，一位名叫琪琪的女孩，因一条微博，被人在网上挖掘个人信息并无情地嘲讽而不堪重负，最后含恨自杀。每一个人的心中都有秘密，正如每一个花蕾都包含着心事，强行剥开花瓣必定会使花蕾凋亡，无情揭开个人隐私必将导致人间惨剧发生。还我距离。生活在网络时代，纵使相隔千里，也可以面对面交谈，于是人与人之间的距离近了，而心的距离却远了。我曾无数次地回想起那个“烽火连三月，家书抵万金”的时代，虽然战乱不断，天各一方，却能“千里共婵娟”，共话相思意。然而，在这个霓虹灯点缀了夜空，万家灯火齐明的大数据时代，手机却反客为主，俨然成了聚会的主角。当“一起来玩手机，顺便吃个饭”成为年轻人的口头禅时，我们不禁感叹人情变了：没有了朱自清的“咫尺天涯，叫我如何奈得”的感慨，却有加拿大女作家的“世界上最远的距离，不是你在天涯，我在海角，而是我在你面前，你却不知道我想你”的无奈。网络，你偷走了距离，让心的故乡何处寻觅还我诗情画意的生活。怎能不向往、向往川端康成凌晨四点半看海棠花未眠，向往瓦尔登湖畔卢梭的小木屋，向往王尔德在阴沟里仰望星空，向往仓央嘉措通透风情踏雪寻梅。反观当下，没了诗情没了画意，处处是屏奴。当点赞、刷微博成了生活的主旋律，我们真正的生活又去了哪儿

  网络，当我再一次把你放在聚光灯下，细细端详，终于窥见了你的真容。你原本只是高科技时代的一个工具，无关好与坏，功与过。合理利用，你可以使人们玩弄世界于股掌，传递信息，播散知识，造福人类。掌控不当，你也可以剥夺隐私，传播谣言，色情暴力、高科技犯罪把人们推向万劫不复的深渊。

  利弊，黑白，两极之间本无界定，然而物极必反，就看你如何掌控。网络，可以送你上天堂，也可以带你下地狱。如何让高科技为人类谋福祉，全在人类的智慧。

网络安全心得体会100字（实用6篇）篇三

  近日，你是否收到一条“莲塘南门路口抢小孩 母亲被捅一刀”的微信信息？你是否浮想联翩？

  可以想象，当时的画面，多么血腥！多么恐怖！犯罪分子佯装打扮潜伏在莲塘的南门路口，静悄悄的等待小孩上钩。忽然，目标出现。一位年轻的母亲带着一位幼小的孩子在街上游玩，就在母亲一不留神之际，孩子被一双粗糙的大手突然拉住，那正是犯罪分子！这时，母亲发现了犯罪分子的身影，急忙冲上前去，试图用微薄的力量与歹徒作斗争！谁知，歹徒从口袋里掏出一把锋利的刀，一把向母亲刺去！鲜血积成了河流，人们的心痛着……

  可是，这只是一条虚假信息！经南安市公安局查实，南安市溪美街道并未发生过此类案件，该信息纯属谣言！

  随着科技突飞猛进的发展，人们已经处处都离不开万能又实用的互联网了。但是，网络就像一个新型___，稍微使用不当，就极有可能坠入万丈深渊，难以挽回，所以，网络安全不可忽视！

  当你在欢快地手机给朋友发信息时，你是否收到了陌生人发来的中奖信息？奖品是价值连城的高科技产品，奖金数额高达千万！你千万不要眉开眼笑，如果你不是买**也没有参加任何有奖活动，那么，这些奖品和奖金又是从何而来？很明显，是骗子利用人们微妙的心理所设计的骗局！明明是很拙劣的骗局，却为何有人上当受骗？相信天上掉馅饼的好事？到头来一无所有？要么这类人太过善良，对网络深信不疑；要么这类人太过愚笨，没有上网安全防范意识！

  朋友们，包含不良信息的网络已经严重影响了人们的生活，但我们千万不要陷入！要时刻提醒自己：网络安全不可忽视！

网络安全心得体会100字（实用6篇）篇四

  9月17日至9月23日是全国网络安全宣传周，为做好国家网络安全宣传工作，教体局三举措落实宣传工作。总结如下：

  1、加强活动组织。

  召开了局党委会，专题安排国家网络安全宣传周活动，落实分管领导和责任股室，印发活动方案，明确开展活动的要求和时限，指导学校开展具有本校特色、形式活泼、内容丰富、实效性强的网络安全教育活动。

  2、营造浓厚氛围。

  组织学校开展网络宣传周宣传活动，各校结合实际，采取案例讲解、宣传海报、校园新媒体、主题班会等多种形式，组织师生宣传网络安全知识，增强网络安全意识，川教网，提升网络安全风险防范能力。

  3、强化活动开展。

  召开全区网络安全教育专题讲座活动，组织全区学校安全副校长学习宣传网络安全教育知识。各学校通过网络安全知识讲座、主题班会教育活动、团日活动，要求师生自觉遵守信息安全管理有关法律、法规，不泄密、不制作和传播有害信息，自觉抵制网络低俗之风，切实提高师生的网络素养。

网络安全心得体会100字（实用6篇）篇五

  接触网站安全管理的工作有几个年头了，非常感谢最初让我接触到网站木马工作任务的陈总对我的信任，那时候虽然完全没有接触过，也没有想过自已是否能够处理，但最终还是凭自已的毅力，找到好多木马处理好了，同时也感谢客户西北在线对我的忍耐，这是我的动力。虽然这些年不是专业在做网络安全管理工作，但是时不时会接触到，并把它当做自已的责任，下面我来下谈谈做网络安全管理工作的体会。

  网络管理是一个系统工程，通过几次黑客入侵，攻击的案例，更加觉得日常的检查和维护，特别是安全管理要求十分必要。下面来说具体的体会：

  1、定期进行安全体检，检查日志文件是否有异常，如有陌生帐户登录，检查比对服务器文件内容，是否发现有明显木马或病毒程序的植入。

  2、做好服务器数据备份，一是服务器系统备份，这样一旦发现黑客入侵，可以快速的恢复系统，二是数据库备份，必须服务器数据信息是一个网站的核心。

  3、作为网络管理员，如果真的被黑客入侵了，查找和解决问题最便捷的办法是充分应用网络资源，可以到网上或论坛搜集一些相关的信息，也许能找到相应的解决办法，同时还可以分享自已经验技巧。还有一个解决办法就是重装系统，重新更换除数据之外的所有文件，找起来太费事，这样子做清除的很彻底。

  4、预防为主，问题发生了心理压力很大，所以要做好提前预防。具体预防的方法首先需要修改管理员帐号，不用默认的Administrator，其次修改远程桌面端口3389，再次修改入站规则。

网络安全心得体会100字（实用6篇）篇六

  随着信息技术的不断发展，校园网站成为学校的门面，多媒体教学成为活跃课堂、调动学生学习积极性的一种主要手段。因而，对于我们教师而言，计算机基本操作是我们必须掌握一门技术。20xx年11月18日，我作为过风楼镇中心小学的一名网络管理员，能有幸参加商南县中小学电教设备管理员和网络管理员培训，我感到很荣幸，故而倍加珍惜这次学习的机会。

  虽然这次培训的时间很短，但每一位老师都很有耐心，对于我们提出的各种问题，总是一遍遍地讲解，这让我很受感动。在与同行的相互学习、交流中，我收获颇丰。我不仅明白了信息技术在教育中的应用，要求教师必须提高职业的专业性。而且清楚地认识到随着以计算机为核心的信息技术在教育中的广泛应用，教师不是像以前那样，单凭一张嘴、一支粉笔、一块黑板即可进行教学，而是综合应用多种媒体技术，利用多媒体和微机网络，开展教学。所以这种教学必然要打破传统的传授式的教学模式，而构建出适应信息社会的新型教学模式来。我深深的体会到了信息技术与各学科的密切联系，信息技术今后将成为教师教学和学生学习的重要工具。在新课程改革的形势下，未来教育应溶入先进的教学理念与最新的信息技术，致力于信息技术在课堂上的有效应用，提高课堂教学效果，冲击着传统教学模式。

  通过这次为期一天的培训，我深深体会到作为一个网络管理员应该具备的专业技能与素养。

  1、信息技术对教师的重要作用。

  在高科技飞速发展的今天，教师不能只停在原有知识的认识上，要不断学习，不断完善自己，不断充实自己。

  现在的学生更是聪明，他们不仅能在学校里学习知识，还能通过电视、网络等多种途径学到更多的知识。因而，教师必须有一种超前意识。

  2、良好的信息素养是教师终生学习、不断完善自身的需要。

  当今社会，一名优秀的教师应具有现代化的教育思想、教学观念，掌握现代化的教学方法和教学手段，熟练运用信息工具（网络、电脑）对信息资源进行有效的收集、组织、运用；通过网络与学生家长或监护人进行交流，在潜移默化的教育环境中培养学生的信息意识。这些素质的养成就要求教师不断地学习，才能满足现代化教学的需要；信息素养成了终生学习的必备素质之一，如果教师没有良好的信息素养，就不能成为一名满足现代教学需要的高素质的教师。

  3、掌握计算机操作技能，也是教育系统本身的需要。

  在教育系统中，教育信息是最活跃的因素。教师可以通过网络学习新知识，可以与同行交流经验，可以与学生进行沟通，可以……因此，教育系统本身要求教师具备一定的信息素养。这次培训的时间虽然短些，但我通过学习认识到计算机的重要性，我会在今后的工作中，充分利用学到的知识进行教育教学，还要不断学习新的信息技术。通过这次的培训，使我深刻意识到：人只有不断地学习，不断地充实，不断地觉醒，才能立足于这个高速发展的社会。虽然我本人处在信息相对落后，设备相对欠缺的农村，但我并不气馁，只要我通过知识来武装自己，不断地提高自身的价值，我相信再大的困难都会迎刃而解，同时，我也相信共同的学习一定会造就共同的进步，祖国的教育事业一定会更加辉煌灿烂。

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

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

1集群架构改造的目标

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

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压测验收，如果存在明显的问题需要不断调整配置和架构，使得达到预期的性能目标。

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

2集群规划设计的选型和思考

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

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

3集群架构的详细设计和实践

1）设计详细的部署架构图

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

2）内核参数优化

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

vmswappiness=10

vmzone_reclaim_mode = 0

vmdirty_expire_centisecs = 500

vmdirty_writeback_centisecs = 100

vmdirty_background_ratio = 0 # See System Memory

vmdirty_ratio = 0

vmdirty_background_bytes = 1610612736

vmdirty_bytes = 4294967296

vmmin_free_kbytes = 3943084

vmovercommit_memory=2

kernelsem = 500 2048000 200 4096

4集群部署步骤

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

2）配置用户，很常规的步骤

groupadd  gpadmin

useradd gpadmin -g gpadmin

passwd gpadmin

3）配置sysctlconf和资源配置

4）使用rpm模式安装

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

# rpm -ivh open-source-greenplum-db-6162-rhel7-x86_64rpm

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

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

gpssh-exkeys -f hostlist

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

gpscp -f /usr/local/greenplum-db/conf/hostlist /tmp/greenplum-db-6162targz =:/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配置和命名，端口区间都是根据一定的规则来动态生成的，所以对于目录的配置需要额外注意。

10）部署GP集群最关键的命令是

gpinitsystem -c gpinitsystem_config -s standby_hostname

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

MASTER_HOSTNAME=xxxx

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

TRUSTED_SHELL=ssh

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分钟以内会完成，在部署过程中建议要查看后端的日志查看是否有异常，异常情况下的体验不是很好，可能会白等。

5集群部署问题梳理

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

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

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

$ cat /etc/hosts

127001   localhost localhostlocaldomain localhost4 localhost4localdomain4

::1      localhost localhostlocaldomain localhost6 localhost6localdomain6

#127001    test-dbs-gp-128-230

xxxxx128238 test-dbs-gp-svr-128-238

xxxxx128239 test-dbs-gp-svr-128-239

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

5集群故障恢复的测试

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

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

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

1）服务器宕机修复后集群恢复

select from gp_segment_configuration where status!='u';

gprecoverseg  -o /recov

gprecoverseg -r

select from gp_segment_configuration where status='u'

2）服务器不可用时集群恢复

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

select from gp_segment_configuration where status='u'

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

gprecoverseg -r

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

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

6集群优化问题梳理

1）部署架构优化和迭代

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

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

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

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

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

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

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

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

2）SQL性能优化的分析

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

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

性能较差的SQL执行计划：

# explain analyze select count()from customer;

QUERY PLAN   

Aggregate  (cost=00043100 rows=1 width=8) (actual time=2479291624792916 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=00043100 rows=1 width=1) (actual time=325516489394 rows=150000000 loops=1)

         ->  Seq Scan on customer  (cost=00043100 rows=1 width=1) (actual time=07801267878 rows=4172607 loops=1)

Planning time: 4466 ms

   (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)

Execution time: 24832611 ms

(9 rows)

Time: 24892500 ms

性能较好的SQL执行计划：

# explain analyze select count()from customer;                            

QUERY PLAN

Aggregate  (cost=00084208 rows=1 width=8) (actual time=15193111519311 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=00084208 rows=1 width=8) (actual time=6347871519214 rows=36 loops=1)

         ->  Aggregate  (cost=00084208 rows=1 width=8) (actual time=14732961473296 rows=1 loops=1)

               ->  Seq Scan on customer  (cost=00083433 rows=4166667 width=1) (actual time=0758438319 rows=4172607 loops=1)

Planning time: 5033 ms

   (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)

Execution time: 1543611 ms

(10 rows)

Time: 1549324 ms

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

analyze customer;

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

3）集群配置优化

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

gpconfig -c statement_mem -m 2457600 -v 2457600

gpconfig -c gp_vmem_protect_limit -m 32000 -v 32000

7集群优化数据

最后来感受下集群的性能：

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

tpch_1t=# iming on

Timing is on

tpch_1t=# select count()from customer;

   count   

-----------

150000000

(1 row)

Time: 1235801 ms

tpch_1t=# select count()from lineitem;

   count    

------------

5999989709

(1 row)

Time: 10661756 ms

2）6个物理节点，（6+6）6

# select count()from customer;

   count   

-----------

 150000000

(1 row)

Time: 1346833 ms

# select count()from lineitem;

   count    

------------

 5999989709

(1 row)

Time: 18145092 ms

3）4个物理节点，（6+6）4

# select count()from customer;

   count   

-----------

 150000000

(1 row)

Time: 1531621 ms

# select count()from lineitem;

   count    

------------

 5999989709

(1 row)

Time: 25072501 ms

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

在1T基准下的基准测试表现：

做了一年的网管了 在这一年里 感受颇深

网管这个职业，就技术方面而言，我感觉是很浅显的一些基础的技术。 并没有多少深层的技术因素。就从最初开始说起吧。刚从服务员转网管这段时间，的确，感觉那个时候很充实。因为，每天都有不懂的。。 因为在上班的时候，可以随时去查资料，只要有一明白的。 就疯狂的在百度里去发帖。或询问群里的一些深资网络管理。 大约经过了五、六个月的时间，自己上百度已越来越少了，在群里提问，也慢慢消失了。 所以有段时间，我几乎把所有的群都退掉了。百度里所有的帐号都丢弃了。 但后来，还是又加入了一十几个群，为的不是别的，只是为了得到一些最新的消息！ 就技术而言：主要的是硬件和系统。 因为在网吧里，是要修机的，各种各样的问题都有。。虽然说现在对硬件还不是完全能够了解。 但一些比较基础的问题，已没什么能够难得住了，除了硬件坏了，特别是主板。这些我没办法之外，其它的，在我看来，都只不过不是坏了，而是时间长了，机器STOP工作了而已。其实硬件最多的，也不过就是内存、显卡，只要你能判断时是那类硬件，就行了。而判断，又是需要长时间的观察和经验的。 现在在我看来，修机，只要硬件没坏，只需短时间就可以了。 修机，最麻烦的，不过就是检测、判断。 对于系统故障，就比较麻烦了。特别是服务器的。 在客户机到还好，一般的都只是一些如：READ、0F000007、扫盘之类的一些故障，只要改改注册表，注册一下DLL动态连接文件就可以了。实在不行的，就恢复系统吧。 这可是网吧里网管的必杀招。 而且也是用得最多的一招，几乎在网吧，没有一个网管，一年没恢复过一两百次系统的。 而服务器，就不行了。很多重要资料，都不能丢失的，这些就比较麻烦了。特别是文件服务器。 如果不到万不得已，一般都不会去选择格盘、重装的。 因为那样，工作的烦杂程度不言而喻。

关于网吧的技术嘛，要说的就比较多了，因为网吧里的技术不是单一的，其实说起来，都是很简单的，简单到什么程度呢，每个上网大概有一、两年左右青年，都能懂，也都会，但只是会部分，而不是网吧里技术内容的全部。 而网管做的工作呢。在我看来，就是从每个顾客身上去学习他们会的，在成千上万的人身上学到的，然后再回报给另外的成千上万的人。 其实网管说通俗点，也就是从一边集合，一边散开的位置。 当然，这只是下面客户机、顾客的要求要达到的，这个，我想，也应该是每位网管必经的路吧！ 因为网管，从开始的工作，就是替人服务，解决替人服务过程中的问题，如果连这个都做不到位，就不应该呆在网吧。可以说，这段经历，是网管的基础功课。也是必修的功课，所以网管首先，必需要会玩一些比较主流的游戏，会用一些相对主流的软件。因此，网吧的网管，和游戏基本上是离不开、分不散的。 如果这层次，没什么问题，之后，可以根据个人兴趣，以及学习方式，学一些比较深一点的。比如，了解WINDOWS XP系统的内核，它线层的优先级、进程的DLL文件，进程文件，注册表、组策略、SYSTEM文件夹之类的。其实，用XP系统，都多少会了解一点，但要想全部了解完整，只怕没一个网管能做到那么精确的了解到XP里面所包含的所有内容了。 就我个人而言，我对XP的了解，最多的还是做网管前期去了解的，因为到后面人变懒散了。 如果不是必需要解决的问题，一般都不会去找资料！ 我对于XP的理解是：几乎所有功能都在注册表里，但注册表里几乎都是英文，而我对英文，又是一文盲。 所以对于XP里的一些比较核心的东西,我几乎是接不上边的。 其次是组策略，这个里面，几乎每个不懂英文的网管、或不清楚注册表的网管都比较喜欢在这里面来配置我们的系统，因为这个里面简单、好看啊。一看就能明白，这一条是做什么的，该怎么去配置，但里面我们就能真的完全去全部了解到位吗？ 反正我只是一知半解的。只会用一些，我自己要用到的。 再次，就是服务了。不管是XP或者是SERVER2003 几乎都用到过这里面的，下面的客户机，你不调这玩意，有时候，还真不行。 这个里面，也没多少好说的，主要就那么几个，如果不安装一些特殊的软件，一般的都不会多出几个来。基本都相差不大。 做网管的，有一个系统自带的好用的工具，谁都不能否认它的功能：命令提示符。 也就是运行CMD的一个命令提示窗口。 有段时间，我还专门研究过一部分命令。 网管只怕用得最多的是PING吧。 但PING又有几个人能完全用好呢。 知道PING里面能显示出多少信息来呢？ 其实，在网吧，命令提示符，有几个命令是必需要会用的，虽然不一定要全部都会用、能用全，但基本功能都必需要会的。 如前面提到的PING，另外还有：netstat nbtstat tracert arp net 等等，一时很多都记不起来了。 但这些命令都几乎在网吧里会用得到吧！！