go-ethereum systemd config

geth.service

[Unit]
Description=go-ethereum node
After=network.target

[Service]
Type=simple
User=geth
Group=geth
## ===== initial sync: no light peers, please =====
ExecStart=/usr/bin/geth --nousb --datadir /home/geth/.ethereum --cache 2048 --txpool.pricelimit 99999999999 --txpool.globalslots 1024
## ============ full nodes' monitoring ============
#ExecStart=/usr/bin/geth --nousb --datadir /home/geth/.ethereum --cache 2048 --txpool.pricelimit 1000000000 --txpool.globalslots 2048 --txpool.accountslots 2 --txpool.accountqueue 2 --maxpeers 1000
## ================ live LES mode =================
#ExecStart=/usr/bin/geth --nousb --datadir /home/geth/.ethereum --cache 2048 --txpool.pricelimit 1000000000 --txpool.globalslots 2048 --txpool.accountslots 2 --txpool.accountqueue 2 --lightserv 50 --lightpeers 775 --maxpeers 800
## =============== debug LES mode =================
#ExecStart=/usr/bin/geth --nousb --datadir /home/geth/.ethereum --cache 2048 --txpool.pricelimit 1000000000 --txpool.globalslots 2048 --txpool.accountslots 2 --txpool.accountqueue 2 --lightserv 50 --lightpeers 3000 --maxpeers 3025 --vmodule "downloader=4"
## restart options
#KillSignal=SIGINT
TimeoutStopSec=120
Restart=on-failure

[Install]
WantedBy=multi-user.target

How big a machine you run this on? any cpu/bandwidth issues serving 975 lightpeers?

FTR, this is currently running on a KVM VPS:

• 4 vCores (2.6GHz, 4MiB cache);
• 8 GiB RAM + 2 GiB swap;
• 160 GiB SSD (top actual usage of 800 IOPS with 40% iowait);
• 100 Mbps connection;
• just missed the window to see how much in/out traffic is consumed per month; on the order of 4 TiB, maybe?..

I've dropped the current limit to 775 light peers (of which ~ 500 are used, due to how geth reserves slots); will edit the file shortly.

The bottleneck for this machine is not the hardware, but the interplay of geth's implementation specifics, and network conditions (of which other geth nodes make a sizeable portion, running with the same peer selection mechanism, but without the additional load of hundreds of peers to send block headers to).

Raising the LES peer count, the node eventually becomes just slow enough (in ping-pong round-trip terms) to be dropped by fast fully-verifying peers; at which point it starts falling behind the chain head, and doesn't seem to recover easily.

Also, the more LES clients you allow, the higher the chance you'll peer with those that haven't seen a lightserv in a while, which requires a bigger set of block headers to be transferred (for them to catch up). This does make a spike in bandwidth use, possibly saturating it for a short while. Sometimes, that's enough to be dropped as a "useless peer".

To clarify: CPU usage does not hit the "hard" hardware limit of 100% utilisation, just about never; but maybe improving some specs would allow serving more light clients, without being dropped by other full nodes. I don't know as I haven't tried: this machine is about as high as I can go ATM without burning a hole in my pocket.

Oh, also: this is on the ETH main-net; on Ropsten, the same .service works pretty well on a much lower-spec machine, because the "~ 500" light client limit is never even reached, there's a lot less transactions, the chain state is smaller, etc..