Skip to content

command: Adding ReleaseCgrouResources() function

John Cai requested to merge jc-cgroups-improved into master

This changes the way cgroups work. Before, commands would be get their whole argument line hashed and placed under control of a cgroup.

This update design will support two modes of cgroups. The first is by repository. The following configuration determines how many cgroups we create for repository-level isolation, and the limit per group:

[cgroups.repositories]
count = 10000
memory_bytes = 21474836480
cpu_shares = 512

When a command is created, it will be placed into one of these groups via a circular hash baesd on its repsitory path. This way, we achieve more or less project-level isolation so a handful of users can't overload the system.

If there are more commands than repository cgroups, the circular hash assigns multiple repositories' commands to a single cgroup.

The second mode is a pool of cgroups that configured git commands can use. These cgroups are dedicated for one process at a time. We implement a cgroup "pool" in memory with a buffered channel. As soon as a command is finished, it releases its cgroup back into the pool for another git command to use. Only git commands that are specifically configured in a config block will make use of this pool.

[cgroups.git]
count = 100

A git cgroup pool has a count that determines how many cgroups get created.

[[cgroups.git.command]]
name = upload-pack
memory_bytes = 12884901888
cpu_shares = 128

If this is the only git command that is configured, then only upload-pack commands will get their own cgroups. When a command gets added to a git cgroup, it updates the limits of that cgroup on the fly before execution.

In the situation where there are no more cgroups left in the pool, and a configured git command comes through, it will not get added to a cgroup rather than wait for one to be made available.

Changelog: changed

Edited by John Cai

Merge request reports