tencent cloud

TencentOS Server

문서TencentOS ServerUser GuideKernel FeaturesDetailed Explanation of cgroup v1/cgroup v2 Features

Detailed Explanation of cgroup v1/cgroup v2 Features

다운로드
포커스 모드
폰트 크기
마지막 업데이트 시간: 2026-10-19 17:22:48
AI 번역

Background Information

cgroup is a feature in the Linux kernel that limits the resources used by processes. It can limit CPU, memory, network, and other resources used by processes, preventing a single process from consuming excessive resources and causing system crashes. cgroup has two versions: cgroup v1 (merged into the kernel in 2007) and cgroup v2 (officially released in 2016). The main differences are as follows:
Comparison Item
cgroup v1
cgroup v2
Hierarchical Structure
Multi-level structure, where the same process may appear in different cgroups simultaneously, resulting in confusing semantics.
A unified hierarchy model where all controllers share the same cgroup tree.
Thread Granularity
Unstable control, with unpredictable behavior when parent and child cgroup threads compete for resources.
Introduces the Threaded Mode, allowing different threads of the same process to be assigned to different cgroups.
Interface Naming
Inconsistent field units and naming (such as memory.limit_in_bytes vs cpu.cfs_quota_us), resulting in a steep learning curve.
Unified interface naming (*.max, *.current, *.events, *.stat), with new advanced features such as io.latency and memory.pressure
Ecosystem Status
A large user base, but systemd does not support cgroup v1 by default starting from v256.
Upstream communities and major distributions have fully transitioned to cgroup v2 (RHEL 9 uses cgroup v2 by default); TencentOS Server 4 uses cgroup v2 by default (unified mode).

Prerequisites

Before performing cgroup query, configuration, or migration operations in this document, make sure the following conditions are met:
root privileges: The cgroup interface files are located in /sys/fs/cgroup, and write operations require root.
Confirm the current cgroup mode: Run mount | grep cgroup to determine whether the current mode is cgroup2 (unified) or multiple cgroup mount points (legacy) to avoid misoperations.
Back up the grub configuration (required for migration scenarios): Make sure to back it up before modifying boot parameters.
Maintenance window: Migrating from cgroup v1 to cgroup v2 involves modifying GRUB boot parameters and restarting the system. Schedule a maintenance window to ensure that your business can tolerate downtime.
systemd version requirement: Full cgroup v2 support requires systemd 239 or later, which TencentOS Server 4 meets by default. If you are migrating from an older system, run systemctl --version first to confirm.
Do not perform migration inside a container: The cgroup mode is determined by the host kernel boot parameters and cannot be modified inside a container. All migration operations must be performed on the host.

Must-Knows

TencentOS Server 4 uses cgroup v2 by default (unified mode).
The no internal process constraint rule of cgroup v2 requires that when a cgroup has controllers enabled (such as memory.max), it cannot directly contain processes at the same time. Processes must be placed in leaf cgroups.
Threaded cgroup operations are irreversible: once a cgroup is set to threaded, it cannot be restored to domain. The parent of a threaded cgroup must be a valid domain cgroup or threaded cgroup.
In cpu.max, max means no limit, and $MAX=0 means CPU usage is completely prohibited. Do not mistakenly set it to 0 100000, as this will prevent processes from running.
Setting memory.swap.max to 0 completely disables swap usage, which may cause processes to be OOM-killed when memory is insufficient. Set a reasonable value based on the actual memory characteristics of your business.
io.latency is an IO latency target mechanism introduced in cgroup v2. When a device exceeds the target latency, the kernel prioritizes the IO requests of this cgroup, making it suitable for latency-sensitive workloads.
The cgroup v2 statistics interfaces (*.stat and *.current) are read-only. Do not attempt to write to them. memory.reclaim is a write-only interface, and writing the number of bytes triggers proactive memory reclamation.
When a migration from cgroup v1 to cgroup v2 is performed, directives such as CPUQuota and MemoryLimit in existing systemd units remain valid under cgroup v2, and systemd automatically translates them to cgroup v2 interfaces. However, scripts that directly operate on /sys/fs/cgroup need to update their interface paths.
Container runtime compatibility: Docker versions earlier than 20.10, containerd versions earlier than 1.6, and Kubernetes versions earlier than 1.25 have incomplete cgroup v2 support. Before migration, upgrade the corresponding container components and confirm in the Docker daemon configuration file /etc/docker/daemon.json that no special --cgroup-driver parameter is required (under cgroup v2, systemd automatically uses the systemd driver).
Production environment risks: The migration from cgroup v1 to cgroup v2 cannot be performed online and requires a system restart. Some cgroup v1 scripts and monitoring metrics (such as those that directly read /sys/fs/cgroup/memory/...) have invalid paths under cgroup v2, so you need to review and update them in advance.

