From b07005c2d175e48fa91fe1275b00144a91b7dc2a Mon Sep 17 00:00:00 2001
From: Lisa Owen <lowen@pivotal.io>
Date: Thu, 9 Nov 2017 11:21:56 -0800
Subject: [PATCH] docs - memory implications when RGs active and failover
 occurs (#3827)

---
 gpdb-doc/dita/admin_guide/wlmgmt_intro.xml    |  2 +-
 .../dita/ref_guide/config_params/guc-list.xml | 19 +++++++++++++++++++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/gpdb-doc/dita/admin_guide/wlmgmt_intro.xml b/gpdb-doc/dita/admin_guide/wlmgmt_intro.xml
index de8b00697b..455d129d66 100644
--- a/gpdb-doc/dita/admin_guide/wlmgmt_intro.xml
+++ b/gpdb-doc/dita/admin_guide/wlmgmt_intro.xml
@@ -112,7 +112,7 @@
           fail. Use the following formula to calculate a safe value for
           <varname>gp_vmem_protect_limit</varname>; provide the <codeph>gp_vmem_rq</codeph>
           value you calculated earlier.</p><p><codeblock>
-gp_vmem_protect_limit = gp_vmem / max_acting_primary_segments</codeblock></p>
+gp_vmem_protect_limit = gp_vmem_rq / max_acting_primary_segments</codeblock></p>
           <p>where <codeph>max_acting_primary_segments</codeph> is the maximum number of
           primary segments that could be running on a host when mirror segments are activated
           due to a host or segment failure.</p>
diff --git a/gpdb-doc/dita/ref_guide/config_params/guc-list.xml b/gpdb-doc/dita/ref_guide/config_params/guc-list.xml
index 4be6cedf8a..94af1b357e 100644
--- a/gpdb-doc/dita/ref_guide/config_params/guc-list.xml
+++ b/gpdb-doc/dita/ref_guide/config_params/guc-list.xml
@@ -4967,6 +4967,25 @@
           </tbody>
         </tgroup>
       </table>
+      <note>When resource group-based resource management is active, the memory allotted to
+        a segment host is equally shared by active primary segments. Greenplum Database assigns
+        memory to primary segments when the segment takes the primary role. The initial memory
+        allotment to a primary segment does not change, even in a failover situation. This may
+        result in a segment host utilizing more memory than the
+        <codeph>gp_resource_group_memory_limit</codeph> setting permits.
+        <p>For example, suppose your Greenplum Database cluster is utilizing the default
+          <codeph>gp_resource_group_memory_limit</codeph> of <codeph>0.7</codeph> and a
+          segment host named <codeph>seghost1</codeph> has 4 primary segments and 4 mirror
+          segments. Greenplum Database assigns each primary segment on <codeph>seghost1</codeph>
+          <codeph>(0.7 / 4 = 0.175%)</codeph> of overall system memory. If failover occurs and
+          two mirrors on <codeph>seghost1</codeph> fail over to become primary segments,
+          each of the original 4 primaries retain their memory allotment of <codeph>0.175</codeph>,
+          and the two new primary segments are each allotted <codeph>(0.7 / 6 = 0.116%)</codeph>
+          of system memory. <codeph>seghost1</codeph>'s overall memory allocation
+          in this scenario is</p><p><codeblock>
+0.7 + (0.116 * 2) = 0.932%</codeblock></p>
+        <p>which is above the percentage configured
+          in the <codeph>gp_resource_group_memory_limit</codeph> setting.</p></note>
     </body>
   </topic>
   <topic id="gp_resource_manager">
-- 
GitLab