This repository has been archived by the owner on Jun 16, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
jstorm 获取系统(linux)获取可用内存应该使用/proc/meminfo中的MemAvailable #427
Open
superwood
wants to merge
3
commits into
alibaba:master
Choose a base branch
from
superwood:GetMemAvailable
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
longdafeng
reviewed
Feb 10, 2017
String free = lines.get(2).split("\\s+")[1]; | ||
return Long.valueOf(free); | ||
} catch (Exception ignored) { | ||
LOG.warn("failed to get total free memory."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@superwood , 切换到available memory 没有什么问题,
但这里有个兼容性的问题, 如果os 不带“MemAvailable”时,需要额外增加一个逻辑,回退到getFreeMemory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@longdafeng 没问题,可以在代码里面做一个兼容。 稍后重新提交下。
@longdafeng 另外即使是回退到老的版本使用 MemFree: 602996 kB 去计算空闲内存也是有问题的。 理论上用 MemFree + Cached -Shmem 更加准确点。 |
unsleepy22
reviewed
Mar 4, 2017
|
||
List<String> lines = IOUtils.readLines(new FileInputStream(PROCFS_MEMINFO)); | ||
String free = lines.get(2).split("\\s+")[1]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
这里的逻辑,我觉得应该反过来,默认使用mem free,当存在MemAvailable的时候才用这个。
另外,默认的情况下,需要考虑mem free + cache
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
3.14 版本后 在/proc/meminfo文件中新增了一个选项
MemTotal: 7662552 kB
MemFree: 602996 kB
MemAvailable: 6005852 kB
应该只用MemAvailable去计算系统的free内存比较合理。
MemAvailable的意义如下:
Many load balancing and workload placing programs check /proc/meminfo to estimate how much free memory is available. They generally do this by adding up "free" and "cached", which was fine ten years ago, but is pretty much guaranteed to be wrong today.
It is wrong because Cached includes memory that is not freeable as page cache, for example shared memory segments, tmpfs, and ramfs, and it does not include reclaimable slab memory, which can take up a large fraction of system memory on mostly idle systems with lots of files.Currently, the amount of memory that is available for a new workload,without pushing the system into swap, can be estimated from MemFree, Active(file), Inactive(file), and SReclaimable, as well as the "low"watermarks from /proc/zoneinfo.However, this may change in the future, and user space really should not be expected to know kernel internals to come up with an estimate for the amount of free memory.It is more convenient to provide such an estimate in /proc/meminfo. If things change in the future, we only have to change it in one place