process_xxx_memory statistics for macOS (cgo) #1616
Conversation
…E on macOS This unfortunately uses cgo, which I think everyone agrees is not great. I dislike using it because it breaks cross-compiling, but this code allows opting out (at the cost of not publishing `process_resident_memory_bytes` and `process_virtual_memory_bytes`), by setting `CGO_ENABLED=0` in the environment. That's not ideal, but good enough for me where I can cross-compile locally most of the time without `cgo`, and enable it always on the CI server. But that may not be reasonable for other projects. The build-tag comment in the C file avoids the usual "C source files not allowed when not using cgo or SWIG" error on the non-darwin platforms that aren't using cgo, without any changes needing to be made to the client project. Otherwise, the file is compiled on darwin by default, unless `CGO_ENABLED=0`, in which case the dummy function is used and the metrics aren't exported. Therefore, the only potential hardships for client programs with this change are limited to darwin builds. I'm still looking into 3rd party modules to call this without cgo, but this code will help test out those implementations, and hopefully highlights the problems getting at these native APIs. The non-cgo implementation will get much more verbose because the structs in play each have a handful of fields, each of which with a train of typedefs that are platform specific. That said, even though the members may be typed slightly differently on amd64 vs arm64, it looks like the field widths are the same, with the minimal testing I did so far. Signed-off-by: Matt Harbison <mharbison72@gmail.com>
mharbison72
force-pushed
the
mac-process-mem-stats
branch
from
78af2fb
to
eca836e
Compare
|
As an alternative to this, I have now managed to also get it working without cgo, using The one wrinkle that I noticed is that the command code passed to the native API is a macro that evaluates to 5 on amd64, and 18 on arm64. It's this kind of nuisance stuff that gives me pause using this mechanism, though there's clear benefit instead of silently dropping some metrics. Maybe a reasonable solution is using So I guess the choices are simpler code, but slightly limited (this cgo PR), or a dependency + a bit more code without C compiler checks by default, but more flexible for users. Let me know if this second approach is reasonable, and I can clean up and submit this alternative in a different PR. |
mharbison72
changed the title
This is built on top of the much easier to get process metrics in PR1600, so only the last commit is interesting here (and the commit message has more details). I don't expect or want this to be landed as-is, but am posting it here to help with any discussion about finishing off #1590.
I've not paid much attention to the RSS values of Go processes on macOS, but after ~5 minutes of banging on my own exporter with
curl, I only ever see the value going up. The values agree with thepscommand. There should be ~0 code other than from this module running, but we'll see what happens.@bwplotka