PurePool:
@Lichtsucher, Apart from the daily Autosend that is not working, I see in the Pool Statistics that the number of shares dropped a lot but the pool keeps founding blocks.
Update: The last block paid was 57760 and no more entries in the Transactions since July 13, 2018, 9:30 a.m. It seems that it got stuck again.
Mhh, strange problem. The Biblepayd had used a lot of ram for a short time, so the OS killed some other daemons. My background job system (which checks the solutions and do the transactions) got half of its processes killed. With that, it could not hold up with the amount of tasks. But with some tasks running, my alert system wasn't triggered.
Fixed it by restarting the jobs, plus I corrected the stuck block. Payouts are already done, missing blocks are shared out right now.
Some solutions got lost, but it hit everybody the same way, so in the end, it should bring the same amount of bbp in the end for everybody
I'm not sure why it is more unstable with the newer biblepay releases. It worked so well before :/
So Ive been running 1.1.3.8 on windows and linux for a few days now, looking at windows its using 265K and linux 277K.
So thats the same as the prior old versions used.
First of all, lets look at your ram use after running 24 hours.
Try this- get process id of biblepay then type:
sudo pmap -x pid
Look at total RSS (resident ram consumption)
See if its higher than 350K for you.
If so let us know what module is hogging the ram.
Next, verify you are not changing the source code before you compile. I posted a few pages back that changing the openssl declarations is not a good idea, and we should be compiled against 101k. So if you need to create a custom build you will have to compile 101k first, then use the OPENSSL_INCLUDE_PATH= and OPENSSL_LIB_PATH= to point to the specific binary to compile against.
Also it would be good to create a rough baseline if you do find a memory issue, let us know the pattern.