API and Parameter Description

cgroup Mode Switch Parameters

Boot Parameter
Value
Description
systemd.unified_cgroup_hierarchy=1
0/1
1=Use cgroup v2 (unified).
0=Use cgroup v1 (legacy). Default value: 1 (TencentOS Server 4).
systemd.legacy_systemd_cgroup_controller=1
0/1
1=cgroup v1 controllers are managed by the systemd unified proxy.
0=cgroup v1 controllers are managed directly by the kernel. This value is valid only in legacy (cgroup v1) mode.
SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1
0/1
1=Force enable cgroup v1.
0=Not enforced (default).
systemd v256 and later versions cannot use cgroup v1.

Core API Mapping Between cgroup v1 and cgroup v2

The mapping between cgroup v1 and cgroup v2 for common controller interfaces is shown in the following table:
Subsystem
cgroup v1 Interface
cgroup v2 Interface
Description
cpu
cpu.cfs_quota_us + cpu.cfs_period_us
cpu.max
Merged into a single interface, with the format "$MAX $PERIOD"
cpu
cpu.cfs_burst_us
cpu.max.burst
Burst CPU Quota
cpu
cpu.shares
cpu.weight
Weight (1-10000), effective only when the device is busy.
cpu
cpuacct.stat + cpuacct.usage
cpu.stat
Unified Statistics Interface
cpu
cpu.rt_period_us + cpu.rt_runtime_us
-
Deleted. Real-time scheduling is no longer controlled by cgroup.
cpuset
cpuset.effective_cpus
cpuset.cpus.effective
Effective CPU List
cpuset
cpuset.effective_mems
cpuset.mems.effective
Effective Memory Node List
cpuset
cpuset.memory_pressure
memory.pressure
Merged into the memory subsystem.
memory
memory.limit_in_bytes
memory.max
Memory Hard Limit
memory
memory.soft_limit_in_bytes
memory.low
Memory Soft Limit (Guaranteed Amount)
memory
memory.usage_in_bytes
memory.current
Current Memory Usage
memory
memory.max_usage_in_bytes
memory.peak
Historical Maximum Usage
memory
memory.memsw.limit_in_bytes
memory.swap.max
swap Limit
memory
memory.swappiness
-
Deleted. Use memory.swap.max instead.
memory
memory.oom_control
-
Deleted. Use the memory.oom.kill event instead.
memory
memory.kmem.*
-
Deleted. Kernel memory is no longer accounted for separately.
blkio
blkio.throttle.read_bps_device and 3 others
io.max
Merged into a single interface
blkio
blkio.throttle.io_service*
io.stat
Statistics Interface
blkio
blkio.bfq.io_service*
-
Deleted
blkio
-
io.latency
New: IO latency target
hugetlb
hugetlb.<size>.usage_in_bytes
hugetlb.<size>.current
Current Usage
hugetlb
hugetlb.<size>.limit_in_bytes
hugetlb.<size>.max
Limit
hugetlb
hugetlb.<size>.max_usage_in_bytes
hugetlb.<size>.events
Event Notification
rdma
-
rdma.max / rdma.current
New: RDMA resource limit
pids
-
pids.peak
New: historical maximum number of processes

Detailed Explanation of cgroup v2 Core APIs

cpu.max

Format: "$MAX $PERIOD". For example, "500000 100000" means a maximum of 50 ms of CPU time within a 100 ms period (equivalent to 0.5 cores).
Conversion notes: The value of cpu.max is in microseconds (μs). $MAX is the allowed runtime within a period, and $PERIOD is the scheduling period length. Cores = $MAX / $PERIOD. Common conversions:
1 core = 100000 100000 (100 ms / 100 ms)
0.5 cores = 50000 100000 or 500000 1000000
2 cores = 200000 100000
Unlimited = max 100000 (max means no CPU usage limit, with the period still being 100 ms)
View the current value (<cgroup_name> is the name of the cgroup you created):
cat /sys/fs/cgroup/<cgroup_name>/cpu.max
Output example (when set to 0.5 cores):
500000 1000000
Set to 0.5 cores (500000 μs / 1000000 μs = 0.5):
echo "500000 1000000" > /sys/fs/cgroup/<cgroup_name>/cpu.max
After writing, run cat /sys/fs/cgroup/<cgroup_name>/cpu.max again to confirm that the setting has taken effect. Output example:
500000 1000000
Set to unlimited (meaning no CPU usage limit for this cgroup):
echo "max 100000" > /sys/fs/cgroup/<cgroup_name>/cpu.max
After writing, run cat /sys/fs/cgroup/<cgroup_name>/cpu.max. Output example:
max 100000

