kubo, an IPFS server, has defaults set for it to run in an aggressive resource-use mode. I’m using it only because it’s a requirement of brig, a file synchronization tool I’m testing to sync files between my laptop and a desktop. With defaults, the ipfs daemon sits at the top of my CPU and memory use unless I’m doing development and running more demanding processes. It can be made to be more well-behaved with some configuration. These are:

  • flatfs (profile)
  • local-discovery (profile)
  • lowpower (profile)
  • –enable-pubsub-experiment
  • –routing=dhtclient
  • –enable-gc

I have not tested each of these independently, so it’s possible some of them are not necessary. Some were suggestions from the web, and some were things in man pages that just looked good to me. The end result is that now ipfs has dropped from 3%/30% (avg/peak) to 0.9%/x (no peaks noticed). Memory use seems to hover around 150MB on my machine, with no content added or pinned, which seems acceptable.

To achieve this, I ran this sequence:

ipfs init -p flatfs
ipfs config profile apply local-discovery
ipfs config profile apply lowpower
ipfs daemon --enable-pubsub-experiment --routing=dhtclient --enable-gc

I also had to set ipfs config Addresses.Gateway /ip4/, because 8080 is a hotly contested port. I added local-discovery because of my use case: I’m not serving up content to a wider network. I’m only sharing data between two computers when they’re on the same intranet.

I run lowpower on both nodes because of the implication of the naming: the alternative to “lowpower” is something that is power spendthrift, which seems irresponsible.

The man page for flatfs talks about lowing memory use, which implies less caching (and so a performance hit).

The defaults feel as if they’re tuned for primarily server nodes designed to host content for wider distribution, and on beefier, dedicated servers. As a backbone for individual services – data sync systems like Brig, or chat clients like Berty – more modest resource tuning is more appropriate.