Conversation

Notices

1. @mcscx2@quitter.no (mcscx2@quitter.no)'s status on Sunday, 27-May-2018 20:36:51 UTC @mcscx2@quitter.no
   @lakwnikos Regarding the "not-responding database server every few minutes" phenomenon I really wonder what the cause of it could be.
   
   1) I think only quitter.se and quitter.no are affected. I did some research and asked on IRC but couldn't find any other instance with this problem yet
   
   At https://fediverse.network/quitter.no we can see a visualisation of the outages: https://quitter.no/attachment/1778104 . I checked a couple of other instances and there was none with a pattern like this.
   
   2) so why only quitter.se and quitter.no? They are independant instances. Or is there some config setting that quitter.no got from quitter.se back when .no was created? Maybe @knuthollund has an idea?
   
   @knuthollund @hannes
   [sorry for repost but I missed adding the !gnusocial tag]
   • @mcscx2@quitter.no (mcscx2@quitter.no)'s status on Monday, 28-May-2018 23:03:52 UTC @mcscx2@quitter.no
     @knuthollund maybe other !gnusocial admins could check one their instances whether they have those slow queries, too.
     
     Because I wonder why this seems to affect only quitter.no (apart from also quitter.se which is currently down), _even though_ quitter.no has already such powerful hardware like SSD, 12 GB RAM and the whole database kept in memory. I would expect there are at least some less powerful instances around, but I'm still still havent found other instances affected by this #every-few-minutes-unresponsive-for30-seconds-issue.
     ⚠nestort 🐃⚠ and Colegota El Villano repeated this.
   • 👣 ghose [:mastodon:] (xosem@mstdn.io)'s status on Tuesday, 29-May-2018 05:38:45 UTC 👣 ghose [:mastodon:]

     in reply to

     @mcscx2 @knuthollund @colegota

     quitter.is is down for, at least, couple of days also :(

     Colegota El Villano repeated this.
   • @mcscx2@quitter.no (mcscx2@quitter.no)'s status on Thursday, 31-May-2018 13:45:12 UTC @mcscx2@quitter.no
     @knuthollund update: the #every-few-minutes-unresponsive-for30-seconds-issue occurs *only with IPv4* ! This will be the reason why you have never encountered it yourself... let me guess:you have IPv6 internet connection at home.
     
     I discovered it with this shell command:
     
     LANG=C; while true; do echo $( date; ( wget -4 -O /dev/null 'https://quitter.no/main/public' 2>&1 | grep "Connecting" ) ); sleep 5; done
     
     This will fetch quitter.no's public timeline page every 5 seconds with either v4 or v6.
     
     Result (side-by-side-comparison):
     
     !gnusocial https://quitter.no/attachment/1781799
   • @mcscx2@quitter.no (mcscx2@quitter.no)'s status on Thursday, 31-May-2018 14:13:34 UTC @mcscx2@quitter.no

     in reply to
     @knuthollund so to me it now looks like that #someone-out-there creates lots of IPv4 connections to q.no's webserver. And that explains why the local user gets "connection failed" with Firefox so often with IPv4.
     
     I guess your webserver has separate connection limits for IPv4 and v6. #Someone-out-there (maybe the lot of mastodon instances) saturates the webserver's IPv4 connection limit.
     
     I have now created a SOCKS proxy for IPv6 for myself and so far Quitter.no works awesome over that proxy, without any annoyances. Just occasionally a little slower (that may be the slow queries) but absolutely acceptable.
     
     So you could try making the webserver's IPv4 connection limit higher. Maybe that will solve all problems. Or: we could block the instances that overload our connections using packet filter or /etc/hosts.
     
     !gnusocial
   • rugk -> ⚠️ Follow me at https://social.wiuwiu.de/@rugk (rugk@gnusocial.de)'s status on Thursday, 31-May-2018 20:06:29 UTC rugk -> ⚠️ Follow me at https://social.wiuwiu.de/@rugk

     in reply to
     @mcscx2 @knuthollund @hannes @lakwnikos the same also happened on GNUSocial.de