-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
userHz is hard-coded to 100 #61
Comments
When this was last looked at, all supported platforms used 100. |
The |
So we removed it as the necessary cgo dependency forced too much overhead in crossbuilds. Could we come up with a simple solution here, like defining the constant in per architecture files and use build flags? |
We could probably generate the constant in x/sys/Unix and then not worry about it. Easier to push it upstream since the build infrastructure is there. |
@SuperQ LX zones should be considered to be similar to full VMs rather than linux containers. We're not talking about LXC or Docker here. |
The setup here is sufficiently weird that the setting may not be the one we expect for the architecture. Which architecture is this? |
I should have said We could re-introduce C code for the syscall in something like @zegelin Do you know how to query for the USER_HZ value in solaris? |
|
Oh, now I see the issue I guess. From the perspective of the program running in the LX zone, the OS will be Linux. I'm very hesitant of introducing a C dependency just for that exception. @zegelin Does LX provide any hint about the environment we could query for without a systemcall? |
x86_64 @grobie
There is a sysctl that returns: LX emulates
|
UDP sockets have a state too
Running node_exporter inside a LX zone on Joyent's SmartOS (or their cloud platform, Triton) reports incorrect CPU stats.
SmartOS is based on Solaris, and LX zones are containers that enable running Linux application on Solaris.
LX zones report a
USER_HZ
value of 1000, which results in incorrect CPU stats being reported.While it may be argued that SmartOS is incorrectly emulating the USER_HZ value (aka, it should report 100), I feel that procfs should query the value rather than have a hard-coded value to maintain compatibility across multiple platforms.
(And yes, I know that procfs did originally query for the value, but it was replaced with a constant for "reasons")
The text was updated successfully, but these errors were encountered: