Open CGlemser opened 6 days ago
Thanks for reporting. I clearly broke things when I tried to improve CGroups in v1.39.0. What does that:
$ cat /sys/fs/cgroup/cpu/cpu.shares
output as-is?
FYI, you can do:
parallelly::availableCores(which = "all")
to get everything that it picks up, i.e. no need to use debugging tools.
PS. Please cut'n'paste from the terminal instead of using screenshots, because of reasons, e.g. we've got users with screen readers (here and elsewhere), it's not possible to search for text in images, and it's not possible to cut'n'paste from them.
The Issue
Since version 1.39.0,
parallelly::availableCores()
no longer returns the correct number of available cores on a Kubernetes Cluster on the Posit Workbench (here: 32 instead of the 2 available to my session)Reproducing example Running
parallelly::availableCores()
on Kubernetes Cluster on the Posit Workbench.Expected behavior In version 1.38.0, running
debugonce
shows thatcgroups.cpuquota
was filled and correctly returned as the number of available cores, as seen here on a small 2-core session: .Since the new version, when debugging,
cgroups.cpuquota
is nowNA
andsystem
is returned, (which is equivalent toparallel::detectCores
, and has always been wrong on the Kubernetes cluster). If I explicitly try to select thecgroups.cpuquota
method, it returns 1 (I presume, because it is the minimal number of cores possible).In case it is helpful, this returns the correct number of cores:
Session information