Containers, Java and things of that ilk

[lars-t-hansen]

I'm just noting this because it's a notable thing, but I don't know what to do about it exactly. Sonar can measure the CPU usage of a VM/Container/managed language, but memory usage may be trickier. Right now I am looking at a Java job that was told to use 512GB and lo, it allocates 512GB at the start and stays there. Containers and VMs may have similar behavior when viewed from the outside.

[bast]

Thanks for noting this.

[lars-t-hansen]

Job IDs and process IDs:

On a system without a batch queue (running sonar with --batchless), we're moving (#89) in the direction of job ID == process group ID, b/c that's how Unix (BSD/POSIX/Linux) likes it. The process group ID and process ID are in the same namespace: the process group ID is the process ID of the process group leader when the group is created.

This system creaks a bit in the presence of process ID namespaces. In that system, it's possible to create a new namespace with PIDs starting at 1, viewed from within the namespace. From outside the namespace, where sonar is normally running, the PIDs and job ID will be something else.

Since sonar will still be able to see what's going on in the system in the same way as for programs not running within a namespace, this is probably OK. There's the possibility of some confusion if the user observes the process group ID within the namespace / container, as it will not be the same as the job ID outside the container, observed by sonar.