OLM memory footprint at scale

This commit adds recommendation for master node sizing around OLM
memory usage to help users and customers plan their environment
accordingly. It depemds on the number of namespaces and user
installed operators that OLM is managing on the cluster.

Author: chaitanyaenr

modules/master-node-sizing.adoc

@@ -33,6 +33,63 @@ On a cluster with three masters or control plane nodes, the CPU and memory usage
 The node sizing varies depending on the number of nodes and object counts in the cluster. It also depends on whether the objects are actively being created on the cluster. During object creation, the control plane is more active in terms of resource usage compared to when the objects are in the `running` phase.
 ====
 
+Operator Lifecycle Manager (OLM ) runs on the master nodes and it's memory footprint depends on the number of namespaces and user installed operators that OLM needs to manage on the cluster. Master nodes need to be sized accordingly to avoid OOM kills. Following data points are based on the results from cluster maximums testing.
+
+[options="header",cols="3*"]
+|===
+| Number of namespaces |OLM memory at idle state (GB) |OLM memory with 5 user operators installed (GB)
+
+| 500
+| 0.823
+| 1.7
+
+| 1000
+| 1.2
+| 2.5
+
+| 1500
+| 1.7
+| 3.2
+
+| 2000
+| 2
+| 4.4
+
+| 3000
+| 2.7
+| 5.6
+
+| 4000
+| 3.8
+| 7.6
+
+| 5000
+| 4.2
+| 9.02
+
+| 6000
+| 5.8
+| 11.3
+
+| 7000
+| 6.6
+| 12.9
+
+| 8000
+| 6.9
+| 14.8
+
+| 9000
+| 8
+| 17.7
+
+| 10,000
+| 9.9
+| 21.6
+
+|===
+
+
 [IMPORTANT]
 ====
 Because you cannot modify the control plane node size in a running {product-title} {product-version} cluster, you must estimate your total node count and use the suggested control plane node size during installation.