-
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
Limits returns 64-bit max for VSS on all platforms #379
Comments
I've been digging into this a bit, and there's a bunch of issues with the current values for When we detect "unlimited" we output uint64 max. This is very wrong for 32-bit systems, and partly wrong even for 64-bit systems. For example, it depends on kernel compile flags for 32-bit systems (CONFIG_VMSPLIT_3G etc). On 64-bit, it's architecture dependent, and kernel version dependent.
I'm considering reverting the patch, or changing it to return nil in the case of "unlimited". I'm also wondering what to do in the unlimited case in client_golang. When ulimit is unlimited I have found no way to determine what the value should be. |
How about |
Yea, +Inf is also an option. The down side is it's also not exactly true, since the real value is there. Perhaps we should not expose the metric in client_golang if the value is +Inf. |
The function currently returns a uint64, so there's no |
How many fields in the We could document in the help string of the proc metrics that a Prometheus floating point value of |
Disclaimer: I might totally misunderstand the context here. (But just not exposing a metric sounds weird.) |
The problem is that "unlimited" doesn't actually mean the value in bytes is "+Inf". There are hard limits imposed by the platform and kernel, and configuration combinations. This is mostly not an issue on 64-bit platforms, but can be very limiting on 32-bit. So, exposing the value as +Inf is not true. |
I got that. That's why I said it has to be documented. However, if I understand you correctly, it's highly non-trivial to find out what the true value is if what we get is Not exposing the metric means the metric doesn't exist. It does not communicate "The value is reported as However, we could document that a value of |
Of course, if there is a way to find out the true value, then let's just use it. |
In #340 we fixed the Limits value for "unlimited" to be max uint64. But this value would be incorrect for 32-bit systems, and could depend on kernel/user VM split configuration.
Now I'm also wondering if it's actually valid that 64-bits is the right value for VSS max for Intel 64bit, given there is still probably some kernel reserved address space in 64-bit mode.
The text was updated successfully, but these errors were encountered: