Resizing /dev/shm
Scenario
/dev/shm is a temporary file system (tmpfs), which is a memory-based file system implemented in Linux or Unix and has high read/write efficiency.
If you use /dev/shm for data interaction between processes or for temporary data storage, the default size of /dev/shm (64 MB) in CCI cannot meet your requirements. CCI allows you to modify the size.
This practice shows how to resize /dev/shm by setting memory-backed emptyDir or running securityContext and mount commands.
Constraints
- /dev/shm uses a memory-based tmpfs to temporarily store data. Data is not retained after the container is restarted.
- You can use either of the following methods to modify the size of /dev/shm. However, do not use both methods in one pod.
- The emptyDir uses the memory requested by the pod and does not occupy extra resources.
- Writing data to /dev/shm is to request memory. In this scenario, you need to evaluate the memory usage of processes. When the sum of the memory requested by processes in the container plus the data volume in the emptyDir exceeds the memory limit of the container, memory overflow occurs.
- When resizing /dev/shm, set the size to 50% of the pod's memory request.
Resizing /dev/shm Using Memory-backed emptyDir
emptyDir is applicable to temporary data storage, disaster recovery, and runtime data sharing. It will be deleted upon deletion or transfer of workload pods.
CCI supports the mounting of memory-backed emptyDir. You can specify the memory size allocated to the emptyDir and mount it to the /dev/shm directory in the container to resize /dev/shm.
apiVersion: v1 kind: Pod metadata: name: pod-emptydir-name spec: containers: - image: 'library/ubuntu:latest' volumeMounts: - name: volume-emptydir1 mountPath: /dev/shm name: container-0 resources: limits: cpu: '4' memory: 8Gi requests: cpu: '4' memory: 8Gi volumes: - emptyDir: medium: Memory sizeLimit: 4Gi name: volume-emptydir1
After the pod is started, run the df -h command to go to the /dev/shm directory. If the following information is displayed, the size is successfully modified.
Resizing /dev/shm by Running securityContext and mount Commands
- Grant the SYS_ADMIN permission to the container.
Linux provides the SYS_ADMIN permission. To apply this permission to the container, Kubernetes needs to add this information to pods by adding the description of the securityContext field to the pod's description file. For example:
"securityContext": { "capabilities": { "add": [ "SYS_ADMIN" ] } }
Another description field CapAdd also needs to be added to the container description.
"CapAdd": [ "SYS_ADMIN" ],
In this case, a parameter is added when the container is automatically started by kubelet.
docker run --cap-add=SYS_ADMIN
- Insert the mount command in the startup command to resize /dev/shm.
apiVersion: v1 kind: Pod metadata: name: pod-emptydir-name spec: containers: - command: - /bin/sh - '-c' - mount -o size=4096M -o remount /dev/shm;bash securityContext: capabilities: add: ["SYS_ADMIN"] image: 'library/ubuntu:latest' name: container-0 resources: limits: cpu: '4' memory: 8Gi requests: cpu: '4' memory: 8Gi
After the pod is started, run the df -h command to go to the /dev/shm directory. If the following information is displayed, the size is successfully modified.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot