说起优化，其实最好的优化就是提升硬件的配置，例如提高cpu的运算能力，提高内存的容量，个人认为如果你考虑升级硬件的话，建议优先提高内存的容量，因为一般服务器应用，对内存的消耗使用要求是最高的。当然这都是题外话了。
这里我们首要讨论的，是在同等硬件配置下（同一台服务器，不提升硬件的情况下）对你的系统进行优化。
作为系统管理员，我认为，首先我们要明确一个观点：在服务器上作任何 *** 作，升级和修改任何配置文件或软件，都必须首要考虑安全性，不是越新的东西就越好，这也是为什么linux管理感觉上和windows有所不同的地方，windows首先推荐大家去使用它的最新版本软件和 *** 作系统，其实我个人认为这是一种商业行为，作为从系统管理上来讲，这是很不好的，使用新的软件和系统可能带来新的问题，有些甚至是致命的。
因此，作为管理，我们还是应该考虑稳定的长期使用的软件版本来作为我们的版本，具体的好处我就不多说了。相信作为管理员的你应该知道的。
其实个人使用的linux最直接的一个优化就是升级内核，自己编译的内核是根据自己的系统编译而来，将得到最大的性能和最小的内核。
但是，服务器就不太一样了，当然我们也希望每一台服务器都是自己手工编译的内核，高效而精巧。但是实际和愿望是有差距的，试想一下，如果你管理100来台linux主机，而每一台也许配置都不一样，那编译内核的一个过程将是一个浩大工程，而且从实际考虑，工作量大得难以想象。我想你也不会愿意做这种事情吧。因此，个人建议，采用官方发布的内核升级包是很好的选择。
首先，我们对新安装的系统，将做一系列升级，包括软件和内核，这是很重要的步骤，（这方面的详细情况欢迎察看我另一篇关于升级方面的文章）。
在升级好所有软件后，基本的防火墙和配置都做好以后，我们开始优化一些细节配置，如果你是老系统，那么在作本问题及的一些 *** 作和优化你系统之前，务必被备份所有数据到其他介质。
1、虚拟内存优化
首先查看虚拟内存的使用情况，使用命令
# free
查看当前系统的内存使用情况。
一般来说，linux的物理内存几乎是完全used。这个和windows非常大的区别，它的内存管理机制将系统内存充分利用，并非windows无论多大的内存都要去使用一些虚拟内存一样。这点需要注意。
Linux下面虚拟内存的默认配置通过命令
# cat /proc/sys/vm/freepages
可以查看，显示的三个数字是当前系统的：最小内存空白页、最低内存空白页和最高内存空白。
注意，这里系统使用虚拟内存的原则是：如果空白页数目低于最高空白页设置，则使用磁盘交换空间。当达到最低空白页设置时，使用内存交换（注：这个是我查看一些资料得来的，具体应用时还需要自己观察一下，不过这个不影响我们配置新的虚拟内存参数）。
内存一般以每页4k字节分配。最小内存空白页设置是系统中内存数量的2倍；最低内存空白页设置是内存数量的4倍；最高内存空白页设置是系统内存的6倍。这些值在系统启动时决定。
一般来讲在配置系统分配的虚拟内存配置上，我个人认为增大最高内存空白页是一种比较好的配置方式，以1G的内存配置为例：
可将原来的配置比例修改为：
2048 4096 6444
通过命令
# echo "2048 4096 6444" > /proc/sys/vm/freepages
因为增加了最高空白页配置，那么可以使内存更有效的利用。
2、硬盘优化
如果你是scsi硬盘或者是ide阵列，可以跳过这一节，这节介绍的参数调整只针对使用ide硬盘的服务器。
我们通过hdparm程序来设置IDE硬盘，
使用DMA和32位传输可以大幅提升系统性能。使用命令如下：
# /sbin/hdparm -c 1 /dev/hda
此命令将第一个IDE硬盘的PCI总线指定为32位，使用 -c 0参数来禁用32位传输。
在硬盘上使用DMA，使用命令：
# /sbin/hdparm -d 1 /dev/hda
关闭DMA可以使用 -d 0的参数。
更改完成后，可以使用hdparm来检查修改后的结果，使用命令：
# /sbin/hdparm -t /dev/had
为了确保设置的结果不变，使用命令：# /sbin/hdparm -k 1 /dev/hda
Hdparm命令的一些常用的其他参数功能
-g 显示硬盘的磁轨，磁头，磁区等参数。
-i 显示硬盘的硬件规格信息，这些信息是在开机时由硬盘本身所提供。
-I 直接读取硬盘所提供的硬件规格信息。
-p 设定硬盘的PIO模式。
-Tt 评估硬盘的读取效率和硬盘快取的读取效率。
-u <0或1> 在硬盘存取时，允许其他中断要求同时执行。
-v 显示硬盘的相关设定。
3、其他优化
关闭不需要的服务，关于系统自动启动的服务，网上有很多资料，在此我就不赘述了；
关于安全
1、安全检查
作为一个系统管理员来说，定期对系统作一次全面的安全检查很重要的，最近遇到一些朋友来信说出现了一些莫名其妙的问题，例如最大的一个问题就是明显感觉网络服务缓慢，这极有可能是被攻击的现象。
实践证明，无论是那种系统，默认安装都是不安全的，实际不管你用windows也好，linux,bsd或其他什么系统，默认安装的都有很多漏洞，那怎么才能成为安全的系统呢，这正是我们系统管理人员需要做的事情。配置配置再配置。
任何系统，只要细心的配置，堵住已知的漏洞，可以说这个系统是安全的，其实并非很多朋友说的那样，安装了系统，配置了防火墙，安装了杀毒软件，那么就安全了，其实如果对系统不作任何安全设置，那就等于向黑客敞开一扇纸做的大门，数十分钟就能完全控制!
这并非骇人听闻。
作为linux系统，同样存在很多漏洞，黑可能利用这些漏洞控制你的整个系统，要防止这些问题，我们需要做以下步骤：
1、 升级系统中所有软件包的最新版本；
2、 设置较为强壮的防火墙；
3、 定期检查关键记录文件，配置杀毒软件
4、 多关心一下发布安全信息警告的网站，掌握一些最新的病毒和黑客程序的特点，这些都利于系统的正常运作。
这篇文章主要以优化为主，为了配合这一主题，安全部分我们只讨论一下日常的一些维护工作。
除了上面列出的4条是管理员必修之课外，对一些linux系统细节的维护也很重要。
包括：
1、 配置日志轮训工具，定期下载备份日志，是个非常好的习惯，这样不但能减少日志的消耗的磁盘空间，提高系统效率，更能及时发现问题，linux下有些很好的系统日志分析器，能直接提取日志中的特殊项目，省去了阅读日志的烦恼；
2、 使用命令lsof –i ,netstat –a ,ps –e等命令，定期检查系统服务端口监听等情况，也可制作一个定期执行的脚本，将这些命令定期执行后发到邮箱中；
3、 定期检查root用户的history列表，last列表，vipw用户列表是否正常；
4、 定期备份文件，用tar命令就能很好的备份了，当然需要下载这些备份并转移介质；
如一点发现有任何特别的没见过的情况或端口，那么要引起足够的重视，切勿因小失大。
以上是我对linux系统安全和优化的一些浅显认识，希望大家都能安全高效的使用linux为你的工作生活带来方便。
刚以外包的身份服务于xx的中国移动，一直标榜自己之前程序员的身份，后来便被叫去机房给服务器安装centos的系统，链接公网，并且对外提供ssh 的登陆服务。
当时我疑惑的几个没有办法接触到的知识点是：
大概是如此的，但是也不一定都如此，不过可见一斑。
而网卡的配置文件在 /etc/sysconfig/network-scripts/ 下，配置文件的名字和网卡的名字（ ip addr 或者 ifconfig ）类似，在里面编辑即可配置。而 机房的服务器的有线网卡是有多个的，配置文件也会略有不同（对于服务器的配置文件实例，在最后会有说明），不同网卡要对应不同配置文件 。
对于我自己计算机安装的linux，我联网是通过wifi的方式，而相关的配置，文章最后也会有说明。
要说还有疑问，就是这台计算及如何能够被公网的其他计算机访问到？当时提供了公网ip、掩码、DNS。之前仅仅知道家里面的设备的链接，家里设备的链接，是无法被公网访问的。这种直接提供公网ip的，我很疑惑。后来也发现，配置网卡静态ip的链接信息后，即可上网，而且，即可被其他公网ip访问。
由此我得到，ip地址和设备是分离的，不论哪台电脑，只要在哪个ip地址的“端口”，那么，就可以接受那个ip端口信息传输。
上述的是这次实践中的问题，关于ssh的搭建，实际上问题不大。其他了解就是关于机房托管方面的和机房环境方面的。其他方面，我用一句话形容：
不说了，这就是实际情况，下面是一些配置记录
wifi链接
注：上述的方法，感觉并不一定可以成功，具体情况还要研究（但是成功过）
静态ip
第二次工信局服务（20210119-20210122）
该次服务的目标： 1、给09年的IMB老机（3850 M2）装 *** 作系统（UOS）；2、安装开发环境asp/aspnet。实际上第一步只是为了第二部。
背景： 机关单位要求使用linux的发行版统信UOS的 *** 作系统，想在IBM上跑asp/aspnet，一台IBM服务器，一台已经安装上UOS的Dell计算机。
过程：
1、尝试安装了centos7的桌面版，完成之后，该老机启动不了；
2、在Dell上安装了 mono + jexus 跑aspnet，发现asp和aspnet的差别较大，不能兼容，便又使用 apache + iasp 来跑aps，但是不兼容aspnet，且不容易维护，网上文章很少；
3、探索了IBM的ServerGuide的对应版本，写入u盘来安装IBM，不可；
4、IBM上安装了Centos7的命令行版本，联网、安装docker，探索 docker 虚拟环境安装IIS、asp、aspnet环境，IBM内核比较老不支持；
5、在Dell上的linux发行版UOS上安装了VMplayer16，用它来安装Window Server 2008 R 系统，用桥接方式接入局域网，可启用IIS服务器，可使用，算一个解决方案；
6、IBM服务器后来换了一个写入镜像的工具Rufus-212，后来那边的麦哥也安装成功。
收获：
思科DHCP服务器配置实例解析
首先我们应该汇总下我们所需要达到的目标：为服务器提供固定的地址，即做MAC与IP地址的绑定为客户机提供并非固定的地址，通常这会涉及到子网因为我们的实验环境限制，我们先设定第二条，检查下客户机能否得到IP地址，再设置第一条，看看是否按照我们的设定的得到IP地址。那么DHCP服务器配置文件如下：
ddns-update-style interim;
ignore client-updates;
subnet 19216810 netmask 2552552550 {
# --- default gateway
option routers 1921681254;
option subnet-mask 2552552550;
option nis-domain " skycom";
option domain-name " skycom";
option domain-name-servers 19216812;
option time-offset -18000; # Eastern Standard Time
# option ntp-servers 19216811;
# option netbios-name-servers 19216811;
# --- Selects point-to-point node (default is hybrid) Don't change this unless
# -- you understand Netbios very well
# option netbios-node-type 2;
range 1921681100 1921681250;
default-lease-time 21600;
max-lease-time 43200;
}
保存并退出，然后重启dhcpd服务
[root@a ~]# service dhcpd restart
Shutting down dhcpd: [OK]
Starting dhcpd: [OK]
之后我们开启客户端，将客户机网卡设置为DHCP模式，然后我们可以看到客户机的IP地址为1921681250，因为dhcp的IP地址倒着分发。
将客户机进行ip与MAC的绑定，首先要获知客户机的MAC地址，Windows系统进入CMD，使用getmac命令，linux使用ifconfig可看到。之后我们修改配置文件，完整配置文件如下:
ddns-update-style interim;
ignore client-updates;
subnet 19216810 netmask 2552552550 {
# --- default gateway
option routers 1921681254;
option subnet-mask 2552552550;
option nis-domain " skycom";
option domain-name " skycom";
option domain-name-servers 19216812;
option time-offset -18000; # Eastern Standard Time
# option ntp-servers 19216811;
# option netbios-name-servers 1921681
telnet和ssh登陆提示
1;
# --- Selects point-to-point node (default is hybrid) Don't change this unless
# -- you understand Netbios very well
# option netbios-node-type 2;
range 1921681100 1921681250;
default-lease-time 21600;
max-lease-time 43200;
host server2{
hardware ethernet 00:0c:29:47:04:17;
fixed-address 19216812;
}
}
之后我们重启DHCP服务
[root@a ~]# service dhcpd restart
Shutting down dhcpd: [OK]
Starting dhcpd: [OK]
重启启用客户机的网卡，service network restart ，之后查看IP信息，这时我们可以看到地址已经变为19216812
DHCP服务器配置故障排除
1 如果遇见service dhcpd restart/start 无法启动的时候，可以试下：[root@a ~]# /usr/sbin/dhcpd start
如果你的配置文件有错误的话，会出现提示，主要关注的部分为line 之后的
2 修改/etc/sysconfig/dhcpd文件，改变dhcp服务所监听的网口(在多网卡下)，在DHCPDARGS=后面添加eth0
3 另外可以关注下/var/lib/dhcpd/dhcpdleases文件，这里面主要保存的是地址的分发
DHCP服务器配置之防火墙的配置
DHCP服务器主要工作在端口67上监听，然后在端口68上回应客户，所以我们需要配置防火墙，在服务器上面运行：Syetem-config-securitylevel，在other ports里面添加TCP 67 68端口即可，然后启动防火墙，运行service iptables start，然后测试，删除dhcpdconf配置文件中绑定的部分，之后重启客户机的网卡，检测下能够正确获得到IP地址。
DHCP服务器配置总结
DHCP服务器配置实验至此就结束了，另外分享个技巧，在测试的时候，将2台VM虚拟的linux网卡模式调成Vmnet2模式，那样不会受到干扰。
;
最近对离线数仓体系进行了扩容和架构改造，也算是一波三折，出了很多小插曲，有一些改进点对我们来说也是真空地带，通过对比和模拟压测总算是得到了预期的结果，这方面尤其值得一提的是郭运凯同学的敬业，很多前置的工作，优化和应用压测的工作都是他完成的。
整体来说，整个事情的背景是因为服务器硬件过保，刚好借着过保服务器替换的机会来做集群架构的优化和改造。
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基准下的基准测试表现：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）