Lots of new spinning wheel of death and a resource-intensive new interface. anyone else notice?
I’d love to see this platform maintain accessibility across older devices. As it is now with the new updates, it barely functions. It’s a bummer. Anyway to go back?
I don’t think it’s interface related. Seems more like a server / db issue? Since it’s not pulling any more data than normal. And it’s slow on every request.
Looking at the waterfall waterfall on the front page, the blocking query is:
https://discuss.noisebridge.info/latest.json?ascending=false
Which takes ~5 seconds to return anything. But it’s only giving back like 50kb of data.
Although I may never get to post this, since I’m getting a 502 gateway error everytime I try.
thanks for the report @Zach and thanks for that analysis @themanmaran
/me strokes chin - I concur.
from some discussion with @James a month or two ago - we will be working to engender stable servering and admisterialization frameworks specifically for discuss (which is currently sharing unicorn with secure scuttlebutt and the minetest server and…)
recognizing that the work involved to do it right represents a significant commitment of time and attention from knowledgeable volunteers - so may take a while yet to tame this particular beast.
while I am personally very much looking forward to helping see it all glide to a smooth state of shall we say business continuity mode for our institutional knowledge and infrastructure - so could you be too! Volunteer devops geeks definitely welcome to join the admin team here.
Only major interface change is switching default view from categories to latest, plus tweaking theme components such as topic previews. It can be toggled back globally, or from your user preferences at iirc https://discuss.noisebridge.info/my/preferences
The system is overloaded, which you can check with df -h or top. We need to clear disk space. Also, discourse needs an upgrade which will require 8gb+ tmp just for postgresql database, plus a similar amount for moving to current tests-pass.
Scuttlebutt has proven immensely popular, and the cache for encrypted / channel messages takes up 1/3 of the disk space. Unsure of whether we can clear it; haven’t had time.
We need maintainers! I cannot do it alone, nor do I feel inspired to. Please do encourage others to assist with administration of the forum and unicorn at large. So far so good with casual meetups in keeping it online.
On Tue, Feb 9, 2021, 4:06 PM fnord via Noisebridge <noreply@discuss.noisebridge.info> wrote:
fnord
February 9thanks for the report @Zach and thanks for that analysis @themanmaran
/me strokes chin - I concur.
from some discussion with @James a month or two ago - we will be working to engender stable servering and admisterialization frameworks specifically for discuss (which is currently sharing unicorn with secure scuttlebutt and the minetest server and…)
recognizing that the work involved to do it right represents a significant commitment of time and attention from knowledgeable volunteers - so may take a while yet to tame this particular beast.
while I am personally very much looking forward to helping see it all glide to a smooth state of shall we say business continuity mode for our institutional knowledge and infrastructure - so could you be too! Volunteer devops geeks definitely welcome to join the admin team here.
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
Update: the postgres_data_old from our last migration was able to be deleted, which brings us to 84% disk usage after freeing up a few more gigs. Also removed unassociated Docker images. This means maintenance of the forum should be okay to proceed. 
In addition, I purchased a brand new instance for us on Black Friday, which is good for the next three calendar years. It just needs new maintainers and SSH keys to get going. Those with server access are welcome to spin it up at any time. Would really appreciate new blood taking it over, or I can handle it if that is preferred.
got an alert today pointing to https://discuss.noisebridge.info/logs/
I don’t have much unallocated time to dig any deeper today - but wondering if this activity is still close to being within normal parameters or …?
6:01 am Job exception: JavaScript was terminated (either by timeout or explicitly) 6:06 am 7 Failed to warm up pretty text: JavaScript was terminated (either by timeout or explicitly) 6:07 am Job exception: JavaScript was terminated (either by timeout or explicitly) 6:07 am Job exception: timeout expired 6:22 am 3 PG::ConnectionBad (could not connect to server: No route to host Is the server running on host "data" (172.17.0.4) and accepting TCP/IP connections on port 5432? ) app/models/user_auth_token.rb:105: 6:24 am 3 Job exception: could not connect to server: No route to host Is the server running on host "data" (172.17.0.4) and accepting TCP/IP connections on port 5432? 6:24 am 3 Job exception: could not connect to server: No route to host Is the server running on host "data" (172.17.0.4) and accepting TCP/IP connections on port 5432? 6:24 am 17 Job exception: could not connect to server: No route to host Is the server running on host "data" (172.17.0.4) and accepting TCP/IP connections on port 5432? 6:24 am PG::ConnectionBad (FATAL: the database system is shutting down FATAL: the database system is shutting down ) app/models/user_auth_token.rb:105:in `lookup' lib/auth/default_current_user_provider.rb:9 6:27 am 2 Job exception: PG::UnableToSend: no connection to the server 6:28 am ActiveRecord::StatementInvalid (PG::UnableToSend: no connection to the server ) (eval):29:in `async_exec' app/models/user_auth_token.rb:105:in `lookup' lib/auth/default_current_user_provider.rb:98:in 6:28 am 6 Job exception: timeout expired 6:28 am 3 PG::ConnectionBad (timeout expired ) app/models/user_auth_token.rb:105:in `lookup' lib/auth/default_current_user_provider.rb:98:in `current_user' lib/admin_constraint.rb:12:in `matches?' lib/middlewar 6:28 am 9 Job exception: timeout expired 6:28 am Job exception: could not connect to server: Connection refused Is the server running on host "data" (172.17.0.4) and accepting TCP/IP connections on port 5432? 6:28 am Job exception: could not connect to server: Connection refused Is the server running on host "data" (172.17.0.4) and accepting TCP/IP connections on port 5432? 6:28 am PG::ConnectionBad (FATAL: the database system is starting up FATAL: the database system is starting up ) app/models/user_auth_token.rb:105:in `lookup' lib/auth/default_current_user_provider.rb:98:in 6:28 am 6220 Job exception: uninitialized constant Jobs::QaUpdateTopicsPostOrder Did you mean? Jobs::UpdateTopicPostOrder Jobs::QAUpdateTopicsPostOrder 2:59 pm
Yeah, I was taking the data container offline in order to dry run the database upgrade process in the early morning. It is ready to proceed. We can do it together if you have some time. Will probably take between 15 minutes and an hour to complete.
thanks @James - indeed it seems better now. If you can please do let me know if/when you’ll be available for Moar Finagling, if anything still planned today or this week (no hurry!)
This is still super slow for me. Any improvement? These UI updates are a bit much and far too frequent imo. Ive voiced concern about this before but Im more worried now that it’s breaking usefulness on older devices.
I’m not sure how to debug this, except that latency in code is documented and incoming / outgoing data can be found through Wireshark, but I’ll see if I can take a look at it this weekend.