memory.max / memory.high / memory.low

API
Description
Behavior After Exceeded
memory.max
Hard Limit
Trigger OOM Killer
memory.high
Soft Limit
Triggers memory reclamation, affecting performance but not killing processes.
memory.low
Guaranteed Amount
Does not reclaim the cgroup memory when usage is below this value.
memory.swap.max
swap Limit
Rejects swap allocation when the limit is exceeded.

io.max

Format: "$MAJ:MIN rbps=<N> wbps=<N> riops=<N> wiops=<N>".
Limit device 8:16 to 10 MB/s for both read and write bandwidth and 500 for both read and write IOPS:
echo "8:16 rbps=10485760 wbps=10485760 riops=500 wiops=500" > /sys/fs/cgroup/<cgroup_name>/io.max
View the current limit:
cat /sys/fs/cgroup/<cgroup_name>/io.max
Output example:
8:16 rbps=10485760 wbps=10485760 riops=500 wiops=500

Threaded cgroup (Threaded Mode)

cgroup v2 introduces a threaded mode that allows different threads of the same process to be assigned to different cgroups, resolving the issue of unstable thread-level control in cgroup v1. The controllers that support threading include cpu, cpuset, perf_event, and pids.
API
Value
Description
cgroup.type
domain/threaded
Read/write: Set the cgroup type.

Steps for Migrating from cgroup v1 to cgroup v2

Warning:
The operations in this section involve modifying GRUB boot parameters and restarting the system, which is a high-risk change. Before proceeding, make sure to:
Back up the GRUB configuration: cp /etc/default/grub /etc/default/grub.bak.$(date +%F-%H%M);
Confirm the maintenance window: A restart will cause service interruption. Make sure that all relevant parties have been notified and a downtime window has been scheduled;

Step 1: Check the Current cgroup Mode

# View the current cgroup mount mode
mount | grep cgroup
# Expected output for v2 (unified): cgroup2 on /sys/fs/cgroup type cgroup2 (...)
# Expected output for v1 (legacy): cgroup on /sys/fs/cgroup/cpuset type cgroup (cpuset), cgroup on /sys/fs/cgroup/memory type cgroup (memory) ... (multiple mount points)

# Further confirm cgroup v2 by using stat
stat -fc %T /sys/fs/cgroup/
# Expected output for v2: cgroup2fs
# Expected output for v1: tmpfs
Verification method: If mount | grep cgroup shows only one line of cgroup2 on /sys/fs/cgroup, the system is already using cgroup v2 and no migration is required. If multiple cgroup on /sys/fs/cgroup/<controller> entries are displayed, the system is using cgroup v1, and you need to proceed with the following steps.

Step 2: Modify GRUB Boot Parameters

# Back up the original configuration
cp /etc/default/grub /etc/default/grub.bak.$(date +%F-%H%M)
# Expected output: No errors. You can run ls -l /etc/default/grub.bak.* to confirm.

# Append or modify the following parameters in GRUB_CMDLINE_LINUX (ensure unified_cgroup_hierarchy=1)
# Add directly with grubby (recommended to avoid manual editing errors)
grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1 systemd.legacy_systemd_cgroup_controller=0"
# Expected output: No errors.

# Check the current kernel boot parameters to confirm that they have been appended.
grubby --info=ALL | grep -E 'args|kernel'
# Expected output: args should contain systemd.unified_cgroup_hierarchy=1
Verification method: The output of grubby --info=ALL | grep args should contain systemd.unified_cgroup_hierarchy=1.

Step 3: Regenerate the GRUB Configuration

# Regenerate grub.cfg (use grub2-mkconfig on x86_64)
grub2-mkconfig -o /boot/grub2/grub.cfg
# Expected output: Generating grub configuration file ... done

# Paths may differ on aarch64. Use:
# grub2-mkconfig -o /etc/grub2-efi.cfg or grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

# Verify the generated result (confirm that the configuration file contains unified_cgroup_hierarchy=1)
grep unified_cgroup_hierarchy /boot/grub2/grub.cfg
# Expected output: systemd.unified_cgroup_hierarchy=1 can be matched.

