NEM Beta 0.4.12

Same problem I had last night.

The failed communications with nodes are usually nothing to be concerned of. Just nodes that can't be reached bcause they are offline (or router isn't configured properly or whatever).

About at height 10400, rigel started his script to pump out transactions. If you are at 10081, the next batch of blocks you request from a node goes up to about 10700. There are many transactions to fetch from the db. That's why you run into the timeout if you are unlucky. We have to look into that issue. There seems to be a bottleneck.


About at height 10400, rigel started his script to pump out transactions. If you are at 10081, the next batch of blocks you request from a node goes up to about 10700. There are many transactions to fetch from the db. That's why you run into the timeout if you are unlucky. We have to look into that issue. There seems to be a bottleneck.

So his script caused this? Perhaps once this instance is fixed we should get a number of people running scripts to test it even harder? Can't let this happen after launch. We should try to test the network beyond the amount of transactions that are expected after launch...

Here is the script  Jaguar posted, to run just change the wallet information to match yours, recipient and other stuff.

data = {
    'wallet': 'xxxx',
    'password': 'xxxxxxx',
    'account': 'TC6B3NHEPS3ZNTCGLYC4IQJVPZC4NQ36AQFNLAEA',
    'recipient': 'TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS',
    'amount': 000001,
    'fee': 1000000,
    'message': 'batch test batch test',

To change how many spams you send:
for i in range(1, 150):
This 149 spams will be sent

Time between spams:
sleep(1)

I called it nemspam.py and on Linux I run it with:
python nemspam.py

import json<br />import sys<br />from time import sleep<br />import datetime<br />import requests<br /><br /><br />class NccConnect:<br />&nbsp; &nbsp; def __init__(self, address, port):<br />&nbsp; &nbsp; &nbsp; &nbsp; self.address = address<br />&nbsp; &nbsp; &nbsp; &nbsp; self.port = port<br /><br />&nbsp; &nbsp; def info_ncc(self):<br />&nbsp; &nbsp; &nbsp; &nbsp; return self.send_get(&#039;info/ncc&#039;)<br /><br />&nbsp; &nbsp; def send_transfer(self, data):<br />&nbsp; &nbsp; &nbsp; &nbsp; return self.send_post(&#039;wallet/account/transaction/send&#039;, data)<br /><br />&nbsp; &nbsp; def send_get(self, path):<br />&nbsp; &nbsp; &nbsp; &nbsp; headers = {&#039;Content-type&#039;: &#039;application/json&#039;}<br />&nbsp; &nbsp; &nbsp; &nbsp; uri = str.format(&#039;http://{0}:{1}/ncc/api/{2}&#039;, self.address, self.port, path)<br />&nbsp; &nbsp; &nbsp; &nbsp; return requests.get(uri, headers=headers, timeout=30)<br /><br />&nbsp; &nbsp; def send_post(self, path, data):<br />&nbsp; &nbsp; &nbsp; &nbsp; headers = {&#039;Content-type&#039;: &#039;application/json&#039;}<br />&nbsp; &nbsp; &nbsp; &nbsp; uri = str.format(&#039;http://{0}:{1}/ncc/api/{2}&#039;, self.address, self.port, path)<br />&nbsp; &nbsp; &nbsp; &nbsp; return requests.post(uri, data=json.dumps(data), headers=headers, timeout=30)<br /><br /><br />connect = NccConnect(&#039;localhost&#039;, 8989)<br />r = connect.info_ncc()<br />if not r.ok:<br />&nbsp; &nbsp; print(str.format(&#039;unable to query ncc status {0}&#039;, r.status_code))<br />&nbsp; &nbsp; sys.exit()<br /><br />print(str.format(&#039;connected to ncc version {0}&#039;, r.json()&#91;&#039;metaData&#039;]&#91;&#039;version&#039;]))<br /><br /># amounts are in micronem<br />data = {<br />&nbsp; &nbsp; &#039;wallet&#039;: &#039;xxx&#039;,<br />&nbsp; &nbsp; &#039;password&#039;: &#039;xxxx&#039;,<br />&nbsp; &nbsp; &#039;account&#039;: &#039;TC6B3NHEPS3ZNTCGLYC4IQJVPZC4NQ36AQFNLAEA&#039;,<br />&nbsp; &nbsp; &#039;recipient&#039;: &#039;TALICELCD3XPH4FFI5STGGNSNSWPOTG5E4DS2TOS&#039;,<br />&nbsp; &nbsp; &#039;amount&#039;: 000001,<br />&nbsp; &nbsp; &#039;fee&#039;: 1000000,<br />&nbsp; &nbsp; &#039;message&#039;: &#039;batch test batch test&#039;,<br />&nbsp; &nbsp; &#039;encrypt&#039;: 0,<br />&nbsp; &nbsp; &#039;hours_due&#039;: 12<br />}<br /><br />time = datetime.datetime.utcnow().time()<br />for i in range(1, 150):<br />&nbsp; &nbsp; print(str.format(&#039;sending transaction {0}&#039;, i))<br />&nbsp; &nbsp; data&#91;&#039;message&#039;]<br />&nbsp; &nbsp; r = connect.send_transfer(data)<br />&nbsp; &nbsp; print(str.format(&#039;send returned {0}&#039;, r.status_code))<br />&nbsp; &nbsp; sleep(1)<br />

I just deleted the db and it got stuck at block 10081 but after some waiting its now at block 11271 and going on.

Now while block 11521 was shown in the web interface, I got the timeout, too.
  -> What to do? Just wait? Or restart NCC?


I just deleted the db and it got stuck at block 10081 but after some waiting its now at block 11271 and going on.

Now while block 11521 was shown in the web interface, I got the timeout, too.
  -> What to do? Just wait? Or restart NCC?


Just wait.


I just deleted the db and it got stuck at block 10081 but after some waiting its now at block 11271 and going on.

Now while block 11521 was shown in the web interface, I got the timeout, too.
  -> What to do? Just wait? Or restart NCC?


Just wait.

Before you answered I already
- closed the wallet and opened it again
  -> NIS unavailable
- restarted NCC
  -> NIS unavailable
- restarted NIS
  -> it started synching again but stuck at block 11521, where it is still now (!)


About at height 10400, rigel started his script to pump out transactions. If you are at 10081, the next batch of blocks you request from a node goes up to about 10700. There are many transactions to fetch from the db. That's why you run into the timeout if you are unlucky. We have to look into that issue. There seems to be a bottleneck.

So his script caused this? Perhaps once this instance is fixed we should get a number of people running scripts to test it even harder? Can't let this happen after launch. We should try to test the network beyond the amount of transactions that are expected after launch...


Ok, but we should avoid making it a race for who spams faster: the result would be leaving people with less powerful machines behind.
I had my script running 24 hours a day but with a 40 seconds pause between transactions.
We are testing the software, not hardware performance.



[font=verdana]Some weird behaviour with beta 0.4.12, windows, webstart. Client was running all the day without a problem. One hour ago started getting error "Oooops! [/font][font=roboto]NEM Infrastructure Server is not available.", yellow warning on top "[/font][font=roboto]NIS is synchronizing. At block 13035, est. less than 1 day behind."[/font][font=verdana], [/font]simultaneous[font=verdana] poping-off messages in task bar "NIS is booted, NNC is running", harvesting status "Unknown status".[/font]

Internet connection is good, all day everything was fine, did nothing special with running client.

What's the matter?

The message "Nis not available" and other weired stuff comes from the load that the scripts put on NIS. There is a bottle neck somewhere.


The message "Nis not available" and other weired stuff comes from the load that the scripts put on NIS. There is a bottle neck somewhere.


I've stopped my script but my NIS is still using CPU a lot.

The message "Nis not available" and other weired stuff comes from the load that the scripts put on NIS. There is a bottle neck somewhere.


Think everything all happened after bots started spam the network. Am I right?
It is important to find problem and fix it, launch is coming :)


The message "Nis not available" and other weired stuff comes from the load that the scripts put on NIS. There is a bottle neck somewhere.


I've stopped my script but my NIS is still using CPU a lot.


And I noticed, that my laptop heats a lot, when running NEM client.


Seems like problem started when some bot started sending transactions with zero amount:


Oct 28, 2014 22:09:15TBRIEP-GXCC5W-F5TGM6-UJUCZS-IEJYAY-WYTZW7-I2Q6 batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test View 1 4[color=rgb(209, 209, 209)].00+0[color=rgb(209, 209, 209)].00

It's definitely the scripts that are causing the problems. But there are not that many transactions, I still don't know what is causing the performance problems…



Seems like problem started when some bot started sending transactions with zero amount:


Oct 28, 2014 22:09:15TBRIEP-GXCC5W-F5TGM6-UJUCZS-IEJYAY-WYTZW7-I2Q6 batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test View 1 4[color=rgb(209, 209, 209)].00+0[color=rgb(209, 209, 209)].00

I cannot find this transaction with the block explorer: http://chain.nem.ninja/

Where did you see it?



Seems like problem started when some bot started sending transactions with zero amount:


Oct 28, 2014 22:09:15TBRIEP-GXCC5W-F5TGM6-UJUCZS-IEJYAY-WYTZW7-I2Q6 batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test batch test View 1 4[color=rgb(209, 209, 209)].00+0[color=rgb(209, 209, 209)].00

I cannot find this transaction with the block explorer: http://chain.nem.ninja/

Where did you see it?


In my client.


About at height 10400, rigel started his script to pump out transactions. If you are at 10081, the next batch of blocks you request from a node goes up to about 10700. There are many transactions to fetch from the db. That's why you run into the timeout if you are unlucky. We have to look into that issue. There seems to be a bottleneck.

So his script caused this? Perhaps once this instance is fixed we should get a number of people running scripts to test it even harder? Can't let this happen after launch. We should try to test the network beyond the amount of transactions that are expected after launch...


It uncovered a few bottlenecks in the code that we're working to fix.



About at height 10400, rigel started his script to pump out transactions. If you are at 10081, the next batch of blocks you request from a node goes up to about 10700. There are many transactions to fetch from the db. That's why you run into the timeout if you are unlucky. We have to look into that issue. There seems to be a bottleneck.

So his script caused this? Perhaps once this instance is fixed we should get a number of people running scripts to test it even harder? Can't let this happen after launch. We should try to test the network beyond the amount of transactions that are expected after launch...


It uncovered a few bottlenecks in the code that we're working to fix.

ok

log you requested: http://s000.tinyupload.com/?file_id=33157498245820725627

DB file in case its needed. http://s000.tinyupload.com/?file_id=08681983080910618879