We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

30

UPDATE: Note that the answer below applies to RHEL 6. In RHEL 7, most cgroups are managed by systemd, and libcgroup is deprecated. Since posting this question I have studied the entire guide that I linked to above, as well as the majority of the cgroups.txt documentation and cpusets.txt. I now know more than I ever expected to learn about cgroups, so I'll ...


13

A better and safer solution is to install cgmanager and run it with systemctl start cgmanager (on a systemd-based distro). You can than have your root user, or if you have sudo rights on the host create cgroups for your unprivileged user in all controllers with: sudo cgm create all $USER sudo cgm chown all $USER $(id -u $USER) $(id -g $USER) Once they have ...


10

I've gotten an initial explanation about this test case from Stefan Seyfried, who wrote the paper this example was taken from. The problem here is that the CPU scheduler parts of cgroups always aims to keep any available CPU busy; it doesn't ever enforce a hard limit if everything will fit at once. In the case where two processes (high and low here) are ...


9

From the kernel documentation concerning memory.swappiness: 5.3 swappiness Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only. Following cgroups' swappiness can't be changed. - root cgroup (uses /proc/sys/vm/swappiness). - a cgroup which uses hierarchy and it has other cgroup(s) below it. - a cgroup which ...


8

There are several uses for cgroups. From the system administration probably the most important one is limiting resources -- the classical example here being the cpu access. If you create a group for e.g. sshd and give it some non-negligible CPU time share (compared to other groups or the default under which fall all unsorted processes), you are guaranteed to ...


8

Remember how I said: The system uses lxc containers for compartmentalisation, but that shouldn't matter here. Well, turns out it did matter. Or rather, the cgroups at the heart of lxc matter. The host machine only sees reboots for kernel upgrades. So, what were the last kernels used? 3.19, replaced by 4.0.5 2 months ago and yesterday with 4.1.3. And ...


8

From reading man systemd-run, it will create a service and thus a cgroup on the fly. From reading systemd.exec, the Nice= directive will apply to all executed processes, so the way that systmd handles the concepts of Nice= and CPUShares= are very similar. My understanding of the relationship is that it has to do with history. nice has existed for a listed a ...


8

You need to check permissions of each element in the path, not just the file permissions. Each directory must have access 'x' (which means execute for files but traverse for directories) for the user wishing to run the command.


8