Step 4: Restart the System

# Restart the system (perform this within a maintenance window)
sync && reboot
# Expected output: The system restarts. After logging in again, perform the next verification step.
Verification method: After the system restarts, log in again via SSH and run uptime to confirm that the system has started normally.

Step 5: Verify Successful Migration

# Verification 1: Verify mount (a single cgroup2 mount is expected)
mount | grep cgroup
# Expected output: cgroup2 on /sys/fs/cgroup type cgroup2 (...)

# Verification 2: Check the file system type with stat
stat -fc %T /sys/fs/cgroup/
# Expected output: cgroup2fs

# Verification 3: Controller mount status (under v2, controllers are exposed through /sys/fs/cgroup/cgroup.controllers)
cat /sys/fs/cgroup/cgroup.controllers
# Expected output: cpuset cpu io memory hugetlb pids rdma (the specific list depends on the kernel configuration)

# Verification 4: The v1 interface has been unmounted (subdirectories such as /sys/fs/cgroup/memory should not exist)
ls /sys/fs/cgroup/ | grep -E '^(cpu|memory|blkio|cpuset)$'
# Expected output: Empty (the v1 subdirectories should no longer exist)

Common Management Commands

Viewing the cgroup Mode

View the current cgroup mode:
mount | grep cgroup
Output example:
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)
In unified (cgroup v2) mode, a single cgroup2 mount is returned. In legacy (cgroup v1) mode, multiple cgroup mount points (cpu, memory, ...) are returned.
Check the cgroup version:
cat /proc/cgroups
Output example:

#subsys_name    hierarchy       num_cgroups     enabled
cpuset  0       188     1
cpu     0       188     1
cpuacct 0       188     1
blkio   0       188     1
memory  0       188     1
devices 0       188     1
freezer 0       188     1
net_cls 0       188     1
perf_event      0       188     1
net_prio        0       188     1
hugetlb 0       188     1
pids    0       188     1
rdma    0       188     1
misc    0       188     1

Switching the cgroup Mode (cgroup v2 > cgroup v1, Not Recommended)

For the following scenarios, refer to the steps in this section to switch from cgroup v2 back to cgroup v1:
Businesses depend on legacy toolchains that support only cgroup v1 (such as old libcgroup interfaces and specific monitoring agents).
Legacy scripts are deeply coupled with the cgroup v1 directory structure and cannot be refactored in the short term.
To switch modes, modify the GRUB boot parameters and regenerate the configuration. The change takes effect persistently after a reboot, with no additional configuration required. To restore cgroup v2, remove these parameters and reboot. Add the following to the GRUB boot parameters:
systemd.legacy_systemd_cgroup_controller=1
systemd.unified_cgroup_hierarchy=0
SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1
After the reboot, verify:
mount | grep cgroup
Output example (switched back to cgroup v1, with multiple mount points returned):
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
...

Using systemd to Manage cgroups

