Node runs out of memory (4GB) with std::bad_alloc

[simon-jentzsch]

Syncing the live form 0 until block 2422715
Then it ran out of memory. (4GB AWS-Server)
After restarting he synchronized until 2423009 and then crashed

2017-02-27 16:08:54  Syncing #2422978 8aac…79bf      1 blk/s   13 tx/s   0 Mgas/s   19551+    1 Qed   #2442531    0/20/25 peers      3 GiB db    1 MiB chain   63 MiB queue    5 MiB sync
2017-02-27 16:08:59  Syncing #2422991 8a38…03d1      2 blk/s   25 tx/s   0 Mgas/s   19540+    0 Qed  
...
2017-02-27 16:12:37  Syncing #2423009 9406…d81f      0 blk/s    0 tx/s   0 Mgas/s   19519+    1 Qed   #2442531    0/15/25 peers      3 GiB db    1 MiB chain   63 MiB queue    5 MiB sync
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

The machine:

cat /proc/meminfo
MemTotal:        4046852 kB

cat /proc/version
Linux version 3.13.0-92-generic (buildd@lgw01-52) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #139-Ubuntu SMP Tue Jun 28 20:42:26 UTC 2016

parity --version
Parity
  version Parity/v1.5.4-beta-74b850e-20170223/x86_64-linux-gnu/rustc1.15.1

Trying to retart just ends with a out of memory again.

[rphmeier]

Try running with --pruning-history 64 or 128. I think it was set back to 1200 recently, which is too high for most machines to sync through the attack blocks.

[arkpar]

Also consider using --warp

[5chdn]

Please indicate whether using --warp synchronization or reducing the --pruning-history fixed your memory issues. Closing as answered.

[Corto77]

Hello
I am running parity1.6.6 from the binary releases (parity_1.6.6_armhf.deb) on a raspberry pi 3 with debian Jessie
I encounter the same problem even with --warp and --pruning-history 64 (or 128)
As the pi has not a lot of memory (1GB) I use the --cache=256 ARGS...

Starting Parity/v1.6.6-beta-8c6e3f3-20170411/arm-linux-gnu/rustc1.16.0
2017-04-22 05:41:40 State DB configuration: fast
2017-04-22 05:41:40 Operating mode: active
2017-04-22 05:41:40 Configured for Foundation using Ethash engine
.../...
Imported #3578475 6231…d042 (14 txs, 0.49 Mgas, 69.59 ms, 2.50 KiB)
2017-04-22 05:41:00 #3144177 5/ 8/25 peers 141 MiB db 12 MiB chain 0 bytes queue 6 MiB sync RPC: 0 conn, 0 req/s,
2017-04-22 05:41:35 #3146971 9/ 9/25 peers 141 MiB db 21 MiB chain 0 bytes queue 6 MiB sync RPC: 0 conn, 0 req/s,
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

sometimes it is an other error that occurs
fatal runtime error: out of memory

[Corto77]

Hi
I increased the cache from 256 to 512
parity --warp --mode active --pruning-history 128 --cache=512 --logging info
Parity is running as a service (debian jessie)

The event occurs less frequently, but it still occurs ( around each 14hours)
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

[arkpar]

@Corto77 Since your system is running out of memory you need to decrease cache size, not increase it. Try setting to 8

[Corto77]

I am surprised by your suggestion : do you suggest me to set the --cache to 8 ?
As I said, increasing the value of the cache decreases the occurrence of the error... So it seems to me that doing the opposite will make it worse...

[arkpar]

--cache specifies how much memory Parity will use for data cache. Lower values reduce memory requirements. Also consider setting --pruning-memory 32 instead of --pruning-history

[5chdn]

This issue is labelled with bug: The client fails to follow expected behavior. It's neither assigned nor linked to a milestone.

@Corto77 could you please state whether reducing cach size and pruning history solves this issue?

@paritytech/core-devs is this related to #4439? Please, decide on a deadline and assign this ticket to a developer within 7 days or close it otherwise.

[arkpar]

Memory usage reduced with #5526. 1GB should be more than enough now unless doing a full sync.

[Corto77]

hi I've tried several configurations of --cache and --pruning-history With --cache =128 the problem occurs after a little bit more than one day right now, It has been running with "--warp --mode active --pruning-history 64 --cache=64 --logging info" for 3 days without error... the top command shows that parity is using almost 50% of the memory "USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND pi 20 0 1844440 491400 4708 S 15,8 49,3 718:13.57 parity" I will send you another info in one week except if the problem occurs before... best regards Le 09/05/2017 à 13:39, Afri a écrit :

…

This issue is labelled with /bug/: The client fails to follow expected behavior. It's neither assigned nor linked to a milestone. @Corto77 <https://github.com/Corto77> could you please state whether /reducing/ cach size and pruning history solves this issue? @paritytech/core-devs <https://github.com/orgs/paritytech/teams/core-devs> is this related to #4439 <#4439>? Please, decide on a deadline and assign this ticket to a developer within 7 days or close it otherwise. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4694 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aacb0ui2gKl6I0jSGPVOLsKq9JMevSyoks5r4FCIgaJpZM4MNPp_>.