Can't start - out of memory? #26
Comments
|
The current database size is 1.2GB |
|
I fixed this by going into C;/Users/youruser/.factom and taking a copy of factoid_wallet_bolt & factoid_bolt (Bolt is the important one) and deleting the entire .factom file from the user directory. Re running factomd and waiting for it to re sync (.factom will be approx 4gb when synced) - put your factoid_bolt and wallet .dat back into the directory and open factom walletapp and should be all good - Out of memory issues can be a number of things. dont forget to backup the entire .factom directory just in case!!! |
|
is this on windows or linux? Here is another issue that might have been a similar problems. We haven't gotten a lot of testing on these new binaries and would like to know if these work for you. 512mb might not be enough for factomd. |
|
@carryforward Linux. I'm in the process of testing out 12 different blockchain products, mostly the biggest-name ones, and so far haven't found one where memory was a problem. But none of those other ones are based on Go (AFAIK), so maybe that makes all the difference |
|
@tdkmatt I will try this, thanks |
|
Here are some experimental linux 64 bit + golang v1.7 binaries: 36d31827b552412e925f035ee04b6aa8e506e5a41bd00bada8789b8757736919 factom-cli fa100ff6c569f77dffa5be82978b090a6fb1d4b33ff355abef5c71fd443b8a6b linux64_1.7.zip We have been distributing with i386 compiled binaries. Also, golang 1.7 is advertised to have fixed some memory errors. To do development and evaluation, you might not want to start with the full blockchain (4.4 GB). Here are directions on how to setup a local testnet. Keep in mind that factom will be going through a hard fork in the near future (Factom Genesis -> Factom Federation AKA m1->m2). It also involves a complete redesign of how the clients work. It will have instant (round trip latency) acknowledgements from the system authorities. Also, the memory overhead is significantly lower with the next generation of code. 512 MB of system RAM may not be enough though, even with the next version. |
|
I'm quite sure the Go 1.6 memory allocation issue is limited to Windows, possibly just newer versions of windows. In my experience Linux is able to handle the stack, even on restricted (1GB RAM) virtual machines running factomd. That said, 512MB is tiny, current RaspberryPi's ship with more RAM. |
|
Hahaha, Digital Ocean $5/month is 512 😌 On Friday, 7 October 2016, Mitchell notifications@github.com wrote:
Marc Beaupré-Pham |
|
Sorry I didn't realise it was a cloud server. Consider running your own if possible, it's usually much cheaper! |
|
I have a similar problem with ubuntu. factomd worked well three days ago. It, however, generates "out of memory" trouble since yesterday. I updated golang to 1.7, but the result was same as before. Should I modify some factom configuration files, too? hiron a@s:~$ factomd 'factomd initializeonly' will do just that. Initialize and stop.
10:41:07 2016-10-21 [WRN] BTCD: open /home/USER/.factom/NONE.conf: no such file or directory (*wire.ShaHash)(0x41cd37a0)((len=32 cap=32) cbd3d09db6defdc25dfc7d57f3479b339a077183cd67022e6d1ef6c041522b40) 10:41:21 2016-10-21 [INF] BMGR: At 59457: syncing to block height 59667 from peer 52.19.117.149:8108 untime stack: goroutine 45 [running]: ... |
|
are you building from source? it looks like you are still running the code compiled in 1.6. See the line: Go compiler version: go1.6.2 you might want to try ./factomd in the directory where you saved the experimental versions. |
|
I tried running it again on a machine with 2GB of memory and that still isn't enough |
|
If I want to try building from source, but still have it work with the existing M1 network, how do I do that? |
|
Can you confirm that you are running Go1.7? Second line should tell you the compiled version. On Wed, Oct 26, 2016 at 11:44 AM, Marc Beaupré-Pham <
|
|
I haven't yet tried compiling from source. I can make sure to try 1.7 when/if I do. I actually did get it working though, using @tdkmatt 's method |
|
please try the new installer for v 0.3.8.0 |
|
Hi, I faced with the same issue with new binaries (0.3.8.0). Log at the moment of factomd crashing: It was syncing from 67775 to 67802 block Memory usage before crashing: Any ideas? |
|
I don't think that the current m1 code works well with only 1 gb of ram. Try bumping that up until we get m2 launched. |
|
@carryforward technically the host has 1Gb of RAM + 4Gb of swap == 5Gb of RAM. Any ideas why the process didn't use the swap? |
|
@carryforward any updates on this issue? |
|
This covers M1 which has been deprecated for a few months now. |
Simply trying to run factomd
But it always crashes nearly right-away. I believe the issue is probably that the machine runs out of memory since it only has 512mb and I notice that it's using ~83% of it right before crashing (polling is slow so that might not be peak).
Any way that I can reduce memory? I noticed from another issue that changing the loglevel could help, but I tried setting it to 'critical' and that didn't work...
The text was updated successfully, but these errors were encountered: