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 , , 142 reacties, 1.749 views •

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.

Appro 2128H rackmount (klein)Apollo III is in grote lijnen gelijk aan de nieuwe database server van de frontpage die in november in bedrijf werd genomen. Verschillend zijn de snelheid van de processors (1,6GHz in plaats van 2,0GHz), de hoeveelheid geheugen (6GB in plaats van 4GB) en de snellere bootschijven (2x 36,7GB Cheetah 10K.6 in plaats van 2x 9,2GB Cheetah 18XL). Beide servers hebben twee schijven in RAID 1 als boot array, drie schijven in RAID 5 voor data en een zesde schijf als hotspare.

De configuratie van Apollo liep enige vertraging op door problemen met de beta van SuSE Linux 8 voor het AMD64-platform en een slecht werkende MegaRAID-driver onder SuSE Linux 9. De machine draait inmiddels stabiel onder SuSE Linux 9. Onze eerste benchmarks wijzen uit dat de MySQL performance van Apollo III ondanks zijn lagere kloksnelheid niet slechter is dan van Artemis III. Waarschijnlijk is dit te danken aan de recentere SuSE-versie op Apollo III.

Apollo IApollo IIApollo III
Ingebruikname15-06-200131-08-200220-12-2003
Processors2x PIII-10002x Athlon MP 1900+2x Opteron 242
Geheugen2GB PC1333,5GB PC21006GB PC2100
MoederbordAsus CUV4X-DTyan Tiger MPTyan Thunder K8S
ChipsetVIA Apollo Pro 133AAMD 760MPAMD-8000
RAID-adapterAdaptec 3200SAdaptec 3200SLSI MegaRAID Elite 1600
Harde schijven2x 18,4GB Atlas 10K II1x 20GB ATA
5x Cheetah 36XL 36,7GB
6x Cheetah 10K.6 36,7GB
Behuizing Antec U3U20ATX300 3UCI-Design RS4100 4UAppro 2128Hs 2U

Voortgang van de werkzaamheden:

  • 15:40: Kees en Femme zijn gearriveerd in TeleCity. Artemis II (die nog in het rack draaide) is net down gehaald na 450 dagen uptime. Naast de bovengenoemde werkzaamheden zal vandaag tevens gepoogd worden om de database-server van Fok! een upgrade te geven van dual PIII 1GHz naar dual Athlon MP 1600+ en is het de bedoeling dat Aphrodite (webserver van Fok!) wordt vervangen door een dual Opteron 240.

  • 16:00: De database van Apollo wordt gekopieerd naar de nieuwe server. Dit zal enige tijd duren (~2 uur) in verband met de grootte van de database en het feit dat de oude server geen gigabit ethernet heeft. In de tussentijd is het forum onbruikbaar.

  • 16:30: De mailserver (Arethusa) is downgehaald wegens vervanging van een schijf die nodig is voor de nieuwe Aphrodite.

  • 17:20: De harde schijf in de mailserver is vervangen. Mail en IRC zijn weer online.

  • 17:50: De databases zijn gekopieerd naar Apollo III. De server is op zijn plaats gezet en het forum draait weer. Er zal nu begon worden met de ontmanteling van Apollo II zodat Alicia kan worden geupgrade naar dual Athlon MP.

  • 0:20: Apollo gedraagt zich helaas nog niet helemaal naar behoren. De oorzaak is nog onduidelijk. Apollo zal om die reden voorlopig met 4GB geheugen gaan draaien. Uit de restanten van Apollo II, Artemis II en de storage hardware van Alicia wordt een nieuwe super-Alicia gecreeŽrd.

  • 1:04: Alicia is weer online na transplantatie van een Thunder K7, twee Athlon MP 1900+, 3GB DDR SDRAM en de 20GB bootdrive van Apollo II.

  • 2:40: Rond 01:45 hebben Femme en Kees na 10 uur zwoegen TeleCity-2 verlaten, een instabiele Apollo achterlatend. Om onverklaarbare reden crasht Apollo soms al binnen een half uur, vele nachten testen, proefdraaien en benchen ten spijt. Daarbij wordt de volgende warning in het syslog achtergelaten:
    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
    Op 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 databasecopy
Apollo III tijdens het kopiŽren van de databases
Tweakers.net Appro serverfarm
Onze Appro serverfarm met van boven naar beneden Apollo, Artemis en de vier webservers

Reacties (142)

Reactiefilter:-11420141+1112+224+33
Moderatie-faq Wijzig weergave
1 2 3 ... 7
Hier staat een berichtje van iemand bij wie een dergelijk probleem oploste na het vervangen van het geheugen.
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.
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.
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
- ....
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.
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!
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 :)
Misschien Linux Kernel 2.6 gaan draaien?
of denk ik nu te makkenlijk / lastig?
(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.)
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!
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. :)
Oei, we mogen mazzel hebben dat het niet tijdens het spitsuur is gebeurd :)
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
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.
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....
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? :)
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.
Hmm, geef anders die servers volgende keer gewoon even mee als ik weer naar TC moet. Ik zal er heeeeel goed op passen :P ;)

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.
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 ;).
130 kilometer, 1 uur 42 minuten, volgens de routeplanner.
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...
Waarom zou True of TC2 niet blij zijn met die upgrades? :D Ze zijn 24/7/365 open. 's Nachts is alleen maar beter, dan vervelen ze zich niet zo bij de bewaking :Y) :).
Ze vervelen zich nu natuurlijk helemaal, omdat de Fok! en T.Net forums down zijn ;)
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.
Zo vangen de normaal gesproken GoTtende nerds weer wat zonlicht op natuurlijk ;)
Nou, ik denk dat er vandaag, uit het raam kijkend, niet veel kans is op een glimpje zonlicht ;)
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!

:D

EDIT:
Kan degene die daar zit ff zwaaien naar de cam? Dan kan ik in elk geval zien wie het is :P
Ik ben aan het meuken :*) .

Maar ik zal ff gaan zwaaien voor alle fans 8-)
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 :)
LOL :)

Ik heb niet eens beeld hier.
De CAM is overbelast... 8-)
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 :o

edit2: Het forum doet het weer bij mij :D
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 :+
er neemt iemand fotos en hij swaait
En kijk ff wat in dat doossie zit...misschien nog wat reepjes?
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.
Ik geloof dat ze hardware gaan rouleren, dus misschien komt er wat beters bij Fok te staan.
Het Fok!-serverpark zal ook zo snel mogelijk verblijd worden met de aanwezigheid van twee dual Opteron machines.
En die downtime die Fok vreesde was niet geheel onterecht :+
Het forum van Fok is nu (20-12 16u45) al een kwartier compleet in paniek, ze vrezen downtime. :z

@veldmuis: Waarom dan nu toch nog 0 - Overbodig?? ;)
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)
Dat was een tijdje terug. Inmiddels zijn veel van de 4U kasten vervangen door 2U's :)
een Appro 2128Hs barebone
Bedoel je niet een rackmount?
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 ;)
1 2 3 ... 7

Op dit item kan niet meer gereageerd worden.



HTC One (M9) Samsung Galaxy S6 Grand Theft Auto V Microsoft Windows 10 Apple iPad Air 2 FIFA 15 Motorola Nexus 6 Apple iPhone 6

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True