Server- & netwerkstatusmeldingen VIII

Problemen met de servers en de netwerkverbinding van Tweakers.net worden in deze .plan gemeld. De laatste informatie over de serverloads en -uptimes kun je volgen op de Statusmeldingen

19-12-2007 Aangezien we blijkbaar geen toffe fix kunnen vinden voor die stomme adaptec kaart hebben we vlak na 12 uur 's nachts maar weer een atlaswissel toegepast. De ellende is dat we niet precies weten wat deze bug laat optreden, dus we hopen maar dat IBM hiermee bekend is en er een oplossing voor heeft. Wordt vervolgd...

12-12-2007 De afgelopen dagen kregen we een aantal smsjes waarmee Nagios ons probeerde te vertellen dat er iets mis was met de webservers, de load sprong opeens omhoog naar 20 of nog hoger waardoor ze onbereikbaar werden. Gisteren kwamen we erachter dat er niets mis was met de webservers, zoals we eigenlijk al dachten, maar dat onze laatste, nieuwe, hippe, ganz geile fileserver er af en toe het bijltje bij neergooit.
Na enig zoekwerk kwamen we erachter dat we last hebben van deze bug. Om last van deze bug te hebben moet je aan een aantal randvoorwaarden voldoen, meer dan 4GB geheugen: check, 64bits kernel: check. Adaptec raid: check.
Oftewel: die raidcontroller loopt te bokken. En vandaag wat erger dan gisteren, want vandaag kapte 'ie er helemaal mee. Er staan in de bugreport wel een aantal semi oplossingen die we op dit moment achter de schermen aan het bespreken zijn om te zien welke oplossing ons probleem op zal lossen.

22-11-2007 Ongeveer een half uur geleden zijn er wat trubbels geweest op de ams-ix, KPN kan hier blijkbaar (nog) niet helemaal mee overweg waardoor er wat rare problemen optreden naar verschillende sites, waaronder dus de onze, helaasch. Het probleem manifesteert zich in een goede traceroute naar ons toe, maar terug hebben de pakketten wat moeite met de route terug te vinden. We hopen uiteraard dat het probleem zich zo snel mogelijk oplost

04-10-2007 Langer dan 2 maanden zonder een serverfuckup kan natuurlijk niet, dus vandaag was het weer zover: een van de webservers ging over de zeik. Dit hoort normaliter totaal geen impact te hebben op de site, maar blijkbaar zit ergens in onze loadbalancing scripting een fout waardoor de loadbalancer ervan was overtuigd dat apache nog draaide op Aphaea, terwijl wij er toch van waren overtuigd (en ps aux ook

) dat apache keidood was. Anyways, na een crashcourse linuxvirtualserver doen de sites het inmiddels weer. Nu alleen nog achterhalen waarom Aphaea de nfs mount opeens niet meer kan vinden..

31-07-2007 Een maand later dan gepland, maar vannacht zijn de nieuwe loadbalancers toch in gebruik genomen. De reden dat de vorige keer de loadbalancers het na enkele minuten begaven bleek in de Linux kernel te liggen. Deze bug was alleen te vinden op SMP-systemen, en trad slechts zeer sporadisch op. (Hij trad alleen op als de server veel verkeer van verschillende IP adressen aan het verwerken was terwijl de configuratie aangepast werd.) Maar als hij wel optrad zorgde hij ervoor dat de kernel het volledige systeem met zich meetrok en nergens meer op reageerde. Door een kleine patch te schrijven is het euvel uiteindelijk opgelost en hebben we de nieuwe loadbalancers in gebruik genomen, hetgeen gepaard ging met een downtime van iets meer dan 4 seconden voor de slave, en 30 seconden voor de master.

19-07-2007 Tegen het eind van de ochtend, begin van de middag zal GoT even down gaan in verband met wat on site onderhoud aan Apollo, de database server. Dit zal (hopelijk

) ongeveer maximaal een kwartiertje duren.
Update 15:39: We bennuh klaor, en we gaon naar huus.

03-07-2007 De arethusa die nu in EUNetworks hangt (eigenlijk de oude achelois die we een tijdje geleden uit Redbus hebben meegenomen naar kantoor voor een herinstallatie) doet nu irc enzo, alleen ging het niet zo soepel als we gehoopt had, waardoor de downtime iets langer was dan een +/- 0.5 minuten die we in het hoofd hadden

