lol使用tgp登入却弹出登入界面，出现客户端无法与登入队列进行通讯，登入不了游戏如何解决_百度知道
lol使用tgp登入却弹出登入界面，出现客户端无法与登入队列进行通讯，登入不了游戏如何解决
答题抽奖
首次认真答题后
即可获得3次抽奖机会，100%中奖。
栉风沐雨017
来自娱乐休闲类芝麻团
栉风沐雨017
采纳数：10104
获赞数：5705
参与团队：
游戏文件丢失或损坏造成的无法启动游戏，可重新下载并安装游戏来解决；游戏需要登陆网络方可启动即的网络游戏，登陆游戏时没有开通网络、刚好网络信号断点、网络出现错误等情况会导致网络游戏无法启动，待网络恢复后可正常启动游戏；系统与游戏有冲突无法开启游戏的，重新安装系统可解决；因电脑硬件损耗过大性能降低所引发的带不起游戏，可清理电脑机箱内的灰尘能少量提高硬件性能，也可以有针对性的升级电脑硬件；由于驱动不全、驱动程序太旧引起的游戏不能正常启动，更新驱动程序到最新版后可以解决，要定期针对显卡驱动升级。
怎么确认系统是否与游戏有冲突？
game201688
game201688
采纳数：50
获赞数：270
先TGP修复下，还不行的话换一下加速节点
试过了，也不行啊
为你推荐：
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。26 资源队列工作负载管理
使用Greenplum的工作负载管理的优先次序，并根据业务需求分配资源来查询，并防止查询时资源不可用开始。
本节将介绍Greenplum数据引擎的工作负载管理，并说明如何使用资源队列管理资源。使用资源的队列中，可用的存储器和CPU资源可以被分配给不同类型的的Greenplum的系统上执行查询。可以限制并发查询的数量，所使用的内存来执行查询的数量，并专门用于处理查询的CPU的相对量。
主资源管理问题是可以同时执行的查询的数量和存储器分配给每个查询量。在不限制的并发性和存储器的使用情况，它是不可能保证可接受的性能。存储器是最有可能限制该系统的处理能力的资源。因此，我们首先Greenplum数据引擎的内存使用情况的概述。
的内存使用情况的概述
存储器为Greenplum的系统，并有效地使用时，能够确保高的性能和吞吐量的关键资源。本主题介绍段主内存是如何细分，并提供给管理员配置内存的选项之间进行分配。
一个Greenplum数据段的主机运行多个PostgreSQL的情况下，所有的共享主机的内存。段具有相同的结构和它们消耗的内存，CPU和磁盘IO同时相似量的，在并行查询工作时。
为了获得最佳的查询吞吐量，内存配置必须慎重处理。有在Greenplum数据每一个级别的内存配置选择，从操作系统参数，管理工作负载资源队列，要设置分配给单个查询的内存量。
On a Greenplum segment host, the available hostmemory is shared among all the processes executing on the computer, includingthe operating system, Greenplum segment instances, and other applicationprocesses. Administrators must
determine what Greenplum and non-Greenplumprocesses share the hosts' memory and configure the system to use the memoryefficiently. It is equally important to monitor memory usage regularly todetect any changes in the way host memory is consumed by Greenplum
or otherprocesses.
The following figure illustrates how memory isconsumed on a Greenplum segment host.
在Greenplum的一个段主机上，可用的主机内存被计算机上执行的所有过程，包括操作系统，Greenplum的段的情况下，与其他应用程序进程之间共享。管理员必须确定的Greenplum和非Greenplum的进程共享主机的内存和系统配置，以有效地利用内存。监视内存使用情况定期检测的方式的主机存储器的任何变化由Greenplum的或其它工艺消耗是同样重要的。
下图显示了内存是如何细分Greenplum的主机上的消耗。
在说明的底部开始，线标记为A表示总主机内存。该生产线正上方线A的总主机内存包括物理RAM和交换空间。
标记为B线显示，可用内存总量必须由Greenplum的数据库和主机上的所有其他进程共享。非Greenplum数据过程包括操作系统和任何其他应用程序，例如系统监控代理。某些应用程序可能使用的存储器的显著部分和，作为结果，则可能需要调整每Greenplum的主机或每段内存量段的数量。
该段（C）各获得Greenplum的数据库内存（B）的一个相等的份额。
在一个领域，资源管理队列内存是如何分配给执行SQL语句。资源队列，让你在你的Greenplum系统业务需求转换执行政策并防范可能降低性能的查询。
提交的非管理用户到一个Greenplum的系统中的每个语句与一个资源队列相关联。队列确定是否该语句将被允许执行，并且当资源可用时，允许其执行。该声明可能会被拒绝，立即执行，或者排队时资源可用来执行。
可以创建用于不同类型的查询资源队列和保留段存储器的一个固定部分，用于每个队列。另外，您也可以设置服务器配置参数指定多少内存分配为每个查询，并把没有最大内存限制对资源的队列中。
查询优化器生成一个查询执行计划，包括一系列被称为operators（图中标记为D）的任务的。operators执行诸如表扫描或联接，并通常产生通过处理输入的行的一个或多个组中间查询结果。operators收到的资源队列分配给查询内存的份额。如果operators不能履行其所有在分配给它的内存的工作，它在溢出文件磁盘缓存数据。
主机内存是由段主机上的所有应用程序共享的内存总量。主机存储器的量可以使用以下任何方法来配置：
o添加更多的RAM为节点，以增加物理内存。
o分配的交换空间来增加虚拟内存的大小。
o设置内核参数vm.overcommit_memory和vm.overcommit_ratio配置操作系统如何处理大的内存分配请求。
物理RAM和操作系统配置通常是由平台团队和系统管理员进行管理。参考Greenplum数据引擎安装指南（Greenplum Database Installation Guide）推荐的内核参数设置。
保留用于操作系统和其他进程的内存大小和工作量相关度很大。操作系统的最小内存推荐为32GB，但如果有很多并发，保留内存需要提高到64GB。操作系统存储器的最大用户是SLAB，其随着Greenplum并发和使用的socket数量的增长而增长。
vm.overcommit_meniory内核参数应该始终设置为2，对Greenplum数据的唯一安全值。
在VM.overcommit_ratio内核参数设置用于为应用程序进程的RAM的百分比，为操作系统保留剩余部分。红帽默认值是50（50％）。设置此参数过高，可能导致操作系统内存不足，这会导致段主机故障或数据库故障。使用默认的50%设置一般是安全的，但非常保守。设定值太低会降低在同一时间运行的并发量和查询的复杂度。当增加vm.overcommit_ratio记得要始终保留一些存储器操作系统的活动是重要的。
要计算vm.overcommit_ratio一个安全值，首先要确定可用于Greenplum的数据库进程的总内存，叫gp_vmem，利用如下公式计算：
gp_vmem =((SWAP + RAM) - (7.5GB + 0.05 * RAM)) / 1.7
其中SWAP是在主机上的交换空间，单位是GB，RAM是安装在主机上的RAM的大小，单位是GB。使用这个公式来计算vm.overcommit_ratio值：
vm.overcommit_ratio= (RAM - 0.026 * gp_vmem) / RAM
例如，SWAP是32GB，RAM是64GB，则gp_vmem =
((32 + 64) - (7.5 +0.05 * 64)) / 1.7=50.3
vm.overcommit_ratio= (RAM - 0.026 * gp_vmem) / RAM =(64 – 0.026*50.3) /64 =0.
Greenplum的数据库内存是内存提供给所有Greenplum数据段实例的数量。
当您设置了Greenplum的集群，确定主要的段数为每台主机和内存来分配每个段的量运行。取决于CPU核心，物理RAM量，和工作负荷的特性上，段的数量通常为4到8之间的值。启用段镜像后，确定为一个故障期间在主机上执行的主段的最大数目分配内存是重要的。例如，如果使用默认的分组镜像配置，一个段主机发生故障，会使得其镜像的段主机的活跃主段进程的数量翻倍。采用分散是的段镜像配置，使得一个段主机的镜像段扩散到多个主机上，会大大降低每个段主机上运行的主段，允许更多的内存分配给每个区段。例如，如果你使用块镜像配置，每块4的主机和每个主机上8个段，一台主机故障将导致其他主机块有最多为11个活跃的主段，相比16默认分组镜像配置。
该gp_vmem_protect_limit值是内存来分配每个段的数量。它是通过计算对于所有Greenplum数据过程中可用的内存和一个故障期间由主段的最大数目除以估计。如果gp_vmem_protect_limit设置过高，查询可能会失败。
使用下面的公式来计算gp_vmem_protect_limit一个安全值。
计算gp_vmem，所有Greenplum的数据库进程的可用内存，使用如下公式：
gp_vmem = ((SWAP +RAM) - (7.5GB + 0.05 * RAM)) / 1.7
其中SWAP是在主机上的交换空间，单位是GB，RAM是安装在主机上的RAM的大小，单位是GB。
计算gp_vmem_protect_limit使用这个公式：
gp_vmem_protect_limit = gp_vmem /max_acting_primary_segments
这里max_acting_primary_segments是主链段，可以是最大数量
在主机上运行时，射镜段由于主机或段故障激活。
另一个重要的Greenplum数据库服务器配置参数是statement_mem。此参数设置的最大内存量分配给执行查询。要确定这个值
参数，划分的每段（gp_vmem_protect_limit）内存量，少了10％的安全余量，由您希望并发执行查询的最大数量。默认Greenplum数据资源队列最多允许20个并发查询。这里有一个公式来计算statement_mem：
（gp_vmem_protect_limit * 0.9）/ max_expected_concurrent_queries
资源队列可以分配给查询的内存量的控制。请参阅配置工作负载管理的详细信息。
资源队列是在Greenplum的系统管理并发度的主要工具。资源队列是你与创建资源队列SQL语句创建数据库对象。您可以使用它们来管理，可能会同时执行活动查询的数量，每种类型的查询被分配的内存量和查询的相对优先级。资源队列，还可以防止将消耗太多资源，并降低系统的整体性能查询。
每个数据库角色与一个单一的资源队列相关联;多个角色可以共享相同的资源队列。角色分配给使用创建角色或ALTER ROLE语句的资源队列短语资源队列。如果未指定资源队列，作用与所述默认资源队列，pg_default相关联。
当用户提交要执行的查询，查询是针对资源队列的限制进行评估。
如果查询不会导致队列超过其资源限制，那么该查询就会立即运行。如果查询导致队列超过其限制（例如，如果活动语句的最大插槽数目前都在使用），那么查询必须等到队列资源是空闲的才能运行。
查询是第一个在评估，先出基础。如果查询优先被启用，系统上的活动的工作量，根据查询优先级定期评估和处理资源被重新分配（见优先工作原理）。与超级用户属性的角色可以从资源队列限制豁免。超级用户查询始终立即运行，无论其分配的资源队列强加的限制。
资源队列定义具有相似资源需求的查询类。关键的建议administratrors创造的各类机构中的工作负载的资源队列。例如，你可以创建资源队列查询以下类，分别对应不同的服务等级协议：
一个资源队列具有以下特点：
MEMORY_LIMIT
每个段所有的查询的总内存量例如，在ETL队列memory_limit的设置为2GB允许ETL查询每个段最多使用2GB的内存。
ACTIVE_STATEMENTS
例如, the pg_defauit resource queue has ACTIVE_STATEMENTS = 20.
为队列时隙数;最大并发级别的队列。当使用了所有的插槽，新的查询必须等待。每个查询默认使用的存储器等量。
例如，在pg_defauit资源队列中ACTIVE_STATEMENTS=20。
相对CPU使用情况的查询。这可能是以下级别之一：低，中，高，MAX。默认级别为中等。查询优先机制监视在系统中运行的所有查询的CPU使用率，并调整用于每个CPU的使用率，以符合其优先级。例如，您可以MAX优先级设置为行政资源队列和中到其他队列，以确保执行查询接收CPU更大的份额。
查询计划成本的限制。
注： Pivotal建议您使用memory_limit的和ACTIVE_STATEMENTS设置为资源队列，而不是MAX_COST限制。
在Greenplum数据引擎优化分配一个数值代价每个查询。如果成本超过了所述资源队列设置MAX_COST值，查询被拒绝，因为过于昂贵。
为Greenplum的数据库系统的默认配置pg_default命名一个默认的资源队列。该pg_default资源队列有20的ACTIVE_STATEMENTS设置，没有了memory_limit，中等优先级，并没有固定的MAX_COST。这意味着所有查询都接受并立即运行，在相同优先级和无记忆限制;然而，只有二十查询可以并发执行。
一个资源队列允许的并发查询的数量取决于memory_limit参数是否被设置：
o如果没有memory_limit的设置为一个资源队列，每个查询分配的内存量为statement_mem服务器配置参数的值。资源队列可以使用的最大内存为statement_mem和ACTIVE_STATEMENTS的产物。
o当memory_limit的设置上的资源队列，查询队列可同时执行的数量由队列的可用内存的限制。
一个查询使用了系统为其分配的内存总量，并为它生成一个查询计划树。树的每个节点是运营商，如排序或散列连接。每个操作者是一个独立的执行线程，并且已分配的整体语句存储器的一小部分，以最小100KB。如果该计划有大量的操作符，操作符所需要的最小内存可以超过可用内存和查询将内存不足错误而被拒绝。操作符确定他们是否能在分配的内存中完成他们的任务，或者他们必须溢出数据到磁盘，在工作的文件。该分配和控制的内存每个操作员使用量的机制称为内存限额。
不是通过资源队列提交的所有SQL语句都通过队列限制评估。默认情况下只能选择，SELECT INTO，CREATE TABLE AS SELECT，并声明CURSOR语句进行评估。如果服务器配置参数resource_seiect_only设置为off，INSERT、UPDATE和DELETE语句也将被评估和限制。
默认资源队列，pg_default，最多允许20个活动查询和并且为每个查询分配相同的内存。对生产系统，这样的资源控制是不够的。为了确保系统符合性能预期，您可以定义查询类，并将它们分配给资源配置来控制并发，内存和CPU资源，以便最适合该类查询。
下图显示了系统的Greenplum用一个例子资源队列配置
gp_vmem_protect_limit设置为8GB：
这个例子有三类具有不同特点和服务水平协议（SLA）查询。三种资源队列为他们配置。该段存储器的一部分被保留为安全余量。
Resource Queue Name
Active Statements
Memory Limit
Memory per Query
The total memory allocated to the queues is 6.4GB,or 80% of the total segment memory defined by the gp_vmem_protect_limitserver configuration parameter. Allowing a safetymargin of 20%o accommodates some operators and queries
that are known to use more memorythan they are allocated by the resource queue.
See the create resource queue and create/alter rolestatements in the Greenplum Database Reference Guide forhelp with command syntax and detailed reference information.
分配给队列中的总存储器是6.4GB，或由gp_vmem_protect_limit服务器配置参数定义的总段存储器的80％。让20％的邻安全边际容纳一些运营商和已知比他们由资源分配队列使用更多的内存的查询。
对资源队列设置memory_limit的设置，通过队列提交的所有活动查询可以消耗为段实例的最大内存量。内存分配给一个查询量是队列内存限制的活动语句限制分歧。 （枢纽建议内存限制在基于语句的队列，而不是基于成本的队列配合使用。）例如，如果一个队列有2000MB的内存限制和10个活动语句的限制，通过队列提交的每个查询默认的内存分配200MB。默认的内存分配可以使用statement_mem服务器配置参数（最多队列内存限制），每次查询进行覆盖。
一旦查询已经开始执行，它保持其分配的存储器中的队列中，直到它完成，即使在执行期间实际消耗小于其分配的内存量。
您可以使用statement_mem服务器配置参数覆盖由目前的资源队列中设置内存限制。在会话级，可以增加statement_mem到资源队列的memory_limit的。这将允许单个查询使用所有分配给整个队列的存储器，而不会影响其他资源的队列。
statement_mem的值使用max_statement_mem配置参数（超级用户参数）为上限。一种用于在资源队列memory_limit的集的查询，为statement_mem的最大值为分钟（memory_limit的，max_statement_mem）。当查询被接纳，存储器
分配给它是从memory_limit的减去。如果memory_limit的耗尽，在同一资源队列中的新查询必须等待。会发生这种情况，即使ACTIVE_STATEMENTS尚未到达。请注意，这只能在statement_mem用于覆盖由资源队列分配的内存发生。
例如，考虑命名具有以下设置即席资源队列：
omemory_limit的是1.5GB
oACTIVE_STATEMENTS 3
默认情况下提交队列中的每个语句分配的内存500MB。现在考虑
下面一系列事件：
1.用户ADHOC_1提交查询Q1，覆盖STATEMENT_MEM到800MB。在Q1语句获准进入该系统。
2.用户ADHOC_2提交查询Q2，使用默认的500MB。
3. Q1和Q2仍在运行，用户ADHOC3提交查询Q3，使用默认的500MB。
查询Q1和Q2使用了队列的1500MB的1300MB。因此，Q3必须等待Q1或Q2完成才能运行。
如果在队列未设置memory_limit的，查询被接纳，直到所有的ACTIVE_STATEMENTS时隙都在使用，并且每个查询可以设置任意高statement_mem。这可能会导致使用无限量的存储器中的资源的队列。
有关在资源配置队列的内存限制的更多信息，以及其他内存利用率
控件，请参阅使用内存限制队列。
优先级设置为资源队列从memory_limit的和ACTIVE_STATEMENTS设置，以确定查询是否被录取到队列中，并最终执行的是不同的。
优先级设置适用于查询他们变得活跃了。活动查询共享可用的CPU
资源通过其资源的队列优先级设置决定。当从一个高优先级队列声明进入集团积极运行报表，它可能会声称可用的CPU更大的份额，减少分配给已经运行在较小的优先级设置队列报表份额。
查询的相对大小或复杂性并不一个^等CPU的分配。如果简单，低成本的查询与一个大型的，复杂的查询同时运行，以及它们的优先级设置是相同的，它们将被分配可用的CPU资源的相同的共享。当一个新的查询变得活跃，CPU份额将重新计算，但相同优先级的查询仍会有CPU的等量。
例如，管理员创建三个资源队列：即席提交的业务分析师持续查询，定期报告工作汇报，并执行提交的执行用户角色查询。管理员希望确保定期报告作业不会严重影响由即席查询分析师无法预测的资源需求。此外，管理员要确保提交的行政职务查询分配CPU的显著份额。因此，资源队列优先权被设定为示出：
o即席 - 低优先级
o报告 - 高优先级
执行 - 最大优先权
在运行时，活动语句的CPU占有率是由这些优先级设置决定。如果查询1和2，报告队列同时运行时，它们的CPU平分秋色。当即席查询变得活跃，它声称CPU的份额较小。由报告查询使用的确切份额调整，但仍然由于其相同的优先级设置相同：
Figure 26: CPU share readjusted according topriority Note:
在这些图中所示的百分数是近似的。高，低和最高优先级的队列之间的CPU使用率并不总是正是这些比例计算。
当执行查询进入组中运行报表，CPU使用率是调整，以考虑其最大的优先级设置。这可能是比分析师和报告查询一个简单的查询，但直到它完成，它会获取CPU的最大份额。
Figure 27: CPU share readjusted for maximumpriority query
For more information about commands to setpriorities, see.
在Greenplum数据引擎启用和使用工作负载管理涉及以下高级任务：
1.配置工作量管理。请参阅配置工作负载管理。
2.创建资源队列并对其设置的限制。请参阅创建资源队列和修改资源队列。
3.分配一个队列的一个或多个用户角色。请参见分配角色（用户）资源队列。
4.使用工作负载管理系统的观点来监控和管理资源的队列。请参阅检查资源队列状态。
资源调度是默认启用的，当您安装的Greenplum数据库，并要求所有角色。默认资源队列，pg_default，有20的活动语句限制，没有内存限制，和中等优先级设置。关键建议您创建不同类型的工作负载的资源队列。
1.下列参数对于资源的队列的一般结构：
omax_resource_queues- 设置资源的队列的最大数量。
omax_resource_portals_per_transaction- 设置每个事务允许同时打开的游标的最大数量。需要注意的是一个开放的光标将在资源队列举行活动查询插槽。
oresource_select_only- 如果设置为ON，然后选择，SELECT INTO，CREATE TABLE ASSELECT，并声明CURSOR命令进行评估。如果设置为off，INSERT，UPDATE和DELETE命令将被限制。
oresource_cleanup_gangs_on_wait- 以一个槽在资源队列之前清理了空闲段工作进程。
ostats_queue_level- 启用资源队列使用情况统计信息收集，然后可以
通过查询pg_stat_resqueues系统视图查看。
以下为一般的资源队列配置参数:
o max_resource_queues -设置资源的队列的最大数量。
max_resource_portais_per_transaction -设置每个事务最多可以打开几个游标 (Cursor)。值得注意的是每个游标需要占用资源队列的一个活动查询。
resource_select_only- 若设置为on，SELECT、SELECT INTO、CREATE TABLE AS SELECT和DECLARE CURSOR语句被评估限制。若设置为off， INSERT、UPDATE和DELETE语句也将被评估和限制。
resource_cleanup_gangs_on_wait-在开始一个新的查询之前先清空所在资源 队列中其他空闲的工作进程。
stats_queue_level- 激活资源队列使用信息收集，这样就可以通过查询系统视图 Pg_stat_resqueues 查看。
以下参数与内存使用有关：
gp_resqueue_memory_policy-启用Greenplum的内存管理特性。
在Greenplum数据引擎4.2和更高版本，分配算法eager_free利用了并非所有的运营商执行在同一时间执行的优势。查询计划被分为不同的阶段，Greenplum数据库在一个阶段执行完之后，就将其内存释放出来，并立即分配给下一个阶段。。设置为none的情况下内 存管理与4.1版本之前相同。设置为auto内存受statement_mem和资源队列内存 限制的控制。缺省为eager_free，译者认为该模式利于合理调整内存使用量。
statement_memand max_statement_mem -用于为每个活动语句分配内存(可以复 写资源队列的缺省值)。max_statement_mem由SUPERUSER设置，应考虑避免 普通用户的超负荷使用。在任何时候statement_mem都必须小于max_statement_mem。
gp_vmem_protect_limit-限制每个SegmentInstance上所有语句可以使用的物理内存总量的上限值。导致内存使用超过该上限的语句会被取消掉(Cancel)而得不到执行。译者认为该参数要根据具体硬件情况进行合理的评估，从OS层 面来说，内存颗粒的容量用完之后会使用SWAP充当内存，对于普通磁盘来说， 不到万不得己，强烈建议不要使用SWAP。
gp_vmem_idle_resource_timeout与gp_vmem_protect_segworker_cache_limit - 用于释放Instance上空闲DB进程的内存。为了提高并发量，管理员可以考虑调整这些配置。详细说明可参考相关附录。
shared_buffers–设置内存的Greenplum的服务器实例使用共享内存缓冲区量。此设置必须至少为128千字节，并至少16千字节倍max_connections中。该值不能超过共享内存最大分配请求大小操作系统，SHMMAX在Linux上。看到Greenplum的数据库安装指南为您推荐平台操作系统内存设置。
Sets the amount of memory a Greenplum serverinstance uses for shared memory buffers. This setting must be at least 128kilobytes and at least 16 kilobytes times max_connections. The value must not exceed the operating
systemshared memory maximum allocation request size, shmmax on Linux. See the GreenplumDatabase Installation Guide forrecommended OS memory settings for your platform.
以下参数与查询优先级有关。注意，这些参数都是本地(LOCAL)参数，必须修改所有 Instance 的postgresql.conf文件：
gp_resqueue_priority -缺省状态下查询优先级特性开启。
gp_resqueue_priority_sweeper_interval -设置CPU为所有活动语句重新计算 CPU资源分配的时间。缺省值通常己经可以满足常规的DB操作。
gp_resqueue_priority_cpucores_per_segment -设置每个Instance使用的CPU核数。缺省状态下Instance为4而Master为25，这对于EMC DCA2(Greenplum Data Computing Appliance Version2)是正确的。该参 数是LOCAL参数。该参数对于Master也是有影响的，需要配置到一个较高的值。比如，在一个集群中，每个Host主机有8个CPU核且每个Segment
Host有4 个Instance，那可以按照如下配置：
每个主机都应在postgresqi.conf文件中检查该参数的值。此参数也影响主节点，在那里它应该被设置为反射CPU核心的更高比率的值。例如，一个具有每台主机10个CPU内核，每个主机4段的集群上，你会指定gp_resqueue_priority_cpucores_per_segment这些值：
为master 和 standby master设置10。通常情况下，只有master实例在maser主机上。在段主机上设置段实例为2.5。
如果未正确设置参数值，就会造成CPU可能无法得到充分的利用，或者是预期的查询优先顺序可能无法正常工作。如果每个Segment Host主机上配置的Instance数量低于CPU核数，请确保将该参数调整到一个合适的值。过低的值可能会导致CPU资源利用不足。
实际的CPU核心利用率是基于Greenplum的数据库的并行查询并执行查询所需要的资源的能力。
注意：被包括在CPU内核的数量不限CPU核心是提供给操作系统。例如，虚拟CPU核心被包括在CPU内核的数量。
要查看和修改这个工作负载管理参数，还可以使用gpconfig命令。译者认为，往往都是使用这个命令，很少有人直接去改postgresql.conf文件的，不过如果由于参数修改不当导致GPDB系统无法启动，目前这个命令是无能为力了。
比如，要查看一个参数值：
$ gpconfig --showgp_vmem_protect_limit
比如，要修改一个参数的值，且Master的值与Segment不同：
$ gpconfig -c gp_resqueue_priority_cpucores_per_segment -v 2 -m 8
重启GPDB以确保修改的参数生效(本节介绍的参数都需要重启才能生效)：
$ gpstop -r
创建资源队列涉及到Name、成本、活动语句数量、执行优先级等。通过CREATE RESOURCE QUEUE命令来创建新的资源队列。
资源队列通过设置ACTIVE_STATEMENTS控制活动语句的数量。例如，创建 一个名称为adhoc活动语句数量为3的资源队列：
=# CREATE RESOURCE QUEUE adhoc WITH(ACTIVE_STATEMENTS=3);
这意味着，分配到adhoc资源队列的所有ROLE，在同一时刻最多只能有3个语 句处于执行状态。如果该队列当前已经有3个语句正在执行，在该队列的ROLE 提交第4个语句时，其将处于等待状态，直到前面3个语句有一个执行完。
资源队列通过设置MEMORY_LIMIT控制该队列所有语句可以使用的内存总量。 每个主机上所有Instance可以获得的物理内存总数不得超过该主机的物理内存 总数。GP建议将MEMORY_LIMIT控制在该Instance可以得的的物理内存总数的 90%以下。比如，一个Host主机有48GB的物理内存，有6个Instance，那么每个 Instance可以获得的物理内存为8GB。这样就可以简单的得到
MEMORY_LIMIT=0.9*8GB=7.2GB。如果存在多个资源队列，他们的 MEMORY_LIMIT总和应被控制为7.2GB。
当与ACTIVE_STATEMENTS结合使用时，缺省每个语句获得的内存为： MEMORY_LIMIT /ACTIVE_STATEMENTS。当与MAX_COST结合使用时，缺 省的内存分配为：MEMORY_LIMIT * (query_cost / MAX_COST)。GP推荐与 ACTIVE_STATEMENTS结合使用而不是与MAX_COST结合使用。
比如，创建一个活动语句数量为10，内存限制为2000MB的资源队列(每个语句 在执行时在每个Instance上获得200MB的内存)：
=# CREATE RESOURCE QUEUE myqueue WITH (ACTIVE_STATEMENTS=10/MEMORY_LIMIT='2000MB');
缺省的内存分配可以在每个语句通过设置statement_mem参数复写，但不可超过 MEMORY_LIMIT和max_statement_mem设定的值。比如，分配更多的内存：
=& SET statement_mem='2GB';
=& SELECT * FROM my_big_table WHERE column='value' ORDER BY
=& RESET statement_
通常来说，MEMORY_LIMIT的设置建议所有的资源队列的总和不要超过 Instance可以获得的物理内存总数。如果不同类型语句之间交错执行尚且可以， 但仍需要留意，如果某个Instance超出了内存限制超，相关语句会被取消。
为了控制CPU资源的使用，管理员可以设置合适的优先级。在并发争用CPU资 源时，高优先级资源队列中的语句将可以获得比低优先级资源队列中的语句更 多的CPU资源。
优先级可以在 CREATE RESOURCE QUEUE 和 ALTER RESOURCE QUEUE 的
时候通过WITH来设置。例如，为adhoc和reporting队列指定优先级，管理员可 以使用下面的命令：
=# ALTER RESOURCE QUEUE adhoc WITH (PRIORITY=LOW);
=# ALTER RESOURCE QUEUE reporting WITH (PRIORITY=HIGH);
创建最高优先级的队列executive，管理员可以使用下面的命令：
=# CREATE RESOURCE QUEUE executive WITH (ACTIVE_STATEMENTS=3,PRIORITY=MAX);
在优查询优先级特性开启时，资源队列的优先级缺省为MEDIUM。see.
重要提示：要使得资源队列的优先级设置在执行语句中强制生效，必须确保优 先级特性的相关参数已经设置好。参见”配置工作负载管理”。
一旦资源队列被创建好了，就需要把ROLE(User)分配到合适的资源队列。如果ROLE 没有被显式的分配到一个资源队列，其将被分配到缺省的资源队列pg_default。缺省 的资源队列含20个活动语句数量和MEDIUM的优先级。
使用ALTER ROLE或者CREATE ROLE命令来分配ROLE到资源队列。比如：
=# ALTER ROLE name RESOURCE QUEUE queue_
=# CREATE ROLE name WITH LOGIN RESOURCE QUEUE queue_
每个ROLE同一时间只能被分配到一个资源队列，可以使用ALTER ROLE命令修改 ROLE的资源队列。
资源队列的分配必须通过逐个User的方式进行。如果有一个层级较高的ROLE(比如 GROUP ROLE)，将给ROLE分配到一个资源队列并不会将其包含的User分配到该资源队列。
SUPERUSER总是不受资源队列限制的。SUPERUSER的查询总是可以立即得到执行， 而不管资源队列的限制如何设置。
所有ROLE都需要分配到资源队列。如果没有被显式分配到指定的资源队列，该ROLE将会进入缺省资源队列pg_default。如果想将ROLE从现有资源队列中 移除并放到缺省队列中，可将其资源队列分配到none。比如：
=# ALTER ROLE role_name RESOURCE QUEUE
修改资源队列
在创建资源队列后，可以使用ALTER RESOURCE QUEUE命令来改变或者重置队列 的限制。还可以使用DROP RESOURCE QUEUE命令删除资源队列。
在创建资源队列后，可以使用ALTER RESOURCE QUEUE命令来改变或者重置队列的限制。还可以使用DROPRESOURCE QUEUE命令删除资源队列。
使用ALTERRESOURCE QUEUE命令来改变资源队列的限制。一个资源队列必 须包含ACTIVE_STATEMENTS或者MAX_COST(或者都包含)。变更资源队列，
执行新的值。例如：
=# ALTER RESOURCE QUEUE adhoc WITH (ACTIVE_STATEMENTS=5);
=# ALTER RESOURCE QUEUE exec WITH (MAX_COST=);
要将活动语句数量或者内存限制重置为无限制，可以使用-1值。要重置Cost门 槛为无限制，可以设置为-1值。比如：
=# ALTER RESOURCE QUEUE adhoc WITH (MAX_COST=-1.0, MEMORY_LIMIT='2GB');
可以使用ALTERRESOURCE QUEUE命令改变查询优先级。比如，设置一个资源队列的优先级为最低级别：
ALTER RESOURCE QUEUE webuser WITH (PRIORITY=MIN);
使用DROP RESOURCE QUEUE命令删除资源队列。要删除一个资源队列，该 资源队列不能与任何ROLE相关，或者队列中有语句正等待执行。删除一个资源队列：
=# DROP RESOURCE QUEUE
检查资源队列状态涉及下列内容：
查看排队语句和资源队列状态
查看资源队列统计信息
查看分配到资源队列的ROLE
查看资源队列中等待的语句
清除资源队列中等待的语句
查看活动语句的优先级
管理员可以通过查看视图gp_toolkit.gp_resqueue_status来查看资源队列的状态。
该视图展示系统中每个资源队列有多少语句在等待执行，多少语句正在执行。 查看资源队列在系统中的创建、限制、当前的状态：
=# SELECT * FROM gp_toolkit.gp_resqueue_
如果要追踪资源队列的统计信息和性能，需要为资源队列开启统计信息收集配置。这可以通过配置Master上postgresql.conf文件的这个参数来实现：
stats_queue_level = on
一旦该配置开启，就可以使用系统视图pg_stat_resqueues来查看资源队列使用的 统计信息。注意，开启该配置会带来轻微的资源开销，每个经资源队列执行的 语句都会被追踪。开启统计信息收集对于初期的资源队列诊断是有帮助的，而 后续的运行应该关闭该参数。
更多关于资源队列统计信息收集的问题可以参考PostgreSQL的相关文档。
要查看ROLE与资源队列之间的关联关系，使用系统日志表pg_roles和 gp_toolkit.gp_resqueue_status 来获得：
要查看ROLE与资源队列之间的关联关系，使用系统日志表pg_roles和 gp_toolkit.gp_resqueue_status 来获得：
=# SELECT rolname, rsqname FROM pg_roles,
gp_toolkit.gp_resqueue_status
WHERE pg_roles.rolresqueue=gp_toolkit.gp_resqueue_status.
或者可以创建一个视图来简化以后的使用。例如：
=# CREATE VIEW role2queue AS
SELECT rolname, rsqname FROM pg_roles, pg_resqueue
WHERE pg_roles.rolresqueue=gp_toolkit.gp_resqueue_status.
这样就可以直接查询试图了：
=# SELECT * FROM role2
当语句在资源队列中执行时，其会被记录在pg_locks系统日志表中。这里可以 查看到所有的活动语句和等待语句。为了检查处于等待状态的语句(即便没有语 句在等待)，可以使用gp_toolkit.gp_locks_on_resqueue视图。例如：
=# SELECT * FROM gp_toolkit.gp_locks_on_resqueue WHERE lorwaiting='true';
若该查询没有结果返回，意味着此时没有语句在资源队列中等待执行。
有时候可能需要清除资源队列中处于等待状态的语句。比如，想要清除在资源 队列中等待还没有得到执行的语句。还有可能想要终止一个已经开始而需要很 长时间才能完成的语句，或者该语句处于空闲的事务状态而希望其把资源让给 其他需要的ROLE。要达到这些目的，首先需要知道哪些语句需要被清除，确 定该进程的ID，然后使用pg_cancel_backend函数来终止该进程。
比如，查看当前处于活动状态或者等待状态的语句：
SELECT rolname, rsqname, pid, granted,
current_query, datname
FROM pg_roles, gp_toolkit.gp_resqueue_status, pg_locks,
pg_stat_activity
WHERE pg_roles.rolresqueue=pg_locks.objid
AND pg_locks.objid=gp_toolkit.gp_resqueue_status.queueid
AND pg_stat_activity.procpid=pg_locks.pid
AND pg_stat_activity.usename=pg_roles.
若没有结果返回，意味着当前没有语句处于资源队列中。比如有两个语句在资源队列中可能是这种样子的：
| rsqname 丨
granted 丨
current_query
丨 datname
&IDLE& in transaction
丨 namesdb
webuser 丨
SELECT * FROM
丨 namesdb
根据输出结果确定需要清除语句的进程ID(pid)。通过下面的方式清除语句：
=# pg_cancel_backend(31905)
注意：尽量不要使用OS的KILL命令。译者认为，不是完全不可以用，如果不小心把系统搞崩溃了有能力拯救的话，其实怎么杀都无所谓。
在gp_toolkit模式中有个视图gp_resq_priority_statement，其包含了所有正在执行的语句的优先级，会话ID等信息。该视图只能通过gp_toolkit模式访问。参看Greenplum数据参考指南了解更多信息。
SUPERUSER可以在语句运行期间通过内置函数gp_adjust_priority(session_id, statement_count, priority)调整其优先级。通过该函数SUPERUSER可以提升或者 降低任何语句的优先级。例如：
=# SELECT gp_adjust_priority(752, 24905, 'HIGH')
该函数需要获取语句的SESSION ID和Statement Count两个参数，SUPERUSER 可以通过gp_toolkit模式的视图gp_resq_priority_statement获得，session_id和 statement_count两个参数分别对应rqpsession和rqpcommand。该函数只对指定 的语句有效，同一个资源队列随后的语句仍然使用其预先设定的优先级。
Note: The gp_adjust_priority() function affectsonly the specified statement. Subsequent statements in The same resource queueare executed using the queue's normally assigned priority.
Greenplum的工作负载及资源管理
关于执行队列和工作管理器
利用yarn多队列实现hadoop资源隔离
《Greenplum5.0 最佳实践》 内存与资源队列 （四）
没有更多推荐了，
(window.slotbydup=window.slotbydup || []).push({
id: "5865577",
container: s,
size: "300,250",
display: "inlay-fix"