Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 94, views: 89.747 •

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 statistiekenpagina.

*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
    dataverkeer na launch

  • 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

    * Februari 2006 - Maart 2007 statusmeldingen VII
    *Januari 2008 - statusmeldingen IX

    * Serverstatus (5 minuten vertraagd)

  • Reacties (94)

    Gaat die oude Appro echt met pensioen (Vraag en Aanbod \o/), of krijgt hij een andere functie, en vindt er een grote doorschuifronde plaats?

    @onder: Typo :/
    Die server gaan ze gebruiken als spelfoutenchecker zodat "oude" niet meer als aude geschreven kan worden.
    Dit is helemaal geen slecht idee (serieus!). Er zijn op Tweakers en GoT zo veel mensen die "echt" als "egt" schrijven.. werkelijk waar tenenkrommend. En als je mensen er op wijst door middel van een posting krijg je een uitbrander van een modje. :/ (Tsja.. doe er dan ZELF wat aan, ffs!)
    Sorry, ik ben niet blind, doof of stom (no flame ;))

    Maar wtf is fonetisch?¿?
    Van Dale, here i come...

    EDIT
    En die zegt dit:
    fo·ne·tisch (bn.)
    1 betr. hebbend op de vorming van de spraakklanken => fonisch

    [Reactie gewijzigd door hp197 op 19 december 2007 09:18]

    Waarschijnlijk gaat deze appro aeolus in ons testpark vervangen, Aeolus is een prima machine, maar de mensen die ernaast zitten klagen dat 'ie teveel herrie maakt :P
    Aeolus zal dan waarschijnlijk verpatst worden :)
    Naam en machine vervangen door naam en collega en hetzelfde is mss ook wel waar :+
    als adonis is vervangen, eergisteren waarom staat er dan in de tabel dat ie al 19 dagen draait?
    ik weet dat het script een vertraging heeft van 5 minuten, maar dat is toch al voorbij? :+

    of draait hij al 19 dagen en zijn alleen de services nu overgenomen door de sun bak?
    Omdat we hem al even geleden hebben opgehangen? -> plan: Fotoverslag serveronderhoud 09-03-2007
    Hij draait inderdaad al 19 dagen en de services zijn nu pas overgenomen. Het is een stuk makkelijker werken vanuit de burostoel dan in een lawaaierige serverruimte, daarom proberen we zoveel mogelijk te voorkomen dat we andere dan fysieke handelingen moeten doen als we met de servers bezig zijn.
    Tijd om de config van Adonis up te daten in het tabelletje ;).
    Zo beter Kuikentje? :>
    Prima moto'tje... over de serverpark review zal ik maar niet klagen O-) snap ook wel dat het een bitch is om steeds bij te houden :>
    Mjah, tis meer de vorm waarin het nu staat die me niet echt aanstaat, en ik heb nog geen ideeen om het beter op te zetten waardoor het automatisch up-to-date wordt gehouden.
    En rethusa draait vandaag net 1 jaar..

    Laat die taart maar komen !
    Eerder voor een nieuwe kernel :P
    Zeg, zijn die loadbalancers gerebooted?
    Of is het een fout in het script?
    Zijn gereboot, nieuwe kernel gekregen, oude was nog < .16 dus vandaar dat je ze niet kon pingen :)
    Ik neem aan dat de test omgeving een andere database server (en wachtwoord) gebruikt dan welke voor de de productie database wordt gebruikt?

    Een fout kan gebeuren, maar de gevolgen (productie website plat vanwege een test database) komen nogal amateuristisch over.

    Elke systeembeheerder weet dat test en productie systemen software- en hardware matig uit elkaar gehouden moeten worden. Juist om dit soort problemen te voorkomen.
    Elke systeembeheerder weet dat test en productie systemen software- en hardware matig uit elkaar gehouden moeten worden. Juist om dit soort problemen te voorkomen.
    Dat was het toch ook? Alleen waren er (voor zover ik het hier lees) per ongeluk een paar passwords gelekt, en wat doe je als goed systeembeheerder zodra er ook maar 1 admin-like password is gelekt? Juist alle passwords veranderen, dus niet alleen van je test omgeving maar ook van de "productie omgeving" :)
    Hoe heeft dit nou kunnen uitlekken? Die passworden staan toch in een php-config-file (die dus een HTML output heeft).
    react kan dumps sturen als er iets mis gaat, en daar staan dankzij onze eigen wijzigingen ook blijkbaar passwords in.
    Kunnen die wachtwoord niet encrypted worden opgeslagen (MD5)?
    Er zal ergens in een config file het wachtwoord van de database opgeslagen moeten worden. Deze kun je wel md5 encrypten, maar die krijg je daarna nooit meer terug. Je kan dan wel een 2 way encryptie techniek gebruiken, maar dan moet je weer ergens de key opslaan om het wachtwoord te decrypten, maar dan heb je weer het zelfde probleem met de key :).
    Je kunt toch een hash maken, en bij een ingevoerd/ingevuld/weetikveel wachtwoord daar ook een hash van maken, en dan de twee hashes vergelijken :) ?
    Idd, als je wachtwoord 'test' is.... dan kan dit ook:

    MD5('test') === MD5(password)
    Ik vind het mooi voor jullie dat er bijna niets meer mis gaat maar ik mis het hobbygevoel wel van t.net.

    geen vage ducttape installaties op servers en dat soort fratsen. Zucht.. het kleine mannetje wordt groot. :D
    is er iets mis met de irc server?
    irc doet het wel gewoon :S
    Het is al een tijdje zo, ik weet ook niet waarom. Misschien iets mis met het monitoring progje?
    Tweakers IRC bestaat uit 2 servers (correct me if wrong), arethusa en osiris. Als je connect zul je in je server window zien dat je connect naar Osiris.parse.nl.
    arethusa.tweakers.net/irc.tweakers.net/irc.fok.nl doet het prima hoor, XplodingForce heeft gelijk, dat stomme programma stuurt niets naar de database en daardoor lijkt Arethusa down, ik ga ff kijken waardoor dat komt :)

    Op dit item kan niet meer gereageerd worden.



    Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

    © 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

    Beste nieuwssite en prijsvergelijker van het jaar 2013