Use this SAS KB article to check and increase the Java heap and Kubernetes container memory for the Files service (sas-files). Note that these are separate settings and might need to be changed together.
This article does not apply to SAS® Viya® 3.x or SAS®9 deployments.
The Files service requires a larger Java heap, a larger container memory limit, or both. Increasing -Xmx without a sufficient container memory limit can cause an out-of-memory condition. In addition, increasing the container memory limit does not change an explicitly configured -Xmx value.
Before you begin, obtain the following permissions:
Replace <namespace> with the namespace where the SAS Viya platform is deployed.
In addition, record the current values before making changes.
IMPORTANT: The examples in this article use -Xmx1536m with a 2Gi container memory limit. The Java heap is approximately 75% of the container limit, leaving memory for non-heap and native use. Adjust the values as appropriate for the environment.
1. In SAS Environment Manager, click Configuration.
2. Select Files service.
3. Open the jvm configuration instance.
4. Record the values of java_option_xmx and java_option_xms.
If a service-level property is not present, check whether a corresponding global JVM option applies.
Here is an example:
java_option_xmx=-Xmx1536m
java_option_xms=-Xms256m
Run the following command:
kubectl -n <namespace> get deployment sas-files \
-o jsonpath='{range .spec.template.spec.containers[*]}{"Container: "}{.name}{"\nMemory request: "}{.resources.requests.memory}{"\nMemory limit: "}{.resources.limits.memory}{"\n\n"}{end}'
The memory request is used when Kubernetes schedules the pod. The memory limit is the container memory ceiling.
1. In SAS Environment Manager, select Configuration ► Files service ► and open or create the jvm configuration instance.
2. Set java_option_xmx.
Here is an example:
java_option_xmx=-Xmx1536m
3. If an explicit initial heap size is required, set java_option_xms.
Here is an example:
java_option_xms=-Xms256m
4. Save the configuration.
Verify that the running Files service uses the new value. If Files service does not use the new value, restart the service by using the documented SAS Viya service-management procedure.
1. Create the following file in the site-config directory: site-config/sas-files-modify-memory-limits.yaml
2. Add the following content:
apiVersion: builtin
kind: PatchTransformer
metadata:
name: sas-files-modify-memory-limits
patch: |-
- op: replace
path: /spec/template/spec/containers/0/resources/limits/memory
value: 2Gi
- op: replace
path: /spec/template/spec/containers/0/resources/requests/memory
value: 1Gi
target:
group: apps
kind: Deployment
name: sas-files
3. Verify that sas-files is container 0:
kubectl -n <namespace> get deployment sas-files \
-o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\n"}{end}'
If sas-files is not the first container in the output, update both patch paths to use the correct container index.
Re-check the container order after updating the SAS Viya deployment assets.
4. Add the transformer to the existing transformers section in kustomization.yaml:
transformers:
- site-config/sas-files-modify-memory-limits.yaml
Preserve all existing transformer entries.
5. Build the manifests and confirm that the generated sas-files deployment contains the intended memory request and limit.
6. Apply the deployment by using the established SAS Viya platform deployment process.
The resource settings apply to every pod created from the sas-files Deployment template.
1. Verify the rollout:
kubectl -n <namespace> rollout status deployment/sas-files
2. Locate the replacement pod:
kubectl -n <namespace> get pods | grep sas-files
3. Confirm that the replacement pod is in the Running state and that all expected containers are ready.
4. When kubectl exec is permitted, verify the JVM options used by the running process:
kubectl -n <namespace> exec <sas-files-pod-name> -- \
sh -c 'tr "\000" " " </proc/1/cmdline'
Confirm that the output contains the expected -Xmx and -Xms values.
If the new values are not present, restart the Files service by using the documented SAS Viya service-management procedure and verify the values again.
5. Check the pod for memory-related restarts:
kubectl -n <namespace> describe pod <sas-files-pod-name>
Review the container state, last state, restart count, and events.
A termination reason of OOMKilled means that the container exceeded its memory limit.
The Files service uses the updated Java heap and container memory settings.
1. Restore the recorded java_option_xmx and java_option_xms values in SAS Environment Manager.
2. Remove the following transformer entry from kustomization.yaml:
- site-config/sas-files-modify-memory-limits.yaml
3. Rebuild and apply the manifests.
4. Verify the effective JVM options and Deployment memory values.
Removing the transformer causes the deployment to use the values supplied by the underlying SAS deployment manifests and any other applicable customizations.