Constant 100% cpu load when there is over >20k accounts

[gituser]

Before filing a new issue, please provide the following information.

I'm running:

• Parity version: 1.6.10
• Operating system: Linux
• And installed: from source

Parity is using 100% cpu all time when there is about 20000 account addresses in it.

From strace I can see that it's doing a lot of lstat() calls to directory with keys. Maybe it's time to implement some sort of caching?

I'm running parity with these parameters:

/home/ethereum/parity --identity p_main --author xxx --chain=frontier --mode=active --mode-timeout 20 --mode-alarm 60 --cache-size 4096 -l 3 --datadir /home/ethereum/.parity --port 5313 --min-peers 25 --max-peers 50 --jsonrpc-interface xxx --jsonrpc-port 9110 --jsonrpc-apis web3,eth,net,personal,traces,rpc,parity,parity_set,parity_accounts --ipc-path /home/ethereum/.parity/parity.ipc --db-path /home/ethereum/.parity --keys-path /home/ethereum/.parity/keys --dapps-path /home/ethereum/.parity/dapps --no-ui --no-dapps --pruning-history 1024 --allow-ips=public --tracing=on

I've checked on other hosts where there is identical parity instance and about 8k accounts and it runs better (no constant 100% or more load though there is some CPU activity).

NOTE: in both cases parity runs on SSD drives.

Thank you

[gituser]

So this is a confirmed bug?

[5chdn]

Yes, we are looking into it. Meanwhile, have you considered to use external account-management of some kind? While I agree Parity should be able to handle lots of accounts, it's probably not initially designed for that tasks and this task requires some more love.

[gituser]

@5chdn, I'd appreciate giving some examples/how-tos how to properly implement external accounting.
The current system is implement strictly on parity and relies on creating new address and monitoring it.
It does work apart but seems to be not scaling good at all.

[gituser]

Yes, it seems to be a confirmed bug.
I've just moved 25k empty accounts out of the keydir and parity stopped eating CPU instantly.

As local accounts growing parity's CPU usage is increasing. So that means parity's accounting is useless for anything more than 10k accounts.

Sure local accounting is a way to go, but it might be complicated for already built systems based on RPC functions.

I'll certainly look into external accounting, but still would be nice to fix this bug somehow.

Thank you.

[tomusdrw]

@gituser What's your workflow? Do you ask for eth_accounts often? Number of accounts should not affect CPU usage unless you are trying to fetch or use them over RPC.

[gituser]

No. I do not use eth_accounts every minute. I only query them when I do display history but that happens only once when administrator loads the history page, which isn't happening every minute.

The most queried thing over RPC is transaction information (e.g. confirmations, etc).

But I do have separate database with another parity instance which indexes whole blockchain into relationship database (MySQL).

So workflow is like this:

1. I generate new address for the client to accept his payment, every payment got 15 minutes to be made, otherwise it's automatically cancelled and not tracked anymore (sometimes client can send later, so address is still needed).
2. I check every minute if there is a payment on that address by querying the MySQL DB
3. If there is a transaction I do check for certain amount of confirmations by getting latestblock and substacting block in the transaction

I can turn on RPC logging if you want, what do I need to pass over to parity?

But the problem is surely there, as I said before after removing empty accounts the CPU usage went downhill, of course it's still there but it's much less now.

[gituser]

Any update on this? Maybe there is possible to implement some trivial fix for this?

Thank you.

[tomusdrw]

Related: #6170

This particular issue should be already solved by #4583. Could you test if the problem persists on 1.7.x?

[gituser]

@tomusdrw thank you for the update, I'm trying v1.7.2 hopefully it won't break anything else.
Building it right now and will report back soon.

Thanks.

[gituser]

Trying to build parity v1.7.2 without luck with rustc 1.19.0, getting this:

Compiling parity v1.7.2 (file:///home/build/parity/source)
error: the crate `semver` is compiled with the panic strategy `abort` which is incompatible with this crate's strategy of `unwind`

error: the crate `semver_parser` is compiled with the panic strategy `abort` which is incompatible with this crate's strategy of `unwind`

error: aborting due to previous error(s)

error: Could not compile `parity`.

any idea how to fix this?

EDIT: seems cargo clean fixed this issue.

[gituser]

I've tested v1.7.2 it didn't fix it either. With 35K accounts there is constant 100% cpu load.

after moving 25k out of the keys dir the CPU usage goes down a bit.