statusmeldingen S228

Technische problemen? Hier kun jij jouw vragen stellen!
Forumregels
Check eerst onze helpsectie (https://www.antagonist.nl/help) voordat je hier een vraag stelt. Voor de meeste vragen hebben we uitgebreide handleidingen met uitleg.
RobbyTown
Berichten: 313
Lid geworden op: 03 aug 2007, 11:00
Contacteer:

Re: statusmeldingen S228

Bericht door RobbyTown » 16 jul 2021, 14:43

Dat met die CL8 update stabiliteit was bekend, alleen net niet technisch uitgebreid dat dit is ook de MySQL kan verzieken. Maar zo te zien komt er flink wat onderhoud aan, hopelijk het probleem gefixt :mrgreen:

Afbeelding

Vraag mij ook af wat dat onderhoud precies is. Sommige servers komen wel heel vaak opnieuw aan de beurt
s212 t/m s219, s233, s238 op 9 juli en binnenkort weer op 23 en 27 juli
https://status.antagonist.nl/event/754/
vandeMeulenhof - Persoonlijke website!

gouwepeer
Berichten: 82
Lid geworden op: 14 jan 2017, 20:29
Contacteer:

Re: statusmeldingen S228

Bericht door gouwepeer » 17 jul 2021, 21:42

En weer serverfouten in het logboek van mijn forum, met een klagende forumbezoeker vanwege het feit dat een bericht na meerdere pogingen ineens 5 keer werd geplaatst. Is er iemand bekend met Vimexx?

gouwepeer
Berichten: 82
Lid geworden op: 14 jan 2017, 20:29
Contacteer:

Re: statusmeldingen S228

Bericht door gouwepeer » 18 jul 2021, 07:37

RobbyTown schreef:
16 jul 2021, 14:43
Dat met die CL8 update stabiliteit was bekend, alleen net niet technisch uitgebreid dat dit is ook de MySQL kan verzieken. Maar zo te zien komt er flink wat onderhoud aan, hopelijk het probleem gefixt :mrgreen:

Afbeelding
Die statuspagina is van 22 juni. Inmiddels zijn we al weer bijna een maand verder. Antagonist is niet de goedkoopste host, en bij een premium prijs verwacht ik toch ook wel een premium service.
Het vervelende is dat ik mijn pakket tot 16 januari 2023 heb betaald. Als ik door het gebrek aan kwaliteit over ga stappen naar een andere host zal ik Antagonist dus in gebreke moeten stellen om het bedrag van het laatste jaar terug te kunnen vorderen. Ik verwacht dat het probleem in de aankomende week toch wel opgelost kan worden (eventueel door middel van een verplaatsing naar een andere server) want anders ga ik toch een verhuizing en een in gebreke stelling overwegen. Het probleem duur nu namelijk al iets te lang naar mijn zin.

@rjen
Berichten: 8
Lid geworden op: 13 jun 2017, 08:04

Re: statusmeldingen S228

Bericht door @rjen » 18 jul 2021, 10:37

Alleen al vanochtend tussen 8:30 en 11:10 MEER DAN 1000 van deze foutmeldingen in het forum:
Databasefout: The total number of locks exceeds the lock table size
en vanaf 11:10, niks meer, alles goed...

Dat ligt niet aan de software, maar aan de server...

gouwepeer
Berichten: 82
Lid geworden op: 14 jan 2017, 20:29
Contacteer:

Re: statusmeldingen S228

Bericht door gouwepeer » 18 jul 2021, 19:31

Ik heb ook in de ochtend problemen ervaren.
Afbeelding
Ik was net ook even aan het uitzoeken hoe ik een afbeelding via Direct Admin kon uploaden. Sinds dat dat vernieuwd is vind ik het niet handiger geworden. Hopelijk kan dat ook nog terug gezet worden.

@rjen
Berichten: 8
Lid geworden op: 13 jun 2017, 08:04

Re: statusmeldingen S228

Bericht door @rjen » 18 jul 2021, 19:53

Vanmiddag tussen drie en vier uur weer dezelfde problemen.

Nu heb ik wat onderzoek gedaan naar deze meldingen: The total number of locks exceeds the lock table size

Deze lijkt te maken te hebben met gebruik van Innobd en de waarde van deze variable: innodb_buffer_pool_size
Helaas geeft de helpdesk mij als antwoord dat die variabele niet wijzigbaar is en dat het aan de code van mijn SMF forum zal liggen. Nu betwijfel ik dat, want die code is de laatste weken niet gewijzigd.

Ik zie dat jij dezelfde problemen hebt met een Xenforo forum (meen ik)... nog een aanwijzing dat dit niet aan onze software ligt lijkt me...?

Daarnaast valt me nog iets op:
de fout treedt elke keer op in dezelfde update, welke een online-log tabel update. Deze tabel bevat gewoonlijk niet meer dan 15 tot 30 regels! Dus dat de buffer pool size te klein is lijkt me niet waarschijnlijk...

De query is deze:

Code: Selecteer alles

		$smcFunc['db_query']('', '
			UPDATE {db_prefix}log_online
			SET log_time = {int:log_time}, ip = IFNULL(INET_ATON({string:ip}), 0), url = {string:url}
				WHERE session = {string:session}',
			array(
				'log_time' => time(),
				'ip' => $user_info['ip'],
				'url' => $serialized,
				'session' => $session_id,
			)
		);
Enig idee wat de query en tabel zijn in jouw geval? Is er een overeenkomst?

gouwepeer
Berichten: 82
Lid geworden op: 14 jan 2017, 20:29
Contacteer:

Re: statusmeldingen S228

Bericht door gouwepeer » 19 jul 2021, 03:53

Voor mij is het nu ook duidelijk dat het niet aan mijn forum ligt. Nu maar hopen dat het probleem netjes wordt opgelost. Antagonist is niet de goedkoopste host, dus een beetje premium service is welkom.

@rjen
Berichten: 8
Lid geworden op: 13 jun 2017, 08:04

Re: statusmeldingen S228

Bericht door @rjen » 19 jul 2021, 06:52

Gisterenavond ter test de betreffende tabel in de database van Innodb teruggezet naar Myisam formaat. Tot op heden treden de foutmeldingen niet meer op.

Als dat zo blijft toch apart: want Antagonist raadt juist aan Innodb te gebruiken.
Dat doe ik dus al jaren, maar nu moet ik misschien toch weer terug?

Dennis Scholing
Antagonist staff
Berichten: 39
Lid geworden op: 04 mei 2017, 08:19

Re: statusmeldingen S228

Bericht door Dennis Scholing » 19 jul 2021, 14:11

We hebben vanuit onze kant meer onderzoek gedaan naar de MySQL problemen op s228.

Inmiddels hebben wij actie ondernomen. Een analyse met meer informatie is op onze status pagina geplaatst:
- https://status.antagonist.nl/event/779/
Met vriendelijke groet,

Dennis Scholing
Antagonist staff

@rjen
Berichten: 8
Lid geworden op: 13 jun 2017, 08:04

Re: statusmeldingen S228

Bericht door @rjen » 19 jul 2021, 17:25

Goed te lezen, ik wacht met spanning af of de errors nu wegblijven.
Wat ik fijn vind is dat jullie onze bevindingen waarderen.

Wat me dan wel een beetje stoort is dat toen ik deze zelfde informatie deelde in een support ticket en expliciet gevraagd heb naar de innodb-buffer-pool-size ik het moest doen met het antwoord : “het ligt aan je site, zorg maar dat je de caching verhoogd…”

Afijn, het gaat uiteindelijk om het resultaat..

gouwepeer
Berichten: 82
Lid geworden op: 14 jan 2017, 20:29
Contacteer:

Re: statusmeldingen S228

Bericht door gouwepeer » 19 jul 2021, 19:05

Mijn laatste foutmelding in het serverfouten-logboek is van 5:43 vanmorgen. Zojuist het logboek weer gewist en nu maar hopen dat het leeg blijft. Ik merk wel dat het forum op dit moment sneller reageert dan dat het de afgelopen tijd ooit gedaan heeft, dus dat is een grote vooruitgang :D

RobbyTown
Berichten: 313
Lid geworden op: 03 aug 2007, 11:00
Contacteer:

Re: statusmeldingen S228

Bericht door RobbyTown » 19 jul 2021, 22:51

gouwepeer schreef:
19 jul 2021, 19:05
Mijn laatste foutmelding in het serverfouten-logboek is van 5:43 vanmorgen. Zojuist het logboek weer gewist en nu maar hopen dat het leeg blijft. Ik merk wel dat het forum op dit moment sneller reageert dan dat het de afgelopen tijd ooit gedaan heeft, dus dat is een grote vooruitgang :D
Kans is er wel dat je een hikje hebt ivm onderhoud. Ben wel benieuwd als het nu is gefixt.

Verder je directadmin. Ja het is even wennen in vergelijking met de oude (in begin ook flink zitten vloeken grr kan die oude terug). Laatste weken heb ik er ontzettend veel in gewerkt. Snel via de mobiel uploaden via directadmin is in elk geval een stuk makkelijker (als het weet te zitten). Op pc gebruik ik gewoon filezilla scheelt weer apart inloggen via de browser..
@rjen schreef:
19 jul 2021, 17:25
Goed te lezen, ik wacht met spanning af of de errors nu wegblijven.
Wat ik fijn vind is dat jullie onze bevindingen waarderen.

Wat me dan wel een beetje stoort is dat toen ik deze zelfde informatie deelde in een support ticket en expliciet gevraagd heb naar de innodb-buffer-pool-size ik het moest doen met het antwoord : “het ligt aan je site, zorg maar dat je de caching verhoogd…”

Afijn, het gaat uiteindelijk om het resultaat..
Betreft support. Inderdaad geen fijn antwoord en uiteindelijk na een onderzoek lag het toch niet aan je site. Echter Antagonist is niet het enige bedrijf. Mijn ervaring is hoe groter de club hoe meer het kan voorkomen. Ooit gehad met een Chello/Ziggo modem constant ervoor bij veel traffic. Bellen kunnen niets doen lag aan mijn stroom blabla. Dag later weer bellen, bekend probleem krijgt een ander modem. Tja apart dat ging makkelijker dan een dag eerder :). Het is maar net wie je treft.
Dennis Scholing schreef:
19 jul 2021, 14:11
We hebben vanuit onze kant meer onderzoek gedaan naar de MySQL problemen op s228.

