When geth process consumes too much memory it gets killed (not at all gracefully) by Digital Ocean.

Partly solved the problem by implementing swap - Setting up geth Ethereum node to run automatically on Ubuntu. But still recieved one kill within 2 mln blocks download running geth --fast --cache=16.

Similar question: Is it possible to decrease RAM usage of go-ethereum(geth)? The answer here is - NO.

Is there a way to limit geth memory usage or maybe kill it "more gracefully" than Digital Ocean with something like monit?

3 Answers 3


It seems like 2 Gigs of swap and swappiness 30 is enough to run geth with no crashes with just 512 Mb of RAM.

It is almost 2 months now. I'm in full sync (block 3097083). And had no crashes ever. So I'm marking this answer as the right one.

I'm also monitoring geth with monit which will restart geth if it crashes.

My config in detail is here - How to run geth at 512Mb RAM Digital Ocean droplet

  • You are mining solo, without any mining pool in a simple droplet. So just wanted to know like how much time will it take to mine a single ether? Commented Feb 4, 2018 at 11:56
  • @DipenDedania i'm not mining. I'm just keeping the blockchain in sync.
    – takeshi
    Commented Feb 5, 2018 at 6:42
  • @takeshi what is the minimum hardware to accomplish something similar in 2024? thanks
    – elier
    Commented Jan 28 at 16:23
  • 1
    @elier heh. Now it requires a bit more power)) geth.ethereum.org/docs/getting-started/hardware-requirements
    – takeshi
    Commented Mar 14 at 7:19

With that limited of resources your best bet is to run in light client mode. Yes it is in alpha but is very usable as long as your just playing around with it, and not using large sums.

Depending on your processor you may also have issues creating accounts on server, if so then also add --lightkdf, this will allow a less taxing method(although probably slighltly less secure) so that your server can complete the wallet creation process before the hard coded timeout threshhold.

$geth --light --lightkdf

We are successfully running the light client on a BeagleBone Black, which also has only 512mb ram, without issue.

Lastly here are some numbers I collected on a Raspberry Pi3 regarding geth light client resource usage as of th release available on Sept 12, 2016:

  • geth binary: 25MB
  • chain data: 54.9MB
  • cpu: 12%
  • ram: 162MB
  • header sync: 9min

Running it on such a low amount of RAM might be tricky. I know the devs have made attempts to reduce RAM usage so it could run on Raspberry PI, but even that has 1GB of RAM.

In addition to making a large swap file, you might want to try RAM compression. This might help on a VPS that has ample CPU power, but restricted RAM resources. On Ubuntu you can just run the command sudo apt-get install zram-config and it will install and configure it. To confirm it is running run the command sudo cat /proc/swaps and you should see something like this:

Filename                                Type            Size    Used    Priority
/dev/sda4                               partition       2095280 0       -1
/dev/zram0                              partition       507596  65800   5
/dev/zram1                              partition       507596  65728   5

To have Ethereum autolaunch and restart, on Ubuntu I would recommend using Systemd. Just edit the config below and drop it into the file /lib/systemd/system/geth.service:

Description=Ethereum Go client

ExecStart=/usr/bin/geth --lightserv 25 --lightpeers 50


The Systemd config above specifies that the client runs as a light server as the user ethereum. You should edit this config as needed.

Then run the command sudo systemctl enable geth to enable autolaunch on boot. Use the following commands to start, stop, and check the status:

  • sudo systemctl start geth
  • sudo systemctl stop geth
  • sudo systemctl status geth

If you keep experiencing problems, I would suggest you try out the experimental light client. It is designed for lower power systems and has a much lower RAM and HDD burden

ExecStart=/usr/bin/geth --light

  • 1
    Thank you very much for your answer! I'm already using monit to monitor geth process and auto-restart it if needed. I'm also using swap 1G with swapiness = 30. Now I'm at full sync and had only one crash with geth --fast --cache=16. I'm a bit afraid to use RAM compression as my CPU is already 20-30%. And I'm looking forward to see light client release. Still hope to find a better solution.
    – takeshi
    Commented Dec 13, 2016 at 7:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.