Oh hai there:

Just putting this here: https://munin.kiska.pw/munin/sidock-day.html

And asking if the Formula BOINC sprint is murdering the server?


As evidenced here by the longer than expected execution time of server_status.php

The Formula BOINC race was announced on 03/18/2021 11:00 (UTC) and began 03/19/2021 11:00 (UTC).
Some contestants begin bunkering where they down load as many WUs as they can finagle and start running them but they don't return them until after the race starts on 3/19 at 11:00 UTC.
So if your graph is in UTC then it makes sense. Returns are way down before race day and In Progress is up.
Then when the starting gun goes off they dump all their completed WUs and rts spikes while inProgress drops down to normal again.

---

Looking at the longer term charts I don't understand why there are so many more Returns than InProgress???

https://munin.kiska.pw/munin/Munin-Node/Munin-Node/results_sidock.html

---

Looking at the longer term charts I don't understand why there are so many more Returns than InProgress???

https://munin.kiska.pw/munin/Munin-Node/Munin-Node/results_sidock.html

rts is Ready To Send

Who is hammering this poor server

root@vultr:/usr/share/munin/plugins# time ./sidock
multigraph results_sidock
rts.value 22612
inProgress.value 55574
multigraph workunits_sidock
validation.value 9
assimilation.value 0
deletion.value 21
deletion_result.value 42
multigraph transitioner_sidock
backlog.value 0.00027777777777778

real    0m17.584s
user    0m0.172s
sys     0m0.044s

It took 17 seconds to grab that...

Oh, there's key on the bottom of the second page that is not on the first page.

In that case I don't see why you think they might be having server problems. SiDock is doing much better than last month for the BAMstats race. I've yet to see them run out of work this week.

---

Who is hammering this poor server

I have two suggestions as to who is hammering the server:
1. BOINCers that are running more than one project but have set Resource for SiDock much higher than their other projects so it polls the server far more often than necessary to get a mere 2 WUs per thread, and
2. Bunkerers that use multiple clients to pretend to have more computers than they actually have and the app_config command <ncpus>N</ncpus> to pretend to have more CPUs than they actually have to suck down more WUs than they can actually run.

---

Oh and not 100's of Users with 100's of threads requesting work..(since we only get 2 per thread [~2 hours worth]).

It seems that we have returned to stable service?

It seems that we have returned to stable service?

Possible reasons:
1) Longer WUs = fewer connections to project server
2) All bunkers have been fully uploaded
2) FB Sprint is going to finish and some users are leaving