Inmiddels hebben wij actie ondernomen. Een analyse met meer informatie is op onze status pagina geplaatst:
- https://status.antagonist.nl/event/779/
Geen idee als jullie dat mogen vertellen ivm bedrijfgeheim. Waar ik eigenlijk benieuwd naar ben. Onderhoud is in de nacht dat onderhoud. Voert iemand dat fysiek uit of word er een ingepland script gedraaid? Mocht het dan echt de soep inlopen dat dan toeters en bellen afgaan dat er dan iemand fysiek naar kijkt? Of is er 24/7 fysiek toezicht/werkzaamheden?
vandeMeulenhof - Persoonlijke website!

gouwepeer
Berichten: 82
Lid geworden op: 14 jan 2017, 20:29
Contacteer:

Re: statusmeldingen S228

Bericht door gouwepeer » 20 jul 2021, 04:00

Mijn forum werkt ook op dit moment lekker snel, en geen enkele foutmelding te zien. Jammer dat ik daarvoor bijna een maand heb moeten klagen, maar het werkt nu zoals het moet werken.

Sander Hoentjen
Antagonist staff
Berichten: 9
Lid geworden op: 17 feb 2015, 15:55

Re: statusmeldingen S228

Bericht door Sander Hoentjen » 20 jul 2021, 09:32

