Quote from: markm on December 23, 2013, 11:04:25 AM

Quote from: sidhujag on December 23, 2013, 09:59:39 AM

He didnt do anything about low memory he just updated to bitcoin 0.8.5 and problem was gone.

If that is true, then the whole "merged mined coins use up more RAM and this is why" theory is maybe blown out of the water?

All the memory usage fixes for the merged mined coins were predicated on the theory that the massive coinbase transactions produced by p2pool get kept in RAM by the merged mined coins because the bitcoin chain's block against which they were merged is their proof of having been correctly merged mined, or something like that.

If that was not afterall what was realy going on, then maybe it was afterall a memory leak that caused GeistGeld and I0Coin to use massive amounts of RAM, not this business of the merged mining proof stuff in RAM...

Unless maybe the bitcoin code now somehow puts such proofs to disk like the memory-hog-fix does or something?

(And we care about that and should care about that not only because things that affect other merged coins might effect us but also because they are part of our merged mined coins family, providing a spread of different features using the same hashing power that secures our own chain. Also because we are all about free open source development and after bitcoin the other merged mined coins are our closest relations. We want merged mining to work nice and smooth for all the merged coins because we don't want merged mining to get a bad rep like "oh no you are merged mined, such and such a coin is merged mined and it has problems such and such and such and such...)

-MarkM-

I didnt see any mem specific code rsnel wrote but I think bitcoin code had something if i can remember about writing to disk instead of using ram.. that was prob part of the fix and then other mem leaks getting cleaned up.. We wont know for sure until someone runs the daemon on the pool and logs the difference of memory usage over sample period of time.