ligi
commented
5 years ago Do you have an RPC port exposed to the public?
Closed mmcc1 closed 5 years ago
ligi
commented
5 years ago Do you have an RPC port exposed to the public?
mmcc1
commented
5 years ago Its just the default settings. So, perhaps. Are you suggesting that this is a denial of service attack?
ligi
commented
5 years ago yes this was my thinking - a lot of memory problems resulting from an open RPC and a lot of requests. But if you run on default settings this should not be the case.
mmcc1
commented
5 years ago I am running with this command and I have tried removing syncmode and cache. Same result each time. 5 minutes then a crash.
geth --rinkeby --rpc --rpcapi="personal,eth,network,web3,net" --ipcpath "~/AppData/Roaming/Ethereum/geth.ipc" --syncmode "fast" --cache 2048
As far as I can see, its a 32 bit exe and its size is increasing. It looks like a memory leak to me.
ligi
commented
5 years ago but wait - then you are exposing rpc with personal. Does this machine have a public IP?
mmcc1
commented
5 years ago Yes, it is on the web. Any logs I could look at?
mmcc1
commented
5 years ago How do I disable listening on public IP addresses? I'm happy enough with loopback. I can test that and see if it resolves the problem.
ligi
commented
5 years ago can you elaborate on your use-case? Shouldn't IPC be enough?
mmcc1
commented
5 years ago I haven't been able to get IPC to work. I used RPC on the loopback instead. I'm behind a NAT and I haven't setup any external ports, however, I do see my external IP address listed as the program starts.
ligi
commented
5 years ago ok if it is not exposed it should not be the problem. Just making sure as it is often the problem. perhaps @fjl has some ideas - seeing a lot of p2p stuff in the stacktrace.
mmcc1
commented
5 years ago As I am syncing to the rinkeby network, I have had an opportunity to restart Geth about hundred times now. An interesting pattern is that the closer Geth gets to completing its sync, the faster out of memory errors are produced.
karalabe
commented
5 years ago Hmm, a 32 bit Windows binary can only ever use 3GB of ram. Why are you using a 32 bit binary on a machine with 32GB of RAM? Please use the 64 bit ones.
mmcc1
commented
5 years ago I will try. I think the only installer packages are 32 bit.
karalabe
commented
5 years ago Ah, that's an issue with the downloads page. We have so many binaries, that listing them from azure returns multiple pages and we only process the first page. Will need that fixed. Sorry about that.
Here's a latest Windows 64 bit installer https://gethstore.blob.core.windows.net/builds/geth-windows-amd64-1.8.22-7fa3509e.exe
mmcc1
commented
5 years ago I've tried the 64 bit version and so far running without issue. I'll run it overnight and see how it goes.
ligi
commented
5 years ago Great! I think we can close this issue then - @karalabe opened a follow up issue here #19042 Feel free to reopen if you run into OOM with the 64bit version
When attempting to sync for the first time with the rinkeby network, 1.8.22-stable keeps crashing every 3-5 minutes with the below error.
This is on a machine with 32GB RAM and 60-80% resources free.
System information
Geth version:
geth versionGeth Version: 1.8.22-stable Git Commit: 7fa3509e2eaf1a4ebc12344590e5699406690f15 Architecture: 386 Protocol Versions: [63 62] Network Id: 1 Go Version: go1.11.5 Operating System: windows GOPATH= GOROOT=C:\go
Expected behaviour
Should sync without crashing
Actual behaviour
Crashes every 5-10 minutes. Seems like a memory leak.
Steps to reproduce the behaviour
Default install, run the following command:
geth --rinkeby --rpc --rpcapi="personal,eth,network,web3,net" --ipcpath "~/AppData/Roaming/Ethereum/geth.ipc" --syncmode "fast" --cache 2048
Backtrace