mmdbctl icon indicating copy to clipboard operation
mmdbctl copied to clipboard

Memory Issue

Open hyperxpro opened this issue 1 year ago • 5 comments

So I have been playing around with mmdbctl and I was doing simple mmdb export to json and import back to mmdb. However, the process started taking up to 46 GB of memory. Luckily my machine had plenty of memory so import was successful. However, systems with low memory may run into problems.

I did some digging into source and found that mmdbctl is holding all data into memory and writing into file at once after processing is done. Can we do buffered writing and flush incrementally to prevent huge memory usages?

https://github.com/ipinfo/mmdbctl/blob/6d422a6ba3bc472ca1c525eb95afa7fa56b46270/lib/cmd_import.go#L453

Task Manager:

Screenshot 2024-02-08 161631

MMDB file used: GeoLite2-City.mmdb

hyperxpro avatar Feb 08 '24 17:02 hyperxpro

@hyperxpro mmdbctl uses the underlying mmdb-writer library for creating the actual MMDB, which doesn't support incremental writes. The MMDB format itself isn't very friendly to incremental writes, which is the root of the problem. It's probably not impossible, but it'd be a really complex and sensitive algorithm using partial files to help deal with the memory growth (similar to a large-scale merge-sort solution).

In practice, almost anyone producing a big enough MMDB file ends up having large RAM machines to do it, which is cheap these days, so little effort has been invested into optimizing that.

It could be something we do!

UmanShahzad avatar Feb 08 '24 17:02 UmanShahzad

Can we not write N bytes into the file and flush and increase offset and repeat the process? I am not sure if it is entirely possible like this but, is there any workaround we can do at the I/O level to fix this?

hyperxpro avatar Feb 08 '24 17:02 hyperxpro

@hyperxpro unfortunately, the memory and I/O model for MMDBs, and the relationship between them, is more complex than that.

See https://maxmind.github.io/MaxMind-DB for the actual MMDB spec

UmanShahzad avatar Feb 08 '24 17:02 UmanShahzad

For reference in my custom mmdb, it takes around 800G of ram and many hours to compile from an optimized ip_trie that takes a fraction of the time and memory to build and is threadsafe. From my shallow dive into it, a large part of it is the fact that the mmdb writer library uses reflection all over the place since it was written before real generics were part of the language.

jhg03a avatar Feb 09 '24 15:02 jhg03a

Hitting the same problem here, doing the same thing. MMDB->JSON->MMDB. JSON file has ~15m routes/prefixes. Un-possible thus far on any of the systems we have here (512G is max) to turn back into MMDB.

johnhtodd avatar Aug 01 '24 23:08 johnhtodd