Topic: Bitcoin memory usage (Read 7774 times)
The new version seems to consume much less memory... 320mb... (previously at my pc 520mb)
ok, 780MB after restarting, still too much imo
what are they storing, tx cache? DB cache? doesn't make sense
what are they storing, tx cache? DB cache? doesn't make sense
My bitcoind is also consuming more and more memory over the time... 590 mb usually.. and then growing growing up to more than 1 gb after some days..
Lucky you!
4072 bitcoin 20 0 6342m 4.9g 25m S 12 63.3 402:46.47 bitcoind
Even after restarting?
Do you know if the new version 0.8.6 has the same problems?
Within the last days, the memory consumption is increasing on my system.. I have to restart the bitcoin daemon every day now :S
My bitcoind is also consuming more and more memory over the time... 590 mb usually.. and then growing growing up to more than 1 gb after some days..
Lucky you!
4072 bitcoin 20 0 6342m 4.9g 25m S 12 63.3 402:46.47 bitcoind
How is it running at the moment for you?
My bitcoind is also consuming more and more memory over the time... 590 mb usually.. and then growing growing up to more than 1 gb after some days..
Anybody knows how to prevent this?
I set maxconnections to 20, but it didnt change anything..
connections do not increase memory usage that much. the biggest factor in usage increase is the growing memory pool for transactions. there is no way to clear the memory pool, or set a limit for it. the only remedy is increasing ram capacity, increasing swap, or restarting the daemon regularly. My bitcoind is also consuming more and more memory over the time... 590 mb usually.. and then growing growing up to more than 1 gb after some days..
Anybody knows how to prevent this?
I set maxconnections to 20, but it didnt change anything..
How is it running at the moment for you?
My bitcoind is also consuming more and more memory over the time... 590 mb usually.. and then growing growing up to more than 1 gb after some days..
Anybody knows how to prevent this?
I set maxconnections to 20, but it didnt change anything..
My bitcoind is also consuming more and more memory over the time... 590 mb usually.. and then growing growing up to more than 1 gb after some days..
Anybody knows how to prevent this?
I set maxconnections to 20, but it didnt change anything..
Just want to add that previously I wrote that my bitcoind version 0.8.3 crashed and I suspected it was because of OOM error. But now I think that isn't the case. I think it ran out of disk space. I've freed up space and restarted bitcoind. Only time will tell how long it stays up.
0.8.1 apparently... I'll keep it until a major flaw is discovered... or pruning is implemented!!!
0.8.1 and 0.8.2 is vulnerable to a memory exhaustion attack. It's highly advised to update.Yes.
0.8.1 apparently... I'll keep it until a major flaw is discovered... or pruning is implemented!!!
0.8.1 and 0.8.2 is vulnerable to a memory exhaustion attack. It's highly advised to update.0.8.1 apparently... I'll keep it until a major flaw is discovered... or pruning is implemented!!!
0.8.1 and 0.8.2 is vulnerable to a memory exhaustion attack. It's highly advised to update.
I see 300-400MB usage.
Just to put it into perspective, chrome uses 3000MB at the moment (lots of open tabs).
Just to put it into perspective, chrome uses 3000MB at the moment (lots of open tabs).
0.8.1 apparently... I'll keep it until a major flaw is discovered... or pruning is implemented!!!
bitcoind runs without memory leak, but memory usage is high (1.2 GB on my setup, uptime 100 days now).
100 days so you are using an older version?
bitcoind runs without memory leak, but memory usage is high (1.2 GB on my setup, uptime 100 days now).
Well my bitcoind installation crashed after a week of uptime. Maybe it was killed because it ran out of memory. I thought this problem was fixed in the 0.8.3 version.
so this could be a potential reason why U get the bluescreen and physical memory dump from timeto time?
Maybe I should switch to electrum...
Maybe I should switch to electrum...
Thats nothing, try using armory lol
I just found this thread cause im seeing bitcoind "version" : 80300, take up 391 megs on the server, its just idle, we compiled it from git and ran it, after it caught up on the blocks its just taking up so much memory, anyone know why or have a solution? ..
Server Ubuntu 12.04.x
Server Ubuntu 12.04.x
This is what I am seeing on my VPS:
bit@hghg:~$ free -m
total used free shared buffers cached
Mem: 768 488 279 0 0 115
-/+ buffers/cache: 373 394
Swap: 256 34 221
So yeah 300-400MB of RAM.
bitcoind 0.8.1 had a memory leak in it. But 0.8.3 can run comfortably on a 512MB RAM VPS
I just found this thread cause im seeing bitcoind "version" : 80300, take up 391 megs on the server, its just idle, we compiled it from git and ran it, after it caught up on the blocks its just taking up so much memory, anyone know why or have a solution? ..
Server Ubuntu 12.04.x
Server Ubuntu 12.04.x
It's been stable between 600m-1g for a while now after it caught up with the blockchain. I guess it has a tendency to use a lot of memory downloading block after being outdated.
running 0.8.1 bitcoind on x64 linux, the mem climbs to 1.5g within 20 minutes. I'm restarting it 2-3 times a day. Once it gets so big like 2.2G, it's really difficult to shutdown the deamon gracefully. Are there some parameters that I should try to mitigate the problem ?
(tried the 0.8.2 a couple days ago noticing that the mem usage was still significant like gig+, and it halted on getaddress command, guess it's a bug or something, so I switched back.)
Do you have a massive wallet/huge number of transactions? My node has 47 connections (I sometimes get up to a few hundred) and memory usage on 0.8.2 doesnt go above 500m. (tried the 0.8.2 a couple days ago noticing that the mem usage was still significant like gig+, and it halted on getaddress command, guess it's a bug or something, so I switched back.)
running 0.8.1 bitcoind on x64 linux, the mem climbs to 1.5g within 20 minutes. I'm restarting it 2-3 times a day. Once it gets so big like 2.2G, it's really difficult to shutdown the deamon gracefully. Are there some parameters that I should try to mitigate the problem ?
(tried the 0.8.2 a couple days ago noticing that the mem usage was still significant like gig+, and it halted on getaddress command, guess it's a bug or something, so I switched back.)
Note that I used the bootstrap.dat from torrent to get started and having more than 20 connections.
(tried the 0.8.2 a couple days ago noticing that the mem usage was still significant like gig+, and it halted on getaddress command, guess it's a bug or something, so I switched back.)
Note that I used the bootstrap.dat from torrent to get started and having more than 20 connections.
There were a few changes about a month ago (that will be in 0.8.2) that hugely decrease memory consumption with a lot of connections. You might try building git master (obviously not supported and dont do it with a lot of coins/as a merchant/miner/etc) and running that, or just wait.
So is there anything (besides digging in the source) to limit this on linux?
Code:
000000000ccac000 0 4 4 rw--- [ anon ]
000000000ccad000 0 64 64 rw--- [ anon ]
000000000ccbd000 0 4 4 rw--- [ anon ]
000000000ccbe000 0 1212 1212 rw--- [ anon ]
000000000cded000 0 4 4 rw--- [ anon ]
000000000cdee000 0 108 108 rw--- [ anon ]
000000000ce09000 0 4 4 rw--- [ anon ]
000000000ce0a000 0 708 708 rw--- [ anon ]
000000000cebb000 0 4 4 rw--- [ anon ]
000000000cebc000 0 76 76 rw--- [ anon ]
000000000cecf000 0 4 4 rw--- [ anon ]
000000000ced0000 0 2232 2232 rw--- [ anon ]
000000000d0fe000 0 4 4 rw--- [ anon ]
000000000d0ff000 0 1184 1184 rw--- [ anon ]
000000000d227000 0 4 4 rw--- [ anon ]
000000000d228000 0 52 52 rw--- [ anon ]
000000000d235000 0 4 4 rw--- [ anon ]
000000000d236000 0 496 496 rw--- [ anon ]
000000000d2b2000 0 4 4 rw--- [ anon ]
000000000d2b3000 0 6076 6076 rw--- [ anon ]
000000000d8a2000 0 4 4 rw--- [ anon ]
000000000d8a3000 0 732 732 rw--- [ anon ]
000000000d95a000 0 4 4 rw--- [ anon ]
000000000d95b000 0 1256 1256 rw--- [ anon ]
000000000da95000 0 4 4 rw--- [ anon ]
000000000da96000 0 600 600 rw--- [ anon ]
000000000db2c000 0 4 4 rw--- [ anon ]
000000000db2d000 0 140 140 rw--- [ anon ]
000000000db50000 0 4 4 rw--- [ anon ]
000000000db51000 0 1516 1516 rw--- [ anon ]
000000000dccc000 0 4 4 rw--- [ anon ]
000000000dccd000 0 4016 4016 rw--- [ anon ]
000000000e0b9000 0 4 4 rw--- [ anon ]
000000000e0ba000 0 944 944 rw--- [ anon ]
000000000e1a6000 0 4 4 rw--- [ anon ]
000000000e1a7000 0 4088 4088 rw--- [ anon ]
000000000e5a5000 0 4 4 rw--- [ anon ]
000000000e5a6000 0 35572 35572 rw--- [ anon ]
00007f961723f000 0 220276 220276 rw--- [ anon ]
00007f96341d7000 0 179848 179848 rw--- [ anon ]
00007f9650000000 0 13184 13184 rw--- [ anon ]
00007f9652f2b000 0 0 0 ----- [ anon ]
00007f965c000000 0 55164 55164 rw--- [ anon ]
00007f965ff6e000 0 0 0 ----- [ anon ]
00007f966c9a8000 0 26400 26400 rw--- [ anon ]
00007f9670000000 0 49788 49788 rw--- [ anon ]
00007f9673f66000 0 0 0 ----- [ anon ]
00007f9678000000 0 132 132 rw--- [ anon ]
00007f96781f1000 0 0 0 ----- [ anon ]
00007f967cf53000 0 31772 31772 rw--- [ anon ]
00007f9680000000 0 6852 6852 rw--- [ anon ]
00007f96807f0000 0 0 0 ----- [ anon ]
00007f9684000000 0 62092 62092 rw--- [ anon ]
00007f9687fca000 0 0 0 ----- [ anon ]
00007f9688000000 0 4 4 rw--- [ anon ]
00007f9688021000 0 0 0 ----- [ anon ]
00007f968cfc9000 0 48 0 r--s- 042100.sst
00007f968d1d5000 0 36 0 r--s- 042099.sst
00007f968d3e1000 0 76 0 r--s- 042070.sst
00007f968d5ed000 0 136 0 r--s- 042051.sst
00007f968d7fc000 0 0 0 ----- [ anon ]
00007f968d7fd000 0 24 24 rw--- [ anon ]
00007f968e1fd000 0 0 0 ----- [ anon ]
00007f968e1fe000 0 28 28 rw--- [ anon ]
00007f968ebfe000 0 0 0 ----- [ anon ]
00007f968ebff000 0 16 16 rw--- [ anon ]
00007f968f5ff000 0 0 0 ----- [ anon ]
00007f968f600000 0 92 92 rw--- [ anon ]
00007f9690000000 0 4 4 rw--- [ anon ]
00007f9690021000 0 0 0 ----- [ anon ]
00007f9694000000 0 52 52 rw--- [ anon ]
00007f9694023000 0 0 0 ----- [ anon ]
00007f9698000000 0 28 28 rw--- [ anon ]
00007f9698021000 0 0 0 ----- [ anon ]
00007f969c000000 0 100 100 rw--- [ anon ]
00007f969c024000 0 0 0 ----- [ anon ]
00007f96a0000000 0 16 16 rw--- [ anon ]
00007f96a0021000 0 0 0 ----- [ anon ]
00007f96a4197000 0 148 0 r--s- 042040.sst
00007f96a43a3000 0 80 0 r--s- 042039.sst
00007f96a49c4000 0 0 0 ----- [ anon ]
00007f96a49c5000 0 44 44 rw--- [ anon ]
00007f96a53c5000 0 0 0 ----- [ anon ]
00007f96a53c6000 0 20 20 rw--- [ anon ]
00007f96a5dc6000 0 0 0 ----- [ anon ]
00007f96a5dc7000 0 20 20 rw--- [ anon ]
00007f96a67c7000 0 0 0 ----- [ anon ]
00007f96a67c8000 0 16 16 rw--- [ anon ]
00007f96a7281000 0 104 0 r--s- 042061.sst
00007f96a748b000 0 88 0 r--s- 042060.sst
00007f96a78a1000 0 84 0 r--s- 042069.sst
00007f96a7aad000 0 92 0 r--s- 042068.sst
00007f96a7cb9000 0 76 0 r--s- 042049.sst
00007f96a7ec9000 0 76 0 r--s- 042111.sst
00007f96a80d1000 0 52 0 r--s- 042110.sst
00007f96a82dd000 0 60 0 r--s- 042067.sst
00007f96a86f8000 0 100 0 r--s- 042048.sst
00007f96a8904000 0 96 0 r--s- 042047.sst
00007f96a8b10000 0 96 0 r--s- 042046.sst
00007f96a8d1c000 0 84 0 r--s- 042081.sst
00007f96a8f27000 0 100 0 r--s- 042090.sst
00007f96a9547000 0 44 0 r--s- 042080.sst
00007f96a9f77000 0 28 0 r--s- 042109.sst
00007f96aa183000 0 68 0 r--s- 042066.sst
00007f96aa394000 0 152 0 r--s- 042065.sst
00007f96aa5a4000 0 0 0 ----- [ anon ]
00007f96aa5a5000 0 20 20 rw--- [ anon ]
00007f96aafa7000 0 68 0 r--s- 042079.sst
00007f96ab1b3000 0 44 0 r--s- 042078.sst
00007f96ab3be000 0 104 0 r--s- 042059.sst
00007f96ab5ca000 0 96 0 r--s- 042089.sst
00007f96ab9de000 0 80 0 r--s- 042108.sst
00007f96abbea000 0 80 0 r--s- 042058.sst
00007f96abdf5000 0 48 0 r--s- 042071.sst
00007f96ac000000 0 236 236 rw--- [ anon ]
00007f96ac08a000 0 0 0 ----- [ anon ]
00007f96b00f8000 0 76 0 r--s- 042056.sst
00007f96b050f000 0 0 0 ----- [ anon ]
00007f96b0510000 0 12 12 rw--- [ anon ]
00007f96b0f49000 0 56 0 r--s- 042055.sst
00007f96b1155000 0 0 0 ----- [ anon ]
00007f96b1156000 0 16 16 rw--- [ anon ]
00007f96b1bcf000 0 76 0 r--s- 042088.sst
00007f96b1ddb000 0 80 0 r--s- 042087.sst
00007f96b1fe6000 0 92 0 r--s- 042086.sst
00007f96b21f2000 0 60 0 r--s- 042054.sst
00007f96b23fe000 0 132 0 r--s- 042085.sst
00007f96b260a000 0 60 0 r--s- 042057.sst
00007f96b2815000 0 8 0 r--s- 042107.sst
00007f96b2a20000 0 20 0 r-x-- libresolv-2.15.so
00007f96b2a38000 0 0 0 ----- libresolv-2.15.so
00007f96b2c38000 0 4 4 r---- libresolv-2.15.so
00007f96b2c39000 0 4 4 rw--- libresolv-2.15.so
00007f96b2c3a000 0 4 4 rw--- [ anon ]
00007f96b2c47000 0 84 0 r--s- 042098.sst
00007f96b2e52000 0 44 0 r--s- 042097.sst
00007f96b326b000 0 60 0 r--s- 042045.sst
00007f96b3477000 0 80 0 r--s- 042064.sst
00007f96b388b000 0 108 0 r--s- 042096.sst
00007f96b3a97000 0 116 0 r--s- 042095.sst
00007f96b3ca4000 0 48 0 r--s- 042044.sst
00007f96b3eb0000 0 72 0 r--s- 042083.sst
00007f96b40bc000 0 68 0 r--s- 042053.sst
00007f96b42c8000 0 80 0 r--s- 042052.sst
00007f96b44d4000 0 88 0 r--s- 042077.sst
00007f96b48e7000 0 60 0 r--s- 042106.sst
00007f96b4af3000 0 128 0 r--s- 042050.sst
00007f96b4cfe000 0 36 0 r--s- 042043.sst
00007f96b4f0a000 0 64 0 r--s- 042042.sst
00007f96b5116000 0 0 0 r-x-- libnss_dns-2.15.so
00007f96b511d000 0 0 0 ----- libnss_dns-2.15.so
00007f96b531c000 0 4 4 r---- libnss_dns-2.15.so
00007f96b531d000 0 4 4 rw--- libnss_dns-2.15.so
00007f96b5530000 0 96 0 r--s- 042038.sst
00007f96b573c000 0 88 0 r--s- 042037.sst
00007f96b594c000 0 28 0 r--s- 042101.sst
00007f96b5b56000 0 24 0 r--s- 042105.sst
00007f96b5d62000 0 80 0 r--s- 042104.sst
00007f96b5f6e000 0 64 0 r--s- 042103.sst
00007f96b6179000 0 88 0 r--s- 042041.sst
00007f96b6590000 0 48 0 r--s- 042091.sst
00007f96b6798000 0 28 0 r--s- 042076.sst
00007f96b69a3000 0 76 0 r--s- 042075.sst
00007f96b6baf000 0 24 0 r-x-- libnss_files-2.15.so
00007f96b6bbb000 0 0 0 ----- libnss_files-2.15.so
00007f96b6dba000 0 4 4 r---- libnss_files-2.15.so
00007f96b6dbb000 0 4 4 rw--- libnss_files-2.15.so
00007f96b6e44000 0 132 0 r--s- 042036.sst
00007f96b7050000 0 92 0 r--s- 042035.sst
00007f96b725c000 0 96 0 r--s- 042034.sst
00007f96b7467000 0 104 0 r--s- 042033.sst
00007f96b7673000 0 68 0 r--s- 042032.sst
00007f96b787f000 0 84 0 r--s- 042020.sst
00007f96b7a1a000 0 104 0 r--s- 042094.sst
00007f96b7c26000 0 84 0 r--s- 042074.sst
00007f96b7e32000 0 68 0 r--s- 042073.sst
00007f96b803e000 0 80 0 r--s- 042084.sst
00007f96b8249000 0 60 0 r--s- 042063.sst
00007f96b8549000 0 76 0 r--s- 042082.sst
00007f96b8755000 0 296 0 r--s- 042019.sst
00007f96b8961000 0 228 0 r--s- 042018.sst
00007f96b8b6d000 0 68 0 r--s- 042062.sst
00007f96b8ef0000 0 44 0 r--s- 042093.sst
00007f96b90fc000 0 88 0 r--s- 042092.sst
00007f96b9307000 0 52 0 r--s- 042072.sst
00007f96b9852000 0 64 0 r--s- 042102.sst
00007f96b9a93000 0 28 0 rw-s- MANIFEST-039877
00007f96b9ad3000 0 196 0 rw-s- 042021.log
00007f96b9b13000 0 0 0 r--s- 000697.sst
00007f96b9ba1000 0 0 0 r--s- 000696.sst
00007f96b9dab000 0 0 0 r--s- 000695.sst
00007f96b9fb6000 0 0 0 r--s- 000693.sst
00007f96ba1c0000 0 0 0 r--s- 000694.sst
00007f96ba3cb000 0 0 0 r--s- 000655.sst
00007f96ba5cd000 0 0 0 r--s- 000654.sst
00007f96ba7d7000 0 0 0 r--s- 000653.sst
00007f96ba9e1000 0 0 0 r--s- 000652.sst
00007f96babec000 0 0 0 r--s- 000651.sst
00007f96badf7000 0 0 0 r--s- 000650.sst
00007f96bb002000 0 0 0 r--s- 000649.sst
00007f96bb20d000 0 0 0 r--s- 000648.sst
00007f96bb417000 0 0 0 r--s- 000647.sst
00007f96bb622000 0 0 0 r--s- 000646.sst
00007f96bb82c000 0 0 0 r--s- 000692.sst
00007f96bb97e000 0 6664 6664 rw--- [ anon ]
00007f96bc000000 0 148 148 rw--- [ anon ]
00007f96bc031000 0 0 0 ----- [ anon ]
00007f96c0018000 0 0 0 r--s- 000699.sst
00007f96c0073000 0 6976 6976 rw--- [ anon ]
00007f96c0743000 0 0 0 ----- [ anon ]
00007f96c0744000 0 12 12 rw--- [ anon ]
00007f96c1144000 0 672 0 r-x-- libc-2.15.so
00007f96c12f9000 0 0 0 ----- libc-2.15.so
00007f96c14f8000 0 16 16 r---- libc-2.15.so
00007f96c14fc000 0 8 8 rw--- libc-2.15.so
00007f96c14fe000 0 20 20 rw--- [ anon ]
00007f96c1503000 0 16 0 r-x-- libgcc_s.so.1
00007f96c1518000 0 0 0 ----- libgcc_s.so.1
00007f96c1717000 0 4 4 r---- libgcc_s.so.1
00007f96c1718000 0 4 4 rw--- libgcc_s.so.1
00007f96c1719000 0 60 0 r-x-- libm-2.15.so
00007f96c1814000 0 0 0 ----- libm-2.15.so
00007f96c1a13000 0 4 4 r---- libm-2.15.so
00007f96c1a14000 0 4 4 rw--- libm-2.15.so
00007f96c1a15000 0 236 0 r-x-- libstdc++.so.6.0.16
00007f96c1af7000 0 0 0 ----- libstdc++.so.6.0.16
00007f96c1cf6000 0 32 32 r---- libstdc++.so.6.0.16
00007f96c1cfe000 0 8 8 rw--- libstdc++.so.6.0.16
00007f96c1d00000 0 12 12 rw--- [ anon ]
00007f96c1d15000 0 68 0 r-x-- libpthread-2.15.so
00007f96c1d2d000 0 0 0 ----- libpthread-2.15.so
00007f96c1f2c000 0 4 4 r---- libpthread-2.15.so
00007f96c1f2d000 0 4 4 rw--- libpthread-2.15.so
00007f96c1f2e000 0 4 4 rw--- [ anon ]
00007f96c1f32000 0 4 0 r-x-- libdl-2.15.so
00007f96c1f34000 0 0 0 ----- libdl-2.15.so
00007f96c2134000 0 4 4 r---- libdl-2.15.so
00007f96c2135000 0 4 4 rw--- libdl-2.15.so
00007f96c2136000 0 8 0 r-x-- libz.so.1.2.3.4
00007f96c214c000 0 0 0 ----- libz.so.1.2.3.4
00007f96c234b000 0 4 4 r---- libz.so.1.2.3.4
00007f96c234c000 0 4 4 rw--- libz.so.1.2.3.4
00007f96c234d000 0 88 0 r-x-- ld-2.15.so
00007f96c237e000 0 48 0 r--s- 042031.sst
00007f96c2390000 0 4 0 r--s- 041967.sst
00007f96c2393000 0 16 0 rw-s- 000704.log
00007f96c23b3000 0 0 0 r--s- 000701.sst
00007f96c240d000 0 0 0 r--s- 041694.sst
00007f96c240e000 0 0 0 r--s- 041317.sst
00007f96c2410000 0 0 0 rw-s- MANIFEST-000703
00007f96c2420000 0 232 232 rw--- [ anon ]
00007f96c255a000 0 24 24 rw--- [ anon ]
00007f96c2560000 0 0 0 r--s- 041328.sst
00007f96c2561000 0 0 0 r--s- 041639.sst
00007f96c2566000 0 0 0 r--s- 041618.sst
00007f96c2568000 0 16 16 rw--- [ anon ]
00007f96c256d000 0 8 8 rw--- [ anon ]
00007f96c256f000 0 4 4 r---- ld-2.15.so
00007f96c2570000 0 8 8 rw--- ld-2.15.so
00007fff708c3000 0 40 40 rw--- [ stack ]
00007fff709fe000 0 4 0 r-x-- [ anon ]
ffffffffff600000 0 0 0 r-x-- [ anon ]
---------------- ------ ------ ------
total kB 2228636 907812 897444
root@w:~#
900mb usage , 40 connections after 24h
0.8.1 on Ubuntu 12.04
Yeah, there is definitely some kind of memory leak, although it's very small. But a lot of people run the client 24/7, so it builds up.
Guess it's not only me then.
What i noticed was that it is lower when you haven't downloaded the blockchain (it starts out at about 20-30mb i believe, rising with about 1-2mb/minute (was getting the blockchain at about 600kbps i believe).
After the blockchain is completely downloaded the memory usage doesn't rise very much, maybe a 2-5 mb/h, not really sure
Since i wrote my old post it's risen from 80 to 98mb though. (7 hours)
What i noticed was that it is lower when you haven't downloaded the blockchain (it starts out at about 20-30mb i believe, rising with about 1-2mb/minute (was getting the blockchain at about 600kbps i believe).
After the blockchain is completely downloaded the memory usage doesn't rise very much, maybe a 2-5 mb/h, not really sure
Since i wrote my old post it's risen from 80 to 98mb though. (7 hours)
bitcoind is running 24/7 on my debian server, and its memory usage seems to be ever increasing as time goes on:
Thats half a gigabyte...
Code:
$ pmap -x `pidof bitcoind`
30338: bitcoind -daemon
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 0 1300 0 r-x-- bitcoind
0000000000994000 0 4 4 r---- bitcoind
0000000000995000 0 32 20 rw--- bitcoind
00000000009b1000 0 16 16 rw--- [ anon ]
00000000026c8000 0 380140 380124 rw--- [ anon ]
00007f8d38000000 0 12964 12964 rw--- [ anon ]
00007f8d3b1f1000 0 0 0 ----- [ anon ]
00007f8d40000000 0 61332 61332 rw--- [ anon ]
00007f8d43d2b000 0 0 0 ----- [ anon ]
00007f8d467d8000 0 0 0 ----- [ anon ]
00007f8d467d9000 0 8 8 rw--- [ anon ]
00007f8d46fd9000 0 48 0 r-x-- libresolv-2.11.2.so
00007f8d46fec000 0 0 0 ----- libresolv-2.11.2.so
00007f8d471eb000 0 0 0 r---- libresolv-2.11.2.so
00007f8d471ec000 0 4 0 rw--- libresolv-2.11.2.so
00007f8d471ed000 0 4 4 rw--- [ anon ]
00007f8d471ef000 0 16 0 r-x-- libnss_dns-2.11.2.so
00007f8d471f4000 0 0 0 ----- libnss_dns-2.11.2.so
00007f8d473f3000 0 4 0 r---- libnss_dns-2.11.2.so
00007f8d473f4000 0 4 0 rw--- libnss_dns-2.11.2.so
00007f8d473f5000 0 24 0 r-x-- libnss_files-2.11.2.so
00007f8d47400000 0 0 0 ----- libnss_files-2.11.2.so
00007f8d475ff000 0 4 4 r---- libnss_files-2.11.2.so
00007f8d47600000 0 4 4 rw--- libnss_files-2.11.2.so
00007f8d47606000 0 0 0 ----- [ anon ]
00007f8d47607000 0 64 64 rw--- [ anon ]
00007f8d47e07000 0 0 0 ----- [ anon ]
00007f8d47e08000 0 24 24 rw--- [ anon ]
00007f8d48608000 0 0 0 ----- [ anon ]
00007f8d48609000 0 88 88 rw--- [ anon ]
00007f8d48e09000 0 0 0 ----- [ anon ]
00007f8d48e0a000 0 36 36 rw--- [ anon ]
00007f8d4960a000 0 0 0 ----- [ anon ]
00007f8d4960b000 0 0 0 rw--- [ anon ]
00007f8d49e0b000 0 0 0 ----- [ anon ]
00007f8d49e0c000 0 32 32 rw--- [ anon ]
00007f8d4a60c000 0 0 0 ----- [ anon ]
00007f8d4a60d000 0 0 0 rw--- [ anon ]
00007f8d4ae0d000 0 0 0 ----- [ anon ]
00007f8d4ae0e000 0 16 16 rw--- [ anon ]
00007f8d4b60e000 0 1408 212 rw-s- __db.005
00007f8d4bb5e000 0 0 0 r-x-- libpcre.so.3.12.1
00007f8d4bb8e000 0 0 0 ----- libpcre.so.3.12.1
00007f8d4bd8d000 0 4 4 rw--- libpcre.so.3.12.1
00007f8d4bd8e000 0 0 0 r-x-- libglib-2.0.so.0.2400.2
00007f8d4be69000 0 0 0 ----- libglib-2.0.so.0.2400.2
00007f8d4c068000 0 4 4 rw--- libglib-2.0.so.0.2400.2
00007f8d4c06a000 0 0 0 r-x-- librt-2.11.2.so
00007f8d4c071000 0 0 0 ----- librt-2.11.2.so
00007f8d4c270000 0 4 4 r---- librt-2.11.2.so
00007f8d4c271000 0 0 0 rw--- librt-2.11.2.so
00007f8d4c272000 0 516 0 r-x-- libc-2.11.2.so
00007f8d4c3ca000 0 0 0 ----- libc-2.11.2.so
00007f8d4c5c9000 0 16 16 r---- libc-2.11.2.so
00007f8d4c5cd000 0 4 4 rw--- libc-2.11.2.so
00007f8d4c5ce000 0 16 16 rw--- [ anon ]
00007f8d4c5d3000 0 40 0 r-x-- libgcc_s.so.1
00007f8d4c5e9000 0 0 0 ----- libgcc_s.so.1
00007f8d4c7e8000 0 4 4 rw--- libgcc_s.so.1
00007f8d4c7e9000 0 72 0 r-x-- libm-2.11.2.so
00007f8d4c869000 0 0 0 ----- libm-2.11.2.so
00007f8d4ca69000 0 4 4 r---- libm-2.11.2.so
00007f8d4ca6a000 0 4 4 rw--- libm-2.11.2.so
00007f8d4ca6b000 0 44 0 r-x-- libstdc++.so.6.0.13
00007f8d4cb61000 0 0 0 ----- libstdc++.so.6.0.13
00007f8d4cd61000 0 20 20 r---- libstdc++.so.6.0.13
00007f8d4cd68000 0 8 8 rw--- libstdc++.so.6.0.13
00007f8d4cd6a000 0 12 12 rw--- [ anon ]
00007f8d4cd7f000 0 60 0 r-x-- libpthread-2.11.2.so
00007f8d4cd96000 0 0 0 ----- libpthread-2.11.2.so
00007f8d4cf95000 0 4 4 r---- libpthread-2.11.2.so
00007f8d4cf96000 0 4 4 rw--- libpthread-2.11.2.so
00007f8d4cf97000 0 4 4 rw--- [ anon ]
00007f8d4cf9b000 0 0 0 r-x-- libdl-2.11.2.so
00007f8d4cf9d000 0 0 0 ----- libdl-2.11.2.so
00007f8d4d19d000 0 4 4 r---- libdl-2.11.2.so
00007f8d4d19e000 0 0 0 rw--- libdl-2.11.2.so
00007f8d4d19f000 0 8 0 r-x-- libz.so.1.2.3.4
00007f8d4d1b6000 0 0 0 ----- libz.so.1.2.3.4
00007f8d4d3b5000 0 4 4 rw--- libz.so.1.2.3.4
00007f8d4d3b6000 0 0 0 r-x-- libgthread-2.0.so.0.2400.2
00007f8d4d3ba000 0 0 0 ----- libgthread-2.0.so.0.2400.2
00007f8d4d5b9000 0 4 4 rw--- libgthread-2.0.so.0.2400.2
00007f8d4d5ba000 0 44 0 r-x-- ld-2.11.2.so
00007f8d4d5ff000 0 4 4 rw-s- __db.006
00007f8d4d60d000 0 36 8 rw-s- __db.004
00007f8d4d625000 0 264 208 rw-s- __db.003
00007f8d4d667000 0 28 20 rw-s- __db.002
00007f8d4d7c3000 0 4 0 rw-s- __db.001
00007f8d4d7c9000 0 24 24 rw--- [ anon ]
00007f8d4d7d3000 0 4 4 rw--- [ anon ]
00007f8d4d7d7000 0 4 4 r---- ld-2.11.2.so
00007f8d4d7d8000 0 4 4 rw--- ld-2.11.2.so
00007f8d4d7d9000 0 4 4 rw--- [ anon ]
00007fff27624000 0 12 8 rw--- [ stack ]
00007fff2776d000 0 4 0 r-x-- [ anon ]
ffffffffff600000 0 0 0 r-x-- [ anon ]
---------------- ------ ------ ------
total kB 634516 458876 455364
Thats half a gigabyte...
Yup, for me the client(GUI) always uses 100+ megabytes of RAM....
Win 7 64bit & fedora 12 32bit
Memory usage seems to have went down @Win7 machine now though (to 80mb, might be because of i newly booted?), only running bitcoind on fedora and it uses as much memory as bitcoin(with GUI) on Win7. Not really sure if this is a huge problem though, maybe some other people could check their current usage and uptime on the client?
Would be nice to see lower mem usage on bitcoind but i guess it shouldn't be that high priority anyway, 140mb isn't too much and there is probaly better things to use energy on fixing for now.
Memory usage seems to have went down @Win7 machine now though (to 80mb, might be because of i newly booted?), only running bitcoind on fedora and it uses as much memory as bitcoin(with GUI) on Win7. Not really sure if this is a huge problem though, maybe some other people could check their current usage and uptime on the client?
Would be nice to see lower mem usage on bitcoind but i guess it shouldn't be that high priority anyway, 140mb isn't too much and there is probaly better things to use energy on fixing for now.
bitcoin/bitcoind uses almost 150mb RAM and the memory usage rises every day.
Any way to lower the usage or am i just doing something wrong? Guessing it has something to do with latest block being stored in memory or something, is there a way to prevent this?
Thanks, Daniel.
Any way to lower the usage or am i just doing something wrong? Guessing it has something to do with latest block being stored in memory or something, is there a way to prevent this?
Thanks, Daniel.
What OS are you running?
What version of bitcoin/bitcoind are you running?
Try upgrading both to the latest versions first and report back. The Bitcoin client is still in beta/testing mode, remember. We still have a long way to go before a "1.0 final" release.
bitcoin/bitcoind uses almost 150mb RAM and the memory usage rises every day.
Any way to lower the usage or am i just doing something wrong? Guessing it has something to do with latest block being stored in memory or something, is there a way to prevent this?
Thanks, Daniel.
Any way to lower the usage or am i just doing something wrong? Guessing it has something to do with latest block being stored in memory or something, is there a way to prevent this?
Thanks, Daniel.
Jump to: