在部署的GreenPlum群集上进行数据查询时，如果数据量变大，查询将在执行时中断，表示某个segment中断了连接。
error 58 m 01 ' erroronreceivefromseg0slice 1192.168.110.8433606000 PID=XXX : serverclosedtheconnectionunexpectedly ' thion
要查看主pg_log日志，请执行以下操作：
seg-1 couldnotconnecttosegment 3360初始化图形故障(CDB gang.c :237 ) )。
经过简单分析，可以推测与内存相关的参数没有优化。 因为即使是同一个SQL查询，只要稍微空出一点时间间隔，马上就会有结果。 那么，从两个方面着手。
1 .由于服务器内存不足，segment中断了对话。
2 .数据库参数设置不合理，不能使用那么多内存。
对于第一个问题：
1 )首先检查了虚拟机的内存，觉得只有8G，有点少，所以追加到32G，但是还出现了以前的问题。
2 )那么，预计系统设置可能会限制内存的使用。 因此，使用如下：
prctl-n project.max-shm-memory-iprojectdefault
prctl-n project.max-SEM-ids-iprojectdefault
确认了合适的设定，但都很大，不需要修改。 因此，排除了系统瓶颈，其次是数据库的
1 )直接打开master节点上的postgresql.conf文件并查看配置，shared_buffers和所有参数均为默认值，并且已进行了优化。 重新启动数据库也存在上述问题。
2 )从max_statement_mem、statement_mem、gp_vmem_protect_limit这三个参数来看，未被设置在master中，这被认为存在问题
3 )使用gpconfig -s statement_mem报告错误，提示节点断开连接。 我觉得这个误报很痛，混淆了想法，认为数据节点错了。
4 )确定gp_vmem_protect_limit参数，发现8GB就足够了。 一旦陷入停滞，经过调查资料和白名单，发现statement_mem参数不在conf文件中，很可能是默认值，进一步。
5 )打开数据库，运行select * from gp_settings； 通过查看数据库的所有配置，可以发现问题，因为statement_mem参数缺省为128MB。
6 )由于gpconfig查询参数失败，没有尝试使用gpconfig设置参数，而是手动更改了每个节点的值。 重新启动数据库后，成功解决了问题。
稍后，我们发现可以通过pgconfig -c statement_mem -v 2GB设置参数。 -s来咨询时报告错误。 rlg，手动更改这么多文件，完全可以轻松完成
Greenplum参数配置优化：
查询参数gpconfig --show max_connections更改参数配置命令gp config-cparametername-vparametervalue示例： gp config-c LLE name work_mem work_mem (，global，物理内存的2%-4% )和segment用作sort和hash操作的内存大小
如果PostgreSQL对大表进行排序，则数据库将按此参数指定的大小对表进行平铺排序，并将中间结果存储在临时文件中。 最终会再次合并和排序这些中间结果中的临时文件，因此增加此参数会减少临时文件的数量并提高排序效率。 当然，如果太大，则会发生swap，因此设置此参数时需要小心。
显示现有配置值gp config-swork _ memvaluesonallsegmentsareconsistentguc 3360 work _ memmastervalue 336032 mbsegmentvalue 336032 MB修改配置gp cconale _mem TO '64MB '配置恢复正常： gp admin-[ info ] :-completedsuccessfullywithparametersmainteance _ withparametersmainteance
16兆字节(16MB)。因为在一个数据库会话里， 任意时刻只有一个这样的操作可以执行，并且一个数据库安装通常不会有太多这样的工作并发执行， 把这个数值设置得比work_mem更大是安全的。 更大的设置可以改进清理和恢复数据库转储的速度。 查看现有配置值gpconfig -s maintenance_work_memGUC : maintenance_work_memMaster value: 64MBSegment value: 64MB 修改配置 gpconfig -c maintenance_work_mem -v 256MB max_statement_mem设置每个查询最大使用的内存量，该参数是防止statement_mem参数设置的内存过大导致的内存溢出.
查看现有配置值gpconfig -s max_statement_memValues on all segments are consistentGUC : max_statement_memMaster value: 2000MB Segment value: 2000MB 修改配置 gpconfig -c max_statement_mem -v 2000MB statement_mem设置每个查询在segment主机中可用的内存，该参数设置的值不能超过max_statement_mem设置的值，如果配置了资源队列，则不能超过资源队列设置的值。
查看现有配置值gpconfig -s statement_memValues on all segments are consistentGUC : statement_memMaster value: 125MB Segment value: 125MB 修改配置 gpconfig -c statement_mem -v 256MB gp_vmem_protect_limit控制了每个segment数据库为所有运行的查询分配的内存总量。如果查询需要的内存超过此值，则会失败。
查看现有配置值gpconfig -s gp_vmem_protect_limitValues on all segments are consistentGUC : gp_vmem_protect_limitMaster value: 8192 Segment value: 8192 gp_workfile_limit_files_per_querySQL查询分配的内存不足，Greenplum数据库会创建溢出文件（也叫工作文件）。在默认情况下，一个SQL查询最多可以创建 100000 个溢出文件，这足以满足大多数查询。
该参数决定了一个查询最多可以创建多少个溢出文件。0 意味着没有限制。限制溢出文件数据可以防止失控查询破坏整个系统。
服务器配置参数 gp_statement_mem 控制段数据库上单个查询可以使用的内存总量。如果语句需要更多内存，则会溢出数据到磁盘。
effective_cache_size（master节点，可以设为物理内存的85%）
这个参数告诉PostgreSQL的优化器有多少内存可以被用来缓存数据，以及帮助决定是否应该使用索引。这个数值越大，优化器使用索引的可能性也越大。因此这个数值应该设置成shared_buffers加上可用操作系统缓存两者的总量。通常这个数值会超过系统内存总量的50%以上。
master和每个segment的可以使用的cpu个数,每个segment的分配线程数;
查看现有配置值gpconfig -s gp_resqueue_priority_cpucores_per_segmentValues on all segments are consistentGUC : gp_resqueue_priority_cpucores_per_segmentMaster value: 4 Segment value: 4 gpconfig -s checkpoint_segments 修改配置 gpconfig -c gp_resqueue_priority_cpucores_per_segment -v 8 max_connections最大连接数，Segment建议设置成Master的5-10倍。
max_connections = 200 #(master、standby)
max_connections = 1200 #(segment)
这个参数只有在启动数据库时，才能被设置。它决定能够同时处于prepared状态的事务的最大数目（参考PREPARE TRANSACTION命令）。如果它的值被设为0。则将数据库将关闭prepared事务的特性。它的值通常应该和max_connections的值一样大。每个事务消耗600字节(b)共享内存。
查看现有配置值：gpconfig -s max_prepared_transactionsValues on all segments are consistentGUC : max_prepared_transactionsMaster value: 250 Segment value: 250 修改配置 gpconfig -c max_prepared_transactions -v 300 max_files_per_process设置每个服务器进程允许同时打开的最大文件数目。缺省是1000。 如果内核强制一个合理的每进程限制，那么你不用操心这个设置。 但是在一些平台上(特别是大多数BSD系统)， 内核允许独立进程打开比个系统真正可以支持的数目大得多得文件数。 如果你发现有"Too many open files"这样的失败现像，那么就尝试缩小这个设置。 这个值只能在服务器启动的时候设置。
查看现有配置值：gpconfig -s max_files_per_processValues on all segments are consistentGUC : max_files_per_processMaster value: 1000 Segment value: 1000 修改配置 gpconfig -c max_files_per_process -v 1000 shared_buffers只能配置segment节点，用作磁盘读写的内存缓冲区,开始可以设置一个较小的值，比如总内存的15%，然后逐渐增加，过程中监控性能提升和swap的情况。
gpconfig -s shared_buffersValues on all segments are consistentGUC : shared_buffersMaster value: 64MB Segment value: 125MB 修改配置 gpconfig -c shared_buffers -v 1024MB gpconfig -r shared_buffers -v 1024MB temp_buffers: 即临时缓冲区，拥有数据库访问临时数据，GP中默认值为1M，在访问比较到大的临时表时，对性能提升有很大帮助。 查看现有配置值：gpconfig -s temp_buffersValues on all segments are consistentGUC : temp_buffersMaster value: 1024 Segment value: 1024 修改配置 gpconfig -c temp_buffers -v 4096 gp_fts_probe_threadcount:设置ftsprobe线程数，此参数建议大于等于每台服务器segments的数目。
查看现有配置值：gpconfig -s gp_fts_probe_threadcountValues on all segments are consistentGUC : gp_fts_probe_threadcountMaster value: 16 Segment value: 16 重启数据库，使参数生效 gpstop -u 重新加载配置文件 postgresql.conf 和 pg_hba.conf转载于:https://www.cnblogs.com/kuang17/p/9968415.html