Skip to content
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

server: catch incomplete available memory detection by gosigar #15841

Merged
merged 1 commit into from
May 12, 2017

Conversation

knz
Copy link
Contributor

@knz knz commented May 10, 2017

If gosigar is told by a syscall there is 0 available memory, consider
this information as false even if there was no error.

Fixes #15839.

@knz knz requested a review from tamird May 10, 2017 12:15
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@knz knz force-pushed the check-gosigar-mem branch from c956ada to 09e9f33 Compare May 10, 2017 12:16
@@ -237,6 +237,12 @@ func GetTotalMemory() (int64, error) {
humanize.IBytes(mem.Total), humanize.Bytes(math.MaxInt64))
}
totalMem := int64(mem.Total)
checkTotal := func(x int64) error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: consider making the signature here (int64, error). That way you can hold up the usual convention (that you return zero when there's an error) more explicitly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh good idea. Done.

@knz knz force-pushed the check-gosigar-mem branch from 09e9f33 to 37e7024 Compare May 10, 2017 12:28
}
if cgAvlMem > mem.Total {
if mem.Total > 0 && cgAvlMem > mem.Total {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mem.Total is (intuitively, not by type) equal to totalMem, right? I think it would add to clarity if mem went out of scope after totalMem was a thing (even at the cost of a type conversion). Just a suggestion, might be misreading this as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes the code slightly more readable perhaps. I changed it as you suggested.

@knz knz force-pushed the check-gosigar-mem branch from 37e7024 to 77b8830 Compare May 10, 2017 12:35
Copy link
Member

@tbg tbg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry to have so many nits for such a small change - you're still free to opt out.

}
if cgAvlMem > mem.Total {
if totalMem > 0 && int64(cgAvlMem) > totalMem {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like we could overflow cgAvlMem here and in l. 284 during the conversion?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah nevermind! You check above.

}
var cgAvlMem uint64
if cgAvlMem, err = strconv.ParseUint(strings.TrimSpace(string(buf)), 10, 64); err != nil {
if log.V(1) {
log.Infof(context.TODO(), "can't parse available memory from cgroups (%s), using system memory %s instead", err,
humanizeutil.IBytes(totalMem))
}
return totalMem, nil
return checkTotal(totalMem)
}
if cgAvlMem > math.MaxInt64 {
if log.V(1) {
log.Infof(context.TODO(), "available memory from cgroups is too large and unsupported %s using system memory %s instead",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this sentence would look weird because cgAvlMem pops up randomly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean "looks weird"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the first %s is outside of the flow of the sentence. It would look better in parentheses, or moved up to read "available memory %s from cgroups is too large, ...". Still only a nit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh now I understand. Thanks for clarifying. Done.

@tamird
Copy link
Contributor

tamird commented May 10, 2017 via email

@knz
Copy link
Contributor Author

knz commented May 10, 2017

@tamird yes elastic/gosigar#72

@benesch
Copy link
Contributor

benesch commented May 10, 2017

FWIW I wasn't encountering this on my OpenBSD VM. I'm going to do some more digging when I have some spare time. 👍 in the meantime.

@knz
Copy link
Contributor Author

knz commented May 10, 2017

@benesch perhaps the syscall(s) used in gosigar is sensitive to some configuration, which the gosigar openbsd support's author didn't take into account. If I were you I'd make an inventory of the syscalls in sigar_openbsd.go and read the man pages thoroughly.

@knz knz force-pushed the check-gosigar-mem branch from 77b8830 to 20826c3 Compare May 10, 2017 14:04
@tamird
Copy link
Contributor

tamird commented May 11, 2017

LGTM but we should like to the upstream issue since we don't want to keep this extra layer of paranoia on top of gosigar forever.

Thanks for fixing! Please consider nominating for 1.0.1.


Reviewed 1 of 1 files at r4.
Review status: all files reviewed at latest revision, 5 unresolved discussions, all commit checks successful.


pkg/server/config.go, line 284 at r4 (raw file):

			return checkTotal(totalMem)
		}
		totalMem = int64(cgAvlMem)

why not return checkTotal(..) in keeping with convention elsewhere?


Comments from Reviewable

If gosigar is told by a syscall there is 0 available memory, consider
this information as false even if there was no error.

Upstream issue: elastic/gosigar#72
@knz knz force-pushed the check-gosigar-mem branch from 20826c3 to f161689 Compare May 12, 2017 17:08
@knz
Copy link
Contributor Author

knz commented May 12, 2017

I have linked the upstream issue. TFYR!


Review status: all files reviewed at latest revision, 5 unresolved discussions, all commit checks successful.


pkg/server/config.go, line 284 at r4 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

why not return checkTotal(..) in keeping with convention elsewhere?

Done.


Comments from Reviewable

@knz knz added the 1.0.1 label May 12, 2017
@knz knz merged commit be5890c into cockroachdb:master May 12, 2017
@knz knz deleted the check-gosigar-mem branch May 12, 2017 17:35
@tamird
Copy link
Contributor

tamird commented May 12, 2017

Reviewed 1 of 1 files at r5.
Review status: all files reviewed at latest revision, 4 unresolved discussions, all commit checks successful.


Comments from Reviewable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants