Zaterdag 20 december onderhoud van GoT database-server

Zaterdag 20 december zal de langverwachte upgrade van Apollo, de database-server van het forum, plaatsvinden. De huidige dual Athlon MP-configuratie lijdt sinds enkele maanden aan een instabiliteitskwaal waardoor deze afhankelijk van zijn humeur eens in de paar weken tot een aantal keren per week op zijn plaat gaat, met downtime en corrupte databases als gevolg. De nieuwe machine bestaat uit een Appro 2128Hs barebone met twee Opteron 242-processors, 6GB RAM en zes 10.000rpm SCSI harde-schijven. De vervanging van Apollo zal in de middag uitgevoerd worden en tot gevolg hebben dat het forum enige tijd onbereikbaar zal zijn. Bij een succesvolle upgrade zal de downtime ongeveer twee uur bedragen.

Apollo III is in grote lijnen gelijk aan de nieuwe database server van de frontpage die in november Dec 20 22:35:00 apollo kernel: Unable to handle kernel paging request at virtual address 00000103c003a644
Dec 20 22:35:00 apollo kernel: printing rip:
Dec 20 22:35:00 apollo kernel: ffffffff80148b29
Dec 20 22:35:00 apollo kernel: PML4 8063 PGD 0Op dit moment hebben we geen idee wat de oorzaak is en we raadplegen uiteraard alle bronnen die ons aan een oplossing zouden kunnen helpen. Hierdoor is het onmogelijk een prognose te geven hoelang de problemen nog voort zullen duren.

16:00: Vandaag om 14:30 was Roelant ter plaatse om Apollo wederom wat bemoedigende woordjes toe te spreken. Na de nodig fsck's durfde Apollo het weer aan om normaal te booten en maakte ACM van de gelegenheid gebruik om de kernel bij te werken en wat instellingen te wijzigen. Het lijkt er op dat alles nu naar behoren functioneert, maar we willen nog even wachten met juichen tot het een paar uur stabiel draait.

23:35: Apollo draait nu zo'n 8,5 uur zonder problemen en suggereert daarmee weer stabiel te zijn. Daarmee mag het onderhoud van 20 (en 21) december definitief als 'ten einde' worden beschouwd.

Apollo III tijdens het kopiëren van de databases

Onze Appro serverfarm met van boven naar beneden Apollo, Artemis en de vier webservers

Reacties (142)

[pven]

Hier staat een berichtje van iemand bij wie een dergelijk probleem oploste na het vervangen van het geheugen.

[DiGuru]

De server krijgt zo te zien een tweede page fault op een pagina die gemapt is helemaal bovenaan het geheugen. Dat gebeurt normaal wanneer de index waarin staat waar een pagina zich in de swapfile bevind ook in de swapfile zit en er geen voorziening is deze terug te lezen. De mogelijke oorzaak daarvan is, dat de gereserveerde ruimte voor de page table in het geheugen te klein is.

Hoe je dat instelt onder Linux weet ik niet. En of je dat in moet stellen voor de kernel (waarschijnlijk) of voor een applicatie (onwaarschijnlijk) weet ik ook niet.

[DiGuru]

Een andere mogelijke oplossing is de kernel vertellen dat hij niet de hele 64 bits adresruimte mag gebruiken (als dat al kan). Ik kan me voorstellen dat dat nu nog problemen op kan leveren. Er hoeft maar een onderdeeltje niet met zo'n groot adres overweg te kunnen en het gaat fout. De server blijft dan draaien totdat de hoogste pages geswapt worden.

[Kees]

Tja, wij dachten ook aan dit probleem, en daarom heb ik de kernel op een gegeven moment ook gezegt dat hij niet meer dan 4G mocht gebruiken, hetgeen in de tests tot nu toe als gevolg had dat hij ook niet meer gebruikte.

Dit had ik ongeveer om 12 uur aangezet, echter de dbase craste wel (met een enorm swap verbruik ineens.)

