The thread count and memory usage are now based on the cgroups CPU and memory limits and/or the number of CPUs the process is bound to. The lowest of all of the limits is chosen.

the newest code in github uses hardware_concurrency() to get the cpu usage, which is not actual processor. I created a jira about the thread also with a patch, in which i parse the cgroup file, which is also closed by your jira manager. So, maxscale does not have the plan to support this?
docker update should be another case, cause it has two step to do.1、get the actual process periodicity 2、make maxscale reload the configuration.

The code was already added to the develop branch:

• https://github.com/mariadb-corporation/MaxScale/commit/10ffb53d550475f22cbc153e2abc776dcad0687e
• https://github.com/mariadb-corporation/MaxScale/commit/75c351f5fe08d9f0405a70db5bb06a8d567cc4f1

The case of docker update will be covered by MXS-3269.

Hi,markus makela , the code use /proc/sys/cgroup as the default parent directory, which should be parsed from /proc/self/mountinfo and /proc/self/cgroup logicaly. and also cgroupv2 can be found from the cgroup hierarchy.i think you can have a look at my patch and my jira, which does the whole thing. This is just a suggestion.

Hongyuan in which cases are the cgroup files mounted somewhere else than /sys/fs/cgroup/?

from "https://www.kernel.org/doc/Documentation/cgroup-v2.txt" and "https://www.kernel.org/doc/Documentation/cgroup-v1.txt", mount point can be decided by user, i think user can change the mount point by "mount -t cgroup .... mount_point". from containerd code, the cgroup file also parsed from /proc/self/mountinfo, golang code list below

func v1MountPoint() (string, error) {

	f, err := os.Open("/proc/self/mountinfo")

	if err != nil {

		return "", err

	}

	defer f.Close()

	scanner := bufio.NewScanner(f)

	for scanner.Scan() {

		var (

			text      = scanner.Text()

			fields    = strings.Split(text, " ")

			numFields = len(fields)

		)

		if numFields < 10 {

			return "", fmt.Errorf("mountinfo: bad entry %q", text)

		}

		if fields[numFields-3] == "cgroup" {

			return filepath.Dir(fields[4]), nil

		}

	}

	if err := scanner.Err(); err != nil {

		return "", err

	}

	return "", ErrMountPointNotExist

}

How often is sysfs mounted somewhere else than /sys? If it's common, then I guess relying on procfs being mounted at /proc is also wrong. All in all, I don't think it's a big problem to require both /sys and /proc to be mounted in their standard locations, especially if this covers a significant majority of all use-cases.

/proc/self/mountinfo is not wrong, which is written in kernel docs. How often is sysfs mounted somewhere else than /sys? i guess that mountpoint is usually /sys/fs/cgroup, so, as i say, that is just a suggestion.

Yeah, we could add support for non-standard sysfs locations when someone presents a use-case where they do it. For the 22.08 release, MaxScale will only support the normal sysfs location of /sys.

Thank you for both your patch and the feedback. We really do appreciate it even if in this case we already added the feature on our own.

that is non-standard, in my opinion, you can say in the release note,you can only support default cgroup mountpoint, which is mounted on /sys/fs/cgroup.

The log message that tells how many cores and how much memory is available uses the container's values if they are limited using cgroups. This is intended to be informational and if the values greatly exceed what it configured in MaxScale, a warning is logged.