Hello.

I have noticed that during the startup phase (block check) one single
bitcoin core instance is sufficient to put the "active" glusterfs server
at 100% CPU for several minutes. This is not happening even with a
number of parallel "dd if=/dev/zero of=/glustermointpoint/files", or
other file intensive applications, and the performance problems are big
for all other clients (even a simple ls hangs for long time).

I'm aware that the bitcoin core is opening a really large number of
files (+- 2000 pro session usually here) however I don't have the
details on what exactly the bitcoin core is doing during his startup.

My test environment is composed of two KVM hosts, connected using a
dedicated vnet, serving as replication servers + 1 physical system on a
100mbit ethernet used only for backups with distributed volumes. The
gluster volumes are mounted from the clients (KVM machines) with a
"mount -t glusterfs".

Does anyone else have noticed a such issue with the bitcoin core and/or
has and ideas on what I could verify/monitor to solve/understand this
problem?

Tnx in advance for help.

Marco
_______________________________________________
Gluster-users mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-users

Reply via email to