View the cgroup hierarchy:
systemd-cgls
Output example:
Control group /:
-.slice
├─user.slice (#1203)
│ └─user-0.slice (#41553)
│   └─session-1.scope
...
└─system.slice (#65)
  ├─sshd.service (#2701)
  │ └─674 sshd: /usr/sbin/sshd -D
  ...
Start a service controlled by cgroup:
systemctl start <service_name>
If the command is executed successfully, no output is returned.
Modify the resource limits of the service:
systemctl set-property <service_name> CPUQuota=50% MemoryLimit=1G
If the command is executed successfully, no output is returned.
After configuration, you can run systemctl show <service_name> | grep -E "CPUQuota|MemoryLimit" to view the effective limits.

Manually Creating a cgroup and Limiting Resources

Create a cgroup (replace <cgroup_name> with the actual name, such as webapp), then set CPU, memory, and I/O limits in sequence, and add the process to the cgroup:
mkdir /sys/fs/cgroup/<cgroup_name>

echo "500000 1000000" > /sys/fs/cgroup/<cgroup_name>/cpu.max

echo 1073741824 > /sys/fs/cgroup/<cgroup_name>/memory.max

echo "8:16 rbps=10485760 wbps=10485760" > /sys/fs/cgroup/<cgroup_name>/io.max

echo $PID > /sys/fs/cgroup/<cgroup_name>/cgroup.procs
If the above commands are executed successfully, no output is returned. You can run the following command to verify whether the limits have taken effect.
Verify that the limits have taken effect:
cat /sys/fs/cgroup/<cgroup_name>/cpu.stat
cat /sys/fs/cgroup/<cgroup_name>/memory.current
cat /sys/fs/cgroup/<cgroup_name>/io.stat
Output example (using the first entry of cpu.stat as an example, the value increases as the process runs; memory.current should be less than or equal to memory.max):
usage_usec 1532600
user_usec 810400
system_usec 722200
nr_periods 12
nr_throttled 6
throttled_usec 3900000

Using systemd-run for Temporary Testing

Start a temporary service and limit its CPU usage:
systemd-run --unit=test-cpu --slice=test-.slice -p CPUQuota=50% -p MemoryLimit=512M /bin/bash -c "while true; do true; done"
Output example (returns the running information of the service):
Running as unit: test-cpu.service
View resource usage:
systemctl status test-cpu
systemd-cgls test-.slice
Output example of systemctl status test-cpu:
● test-cpu.service - /bin/bash -c while true; do true; done
     Loaded: loaded (/run/systemd/transient/test-cpu.service; transient)
     Active: active (running) since Sat 2026-08-22 11:00:00 CST; 5s ago
   Main PID: 2475 (bash)
      Tasks: 1 (limit: 48621)
     Memory: 512.0M (max: 512.0M)
        CPU: 2.5s

Enabling Threaded cgroups

Mark the cgroup as threaded (this operation is irreversible), and add different threads of the process to different child cgroups:
echo threaded > /sys/fs/cgroup/<cgroup_name>/cgroup.type

echo $TID > /sys/fs/cgroup/<cgroup_name>/worker_threads/cgroup.threads
Run cat /sys/fs/cgroup/<cgroup_name>/cgroup.type to confirm that the type has changed. Output example:
threaded

Expected Results

Verifying Resource Limit Enforcement

The verification methods for unmounting mount, controllers, and cgroup v1 interfaces are provided in Step 5: Verify Successful Migration, and will not be repeated here.

Verifying Resource Limit Enforcement

After creating a cgroup and setting cpu.max and memory.max:
The cat /sys/fs/cgroup/<cgroup_name>/cpu.stat command should output statistical fields such as usage_usec, user_usec, and system_usec, and the values increase as the process runs.
The cat /sys/fs/cgroup/<cgroup_name>/memory.current command should output the current memory usage in bytes, which should be less than or equal to memory.max.
When the usage exceeds memory.max, the oom count in memory.events should increase, and the process is killed by the OOM Killer.

Other Must-Knows

TencentOS Server 4 uses cgroup v2 by default (unified mode), and switching back to cgroup v1 is not recommended. If cgroup v1 is required, add systemd.unified_cgroup_hierarchy=0 to the GRUB boot parameters and restart the system.
The no internal process constraint rule of cgroup v2 requires that when a cgroup has controllers enabled (such as memory.max), it cannot directly contain processes at the same time. Processes must be placed in leaf cgroups. This is one of the biggest behavioral differences from cgroup v1.
Threaded cgroup operations are irreversible: once a cgroup is set to threaded, it cannot be restored to domain. The parent of a threaded cgroup must be a valid domain cgroup or threaded cgroup.
In cpu.max, max means no limit, and $MAX=0 means CPU usage is completely prohibited. Do not mistakenly set it to 0 100000, as this will prevent processes from running.
Setting memory.swap.max to 0 completely disables swap usage, which may cause processes to be OOM-killed when memory is insufficient. Set a reasonable value based on the actual memory characteristics of your business.
io.latency is an IO latency target mechanism introduced in cgroup v2. When a device exceeds the target latency, the kernel prioritizes the IO requests of this cgroup, making it suitable for latency-sensitive workloads.
The cgroup v2 statistics interfaces (*.stat and *.current) are read-only. Do not attempt to write to them. memory.reclaim is a write-only interface, and writing the number of bytes triggers proactive memory reclamation.
When a migration from cgroup v1 to cgroup v2 is performed, directives such as CPUQuota and MemoryLimit in existing systemd units remain valid under cgroup v2, and systemd automatically translates them to cgroup v2 interfaces. However, scripts that directly operate on /sys/fs/cgroup need to update their interface paths.
Container runtime compatibility: Docker versions earlier than 20.10, containerd versions earlier than 1.6, and Kubernetes versions earlier than 1.25 have incomplete or disabled-by-default cgroup v2 support. Before migration, upgrade the container runtime and confirm in the Docker daemon configuration file /etc/docker/daemon.json that no special --cgroup-driver parameter is required (under cgroup v2, systemd automatically uses the systemd driver).
systemd version requirement: Full cgroup v2 support requires systemd 239 or later, which TencentOS Server 4 meets by default. If you are migrating from an older system, run systemctl --version first to confirm.
Production environment risks: The migration from cgroup v1 to cgroup v2 cannot be performed online and requires a system restart. Some cgroup v1 scripts and monitoring metrics (such as those that directly read /sys/fs/cgroup/memory/...) have invalid paths under cgroup v2, so you need to review and update them in advance.

FAQs

Q1: After a migration to cgroup v2 is performed, containers fail to start and the logs show "cgroup v2 not supported"? A: The container runtime version is too old. Solution: Upgrade Docker to 20.10 or later, containerd to 1.6 or later, or Kubernetes to 1.25 or later. For Docker, check /etc/docker/daemon.json to ensure that --exec-opt native.cgroupdriver=cgroupfs is not explicitly specified (the systemd driver should be used under cgroup v2). After the upgrade, restart the container runtime: systemctl restart docker or systemctl restart containerd.
Q2: Application logs report memory.kmem.limit_in_bytes read/write failure or "No such file or directory"? A: This is a kernel memory accounting interface in cgroup v1, which has been removed in cgroup v2 (kernel memory is no longer accounted for separately and is unified into memory.max). Solution: Update the application or container runtime configuration to remove references to memory.kmem.* and use memory.max to control total memory (including kernel memory).
Q3: How do I roll back to cgroup v1 if services become abnormal after the migration to cgroup v2 is performed? A: Modify the GRUB parameters in reverse and restart the system. Steps:
# The following commands produce no output when executed successfully.
# Remove unified_cgroup_hierarchy=1 and add the v1 parameter.
grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller=1 SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1"
# Regenerate the grub configuration.
grub2-mkconfig -o /boot/grub2/grub.cfg
# Restart.
sync && reboot
After the reboot, verify:
mount | grep cgroup
Output example (restored to multiple cgroup mount points):
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
...
Note: systemd v256 and later versions no longer support rolling back to cgroup v1. If the rollback still fails after SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 is set, the system can no longer be downgraded to cgroup v1. In this case, adapt your services to run in cgroup v2 compatibility mode, or replace the machine with one that has an older systemd version.
Q4: echo "500000 100000" > cpu.max causes the process CPU to be completely limited and the process fails to run? A: The parameters are misunderstood. 500000 100000 means that 500 ms of CPU time is allowed within a 100 ms period, which equals 5 cores (not 0.5 cores). To limit CPU usage to 0.5 cores, use 50000 100000 or 500000 1000000. Conversion formula: number of cores = $MAX / $PERIOD. Setting $MAX=0 completely prohibits CPU usage and is a dangerous configuration.
Q5: Creating a child cgroup reports the error "Device or resource busy" or "Invalid argument"?
A: Common causes:
The parent cgroup already directly contains processes, which violates the no internal process constraint of cgroup v2. Move the processes to a leaf cgroup.
If the corresponding controllers are not enabled, write +cpu +memory +io to the parent cgroup.subtree_control to re-enable them.
The parent type of the threaded cgroup does not match.
Troubleshoot:
Run cat /sys/fs/cgroup/cgroup.controllers to view the controllers that can be enabled.
Run cat /sys/fs/cgroup/cgroup.subtree_control to view the controllers enabled on the parent (and compare them with the list of controllers that can be enabled to check whether any are missing).
After confirmation, enable the controllers on the parent:
echo "+cpu +memory +io" > /sys/fs/cgroup/cgroup.subtree_control
After enabling, run cat /sys/fs/cgroup/cgroup.subtree_control again to confirm that the output contains cpu memory io.
Q6: stat -fc %T /sys/fs/cgroup/ outputs tmpfs instead of cgroup2fs? A: The system is still in cgroup v1 mode, and the migration has not succeeded. After the migration is complete, this command should return cgroup2fs (cgroup v1 mode returns tmpfs). Troubleshoot the issue in the following areas:
Run grubby --info=ALL | grep args to confirm that systemd.unified_cgroup_hierarchy=1 has been added to the kernel boot parameters.
Confirm that you have run grub2-mkconfig -o /boot/grub2/grub.cfg to regenerate the configuration and have rebooted the system.
Run systemctl --version to confirm that the systemd version is 239 or later.
이전 주제: Kernel Version Management and Switching다음 주제: Network Kernel Optimization

도움말 및 지원

문제 해결에 도움이 되었나요?

피드백

키워드로 검색
    Enter keywords to search documentation