Ik denk dat het probleem wat je hierboven beschrijft oa opgevangen moet worden door iommu, dit staat in de bios op best fit, en de kernel is een aantal keer geboot met iommu=force. Het grootste probleem dat arjen hierboven nog niet vertelde is dat er ook sporadisch filesystem corruptie optreed, zo was op een gegeven moment de helft van /bin en /usr/bin verdwenen (gelukkig kon ik met 'mc' wat bin's kopieren van een ander systeem waarop ik weer met rpm de rest kon installen).

Overigens, om de reacties voor te zijn van 'dat test je toch', dat hebben we gedaan, de server heeft vanaf woensdag prima gedraait en een dikke 1.000 miljoen queries gedaan onder een load die een stuk hoger is dan hij normaal te verwerken krijgt. Het enige probleem van de tests was dus blijkbaar dat de geteste dataset niet groot genoeg was om de server zijn geheugen helemaal vol te krijgen (ook dat is getest, dmv een paar cp's van een linux-kernel-source krijg je je geheugen ook best snel heel vol ) maar dat resulteerde niet in een crash.. waarom hij dus nadat hij lekker 2 uur draaide ineens WEL ging crashen is ons dus een raadsel, mede omdat hij ook crasht als a) de swap helemaal uitstaat en b) het geheugen gelimiteerd wordt op 4G en c) iommu=force acpi=off resulteerd in een corrupt FS. Nu hebben we de raidcontroller ook voorzien van het laatste bios (16 december uitgekomen) waardoor er een aantal problemen het PCI-X opgelost moeten zijn, maar de server crashte pas toen wij al weer buiten stonden..

Waarschijnlijk gaat er morgen iemand heen, en anders ga ik overmorgen weer aan die bak zitten om te zien of het crashen op te lossen is, ik verwacht iig niet dat ik hem vanavond nog weer up krijg, zowiezo ga ik eerst slapen, ben er al vanaf 11 uur vanochtend mee bezig zo ongeveer. (en femme moet nu nog naar ruurlo rijden, die is nog later thuis )

Maargoed, een aantal concrete oplossingen die ik wil gaan testen, input is uiteraard gewenst:
- andere kernel, zelf gebakken, met IOMMU en NUMA support
- kernelopties iommu=[no]force, acpi aan/uit [aanvullingen gewenst]
- LSI mailenbomben waarom ze zulke brakke drivers hebben dat die spontaan a) raid configs vergeten b) bios niet kan laden c) FS corrupt maken
- ....

[Kees]

Interesant, dit vind ik nu net in de changelog van 2.6.0-test11-AMD64 patch (van ftp.x86-64.org), hier hebben wij dus ook mee te maken, en wederom een leuke kerneloptie om uit te proberen
Some people report disk corruptions with IOMMU. Not able to reproduce it.
It seems to happen on some block device drivers who have a very deep
queue. Mostly these devices don't need an IOMMU (3ware is a prominent
exception) because they support 64bit IO. Unfortunately many people
still run with CONFIG_IOMMU_DEBUG which will force the IOMMU support
for every device. Changing the IOMMU flush to flush on every mapping
seems to fix it. Currently there are workarounds active that
check for Qlogic and 3ware and do that. Anybody still seeing this please
try with iommu=fullflush and report back.
Underlying bug still undebugged.

[DiGuru]

Petje af! Jullie hebben er duidelijk alles aan gedaan wat mogelijk is! Het probleem zit hem dus waarschijnlijk in het moederbord, SuSE, de database-server, of een kombinatie daarvan.

Blijkbaar is er ondanks de beperking van het adresseerbare geheugen tot 4GB toch een proces dat geheugen vlak onder de 64-bit limiet gebruikt. En waarschijnlijk crashed de zaak omdat de kernel daar dan niet mee om kan gaan. En blijkbaar corrupteert dat het file system.

De hoofdverdachte is dan toch waarschijnlijk de database-server, als hij dringend meer geheugen nodig heeft. Zeker als je er rekening mee houd, dat de kernel zich voor zover jullie hebben kunnen bepalen netjes aan die limiet houdt. Of misschien dat de database (of het file-subsystem) probeert te veel file-blokken te bufferen (dat zou ook verklaren waarom hij dan ineens zo gaat swappen).

Wat gebeurde er precies voordat je het geheugen limiteerde op 4GB? Het zou misschien toch al helpen als je de hoeveelheid geheugen voor de page table flink oprekt.

EDIT: Ik zag net je vorige post. Ja, dat zou het inderdaad wel eens kunnen zijn!

[Klovan]

Nou, heel veel succes d'r maar mee!

Jammer dat het niet gelijk ging zoals je verwachtte, maar met dit soort grote dingen kan er natuurlijk altijd wel wat mis gaan. Ondanks dat alles toch goed getest is.

En een dagje zonder GoT is ook weer ff wat anders

[Robinski]

Misschien Linux Kernel 2.6 gaan draaien?
of denk ik nu te makkenlijk / lastig?

