[QUOTE=chalsall;511439]If I was paying money for this shared server (which you are, and take collections towards), and this kept happening, I would at the very least raise a trouble ticket....[/QUOTE]Hear, hear. Very appreciative of this forum and those that make it work.
Access was again pretty schrecklich midday today, although my even more frequently unreliable ISP masked some of that. Response time of both are usually pretty good when I ought to be sleeping. The ISP situation _might_ be getting addressed this summer if several more signups for fiber than defections from it occur in my neighborhood in the next several days.

(English synonyms given online for Deutsche schrecklich are awful, terrible, horrible)

[QUOTE=henryzz;512056]Also, is it possible to turn off the forum shutting down? Yes it will be slow but it will work to some extent.[/QUOTE]We will experiment with raising the load limit thingy a bit.

Please let us know in a few days if this is still an issue.

:mike:

I got it again.

[QUOTE=Uncwilly;514503]I got it again.[/QUOTE]

I get this once in a while too, I just tell myself "oh well time to read more maff" and shut off the internet and come back another time. :lol:

[QUOTE=dcheuk;514601]I get this once in a while too, I just tell myself "oh well time to read more maff" and shut off the internet and come back another time. :lol:[/QUOTE]That's all well and good, unless you've just created and submitted a rather long post reply... and are late for something else...

vBulletin Message

The server is too busy at the moment. Please try again later.


All times are UTC. The time now is 22:51.

Sat May 4

**************

vBulletin Message
The server is too busy at the moment. Please try again later.


All times are UTC. The time now is 12:29.

Thu May 9

DDoS, or just bad hosting?
 

About 20 minutes of downtime.

113.33 load average.

Sounds like we need more bandwidth. OTOH, Why UTC+666? Wouldn't that be the same as UTC-6, as 666 mod 24=18 (or -6), or are the forum pets being silly again?

Are there any straightforward ways - perhaps load-dependent ones - to cut page-load bandwidth when load is high? E.g. I browse with image rendering disabled, so only see the bandwidth-hoggish avatars if I click on them. Now I know lots of folks have a childish love for seeing the avs, but perhaps when load is high they could be disabled? Similarly with the post-edit icons menu - even sans images I see the associated text and can select one just fine. I wouldn't mind an occasional "images have been temporarily disabled due to heavy system load" message if it would decrease the outages. Visual - as opposed to zipfile and text - attachments might also be a candidate for such treatment.

[QUOTE=ewmayer;519041]Are there any straightforward ways - perhaps load-dependent ones - to cut page-load bandwidth when load is high? E.g. I browse with image rendering disabled, so only see the bandwidth-hoggish avatars if I click on them. Now I know lots of folks have a childish love for seeing the avs, but perhaps when load is high they could be disabled? Similarly with the post-edit icons menu - even sans images I see the associated text and can select one just fine. I wouldn't mind an occasional "images have been temporarily disabled due to heavy system load" message if it would decrease the outages. Visual - as opposed to zipfile and text - attachments might also be a candidate for such treatment.[/QUOTE]I think the load averages are CPU bandwidth, not network bandwidth.

[QUOTE=retina;519062]I think the load averages are CPU bandwidth, not network bandwidth.[/QUOTE]

What other major forms of CPU bandwidth are in play here besides serving up pages? Database management, perhaps?