-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Alternative memory used by Erlang VM calculation strategy #1223
Comments
Windows is particularly problematic here because gathering certain OS level metrics currently requires an external tool to be installed. The plan is to fall back to the less precise implementation if that's not available. Also worth pointing out that we already obtain the total amount of memory in an OS-specific way (such as |
Memory reported by erlang:memory(total) is not supposed to be equal to the total size of all pages mapped to the emulator, according to http://erlang.org/doc/man/erlang.html#memory-0 erlang:memory(total) under-reports memory usage by around 20% [#1223] [#145451399]
A follow-up change for Windows: #1270. |
As discussed with @michaelklishin: We discovered that `erlang:memory(system).` can be almost as large as OsTotal when swapping is in effect. This means that total (processes + system) will be larger than the OsTotal, therefore OsTotal - ErlangTotal cannot be assumed to be non-negative. I think having some "unaccounted" memory is better than having it "accounted" as negative. re #1223 [finishes #148435813]
An update: due to what we've learned in #1343 and a few other places, as of Because existing strategy names no longer make sense with these changes, we renamed them to |
We have seen the following scenario play out many times:
This erlang-questions thread explains some of the discrepancies: the kernel and the runtime use different approaches to accounting and the kernel is blissfully unaware of whatever pre-allocation strategies a process can use.
We are proposing to use the memory as reported by the kernel in all places that
erlang:memory/0
is called. When setting{use_system_memory_reporting,1}
, we will try to use the process memory as reported by the system forvm_memory_high_watermark
, most likely via the/proc/pid
subsystem. If this is not possible, we will fallback to the current implementation.We are thinking of introducing this as an experimental feature in 3.6 and learning whether this can be a viable default in 3.7
A few related issues that could benefit from this: #993 & #965.
UPD: the option name was changed to
rabbit.vm_memory_calculation_strategy
(which can berss
orerlang
, the former is the new default, the latter is used to go to the earlier calculation strategy which is less accurate, often significantly so).The text was updated successfully, but these errors were encountered: