OWLS-103387 - Add FAQ about the active processor count for burstable pods with no CPU limit. (#3623)

* OWLS-103387 - Add FAQ about the active processor count for burstable pods and JDK bug.

Author: ankedia

documentation/4.0/content/faq/resource-settings.md

@@ -199,6 +199,13 @@ There's no memory or CPU limit configured by default in samples and so the defau
 
 If you wish to set resource requests or limits differently on a sample Domain or Cluster YAML file or template, see [Setting resource requests and limits in a Domain or Cluster resource](#setting-resource-requests-and-limits-in-a-domain-or-cluster-resource). Or, for samples that generate their Domain resource using an "inputs" YAML file, see the `serverPodMemoryRequest`, `serverPodMemoryLimit`, `serverPodCpuRequest`, and `serverPodCpuLimit` parameters in the sample's `create-domain.sh` inputs file.
 
+#### Burstable pods and JDK active processor count calculation
+If you have [Burstable Pods](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-burstable) that configure the CPU resource requests but have no CPU limits, then the JDK can incorrectly calculate the active processor count. The JDK interprets the value of the `--cpu-shares` parameter (which maps to `spec.containers[].resources.requests.cpu`) to limit how many CPUs the current process can use, as explained in [JDK-8288367](https://bugs.openjdk.org/browse/JDK-8288367). This might cause the JVM to use fewer CPUs than available, leading to an under utilization of CPU resources when running in a Kubernetes environment. Updating the JDK to newer versions, `JDK 8u371` or `JDK 11.0.17`, fixes this. 
+
+{{% notice note %}}
+To override the number of CPUs that the JVM automatically detects and uses when creating threads for various subsystems, use the `-XX:ActiveProcessorCount` Java option.
+{{% /notice %}}
+
 #### Configuring CPU affinity
 
 A Kubernetes hosted WebLogic Server may exhibit high lock contention in comparison to an on-premises deployment. This lock contention may be due to a lack of CPU cache affinity or scheduling latency when workloads move between different CPU cores.