First of all, most of what comes up in search on the web has been deprecated. For example cgmanager is no longer supported on new systemd versions. Don't follow 99% of what comes up in web serches as far as using cuplimit, nice, cgset or other tools for this job. They either won't work at all as advertised (as in the case of cgroup management tools that ...


7

Microsoft Azure is a public cloud offering both Infrastructure as a Service and Platform as a Service components. It sounds like the Platform as a Service (PaaS) aspects are what you are after — but note that you will need infrastructure of some sort to run this on. There are two main open source projects which will allow you to build and run a PaaS of your ...


7

There seems no officially supported way to do that. (This is incorrect. See the bottom) An officially discouraged way (because it manipulates the cgroup) is as follows: Make the following file as /etc/systemd/system/user@.service.d/set-memhigh.conf [Service] Type=simple ExecStartPost=+/root/set-memoryhigh.sh %i Then make the following file as "/root/set-...


7

The whole idea behind podman is to go away from the centralized architecture with the super-powerful overseer (e.g. dockerd), where the centralized daemon is a single point of failure. There even is a hashtag about this - "#nobigfatdaemons". How to avoid the centralized container management? You remove the single main daemon (again, dockerd) and start the ...


6

The easiest way is using systemd which may be responsible for your sshd anyway (depending on the distribution). You can easily configure the limits in the sshd unit file. systemd puts all services in separate cgroups anyway. Without systemd the easiest solution is probably a modification to the sshd start script (pay attention that it's not overwritten by ...


6

I had the same problem, and I found that you have to set $LIMIT to 0 to remove that limit: echo "$MAJOR:$MINOR 0" > blkio.throttle.write_bps_device This removes the entry from the cgroup. If you then cat blkio.throttle.write_bps_device, you will not see the entry any more.


6

That's the highest positive signed 64-bit integer (263-1), rounded down to multiples of 4096 (212), the most common page size on x86 systems. It would seem difficult to get anything higher while avoiding possible confusion between signed and unsigned, so it seems at least a reasonable approximation for infinity. That said, I don't know for sure, this is ...


6

The value comes from the cgroup setup in the memory management layer; by default, it’s set to PAGE_COUNTER_MAX, which is LONG_MAX / PAGE_SIZE on 64-bit platforms, and multiplied by PAGE_SIZE again when read. This confirms ilkkachu’s explanation: the value is the maximum 64-bit signed integer, rounded to the nearest page (by dropping the last bits).


6

According to Lennart Poettering: Try this: stat -fc %T /sys/fs/cgroup/ if that reports "cgroups2fs" then you are in full cgroupsv2 mode. If it returns "tmpfs" then you are in either full cgroupsv1 mode, or in hybrid mode. Then, check if /sys/fs/cgroup/unified exists. If it does, then you are in hybrid mode. if not you are in pure cgroupsv1 ...


5

As far as I'm concerned, I think cgroups would be overkill here. However, I tend to use ulimit whenever I run something witk a fork system call in it (bad experiences made it a habit...) : $ ulimit -u 2500 $ ./mypotentiallydeadlyprogram This way, I put a 2500 processes limit on my current shell. Thanks to this, my fork calls will end up failing if they get ...


5

OOM killer does send a SIGKILL as it would otherwise be counter-productive to let the problematic program the choice of continuing. This means that there is absolutely no way for a process to know when it is about to get killed by it. Managing such issues usually imply making corrections to the programs or their configuration. Sometimes, depending on ...


5

You don't need to be root to start a user-scoped group with systemd-run: $ systemd-run --user --scope /bin/bash Running scope as unit run-23318.scope. $ sleep 999 & [1] 23369 You can see the unit: $ systemctl --user status run-23318.scope * run-23318.scope - /bin/bash Loaded: loaded (/run/user/1000/systemd/user/run-23318.scope; static; ...


5

On Linux, a nice value applies to a task, that is a process or thread (see link for disambiguation), a "CPU shares" value applies to a cgroup (a group of one or more tasks). The default non-realtime Linux' task scheduler (CFQ), distributes CPU time "fairly" among the different cgroups. It will use the cpu.shares value of each cgroup (by default 1024), ...


5

A container isn't defined in Linux. It's purely a construct of the application you use to launch it. Typically there are a number of features that define a container: Namespace isolation mount process UTS ... etc Cgroup resource limitations seccomp restrictions stop apps being able to reach syscalls And so on. Containers aren't defined by cgroups, so ...


4

Someone suggested in your hear cgroups. Well, try to seek that direction as it can provide you with: applied to a group of task you choose (thus not system wide but neither per process) the limits are set for the group the limits are static they can enforce hard limit on memory and/or memory+swap Something like that could bring you closer to your goals: ...


4

The time slice used will matter for CPU intensive jobs that require cache persistence, unless you lock a particular core to each PID. You can increase the time slice with scheduler policy SCHED_BATCH and improve performance up to 300% in some cases, while reducing interactive responsiveness. The opposite effect of smaller time slices occurs with SCHED_RR (...


4

Well, for the CPU affinity bit, that's usually intended to solve a different set of problems that pertain to the physical CPU's that are executing the program. That's why you have to specify which particular CPU's you're talking about with CPU affinity. From the fact that you don't care which CPU's get used, I'm guessing you're just trying to get time ...


4

The problem here is that you need to use the fair scheduler, I was using the wrong scheduler, and had mis-read a setting (thought I was using fair scheduler, but really wasn't). Swapping to the correct IO scheduler fixed the problem. To change the IO scheduler (taken from here): echo cfq > /sys/block/{DEVICE-NAME}/queue/scheduler


4

It's possible to register for a notification for when a cgroup's memory usage goes above a threshold. In principle, setting the threshold at a suitable point below the actual limit would let you send a signal or take other action. See: https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt


4

You're looking in the wrong place, because this isn't really to do with the mount command itself. What you're doing is mounting a special filesystem, in this case, a cgroups hierarchy, and the options happen to be how you attach different cgroup subsystems like cpu or memory. Red Hat* has some good documentation on cgroups in general and the mount options ...


4

What does cat memory.memsw.usage_in_bytes say? You cannot set the max below the current limit. Looking at the 3.10 Linux sources, modifying memsw.limit_in_bytes results in a call to mem_cgroup_write(): { .name = "memsw.limit_in_bytes", .private = MEMFILE_PRIVATE(_MEMSWAP, RES_LIMIT), .write_string = mem_cgroup_write, .read = ...


4

There’s no refresh, the values given when you read one of the cgroup files reflect the actual use at the time. You can see this in action by watching the memory.stat file, highlighting differences: watch -d cat /sys/fs/cgroup/memory/memory.stat


Only top voted, non community-wiki answers of a minimum length are eligible