When I tried to load the crawling data to the dgraph by using raw http, I got a OOM problem.
Even if I increased my docker instance memory to 8GB and ran dgraph server with “–memory_mb 2048”, I got a same problem.
Is there any way to limit the dgraph server memory usage??
The below image is the screenshot before the dgraph server died by the OOM killer.
Since I used a raw HTTP request likes below, I’d guess that there was another reason for the OOM.
// I used OkHttp java library and dgraph version is v0.9.0
Request request = new Request.Builder()
.url(mutateUrl)
.header("X-Dgraph-CommitNow", "true")
.post(requestBody)
.build();
Response response = client.newCall(request).execute();
...
response.close()
After visited the dgraph4j github repository, I found that the java client is officially supported at the maven.
I’ll try to use it. Thank you.
Even if I used the dgraph4j client, I found that the dgraph server took memory more that I specified.
I ran dgraph server with “–memory_mb 2048” and it currently uses 8GB memory.
I’m sorry to ask how can I get a heap profile and out of /debug/vars.
Could you give me a guide for it?? (For example, command on the mac or command inside the docker instance)
I could not find /debug/vars path in my docker instance.
I have run dgraph by using the docker on my mac book.
My mutation task is still running without error, but the memory usage is increasing steadily.
I’m not sure the exact the mutation count. I guess that it may be 150,000 * 30 = 4,500,000.
Since I’m not familiar with ‘go tool pprof’, I can not be sure that the resulting file is correct.
If you’ll find any fault above files, please notice to me. I’ll try again. Thank you.
@hyunseok: Thanks for providing the info. Can you please try the same on latest nightly build.
There was a bug in lru eviction which has been fixed in master.
With the latest nightly build, I found that the dgraph used near 4GB memory.
I think that it is a reasonable memory usage when I ran the dgraph with “–memory_mb 2048”.