@rjen schreef:
19 jul 2021, 17:25
Goed te lezen, ik wacht met spanning af of de errors nu wegblijven.
Wat ik fijn vind is dat jullie onze bevindingen waarderen.

Wat me dan wel een beetje stoort is dat toen ik deze zelfde informatie deelde in een support ticket en expliciet gevraagd heb naar de innodb-buffer-pool-size ik het moest doen met het antwoord : “het ligt aan je site, zorg maar dat je de caching verhoogd…”

Afijn, het gaat uiteindelijk om het resultaat..
Allereerst snap ik je gevoel hierbij en ben ik ook van mening dat dit beter door ons had kunnen worden opgepakt. Ik denk dat dit enigszins is misgegaan bij het delen van de urgentie van dit probleem tussen onze Support en Systeembeheer. We hebben namelijk wel de vraag gekregen of er iets speelde met MySQL op s228. Na inspectie van de monitoring-data en een kort onderzoek op de server hebben wij toen geconcludeerd dat we geen afwijkingen zagen. Dit in combinatie met de relatief lage frequentie van deze foutmelding is helaas onterecht de inschattingsfout gemaakt dat het om een probleem bij de website ging, en niet de onderliggende server. We gaan daarom kijken hoe we de onderlinge communicatie kunnen verbeteren, zodat we ook deze gevallen er snel uit kunnen pikken.
RobbyTown schreef:
19 jul 2021, 22:51
Geen idee als jullie dat mogen vertellen ivm bedrijfgeheim. Waar ik eigenlijk benieuwd naar ben. Onderhoud is in de nacht dat onderhoud. Voert iemand dat fysiek uit of word er een ingepland script gedraaid? Mocht het dan echt de soep inlopen dat dan toeters en bellen afgaan dat er dan iemand fysiek naar kijkt? Of is er 24/7 fysiek toezicht/werkzaamheden?
Dit hangt erg van het type onderhoud af. Bij het vervangen van hardware is het uiteraard zo dat er iemand op locatie moet zijn. Verder gebeurt onderhoud vanaf een remote locatie. Sommige wijzigingen worden gedaan door een medewerker op het tijdstip dat het onderhoud is en andere worden vooraf ingepland. Het onderhoud van deze week is een voorbeeld waarbij dit wordt ingepland. Wij hebben hiervoor zelf software geschreven (Rebootmanager). Geschreven in Python, kunnen we hiermee een lijst met servers inplannen voor een reboot op een bepaald moment. Wanneer het tijdstip daar is, gebeurt het volgende:
- Eén van de servers uit het lijstje wordt gereboot;
- Als de monitoringsoftware aangeeft dat de reboot succesvol is verlopen, worden er nieuwe reboots gepland voor andere servers uit het lijstje;
- Wanneer een reboot langer duurt dan we verwachten, worden er alerts verstuurd naar de dienstdoende medewerker. Deze zal de situatie onderzoeken en oplossen.