[DiGuru]

(Als je als programmeur per ongeluk een Long Int gebruikt ipv. een Unsigned Long voor een adres. Dan gaat het tot de helft van het geheugen goed.)

[jwpmzijl]

Voor het geval iemand van de crew dit nog leest. Zojuist is GOT plat gegaan (althans ik krijg mooie teksten te zien: Warning: mysql_connect(): Can't connect to MySQL server on '192.168.1.4' (113) in /mnt/web/react/got/react/global/non-www/actionclasses/list_categories.classes.inc.php on line 1750). Een half uur geleden had is wel toegang. Ik vrees dat er dus nog iets niet helemaal correct is. Succes met troubleshooten!

[PromWarMachine]

Inderdaad, deze krijg ik ook. Dat mag duidelijk zijn. Eerder had ik geen toegang, toen weer wel, na half 1. Nu weer niet. Er is blijkbaar inderdaad nog iets aan de hand. Veel succes, zal aan jullie denken.

[Verwijderd]

Oei, we mogen mazzel hebben dat het niet tijdens het spitsuur is gebeurd

[MadMan]

Ik heb het vermoeden dat jullie de volgende melding:

Dec 20 22:35:00 apollo kernel: Unable to handle kernel paging request at virtual address 00000103c003a644
Dec 20 22:35:00 apollo kernel: printing rip:
Dec 20 22:35:00 apollo kernel: ffffffff80148b29
Dec 20 22:35:00 apollo kernel: PML4 8063 PGD 0

Waarschijnlijk door een configuratiefout in de dpms service krijgen De service dpms kan worden uitgezet door het volgende commando:
xset -dpms
in te voeren.

@ sprite_tm: Ik kan het natuuurlijk ook fout hebben. Ik heb dit gevonden na een search en hulp van mijn broer die een it-opleiding volgt.

ff tussen haakjes: why is mijn post "grappig"?

edit: typo's en aanvulling

[Sprite_tm]

Errm, als ik me niet vergis is DPMS een monitor power management iets, dat heeft weinig met de server die hier draait te maken. En het lijkt me al helemaal niet dat ze op deze machine ook nog es X hebben draaien, dus xset zal niet werken.

[neographikal]

Wordt nou ook de AMD64 versie van MySQL gedraaid gecompiled met gcc 3.3.2?

Ben benieuwd hoe hij dan gaat presteren aangezien het met gcc 3.2.2 nogal tegenviel. Is dit al getest?

Is de Suse versie volledig AMD64 geoptimaliseerd?

Zomaar een paar vraagjes

Zijn jullie trouwens niet bang voor stabiliteitsproblemen op Alicia ivm de problemen met Apollo? Zou het niet handiger zijn Artemis II te strippen?

Misschien dat het verstandig is om een standaardservertje mee te nemen naar de colo, zodat het forum iig draait. Misschien niet heel erg snel, maar het draait tenminste. Moet op zich te doen zijn, aangezien Apollo niet extreem snelle cpu's nodig heeft (max wat de MP's deden lag op zo'n 35%). Geheugen is misschien een probleem, maar een langzaam forum is beter dan geen forum en dan hebben jullie de tijd om de boel te debuggen

Waarom een score van 0? Dit zou getest worden hoor dus zulke stomme vragen zijn het niet....

[T.T.]

De vervanging van Apollo zal in de middag uitgevoerd worden en tot gevolg hebben dat het forum enige tijd onbereikbaar zal zijn.

Nog technische redenen om dit 's middags te doen, of hebben jullie geen zin om ter meerdere ere van GoT 's nachts aan het werk te gaan?

[Femme]

Overdag upgraden komt gewoon veel beter uit. Als je 's middags begint is het geen probleem als de werkzaamheden een paar uurtjes uitlopen. Zou je 's nachts werken, dan ben je bij wat vertragingen pas om 7:00u 's ochtends of nog later klaar. Bovendien wonen ik en Kees in het oosten van het land. Het kost mij bijna twee uur om in Amsterdam te komen.

[eborn]

Hmm, geef anders die servers volgende keer gewoon even mee als ik weer naar TC moet. Ik zal er heeeeel goed op passen

Binnen twee uur van Ruurlo naar Amsterdam vind ik trouwens al rap. Hoewel het met de auto natuurlijk beter te doen is dan met de Openbare Vertraging.

[jep]

Ik kom uit het oosten (Didam) en doe er naar Telecity 55 minuten over. Femme, volgens mij ga je over groningen als je er 2 uur over doet .

[burne]

130 kilometer, 1 uur 42 minuten, volgens de routeplanner.

[Alex]

Ik denk dat Kees en Femme gewoon een dataum hebben gekozen die het dichtste bij lag waarop ze allebei konden. En dan is 's-nachts erg vervelend werken als je net als Kees een gewone baan hebt. Daarbij zijn ze vanuit TrueServer en als helemaal niet vanuit TeleCity2 blij met nachtelijke upgrades...

[jep]

Waarom zou True of TC2 niet blij zijn met die upgrades? Ze zijn 24/7/365 open. 's Nachts is alleen maar beter, dan vervelen ze zich niet zo bij de bewaking .

[eborn]

Ze vervelen zich nu natuurlijk helemaal, omdat de Fok! en T.Net forums down zijn

[hennink]

Wat is dat nu voor onzin.
Wij doen per voorkeur al het onderhoud 's nachts en ben nog nooit iemand van TS of Telecity tegengekomen die daar moeilijk over doet.

[Rafe]

Zo vangen de normaal gesproken GoTtende nerds weer wat zonlicht op natuurlijk

[RRX]

Nou, ik denk dat er vandaag, uit het raam kijkend, niet veel kans is op een glimpje zonlicht

[Verwijderd]

Hehe, nu snap ik wat ze bedoelen met "reanimeren".
Volgens mij is het Femme die momenteel op z'n knieën voor een computer licht 'iets' te doen (op de Trueserver cam). Ik zie geen shock-apparaat, dus het zal handwerk zijn.

Zodra er mond-op-mond beademing word toegepast geef ik wel een schreeuw!



EDIT:
Kan degene die daar zit ff zwaaien naar de cam? Dan kan ik in elk geval zien wie het is

[Femme]

Ik ben aan het meuken .

Maar ik zal ff gaan zwaaien voor alle fans

[satcp]

Ik kijk ook eens één keer naar de webcam en staat Femme daar toch wel naar mij te zwaaien zeker

Voor de fans die het gemist hebben: Femme in Telecity-2

[KillerDream]

LOL

Ik heb niet eens beeld hier.
De CAM is overbelast...

[oli4100]

Kan degene die daar zit ff zwaaien naar de cam? Dan kan ik in elk geval zien wie het is

Ik denk dat die met zn hoofd op dit moment bij andere zaken zit....

edit: die webcam gaat nu onwijs traag, volgens mij zijn er meer mensen op het idee gekomen dit te volgen

edit2: Het forum doet het weer bij mij

[Glashelder]

wat betreft die snelheid, dat dacht ik eerst ook, maar toen ik beter keek blijkt het dat de persoon die met die server aan het 'spelen' is bijna niet beweegt

[Robinski]

er neemt iemand fotos en hij swaait

[M.I.G.]

En kijk ff wat in dat doossie zit...misschien nog wat reepjes?

[Thyzz]

Is er ook al bekend wanneer de database server van fok vervangen wordt? Ik vind het zielig voor ze dat ze de search moesten uitschakelen omdat ze anders te veel 'load' hebben.

Hij schijnt het nu wel te doen, maar ze hebben wel een verschrikkelijke load.

[Rob]

Ik geloof dat ze hardware gaan rouleren, dus misschien komt er wat beters bij Fok te staan.

[Daniel]

Het Fok!-serverpark zal ook zo snel mogelijk verblijd worden met de aanwezigheid van twee dual Opteron machines.

[veldmuis]

En die downtime die Fok vreesde was niet geheel onterecht

[BèR]

Het forum van Fok is nu (20-12 16u45) al een kwartier compleet in paniek, ze vrezen downtime.

@veldmuis: Waarom dan nu toch nog 0 - Overbodig??

[Brons]

Ik zie dat de kast ook een stuk kleiner geworden is!
Hebben jullie ruimte tekort in jullie rack ofzo? (dacht dat ik ergens gelezen had dat het vol zit)

[Alex]

Dat was een tijdje terug. Inmiddels zijn veel van de 4U kasten vervangen door 2U's

[Marc2984]

een Appro 2128Hs barebone

Bedoel je niet een rackmount?

[twan1]

nee, het is een barebone. Appro verkoopt barebone servers, je moet er dus nog wel zelf de ram, ... en dergelijke instoppen.

Net zoals een Shuttle barebone. Die Appro barebones zitten nu eenmaal in een rackmount