# Current situation with garbage collection **URL:** \ **Category:** Node Operators\ **Tags:** garbage-collector, storagenode\ **Created:** [April 2, 2024, 4:47pm UTC](https://forum.storj.io/t/current-situation-with-garbage-collection/25711 "2024-04-02T16:47:47Z")\ **Posts on this page:** 1\ **Showing post:** 274
**Author:** ![Toyoo](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/toyoo/32/1126_2.png) [@Toyoo](https://forum.storj.io/u/Toyoo)\ **Post date:** [April 23, 2024, 3:38am UTC](https://forum.storj.io/t/current-situation-with-garbage-collection/25711/274 "2024-04-23T03:38:12Z")
> [@elek](#): > > First we need to generate 10Mb files. The current generator uses ~100Gb memory and requires \>5 days to be completed. We need to find out the right resource settings… So it takes some time. You’ve nerdsniped me. Please admit that this was your goal. Some sample code for computing bloom filters with negligible amount of RAM and at a fraction of time: [GitHub - liori/bloom\_filters\_for\_nodes](https://github.com/liori/bloom_filters_for_nodes/). `generator` is a sample dataset generator, and `bloomfilter` computers bloom filters. For the dataset of `us1.storj.io` size you need ~16 TB of storage, but you probably know that. Can’t guarantee it’s correct because I’m drunk. But I’ve run it on my i3-9100f and I estimate that I could generate bloom filters for [us1.storj.io](http://us1.storj.io) in 20 hours with a single CPU thread. The lousy attempts at concurrency didn’t pay off for me—just set thread\_count to 1. `i3.16xlarge` is not much faster 🤷 I/O is the bottleneck, but you probably know that. I guess I would have to get a machine like [this one](https://tanelpoder.com/posts/11m-iops-with-10-ssds-on-amd-threadripper-pro-workstation/) to actually take advantage of concurrency. Algorithm details: basic radix sort. --- _[View the full topic](https://forum.storj.io/t/current-situation-with-garbage-collection/25711)._