# Recommended RAM to bulk load 200M RDF entries to avoid OOM **URL:** \ **Category:** Dgraph\ **Created:** [May 7, 2020, 8:37am UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634 "2020-05-07T08:37:47Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![geoyws](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/geoyws/32/2627_2.png) [@geoyws](https://discuss.dgraph.io/u/geoyws)\ **Post date:** [May 7, 2020, 8:37am UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/1 "2020-05-07T08:37:47Z")
Edit: Apologies, after checking the successful load, I realized that I’ve loaded 1B nquads and 1.6B edges. I thought it was 200M+ RDF entries, but it was actually the equivalent of 200M+ RDBMS row entries translated into RDF, so it came to about 1B RDF entries I think. Perhaps that was why the RAM was necessary. Everything loaded in 48mins, without ludicrous mode, 16 vCPU 128GB RAM Intel Cascade Lake on Huawei Cloud. ![Screenshot 2020-05-08 at 11.36.44 AM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/7/7be97ecf70da77ea36594a6de0eb6ac9b08add4a.png) ![Screenshot 2020-05-08 at 11.34.08 AM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/e/ed0c262a3d167c7b0db8f44d0f41d4ab6ea818c6.png) ![Screenshot 2020-05-08 at 11.20.13 AM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/8/898015704054ddaf2f2638bfd90e14c4029e2e04.png) Original: I’m doing a benchmark for management and they’re requesting we do a simple load test on a 2vCPU 4GB RAM server. I load 200 .rdf files (each with 1M records) containing a total of 200M+ entries via bulk loader (–ludicrous\_mode seems to make a small difference here) and Dgraph consistently runs out of memory at the 14th .rdf file. It takes about 40-50s per file. Alpha’s lru\_mb is at 2048 to be safe. Postgres and MSSQL managed to load the 200M+ records with the same CPU and RAM constraints in about 2-3 hours. ---
**Author:** ![geoyws](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/geoyws/32/2627_2.png) [@geoyws](https://discuss.dgraph.io/u/geoyws)\ **Post date:** [May 7, 2020, 10:10am UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/2 "2020-05-07T10:10:56Z")
I’ve provisioned a server with 4vCPUs and 16GB RAM. Memory usage seems to be climbing with no end in sight at 9GB/16GB used at only the 33rd .rdf file. Takes about 30-40s per file. Not using ludicrous\_mode. If it OOMs again, perhaps I’ll use the Live loader instead. ☹ ---
**Author:** ![ashishgoswami](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/ashishgoswami/32/3416_2.png) [@ashishgoswami](https://discuss.dgraph.io/u/ashishgoswami)\ **Post date:** [May 7, 2020, 11:16am UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/3 "2020-05-07T11:16:43Z")
Hi @geoyws, please try bulk loader without ludicrous mode as well. ---
**Author:** ![geoyws](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/geoyws/32/2627_2.png) [@geoyws](https://discuss.dgraph.io/u/geoyws)\ **Post date:** [May 7, 2020, 1:02pm UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/4 "2020-05-07T13:02:46Z")
@ashishgoswami yup currently running without ludicrous mode The 4vCPU 16GB RAM VM went OOM after 110 .rdf files (1 million RDF entries each). **(Edit: Actually ~5M RDF entries each)** ![Screenshot 2020-05-07 at 3.50.47 PM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/4/43203048641a17b19f8da5b019c2b6c2cb26f01d.png) ![Screenshot 2020-05-07 at 7.20.03 PM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/7/7f16fd83baabc787f7af08c6961eee9a4d7d77ec.png) ![Screenshot 2020-05-07 at 6.23.35 PM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/2/2c360c35e50d2e5f5b9d1c00a435d71e110f4a94.png) So I’ve gone with a 8 vCPU 32GB RAM VM. If that OOMs, will go with the 64GB RAM VM next. Update: OOM again. ![Screenshot 2020-05-07 at 8.58.16 PM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/3/399e71d0a725d032e05e64441659e16546e70f74.png) ![Screenshot 2020-05-07 at 11.01.34 PM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/a/acfc7295df7c1ccc62c801300f568e2935506e86.png) ![Screenshot 2020-05-07 at 11.01.59 PM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/e/e08ca1d27e15f536addf17c4e50f46248e691114.png) Going with the 64GB RAM now. ---
**Author:** ![dereksfoster99](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/dereksfoster99/32/2886_2.png) [@dereksfoster99](https://discuss.dgraph.io/u/dereksfoster99)\ **Post date:** [May 7, 2020, 5:33pm UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/5 "2020-05-07T17:33:28Z")
Hi @geoyws Would you like to have a quick call with one of our engineers to try and figure out this issue? Please let me know. We’d be happy to help. ---
**Author:** ![geoyws](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/geoyws/32/2627_2.png) [@geoyws](https://discuss.dgraph.io/u/geoyws)\ **Post date:** [May 8, 2020, 3:45am UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/6 "2020-05-08T03:45:03Z")
@dereksfoster99 Sure, when would be a good time? In short, I repeated the same process with a VM image on a 64GB RAM VM and it still went OOM. The 128GB RAM VM however managed to do it. 1B nquads and 1.6B edges in 48mins without ludicrous mode, 16 vCPU 128GB RAM Intel Cascade Lake on Huawei Cloud. ![Screenshot 2020-05-08 at 11.36.44 AM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/7/7be97ecf70da77ea36594a6de0eb6ac9b08add4a.png) ![Screenshot 2020-05-08 at 11.34.08 AM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/e/ed0c262a3d167c7b0db8f44d0f41d4ab6ea818c6.png) ![Screenshot 2020-05-08 at 11.20.13 AM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/8/898015704054ddaf2f2638bfd90e14c4029e2e04.png) ---
**Author:** ![dereksfoster99](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/dereksfoster99/32/2886_2.png) [@dereksfoster99](https://discuss.dgraph.io/u/dereksfoster99)\ **Post date:** [May 8, 2020, 4:00am UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/7 "2020-05-08T04:00:13Z")
@geoyws How about Monday afternoon? We’re on Pacific time. ---
**Author:** ![geoyws](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/geoyws/32/2627_2.png) [@geoyws](https://discuss.dgraph.io/u/geoyws)\ **Post date:** [May 8, 2020, 4:42am UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/8 "2020-05-08T04:42:16Z")
Appreciate the help. We’re in Kuala Lumpur at UTC +8, so that means at Monday 12pm Pacific Time it would be Monday 3am UTC +8 in KL. Could we somehow do it either 9am PT or perhaps 3pm PT? ---
**Author:** ![mrjn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mrjn/32/775_2.png) [@mrjn](https://discuss.dgraph.io/u/mrjn)\ **Post date:** [September 7, 2020, 1:35am UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/9 "2020-09-07T01:35:40Z")
This commit should fix the issue: [perf: Various optimizations to the bulk loader (#6412) · dgraph-io/dgraph@9109186 · GitHub](https://github.com/dgraph-io/dgraph/commit/9109186e0963a61e54f41c6755f778361fbe8b98) If you compile from master, do send the build tag “jemalloc”, would require jemalloc to have been installed with `je_` prefix. We’ll be updating our Makefile to automatically do this. ---
**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\ **Post date:** [September 8, 2020, 3:51am UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/10 "2020-09-08T03:51:47Z")
Will any of these improvements also help reduce OOM in live loader? Or reduce memory consumption of a running machine? ---
**Author:** ![mrjn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mrjn/32/775_2.png) [@mrjn](https://discuss.dgraph.io/u/mrjn)\ **Post date:** [September 8, 2020, 3:03pm UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/11 "2020-09-08T15:03:46Z")
Not yet. But, I’ve just asked the team to replicate those live loader OOM issues, so we can fix those. If you have a way to replicate them, do let us know. ---
**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\ **Post date:** [September 8, 2020, 5:38pm UTC](https://discuss.dgraph.io/t/recommended-ram-to-bulk-load-200m-rdf-entries-to-avoid-oom/6634/12 "2020-09-08T17:38:38Z")
Just throw ~6 million quads at a 4Gb RAM dgraph instance. That should make it go OOM. I hqven’t troed lately.