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

Memory could be down #43133

Closed
zgb40302 opened this issue Dec 11, 2020 · 1 comment
Closed

Memory could be down #43133

zgb40302 opened this issue Dec 11, 2020 · 1 comment

Comments

@zgb40302
Copy link

What version of gRPC are you using?
v1.32.0

What version of Go are you using (go version)?
1.14

What operating system (Linux, Windows, …) and version?
linux (kernel 3.10)

What did you do?

client (lua http/json) ----------> server(go grpc) ---------> index ( brpc)

because the delay of index is long , so, the tcp buffer between server and index is full ,then the requests from server to index is timeout , at the time the memory of server keeps rising。
when server start , ps result: 35513 root 20 0 1692384 431464 12128 S 203.3 0.7 59:48.71 webapp
when server timeout, ps result: 35513 root 20 0 5835044 4.3g 12164 S 21.1 6.9 111:56.14 webapp

then , I stop the client and index , the pprof result of server:
image
but the RSS of server still 4.3g ,and wait for 8 hours ,it is still 4.3g.

I close the hugepage option , reproduce it , the memory could be still not down.
echo 'never' > /sys/kernel/mm/transparent_hugepage/enabled
echo 'never' > /sys/kernel/mm/transparent_hugepage/defrag

so , who know why could the memory of RSS not down, and it is normal ?

thanks!

@mdlayher
Copy link
Member

Please see https://github.com/golang/go/wiki/Questions. Closing.

@golang golang locked and limited conversation to collaborators Dec 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants