Success_rate script

[maxPalermo]

hi, i am trying to use the script following the instructions written on github,
i ran the first command \ successrate.ps1 but as you can see from the screenshot there was no measurement,
I tried running the third command. \ successrate.ps1 - Path “C: \ Program Files \ Storj \ Storage Node \ storagenode.log”
the process started, but after 30 minutes it still hasn’t given results, is this normal? do i have to wait more than 30 minutes? or is there some problem in my node?

[Stob]

Hi @maxPalermo
The powershell script is very slow for large log files. You could try on a smaller log file to check it is running first, then leave it to run on the larger log file. Check your RAM usage when the command is first run and you should see it climb.

[maxPalermo]

hi, i am trying to use the script following the instructions written on github,
i ran the first command \ successrate.ps1 but as you can see from the screenshot there was no measurement,
I tried running the third command. \ successrate.ps1 - Path “C: \ Program Files \ Storj \ Storage Node \ storagenode.log”
the process started, but after 10 minutes it still hasn’t given results, is this normal? do i have to wait more than 10 minutes? or is there some problem in my node?

[Alexey]

I could only suggest to stop the storagenode and rename the log, then start the storagenode back - it will create a new log with less size and then after a while you can run this script again.

The alternative is to use this version:

Success rate script - Now updated for new delete terminology since v1.29.3

The original successrate.ps1 script from @Alexey was having problems on my machine with high memory usage whilst running on larger log files. So I rewrote it slightly to read the log one line at a time, calculate all the variables as it goes and then print out at the end. It’s between 10% and 30% faster to run on my machine using an identical log file. param( $Path = "C:\Program Files\Storj\Storage Node\storagenode - Copy.log" ) $auditsSuccess=0 $auditsFailed=0 $auditsFailedCritical=0 $dl…

But it’s better to rename/archive your logs from time to time.
See

QUIC Misconfigured

About logs… If the log is too big, you can open it with Notepad++ or other coding editor. Available log levels are: debug , info , warn , error , none . You can open/edit the config.yaml with Notepad++ or Visual Studio Code or some other coding editor and change the log level. The error level makes the smallest log, but with the fewest info. The debug is the richest in info and makes a huge log. You cand delete the storagenode.log and storagenode-updater.log anytime, after you stop both serv…