Thank you for replying dreamwatcher
I've doubled the amount of RAM for the VM and it did accelerate the process. It loaded over 200000 blocks the past half hour.
I must agree with you that the daemon and qt wallet is very slow. Changing the rpc timeout to 60 seconds in comm.py and the deamon's config also seems to have a positive effect.
We discovered that our coin was forked from Hackcoin and have managed to more or less clean the code and take control, but that never solved the performance issues. In fact, it has been like this since the beginning and staking puts a considerable amount of stress on the system, which shouldn't happen. I'm working with a coin that has been abandoned by the original developer and the two of us trying to keep it afloat, are no developers.
The VM is basically running on top of a computer that I used for mining altcoins last year. I extended the memory to 16GB, but the CPU is still the old one, an Intel Celeron G1610, which probably acts as a bottleneck for quite demanding processes. I intend on replacing it soon.
The VPS that runs bitcoin-abe atm is a 4 vCPU VM with 6GB RAM and 30GB SSD storage and has an offloaded MySQL DB running on Dual E5 2620 CPUs, 384GB RAM and 8 x 480GB SSD on RAID10. I don't worry about its performance in running CCE.
It's just that before deploying something, I tend to test it first and see what I can expect
The things like the rich list and largest tx... is that processed after all the blocks are loaded or when invoking stats.py? I imagine it will take some time to process it on 1.7M blocks.
I've doubled the amount of RAM for the VM and it did accelerate the process. It loaded over 200000 blocks the past half hour.
I must agree with you that the daemon and qt wallet is very slow. Changing the rpc timeout to 60 seconds in comm.py and the deamon's config also seems to have a positive effect.
We discovered that our coin was forked from Hackcoin and have managed to more or less clean the code and take control, but that never solved the performance issues. In fact, it has been like this since the beginning and staking puts a considerable amount of stress on the system, which shouldn't happen. I'm working with a coin that has been abandoned by the original developer and the two of us trying to keep it afloat, are no developers.
The VM is basically running on top of a computer that I used for mining altcoins last year. I extended the memory to 16GB, but the CPU is still the old one, an Intel Celeron G1610, which probably acts as a bottleneck for quite demanding processes. I intend on replacing it soon.
The VPS that runs bitcoin-abe atm is a 4 vCPU VM with 6GB RAM and 30GB SSD storage and has an offloaded MySQL DB running on Dual E5 2620 CPUs, 384GB RAM and 8 x 480GB SSD on RAID10. I don't worry about its performance in running CCE.
It's just that before deploying something, I tend to test it first and see what I can expect
The things like the rich list and largest tx... is that processed after all the blocks are loaded or when invoking stats.py? I imagine it will take some time to process it on 1.7M blocks.