Bij elke succesvolle reboot wordt het aantal gelijktijdige reboots verhoogd (tot een ingesteld maximum). Zo voorkomen we dat bij een probleem met het onderhoud meteen veel servers tegelijk menselijk ingrijpen nodig hebben. Onze servers zijn nagenoeg identiek, dus als het onderhoud op een server slaagt, weten we vrij zeker dat dit ook op de volgende servers zal slagen.

Voor ons is dit een manier waarop we met een klein team toch veel gedaan kunnen krijgen. Als dergelijk onderhoud altijd aanwezigheid vroeg, dan zou dat ten koste gaan van de tijd die deze persoon overdag actief kan zijn :)
Daarnaast forceert deze manier van werken een goede voorbereiding. We testen zulk onderhoud altijd eerst op staging servers. Dat voorkomt problemen tijdens het proces en zorgt ook dat het sneller is afgerond.
Met vriendelijke groet,

Sander Hoentjen
Antagonist staff

gouwepeer
Berichten: 82
Lid geworden op: 14 jan 2017, 20:29
Contacteer:

Re: statusmeldingen S228

Bericht door gouwepeer » 20 jul 2021, 19:16

Sander Hoentjen schreef:
20 jul 2021, 09:32
We gaan daarom kijken hoe we de onderlinge communicatie kunnen verbeteren, zodat we ook deze gevallen er snel uit kunnen pikken.
Het is altijd mooi als je door ervaring weer iets kan verbeteren.
Ik had trouwens nog 1 foutmelding in mijn serverfouten-logboek:

Code: Selecteer alles

     XF\Db\Exception: MySQL statement prepare error [1267]: Illegal mix of collations (utf8mb4_unicode_ci,IMPLICIT) and (utf8mb4_general_ci,IMPLICIT) for operation '=' src/XF/Db/AbstractStatement.php:228 
Het ziet er naar uit dat verschillende collations voor problemen zorgen (terwijl ik dit toch al vrij lang zo heb staan).
Heeft dit ook te maken met de nieuwe CloudLinux omgeving? Mijn forum heeft voor bepaalde kolommen utf8mb4_unicode_ci nodig om o.a. Emoji's te kunnen gebruiken, waarbij ik de keuze kan instellen op Emoji's van JoyPixels, Twitter of Native Device.
https://xenforo.com/docs/xf2/unicode/
Voor de overgang naar CloudLinux heb ik deze foutmelding nooit gehad.

Plaats reactie