01-07-2007 Nadat we gisteren zijn verhuisd, bleek een van onze nieuwe loadbalancers stuk te gaan. Helaas reageerde de kvm-over-ip niet helemaal zoals we wilden zodat we iemand moesten instrueren om eerst dat te fixen. Inmiddels werkt het weer, en morgen, als we weer helder in dem Kopf zijn, gaan we zoeken wat er nu precies gebeurd is.
Update 14:31 Blijkbaar is er iets mis met de nieuwe loadbalancers, dus as we speak racet Daniel naar Redbus toe om daar een oude loadbalancer weer aan te zetten zodat dit knipperlicht gedoe hopelijk over is
Update 14:58 Inmiddels is een van de oude loadbalancers in Redbus zo vriendelijk geweest (met wat hulp van Daniel

) om zijn oude taak nog even waar te nemen.

10-6-2007 Even wat kort onderhoud om ervoor te zorgen dat mysql hopelijk wat beter presteert op de frontpage, helaas werkt de maintenance-popup niet helemaal tof, waardoor iedereen een postlaunch-scherm kreeg te zien

5-6-2007 Zoals je kunt zien hebben wij een nieuwe layout, deze is echter af en toe behoorlijk traag. Dit komt doordat onze bezoekers massaal de nieuwe site willen bekijken, en dat trok het serverpark niet helemaal. De boosdoener bleek voornamelijk de loadbalancer te zijn die op de nominatie staat om vervangen te worden. Een 2GHz celeron is niet meer genoeg om de pieken op te vangen in ons dataverkeer. Dit dataverkeer was overigens extreem hoog. Ter vergelijking; op een normale dag pieken wij rond de 500 requests per seconde. Toen de site echter 5 minuten in de lucht was hadden we er al meer zeshonderdduizend requests op zitten, oftewel meer dan 2000 requests per seconde. In eerste instantie trok de nieuwe apache configuratie dit niet helemaal, maar na enkele aanpassingen deed deze het weer. De loadbalancer begon het toen te begeven. Zijn CPU bleek te licht te zijn. Meerdere minuten van 100% CPU gebruik was geen uitzondering, en hierdoor vertraagde het netwerkverkeer aanzienlijk. Op dit moment draait de loadbalancer behoorlijk 'uitgekleed' en ontdaan van niet kritieke processen, en in deze mode kan hij het maar net volhouden getuige zijn stats:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
2  0      0 442524   4704  21740    0    0     0     0 18173   14  0 99  1  0
0  0      0 442524   4704  21740    0    0     0     0 18566   37  1 97  2  0
1  0      0 442524   4704  21740    0    0     0     0 18203   22  0 97  3  0
2  0      0 442268   4704  21740    0    0     0     0 45101   29  1 99  0  0

19-05-2007 De verbindingen naar Apollo liepen wat vol waardoor het forum een niet zo toffe foutmelding gaf, nadat we mysql ~~een schop onder z'n kont~~ op de door mysql.org aangeraden manier hebben herstart werkt het weer, eerste paar hits zullen wat langzaam zijn omdat hij z'n cache even moet vullen.

02-05-2007 It happens to the best: Onze React testomgeving ging over z'n nek en was zo stom om wat l33te mysqlpasswords te lekken naar een kleine groep gebruikers, en dat was uiteraard niet de bedoeling. Vandaar dat we even rap wachtwoorden moesten aanpassen. Alleen vergaten we dat we nog gedeeltelijk oude password-typen gebruiken waardoor de frontpage en het forum even de weg kwijt waren. Het was wel binnen 5 minuten opgelost, maar netjes is anders, sorry

28-03-2007 Aanstaande vrijdag zijn wij van plan de mailserver te upgraden. Zoals je al eerder in verschillende .plans hebt kunnen lezen staat deze vervanging al een tijdje op stapel. Komende vrijdag is het dan eindelijk zover en vervangen we de oude Appro door een gloednieuwe Sun bak met up-to-date soft- en hardware. De mailservices zullen vanaf 13:00 voor ongeveer 2 uur minder goed bereikbaar zijn.
Update: Het een en ander liep nogal uit, maar vanaf een uur of 19:00 zou alles weer moeten werken, zo niet, jullie weten ons vast wel te vinden

Serverstatus (5 minuten vertraagd)

Server- & netwerkstatusmeldingen VIII

Lees meer

Reacties (94)

Sorteer op:

Weergave: