I'm running 0.3.2-ALPHA on an Intel Core2Duo P8600 @ 2.4 GHz (Laptop) System with Win 7 x64.
In the picture you can see ~ 15 Minutes. Isn't that a little bit too much?
Will this be significantly better in the beta version?
I am not seeing that in mine…
I'm running 0.3.2-ALPHA on an Intel Core2Duo P8600 @ 2.4 GHz (Laptop) System with Win 7 x64.
In the picture you can see ~ 15 Minutes. Isn't that a little bit too much?
Will this be significantly better in the beta version?
How much memory do you have? That looks a lot like the Java garbage collector...
I'm running 0.3.2-ALPHA on an Intel Core2Duo P8600 @ 2.4 GHz (Laptop) System with Win 7 x64.
In the picture you can see ~ 15 Minutes. Isn't that a little bit too much?
Will this be significantly better in the beta version?
How much memory do you have? That looks a lot like the Java garbage collector...
I have 4 GB Ram.
There are 2 java.exe running (both jre1.8.0_25). One with that high CPU time takes ~770 MB and the other one takes ~460 MB with 0 CPU time. Is that normal?
Edit:
2 java.exe are probably normal, because NIS and NCC run standalone in a command line window.
For testing I closed Firefox which takes a lot of RAM (600 MB+). While having ~800 MB free RAM now and ~1,3 GB available, the CPU time for the java.exe didn't change. So I doubt that it is really the garbage collector.
I think this is a pretty important thing since people want to use NIS as a background program which should not heat up the system.
What can I do to localize the problem? The only thing I noticed is that there is a lot going on in the log when the CPU workload is high.
Edit:
Just making sure: Harvesting is activated. But still… that shouldn't be like that, right?
After windows restart now again.
Harvesting:
[url=http://postimg.org/image/ug5iw9nhv/]
No Harvesting:
[url=http://postimg.org/image/omg7hb31p/]
After a chat with BloodyRockie we came to the conclusion that it is not the garbage collector but the processing of new blocks. The timestamps of new blocks at the block explorer show that clearly.
I'm still surprised that it causes that much CPU load and I/O (at the peaks 70-80 MByte/s). And while talking to BloodyRookie we were thinking if a node will be running on a Raspberry Pi? Did anybody ever try that?
After a chat with BloodyRockie we came to the conclusion that it is not the garbage collector but the processing of new blocks. The timestamps of new blocks at the block explorer show that clearly.
I'm still surprised that it causes that much CPU load and I/O (at the peaks 70-80 MByte/s). And while talking to BloodyRookie we were thinking if a node will be running on a Raspberry Pi? Did anybody ever try that?
Jaguar had one running when alpha started.
I investigated the high I/O during processing a new block a bit further and found out that it is mainly: ReadFile nis2.h2.db
In this example the whole process lasts about 10 seconds.
What I don't get is:
- Why is it reading the whole database over and over again?
- And why is the offset (which is a representation of a location on the disk) going up and down and up and down and …?
[url=http://postimg.org/image/4drthuw9z/]
Maybe this is just the normal behaviour of java reading a database file… But from my understanding it would be better to read the database file into RAM and do all the read there.
The problem seems fixed in beta:
[url=http://postimg.org/image/sg7gizb91/]
After a chat with BloodyRockie we came to the conclusion that it is not the garbage collector but the processing of new blocks. The timestamps of new blocks at the block explorer show that clearly.
I'm still surprised that it causes that much CPU load and I/O (at the peaks 70-80 MByte/s). And while talking to BloodyRookie we were thinking if a node will be running on a Raspberry Pi? Did anybody ever try that?
Jaguar had one running when alpha started.
I haven't tried running it recently, but I might start it up again now that we're in beta.
The problem seems fixed in beta:
[url=http://postimg.org/image/sg7gizb91/][img width=180 height=100]http://s10.postimg.org/sg7gizb91/nis_cpu_and_I_O.jpg[/img]
To be fair, there aren't that many blocks yet ^^.
I investigated the high I/O during processing a new block a bit further and found out that it is mainly: ReadFile nis2.h2.db
In this example the whole process lasts about 10 seconds.
What I don't get is:
- Why is it reading the whole database over and over again?
- And why is the offset (which is a representation of a location on the disk) going up and down and up and down and ...?
[url=http://postimg.org/image/4drthuw9z/][img width=180 height=100]http://s23.postimg.org/4drthuw9z/Readfile_nis2_h2_db.jpg[/img]
Maybe this is just the normal behaviour of java reading a database file... But from my understanding it would be better to read the database file into RAM and do all the read there.
I would guess that it's not reading the "whole" database, but it is something that should be investigated further. We're also using an H2 database by default, but that is swappable. Using a faster database *could* help.
The problem seems fixed in beta:
[url=http://postimg.org/image/sg7gizb91/][img width=180 height=100]http://s10.postimg.org/sg7gizb91/nis_cpu_and_I_O.jpg[/img]
To be fair, there aren't that many blocks yet ^^.
hm yeah. thats right lol 8)