Re: [ANNOUNCE] Abe 0.7: Open Source Block Explorer Knockoff
I have a question about mempool transactions regarding performance:
So I'm running http://blockexplorer.auroracoin.eu and because I have allocated quite a machine to the task everything has been zappy and fine this morning.
However when I checked back from work an hour later I saw loads of exceptions saying "error: [Errno 32] Broken pipe", the nginx I have in front reporting gateway timeouts. I'm hypothesizing the db queries are the bottleneck.
I tried rebuilding the database (drop it completely and rebuild)... that didn't help, it started again right away.
There are loads of mempool transactions in AURoracoin because we're being pool-hopping-attacked to the point where there hasn't been a block for 6 hours or so.
Another instance I run with same setup, but on quite weak machine (vm) was able to cope with the load quite well and didn't suffer broken pipes.
What fixed it was to re-initialize BOTH the blockchain of the AuroraCoind AND the db (just db didn't help).
Now the question: how are mempool transactions handled and could the existance of many mempool transactions have considerable impact on db (or abe.py) performance?
I'm a bit confused... does anyone have an idea what could've been causing this?
So I'm running http://blockexplorer.auroracoin.eu and because I have allocated quite a machine to the task everything has been zappy and fine this morning.
However when I checked back from work an hour later I saw loads of exceptions saying "error: [Errno 32] Broken pipe", the nginx I have in front reporting gateway timeouts. I'm hypothesizing the db queries are the bottleneck.
I tried rebuilding the database (drop it completely and rebuild)... that didn't help, it started again right away.
There are loads of mempool transactions in AURoracoin because we're being pool-hopping-attacked to the point where there hasn't been a block for 6 hours or so.
Another instance I run with same setup, but on quite weak machine (vm) was able to cope with the load quite well and didn't suffer broken pipes.
What fixed it was to re-initialize BOTH the blockchain of the AuroraCoind AND the db (just db didn't help).
Now the question: how are mempool transactions handled and could the existance of many mempool transactions have considerable impact on db (or abe.py) performance?
I'm a bit confused... does anyone have an idea what could've been causing this?
It could be transactions being left open, suboptimal SQL, or
If you have a collection of Python stack traces or database process lists from during the timeouts, they might point to the offender(s).This is the error
Exception happened during processing of request from ('178.63.69.203', 49828)
Traceback (most recent call last):
File "/usr/lib/python2.7/SocketServer.py", line 295, in _handle_request_noblock
self.process_request(request, client_address)
File "/usr/lib/python2.7/SocketServer.py", line 321, in process_request
self.finish_request(request, client_address)
File "/usr/lib/python2.7/SocketServer.py", line 334, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.7/SocketServer.py", line 651, in __init__
self.finish()
File "/usr/lib/python2.7/SocketServer.py", line 704, in finish
self.wfile.flush()
File "/usr/lib/python2.7/socket.py", line 303, in flush
self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 32] Broken pipe
(I think nginx (load-balancing here) or the client times out because it's taking too long)
on AuroraCoind debug.log I see this:
22478 ThreadRPCServer method=getrawtransaction
22479 ThreadRPCServer method=getrawtransaction
22480 ThreadRPCServer method=getrawtransaction
22481 ThreadRPCServer method=getrawtransaction
22482 ThreadRPCServer method=getrawtransaction
22483 ThreadRPCServer method=getrawtransaction
22484 ThreadRPCServer method=getrawtransaction
22485 ThreadRPCServer method=getrawtransaction
22486 ThreadRPCServer method=getrawtransaction
22487 ThreadRPCServer method=getrawtransaction
22488 ThreadRPCServer method=getrawtransaction
22489 ThreadRPCServer method=getrawtransaction
22490 ThreadRPCServer method=getrawtransaction
22491 ThreadRPCServer method=getrawtransaction
22492 ThreadRPCServer method=getrawtransaction
22493 ThreadRPCServer method=getrawtransaction
22494 ThreadRPCServer method=getrawtransaction
22495 ThreadRPCServer method=getrawtransaction
22496 ThreadRPCServer method=getrawtransaction
22497 ThreadRPCServer method=getrawtransaction
22498 ThreadRPCServer method=getrawtransaction
22499 ThreadRPCServer method=getrawtransaction
22500 ThreadRPCServer method=getrawtransaction
22501 ThreadRPCServer method=getrawtransaction
22502 ThreadRPCServer method=getrawtransaction
22503 ThreadRPCServer method=getrawtransaction
22504 ThreadRPCServer method=getrawtransaction
about 500 per seconds
psql> select * from pg_stat_activity;
reports only one IDLE connection