Wat is ecc in operationeel. Soorten RAM

Heel vaak komen we bij het kiezen van componenten verschillende onbegrijpelijke termen en concepten tegen. Bij het kiezen van RAM kan dit DDR, DDR2, DDR3, DDR4, RDRAM, RIMM, enz. zijn. Als alles min of meer duidelijk is met de belangrijkste typen RAM en ondersteuning voor elk type wordt aangegeven in de beschrijving van het moederbord, dan roept een parameter als ECC voor velen vragen op. Wat is ECC-geheugen? Is het mogelijk om ECC RAM op een thuiscomputer te gebruiken en wat is het belangrijkste verschil tussen ECC RAM en niet-ECC RAM?

Wat is ECC-geheugen?

Dit is een speciaal soort RAM met ingebouwde hardware voor foutcorrectie. Dergelijke geheugenmodules zijn speciaal ontwikkeld voor servers, waar de eisen voor de juistheid van gegevens en de betrouwbaarheid van hun verwerking veel hoger zijn dan op personal computers.

ECC-Ram herkent automatisch spontane gegevenswijzigingen in opslagblokken, dat wil zeggen fouten die zijn opgetreden. Normaal - desktopgeheugen zonder ondersteuning voor correctiemechanismen wordt niet-ECC genoemd.

Waartoe is ECC-geheugen in staat en hoe werkt het?

Het foutcorrigerende geheugen kan 1 bit gewijzigde gegevens in elk machinewoord detecteren en corrigeren. Wat betekent het? Als de gegevens tussen schrijven en lezen om de een of andere reden zijn gewijzigd (dat wil zeggen, er is een fout opgetreden), dan zal het ECC RAM de waarde corrigeren naar de juiste waarde. Dergelijke functionaliteit vereist ondersteuning van de RAM-controller. Deze ondersteuning kan worden georganiseerd door de chipset van het moederbord, de ingebouwde RAM-controller in moderne processors.

Het foutcorrectie-algoritme is gebaseerd op de Hamming-code, maar andere algoritmen worden gebruikt om meer dan één fout te corrigeren. In de praktijk worden geheugenmodules gebruikt, waarbij voor elke 8 geheugenchips één extra chip wordt toegevoegd die ECC-codes opslaat (8 bits voor elke 64 bits van het hoofdgeheugen).

Waarom is de waarde in RAM-geheugencellen vervormd?

Een van de belangrijkste oorzaken van gegevensvervorming is kosmische straling. Hoewel we op aarde worden beschermd door de atmosfeer, dragen kosmische straling enkele elementaire deeltjes met zich mee die elektronica kunnen aantasten, inclusief computergeheugen. Onder invloed van de energie van deze deeltjes is een verandering in de toestand van de geheugencel mogelijk, wat leidt tot gegevensvervorming en fouten. Interessant is dat de blootstelling aan kosmische straling toeneemt met de hoogte, dus computersystemen op grote hoogte vereisen betere bescherming.

Hoe ECC-geheugen werkt

Een van de foutcontrolemechanismen in RAM is het gebruik van pariteitstechnologie, waarmee u het feit van een fout in de gegevens kunt herstellen, maar niet kunt corrigeren.

Hamming-code wordt gebruikt voor ECC-correctie. ECC beschermt computersystemen tegen onjuiste werking als gevolg van geheugenbeschadiging en vermindert de kans op een kritieke systeemstoring. Geheugen met ECC-ondersteuning is 2-3% langzamer dan niet-ECC-geheugen, afhankelijk van de toepassing.

Redenen om ECC-geheugen te gebruiken

Er is geen objectieve reden om ECC-enabled RAM in desktopcomputers te gebruiken. Aangezien de kans op het optreden van gegevensfouten extreem klein is, is het in normale pc-gebruiksscenario's uiterst onwaarschijnlijk dat een fout problemen of crashes op de pc veroorzaakt. Het meest verschrikkelijke scenario is het verschijnen van een blue screen of death BSOD. Daarnaast is het gebruik van ECC-RAM lastig omdat de meeste desktopprocessors en moederborden dit type RAM niet ondersteunen.

Het gebruik van RAM met ECC-foutcorrectie is relevant voor het server- en bedrijfssegment, waar de vereisten voor fouttolerantie en betrouwbaarheid zeer hoog zijn, en de correctheid van de gegevens de resultaten van berekeningen en de werking van het systeem als geheel kan beïnvloeden .

Ook kunnen ECC-gegevensbeschermingsschema's worden toegepast op het geheugen dat in microprocessors is ingebouwd: cachegeheugen, registerbestand. Soms wordt controle ook toegevoegd aan rekencircuits.

beschrijving van het probleem

Er bestaat bezorgdheid dat de trend naar kleinere fysieke afmetingen van geheugenmodules zal leiden tot een toename van het foutenpercentage omdat deeltjes met een lagere energie de bit kunnen veranderen. Anderzijds verkleint het compacte formaat van het geheugen de kans dat er deeltjes in terecht komen. Bovendien kan het overstappen op technologieën zoals silicium op een isolator het geheugen stabieler maken.

Een onderzoek uitgevoerd op een groot aantal Google-servers toonde aan dat het aantal fouten kan variëren van 25.000 tot 70.000 fouten per miljard werkuren (engels apparaaturen) per megabit (dat wil zeggen 2,5-7,0 × 10 × 11 fouten / bituur).

Technologie

Een oplossing voor dit probleem is pariteit - een extra bit gebruiken die de pariteit van de rest van de bits registreert. Met deze aanpak kunt u fouten opsporen, maar niet corrigeren. Dus wanneer een fout wordt gedetecteerd, kunt u de uitvoering van het programma alleen onderbreken.

Een betrouwbaardere benadering is er een die foutcorrigerende codes gebruikt. De meest gebruikte foutcorrigerende code is de Hamming-code. De meeste foutcorrigerende geheugens die in moderne computers worden gebruikt, kunnen een enkele bitfout in een 64-bits machinewoord corrigeren en een tweebitsfout in een enkel 64-bits woord detecteren, maar niet corrigeren.

De meest effectieve aanpak voor foutcorrectie hangt af van het soort fouten dat wordt verwacht. Vaak wordt aangenomen dat de verschillende bits onafhankelijk van elkaar veranderen. In dit geval is de kans op twee fouten in één woord verwaarloosbaar klein. Deze veronderstelling geldt echter niet voor moderne computers. Geheugen gebaseerd op foutcorrectietechnologie Chipkill(IBM), kunt u verschillende fouten corrigeren, ook wanneer de hele geheugenchip is beschadigd. Andere geheugencorrectietechnologieën die geen onafhankelijkheid van fouten in verschillende bits veronderstellen, zijn onder meer: Verlengd ECC(Sun-microsystemen), Spaan reserve(Hewlett-Packard) en SDDC(Intel).

Veel oudere systemen rapporteerden geen opgeloste bugs, maar rapporteerden alleen bugs die werden gevonden en niet konden worden verholpen. Moderne systemen registreren zowel gecorrigeerde fouten (CE, Engelse corrigeerbare fouten) als niet-corrigeerbare fouten (UE, Engelse niet-corrigeerbare fouten). Hierdoor kunt u beschadigd geheugen op tijd vervangen: ondanks het feit dat een groot aantal gecorrigeerde fouten bij afwezigheid van oncorrigeerbare fouten geen invloed heeft op de juiste werking van het geheugen, kan dit erop wijzen dat voor een bepaalde geheugenmodule de kans op oncorrigeerbare fouten zal in de toekomst toenemen.

Voor- en nadelen

Foutcorrigerend geheugen beschermt tegen onjuiste werking van een computersysteem als gevolg van geheugenbeschadiging en vermindert de kans op een fatale systeemstoring. Zo'n geheugen kost echter meer; het moederbord, de chipset en de processor die foutcorrigerend geheugen ondersteunen, kunnen ook duurder zijn, dus dergelijk geheugen wordt gebruikt in systemen waar een vlotte en correcte werking belangrijk is, zoals een bestandsserver, wetenschappelijke en financiële toepassingen.

Het foutcorrigerende geheugen is 2-3% langzamer (vaak is een extra cyclus van de geheugencontroller nodig om de sommen te controleren) dan conventioneel geheugen, afhankelijk van de toepassing. Aanvullende logica die het tellen, ECC-controle en foutcorrectie implementeert, vereist logische bronnen en tijd om te werken in de geheugencontroller zelf of in de interface tussen de CPU en de geheugencontroller.

zie ook

Opmerkingen:

1. Werner Fischer. RAM onthuld (onbepaald) . admin-magazine.com. Ontvangen 20 oktober 2014.
2. Gearchiveerde kopie (onbepaald) (niet beschikbare link). Ontvangen 20 november 2016. Gearchiveerd van het origineel op 18 april 2016.
3. Single Event Upset at Ground Level, Eugene Normand, Member, IEEE, Boeing Defense & Space Group, Seattle, WA 98124-2499
4. "Een overzicht van technieken voor het modelleren en verbeteren van de betrouwbaarheid van computersystemen", IEEE TPDS, 2015
5. Kuznetsov VV Zonne-terrestrische fysica (colleges voor studenten natuurkunde). College 7. Zonneactiviteit. // Zonnestormen. Staatsuniversiteit van Gorno-Altai. 2012
6. Gary M. Swift en Steven M. Guertin. "In-Flight Observaties van Multiple-Bit Upset in DRAM's". Jet Propulsion Laboratory
7. Borucki, "Vergelijking van versnelde DRAM-zachte foutpercentages gemeten op component- en systeemniveau", 46e jaarlijkse International Reliability Physics Symposium, Phoenix, 2008, pp. 482-487
8. Schroeder, Bianca; Pinheiro, Eduardo; Weber, Wolf Dietrich. DRAM-fouten in het wild: een grootschalig veldonderzoek (onbepaald) // SIGMETRICS/Prestaties. - ACM, 2009. - ISBN 978-1-60558-511-6.
9. StrongArm SA-1110 gebruiken in de boordcomputer van Nanosatellite (onbepaald) . Tsinghua Space Center, Tsinghua Universiteit, Peking. Ontvangen 16 februari 2009. Gearchiveerd van het origineel op 2 oktober 2011.
10. Doug Thompson, Mauro Carvalho Chehab. "EDAC - Foutdetectie en -correctie" Gearchiveerd van het origineel op 5 september 2009. . 2005-2009. "Het doel van de "edac"-kernelmodule is het detecteren en rapporteren van fouten die optreden in het computersysteem dat onder linux draait."
11. Bespreking van ECC op pcguide (onbepaald) . Pcguide.com (17 april 2001). Ontvangen 23 november 2011.

Zoals ik het begrijp, zijn zijn argumenten als volgt:

1. Google gebruikte ECC niet toen ze hun servers in 1999 bouwden.
2. De meeste RAM-fouten zijn systematische fouten, geen willekeurige.
3. RAM-fouten zijn zeldzaam omdat de hardware is verbeterd.
4. Als ECC-geheugen echt belangrijk zou zijn, dan zou het overal worden gebruikt, niet alleen in servers. Betalen voor dit soort optioneel materiaal is duidelijk te dubieus.

1. Google gebruikte ECC niet in 1999

A. Plaats uw servers in verzendcontainers.

B. Branden stichten in uw eigen datacenters.

Sommigen kijken misschien naar deze vroege Google-servers en zien het onprofessionalisme met betrekking tot het brandgevaar. Niet ik. Ik zie hier een visionair begrip van hoe goedkope, kant-en-klare hardware het moderne internet zal vormen.

Het laatste deel van wat werd gezegd is waar. Maar in het eerste deel zit een kern van waarheid. Toen Google hun eigen borden begon te ontwerpen, had een generatie van hen een "groei"-probleem ( ) dat een niet-nul aantal branden veroorzaakte.

Trouwens, als je naar Jeff's post gaat en naar de foto kijkt waarnaar in het citaat wordt verwezen, zul je zien dat er veel startkabels op de borden zitten. Dit veroorzaakte problemen en werd opgelost in de volgende generatie hardware. Je ziet ook nogal slordige bekabeling, die bovendien voor problemen zorgde en ook snel werd verholpen. Er waren nog andere problemen, maar die laat ik als oefening voor de lezer.

C. Creëer servers die uw werknemers verwonden

D. Creëer uw eigen weer in uw datacenters

Houd er rekening mee dat alles wat door Google is aangegeven, is geprobeerd en vervolgens is gewijzigd. Fouten maken en deze vervolgens herstellen is gebruikelijk in elke succesvolle ontwikkelingsorganisatie. Als je de ingenieurspraktijk verafgoodt, moet je op zijn minst vasthouden aan de moderne praktijk, en niet aan wat er in 1999 werd gedaan.

Toen Google in 1999 niet-ECC-servers gebruikte, vertoonden ze een aantal symptomen die uiteindelijk geheugenbeschadiging bleken te zijn. Inclusief een zoekindex die vrijwel willekeurige resultaten in zoekopdrachten opleverde. De feitelijke faalmodus is hier leerzaam. Ik hoor vaak dat ECC op deze machines kan worden genegeerd omdat fouten in individuele resultaten acceptabel zijn. Maar zelfs als u willekeurige fouten acceptabel vindt, betekent het negeren ervan dat er een gevaar bestaat voor volledige gegevenscorruptie, tenzij een zorgvuldige analyse wordt uitgevoerd om ervoor te zorgen dat één fout één resultaat slechts in geringe mate kan vervormen.

In onderzoek naar bestandssystemen is herhaaldelijk aangetoond dat het, ondanks heroïsche pogingen om systemen te maken die bestand zijn tegen een enkele fout, buitengewoon moeilijk is om dit te doen. In wezen kan elk zwaar getest bestandssysteem een ​​grote storing hebben als gevolg van een enkele fout (). Ik ga geen ontwikkelaars van bestandssystemen aanvallen. Ze zijn beter in dit soort analyses dan 99,9% van de programmeurs. Alleen is herhaaldelijk aangetoond dat dit probleem zo moeilijk is dat mensen het redelijkerwijs niet kunnen bespreken, en een geautomatiseerd hulpmiddel voor een dergelijke analyse is nog steeds verre van een eenvoudig proces met een muisklik. In hun Warehouse Computer Handbook bespreekt Google foutdetectie en -correctie, en ECC-geheugen wordt als de meest geschikte optie beschouwd wanneer het duidelijk is dat hardwarefoutcorrectie ( ) moet worden gebruikt.

Google heeft een uitstekende infrastructuur. Van wat ik heb gehoord over infrastructuur bij andere grote technologiebedrijven, lijkt Google de beste ter wereld te zijn. Maar dat betekent niet dat je alles wat ze doen moet kopiëren. Zelfs als alleen hun goede ideeën worden overwogen, heeft het voor de meeste bedrijven geen zin om ze te kopiëren. Ze creëerden een vervanging voor de Linux job hook-planner die zowel hardware-runtime-informatie als statische traces gebruikt, zodat ze kunnen profiteren van de nieuwe hardware in Intel-serverprocessors, waardoor dynamische cache-partitionering over kernen mogelijk is. Als u dit op al hun hardware gebruikt, bespaart Google in een week meer geld dan Stack Exchange in zijn hele geschiedenis aan al zijn machines heeft uitgegeven. Betekent dit dat je Google moet kopiëren? Nee, tenzij je al bent getroffen door manna uit de hemel, zoals het hebben van je kerninfrastructuur geschreven in sterk geoptimaliseerde C++ in plaats van Java of (God verhoede) Ruby. En het feit is dat voor de overgrote meerderheid van bedrijven het schrijven van programma's in een taal die een 20-voudige afname van de productiviteit met zich meebrengt, een volkomen redelijke beslissing is.

2. De meeste RAM-fouten zijn systematische fouten

Ons onderzoek heeft verschillende hoofdresultaten. Ten eerste ontdekten we dat ongeveer 70% van de DRAM-storingen repetitieve (bijv. permanente) storingen zijn, terwijl slechts 30% intermitterende (intermitterende) storingen zijn. Ten tweede ontdekten we dat grote multi-bit-storingen, zoals storingen die een hele rij, kolom of blok beïnvloeden, verantwoordelijk zijn voor meer dan 40% van alle DRAM-storingen. Ten derde ontdekten we dat bijna 5% van de DRAM-storingen van invloed zijn op circuits op bordniveau, zoals data (DQ) of gate (DQS) lijnen. Ten slotte ontdekten we dat de Chipkill-functie de frequentie van systeemstoringen veroorzaakt door DRAM-storingen met een factor 36 verminderde.

Ten eerste is de 2:1-verhouding niet groot genoeg om willekeurige fouten eenvoudigweg te negeren. Ten tweede impliceert de post Jeffs overtuiging dat systematische fouten in wezen onveranderlijk zijn en niet na een tijdje kunnen verschijnen. Dit is niet waar. Elektronica slijt op dezelfde manier als mechanische apparaten. De mechanismen zijn verschillend, maar de effecten zijn vergelijkbaar. Als we de betrouwbaarheidsanalyse van chips vergelijken met andere soorten betrouwbaarheidsanalyses, kunnen we zien dat ze vaak dezelfde distributiefamilies gebruiken voor het modelleren van fouten. Ten derde houdt Jeffs redenering in dat ECC niet kan helpen bij het opsporen of oplossen van bugs, wat niet alleen verkeerd is, maar ook rechtstreeks in tegenspraak is met het citaat.

Dus, hoe vaak gaat u memtest op uw machines uitvoeren in een poging om deze systeemfouten op te vangen, en hoeveel gegevensverlies bent u bereid te verduren? Een van de belangrijkste toepassingen van ECC is niet om fouten te corrigeren, maar om fouten te signaleren zodat hardware kan worden vervangen voordat "stille corruptie" optreedt. Wie zou ermee instemmen om elke dag alles op de machine te sluiten om memtest uit te voeren? Het zou veel duurder zijn dan alleen ECC-geheugen kopen. En zelfs als je me zou kunnen overtuigen om een ​​geheugentest uit te voeren, zou memtest niet zoveel fouten vinden als ECC kan.

Toen ik voor een bedrijf werkte met een vloot van ongeveer duizend machines, merkten we dat we vreemde fouten bij de controle op de gegevensintegriteit hadden, en na ongeveer zes maanden realiseerden we ons dat fouten op sommige machines waarschijnlijker waren dan op andere. Deze storingen waren vrij zeldzaam (misschien een paar keer per week gemiddeld), dus het duurde lang om informatie te verzamelen en te begrijpen wat er aan de hand was. Zonder de oorzaak te kennen, was het ontleden van de logs om te zien of de fouten werden veroorzaakt door single-bit flips (met een grote waarschijnlijkheid) ook niet triviaal. We hadden het geluk dat, als neveneffect van het proces dat we gebruikten, de controlesommen werden berekend in een apart proces op een andere machine op verschillende tijdstippen, zodat een bug het resultaat niet kon corrumperen en deze corruptie kon doorgeven aan de controlesom.

Als je jezelf gewoon probeert te beschermen met in-memory checksums, is de kans groot dat je een checksum-operatie uitvoert op reeds beschadigde data en de juiste checksum van de slechte data krijgt, tenzij je echt rare berekeningen doet die hun eigen checksums geven. En als je serieus bent over foutcorrectie, dan gebruik je waarschijnlijk nog steeds ECC.

Hoe dan ook, na het voltooien van de analyse ontdekten we dat memtest geen problemen kon detecteren, maar het vervangen van het RAM-geheugen op slechte machines leidde tot een afname van het foutenpercentage met één tot twee ordes van grootte. De meeste services hebben niet het soort controlesommen dat we hadden; deze services zullen gewoon in stilte beschadigde gegevens naar permanente opslag schrijven en zullen het probleem niet zien totdat de klant klaagt.

3. Door de ontwikkeling van hardware zijn fouten zeer zeldzaam geworden.

Nog een opmerking: als u voor ECC betaalt, betaalt u niet alleen voor ECC-geheugen - u betaalt voor onderdelen (processors, boards) die van hogere kwaliteit zijn. Dit is gemakkelijk te zien bij uitvalpercentages van schijven, en ik heb gehoord dat veel mensen dit opmerken in hun persoonlijke observaties.

Om openbaar beschikbaar onderzoek te citeren, voor zover ik me herinner, heeft de groep van Andrea en Ramsey een paar jaar geleden de SIGMETRICS-paper uitgebracht, waaruit bleek dat een SATA-schijf 4 keer meer kans had om niet te lezen dan een SCSI-schijf, en 10 keer meer kans om verborgen gegevenscorruptie te hebben. Deze verhouding bleef behouden, zelfs bij gebruik van schijven van dezelfde fabrikant. Er is geen specifieke reden om te denken dat de SCSI-interface betrouwbaarder zou moeten zijn dan de SATA-interface, maar het gaat niet om de interface. We hebben het over het kopen van zeer betrouwbare servercomponenten in vergelijking met clientcomponenten. Misschien ben je niet specifiek geïnteresseerd in de betrouwbaarheid van de schijf, omdat je alles op de checksums hebt staan ​​en schade gemakkelijk te vinden is, maar er zijn sommige soorten overtredingen die moeilijker te detecteren zijn.

4. Als ECC-geheugen echt belangrijk zou zijn, dan zou het overal worden gebruikt, niet alleen in servers.

Ze hebben voldoende invloed om de meeste componenten voor de juiste prijs te krijgen. Maar onderhandelen werkt alleen als er meer dan één levensvatbare leverancier is.

Een van de weinige gebieden waar er geen levensvatbare concurrenten zijn, is de productie van centrale verwerkingseenheden en videoversnellers. Gelukkig voor grote leveranciers hebben ze meestal geen videoversnellers nodig, ze hebben processors nodig, veel - dit is al lang het geval. Er waren verschillende pogingen van processorleveranciers om de servermarkt te betreden, maar elke poging had vanaf het begin altijd fatale fouten, waardoor het duidelijk was dat het gedoemd was te mislukken (en dit zijn vaak projecten die minstens 5 jaar vergen, dat wil zeggen dat het noodzakelijk was veel tijd doorbrengen zonder vertrouwen in succes).

De inspanningen van Qualcomm hebben veel rumoer gekregen, maar als ik met mijn contacten bij Qualcomm praat, vertellen ze me allemaal dat de chip die momenteel wordt gemaakt, voornamelijk bedoeld is om te testen. Het gebeurde omdat Qualcomm moest leren hoe hij een serverchip moest maken van alle mensen die het van IBM had gejat, en dat de volgende chip de eerste zou zijn die hopelijk concurrerend zou kunnen zijn. Ik heb hoge verwachtingen van Qualcomm, en ook van de inspanningen van ARM om goede servercomponenten te maken, maar deze inspanningen hebben nog niet het gewenste resultaat opgeleverd.

De bijna totale ongeschiktheid van de huidige ARM- (en POWER)-opties (afgezien van hypothetische opties voor de indrukwekkende ARM-chip van Apple) voor de meeste serverworkloads in termen van prestaties per dollar van de totale eigendomskosten (TCO) is een onderwerp dat een beetje buiten de gebaande paden ligt track, dus daar laat ik het voor nu bij, nog een publicatie. Maar het punt is dat Intel een marktpositie heeft die mensen kan dwingen extra te betalen voor serverfuncties. En Intel doet het. Bovendien zijn sommige functies inderdaad belangrijker voor servers dan voor mobiele apparaten met enkele gigabytes RAM en een stroombudget van enkele watts, mobiele apparaten waarvan wordt verwacht dat ze periodiek crashen en opnieuw opstarten.

Gevolgtrekking

Voor desktops ben ik ook een voorstander van ECC. Maar maak je geen reguliere back-ups, dan is het voor jou voordeliger om te investeren in reguliere back-ups dan in ECC-geheugen. En als u niet-ECC-back-ups hebt, kunt u de beschadigde gegevens eenvoudig naar de hoofdopslag schrijven en die beschadigde gegevens naar de back-up repliceren.

Met dank aan Prabhakar Ragda, Tom Murphy, Jay Weiskopf, Leah Hanson, Joe Wilder en Ralph Corderoy voor discussie/opmerkingen/correcties. Ook dank (of misschien niet) aan Leah voor het overtuigen van mij om deze mondelinge geïmproviseerde post als blogpost te schrijven. Onze excuses voor eventuele fouten, gebrek aan verwijzingen en subliem proza; dit is in wezen een opname van de helft van de discussie, en ik heb de termen niet uitgelegd, links gegeven of de feiten gecontroleerd op het detailniveau dat ik gewoonlijk doe.

Een grappig voorbeeld is (voor mij althans) de magische zelfhelende smeltbare link. Hoewel er veel implementaties zijn, stel je een smeltbare link op een chip voor als een soort weerstand. Als je er wat stroom doorheen laat gaan, zou je een verbinding moeten krijgen. Als de stroom te hoog is, zal de weerstand opwarmen en uiteindelijk breken. Dit wordt vaak gebruikt om elementen op chips uit te schakelen of voor activiteiten zoals het instellen van de kloksnelheid. Het basisprincipe is dat nadat de jumper is opgebrand, er geen manier is om deze in zijn oorspronkelijke staat terug te brengen.

Er was eens een fabrikant van halfgeleiders die een beetje gehaast was met hun fabricageproces en enigszins overdreven toleranties in een bepaalde technologiegeneratie. Na een paar maanden (of jaren) kon de verbinding tussen de twee uiteinden van zo'n jumper weer verschijnen en herstellen. Als je geluk hebt, zal zo'n jumper zoiets zijn als het meest significante deel van de klokvermenigvuldiger, die, indien gewijzigd, de chip zal uitschakelen. Als je geen geluk hebt, zal dit leiden tot verborgen gegevenscorruptie.

Ik hoorde van veel mensen in verschillende bedrijven over de problemen in deze technologische generatie van deze fabrikant, dus dit waren geen geïsoleerde gevallen. Als ik zeg dat het grappig is, bedoel ik dat het grappig is om dit verhaal in een bar te horen. Het is minder grappig om na een jaar testen te ontdekken dat sommige van je chips niet werken omdat hun jumperinstellingen zinloos zijn en je je chip opnieuw moet maken en de release met 3 maanden moet uitstellen. Trouwens, deze herstelsituatie met smeltbare koppelingen is een ander voorbeeld van een klasse van fouten die met ECC kunnen worden verholpen.

Dit is geen Google-probleem; Ik vermeld dit alleen omdat veel van de mensen met wie ik praat verbaasd zijn over hoe hardware kan falen.

Als je niet het hele boek wilt doorzoeken, dan is hier het fragment:

In een systeem dat een reeks softwarefouten kan overleven, is de minimumvereiste voor hardware dat fouten van dat onderdeel altijd tijdig worden gedetecteerd en aan de software worden gemeld, zodat de software-infrastructuur ze kan bevatten en passende herstelacties kan ondernemen. Het is niet nodig dat de hardware alle storingen expliciet afhandelt. Dit betekent niet dat de hardware voor dergelijke systemen moet worden ontworpen zonder mogelijkheid tot foutcorrectie. Wanneer bugfixing-functionaliteit kan worden aangeboden tegen redelijke kosten of complexiteit, loont het vaak om deze te ondersteunen. Dit betekent dat als hardwarefoutcorrectie extreem duur zou zijn, het systeem mogelijk een goedkopere versie zou kunnen gebruiken die alleen detectiemogelijkheden bood. De huidige DRAM-systemen zijn een goed voorbeeld van een situatie waarin krachtige foutcorrectie kan worden geleverd tegen zeer lage meerkosten. Het versoepelen van de eis om hardwarefouten te detecteren zou echter veel moeilijker zijn, omdat het zou betekenen dat elke softwarecomponent zou worden belast met de noodzaak om zijn eigen correcte uitvoering te verifiëren. Al vroeg in zijn geschiedenis had Google te maken met servers waar DRAM niet eens pariteit had. Het creëren van een webzoekindex bestaat in wezen uit een zeer grote sorteer-/samenvoegbewerking waarbij meerdere machines langdurig worden gebruikt. In 2000 mislukte de pre-validatie van een van de maandelijkse webindex-updates van Google toen werd ontdekt dat een subset van de geteste zoekopdrachten documenten retourneerde, blijkbaar willekeurig. Na enig onderzoek werd in de nieuwe indexbestanden een situatie gevonden die overeenkwam met het op een bepaalde plaats in de datastructuren op nul zetten van een bit, wat een negatief neveneffect was van het streamen van een grote hoeveelheid data via een defecte DRAM-chip. Er zijn consistentiecontroles toegevoegd aan de indexgegevensstructuren om de kans dat dit probleem zich opnieuw voordoet te minimaliseren, en er hebben zich geen verdere problemen van deze aard voorgedaan. Er moet echter worden opgemerkt dat deze methode geen 100% foutdetectie in de indexeringspas garandeert, omdat niet alle geheugenposities worden gecontroleerd - instructies blijven bijvoorbeeld ongecontroleerd. Dit werkte omdat de indexgegevensstructuren zo veel groter waren dan alle andere gegevens die bij de berekening betrokken waren, dat de aanwezigheid van deze zelfcontrolerende gegevensstructuren het zeer waarschijnlijk maakte dat machines met defect DRAM zouden worden geïdentificeerd en uitgesloten van het cluster. De volgende generatie machines bij Google omvatte al geheugenpariteitsdetectie, en toen de prijs van ECC-geheugen tot een concurrerend niveau zakte, gebruikten alle volgende generaties ECC-DRAM.

Trefwoorden:

• geheugen
• ECC
• server
• loopt vast
• geheugenstoringen

Zoals ik het begrijp, zijn zijn argumenten als volgt:

1. Google gebruikte ECC niet toen ze hun servers in 1999 bouwden.
2. De meeste RAM-fouten zijn systematische fouten, geen willekeurige.
3. RAM-fouten zijn zeldzaam omdat de hardware is verbeterd.
4. Als ECC-geheugen echt belangrijk zou zijn, dan zou het overal worden gebruikt, niet alleen in servers. Betalen voor dit soort optioneel materiaal is duidelijk te dubieus.

1. Google gebruikte ECC niet in 1999

A. Plaats uw servers in verzendcontainers.

B. Branden stichten in uw eigen datacenters.

Sommigen kijken misschien naar deze vroege Google-servers en zien het onprofessionalisme met betrekking tot het brandgevaar. Niet ik. Ik zie hier een visionair begrip van hoe goedkope, kant-en-klare hardware het moderne internet zal vormen.

Het laatste deel van wat werd gezegd is waar. Maar in het eerste deel zit een kern van waarheid. Toen Google hun eigen borden begon te ontwerpen, had een generatie van hen een "groei"-probleem ( ) dat een niet-nul aantal branden veroorzaakte.

Trouwens, als je naar Jeff's post gaat en naar de foto kijkt waarnaar in het citaat wordt verwezen, zul je zien dat er veel startkabels op de borden zitten. Dit veroorzaakte problemen en werd opgelost in de volgende generatie hardware. Je ziet ook nogal slordige bekabeling, die bovendien voor problemen zorgde en ook snel werd verholpen. Er waren nog andere problemen, maar die laat ik als oefening voor de lezer.

C. Creëer servers die uw werknemers verwonden

D. Creëer uw eigen weer in uw datacenters

Houd er rekening mee dat alles wat door Google is aangegeven, is geprobeerd en vervolgens is gewijzigd. Fouten maken en deze vervolgens herstellen is gebruikelijk in elke succesvolle ontwikkelingsorganisatie. Als je de ingenieurspraktijk verafgoodt, moet je op zijn minst vasthouden aan de moderne praktijk, en niet aan wat er in 1999 werd gedaan.

Toen Google in 1999 niet-ECC-servers gebruikte, vertoonden ze een aantal symptomen die uiteindelijk geheugenbeschadiging bleken te zijn. Inclusief een zoekindex die vrijwel willekeurige resultaten in zoekopdrachten opleverde. De feitelijke faalmodus is hier leerzaam. Ik hoor vaak dat ECC op deze machines kan worden genegeerd omdat fouten in individuele resultaten acceptabel zijn. Maar zelfs als u willekeurige fouten acceptabel vindt, betekent het negeren ervan dat er een gevaar bestaat voor volledige gegevenscorruptie, tenzij een zorgvuldige analyse wordt uitgevoerd om ervoor te zorgen dat één fout één resultaat slechts in geringe mate kan vervormen.

In onderzoek naar bestandssystemen is herhaaldelijk aangetoond dat het, ondanks heroïsche pogingen om systemen te maken die bestand zijn tegen een enkele fout, buitengewoon moeilijk is om dit te doen. In wezen kan elk zwaar getest bestandssysteem een ​​grote storing hebben als gevolg van een enkele fout (). Ik ga geen ontwikkelaars van bestandssystemen aanvallen. Ze zijn beter in dit soort analyses dan 99,9% van de programmeurs. Alleen is herhaaldelijk aangetoond dat dit probleem zo moeilijk is dat mensen het redelijkerwijs niet kunnen bespreken, en een geautomatiseerd hulpmiddel voor een dergelijke analyse is nog steeds verre van een eenvoudig proces met een muisklik. In hun Warehouse Computer Handbook bespreekt Google foutdetectie en -correctie, en ECC-geheugen wordt als de meest geschikte optie beschouwd wanneer het duidelijk is dat hardwarefoutcorrectie ( ) moet worden gebruikt.

Google heeft een uitstekende infrastructuur. Van wat ik heb gehoord over infrastructuur bij andere grote technologiebedrijven, lijkt Google de beste ter wereld te zijn. Maar dat betekent niet dat je alles wat ze doen moet kopiëren. Zelfs als alleen hun goede ideeën worden overwogen, heeft het voor de meeste bedrijven geen zin om ze te kopiëren. Ze creëerden een vervanging voor de Linux job hook-planner die zowel hardware-runtime-informatie als statische traces gebruikt, zodat ze kunnen profiteren van de nieuwe hardware in Intel-serverprocessors, waardoor dynamische cache-partitionering over kernen mogelijk is. Als u dit op al hun hardware gebruikt, bespaart Google in een week meer geld dan Stack Exchange in zijn hele geschiedenis aan al zijn machines heeft uitgegeven. Betekent dit dat je Google moet kopiëren? Nee, tenzij je al bent getroffen door manna uit de hemel, zoals het hebben van je kerninfrastructuur geschreven in sterk geoptimaliseerde C++ in plaats van Java of (God verhoede) Ruby. En het feit is dat voor de overgrote meerderheid van bedrijven het schrijven van programma's in een taal die een 20-voudige afname van de productiviteit met zich meebrengt, een volkomen redelijke beslissing is.

2. De meeste RAM-fouten zijn systematische fouten

Ons onderzoek heeft verschillende hoofdresultaten. Ten eerste ontdekten we dat ongeveer 70% van de DRAM-storingen repetitieve (bijv. permanente) storingen zijn, terwijl slechts 30% intermitterende (intermitterende) storingen zijn. Ten tweede ontdekten we dat grote multi-bit-storingen, zoals storingen die een hele rij, kolom of blok beïnvloeden, verantwoordelijk zijn voor meer dan 40% van alle DRAM-storingen. Ten derde ontdekten we dat bijna 5% van de DRAM-storingen van invloed zijn op circuits op bordniveau, zoals data (DQ) of gate (DQS) lijnen. Ten slotte ontdekten we dat de Chipkill-functie de frequentie van systeemstoringen veroorzaakt door DRAM-storingen met een factor 36 verminderde.

Ten eerste is de 2:1-verhouding niet groot genoeg om willekeurige fouten eenvoudigweg te negeren. Ten tweede impliceert de post Jeffs overtuiging dat systematische fouten in wezen onveranderlijk zijn en niet na een tijdje kunnen verschijnen. Dit is niet waar. Elektronica slijt op dezelfde manier als mechanische apparaten. De mechanismen zijn verschillend, maar de effecten zijn vergelijkbaar. Als we de betrouwbaarheidsanalyse van chips vergelijken met andere soorten betrouwbaarheidsanalyses, kunnen we zien dat ze vaak dezelfde distributiefamilies gebruiken voor het modelleren van fouten. Ten derde houdt Jeffs redenering in dat ECC niet kan helpen bij het opsporen of oplossen van bugs, wat niet alleen verkeerd is, maar ook rechtstreeks in tegenspraak is met het citaat.

Dus, hoe vaak gaat u memtest op uw machines uitvoeren in een poging om deze systeemfouten op te vangen, en hoeveel gegevensverlies bent u bereid te verduren? Een van de belangrijkste toepassingen van ECC is niet om fouten te corrigeren, maar om fouten te signaleren zodat hardware kan worden vervangen voordat "stille corruptie" optreedt. Wie zou ermee instemmen om elke dag alles op de machine te sluiten om memtest uit te voeren? Het zou veel duurder zijn dan alleen ECC-geheugen kopen. En zelfs als je me zou kunnen overtuigen om een ​​geheugentest uit te voeren, zou memtest niet zoveel fouten vinden als ECC kan.

Toen ik voor een bedrijf werkte met een vloot van ongeveer duizend machines, merkten we dat we vreemde fouten bij de controle op de gegevensintegriteit hadden, en na ongeveer zes maanden realiseerden we ons dat fouten op sommige machines waarschijnlijker waren dan op andere. Deze storingen waren vrij zeldzaam (misschien een paar keer per week gemiddeld), dus het duurde lang om informatie te verzamelen en te begrijpen wat er aan de hand was. Zonder de oorzaak te kennen, was het ontleden van de logs om te zien of de fouten werden veroorzaakt door single-bit flips (met een grote waarschijnlijkheid) ook niet triviaal. We hadden het geluk dat, als neveneffect van het proces dat we gebruikten, de controlesommen werden berekend in een apart proces op een andere machine op verschillende tijdstippen, zodat een bug het resultaat niet kon corrumperen en deze corruptie kon doorgeven aan de controlesom.

Als je jezelf gewoon probeert te beschermen met in-memory checksums, is de kans groot dat je een checksum-operatie uitvoert op reeds beschadigde data en de juiste checksum van de slechte data krijgt, tenzij je echt rare berekeningen doet die hun eigen checksums geven. En als je serieus bent over foutcorrectie, dan gebruik je waarschijnlijk nog steeds ECC.

Hoe dan ook, na het voltooien van de analyse ontdekten we dat memtest geen problemen kon detecteren, maar het vervangen van het RAM-geheugen op slechte machines leidde tot een afname van het foutenpercentage met één tot twee ordes van grootte. De meeste services hebben niet het soort controlesommen dat we hadden; deze services zullen gewoon in stilte beschadigde gegevens naar permanente opslag schrijven en zullen het probleem niet zien totdat de klant klaagt.

3. Door de ontwikkeling van hardware zijn fouten zeer zeldzaam geworden.

Nog een opmerking: als u voor ECC betaalt, betaalt u niet alleen voor ECC-geheugen - u betaalt voor onderdelen (processors, boards) die van hogere kwaliteit zijn. Dit is gemakkelijk te zien bij uitvalpercentages van schijven, en ik heb gehoord dat veel mensen dit opmerken in hun persoonlijke observaties.

Om openbaar beschikbaar onderzoek te citeren, voor zover ik me herinner, heeft de groep van Andrea en Ramsey een paar jaar geleden de SIGMETRICS-paper uitgebracht, waaruit bleek dat een SATA-schijf 4 keer meer kans had om niet te lezen dan een SCSI-schijf, en 10 keer meer kans om verborgen gegevenscorruptie te hebben. Deze verhouding bleef behouden, zelfs bij gebruik van schijven van dezelfde fabrikant. Er is geen specifieke reden om te denken dat de SCSI-interface betrouwbaarder zou moeten zijn dan de SATA-interface, maar het gaat niet om de interface. We hebben het over het kopen van zeer betrouwbare servercomponenten in vergelijking met clientcomponenten. Misschien ben je niet specifiek geïnteresseerd in de betrouwbaarheid van de schijf, omdat je alles op de checksums hebt staan ​​en schade gemakkelijk te vinden is, maar er zijn sommige soorten overtredingen die moeilijker te detecteren zijn.

4. Als ECC-geheugen echt belangrijk zou zijn, dan zou het overal worden gebruikt, niet alleen in servers.

Ze hebben voldoende invloed om de meeste componenten voor de juiste prijs te krijgen. Maar onderhandelen werkt alleen als er meer dan één levensvatbare leverancier is.

Een van de weinige gebieden waar er geen levensvatbare concurrenten zijn, is de productie van centrale verwerkingseenheden en videoversnellers. Gelukkig voor grote leveranciers hebben ze meestal geen videoversnellers nodig, ze hebben processors nodig, veel - dit is al lang het geval. Er waren verschillende pogingen van processorleveranciers om de servermarkt te betreden, maar elke poging had vanaf het begin altijd fatale fouten, waardoor het duidelijk was dat het gedoemd was te mislukken (en dit zijn vaak projecten die minstens 5 jaar vergen, dat wil zeggen dat het noodzakelijk was veel tijd doorbrengen zonder vertrouwen in succes).

De inspanningen van Qualcomm hebben veel rumoer gekregen, maar als ik met mijn contacten bij Qualcomm praat, vertellen ze me allemaal dat de chip die momenteel wordt gemaakt, voornamelijk bedoeld is om te testen. Het gebeurde omdat Qualcomm moest leren hoe hij een serverchip moest maken van alle mensen die het van IBM had gejat, en dat de volgende chip de eerste zou zijn die hopelijk concurrerend zou kunnen zijn. Ik heb hoge verwachtingen van Qualcomm, en ook van de inspanningen van ARM om goede servercomponenten te maken, maar deze inspanningen hebben nog niet het gewenste resultaat opgeleverd.

De bijna totale ongeschiktheid van de huidige ARM- (en POWER)-opties (afgezien van hypothetische opties voor de indrukwekkende ARM-chip van Apple) voor de meeste serverworkloads in termen van prestaties per dollar van de totale eigendomskosten (TCO) is een onderwerp dat een beetje buiten de gebaande paden ligt track, dus daar laat ik het voor nu bij, nog een publicatie. Maar het punt is dat Intel een marktpositie heeft die mensen kan dwingen extra te betalen voor serverfuncties. En Intel doet het. Bovendien zijn sommige functies inderdaad belangrijker voor servers dan voor mobiele apparaten met enkele gigabytes RAM en een stroombudget van enkele watts, mobiele apparaten waarvan wordt verwacht dat ze periodiek crashen en opnieuw opstarten.

Gevolgtrekking

Voor desktops ben ik ook een voorstander van ECC. Maar maak je geen reguliere back-ups, dan is het voor jou voordeliger om te investeren in reguliere back-ups dan in ECC-geheugen. En als u niet-ECC-back-ups hebt, kunt u de beschadigde gegevens eenvoudig naar de hoofdopslag schrijven en die beschadigde gegevens naar de back-up repliceren.

Met dank aan Prabhakar Ragda, Tom Murphy, Jay Weiskopf, Leah Hanson, Joe Wilder en Ralph Corderoy voor discussie/opmerkingen/correcties. Ook dank (of misschien niet) aan Leah voor het overtuigen van mij om deze mondelinge geïmproviseerde post als blogpost te schrijven. Onze excuses voor eventuele fouten, gebrek aan verwijzingen en subliem proza; dit is in wezen een opname van de helft van de discussie, en ik heb de termen niet uitgelegd, links gegeven of de feiten gecontroleerd op het detailniveau dat ik gewoonlijk doe.

Een grappig voorbeeld is (voor mij althans) de magische zelfhelende smeltbare link. Hoewel er veel implementaties zijn, stel je een smeltbare link op een chip voor als een soort weerstand. Als je er wat stroom doorheen laat gaan, zou je een verbinding moeten krijgen. Als de stroom te hoog is, zal de weerstand opwarmen en uiteindelijk breken. Dit wordt vaak gebruikt om elementen op chips uit te schakelen of voor activiteiten zoals het instellen van de kloksnelheid. Het basisprincipe is dat nadat de jumper is opgebrand, er geen manier is om deze in zijn oorspronkelijke staat terug te brengen.

Er was eens een fabrikant van halfgeleiders die een beetje gehaast was met hun fabricageproces en enigszins overdreven toleranties in een bepaalde technologiegeneratie. Na een paar maanden (of jaren) kon de verbinding tussen de twee uiteinden van zo'n jumper weer verschijnen en herstellen. Als je geluk hebt, zal zo'n jumper zoiets zijn als het meest significante deel van de klokvermenigvuldiger, die, indien gewijzigd, de chip zal uitschakelen. Als je geen geluk hebt, zal dit leiden tot verborgen gegevenscorruptie.

Ik hoorde van veel mensen in verschillende bedrijven over de problemen in deze technologische generatie van deze fabrikant, dus dit waren geen geïsoleerde gevallen. Als ik zeg dat het grappig is, bedoel ik dat het grappig is om dit verhaal in een bar te horen. Het is minder grappig om na een jaar testen te ontdekken dat sommige van je chips niet werken omdat hun jumperinstellingen zinloos zijn en je je chip opnieuw moet maken en de release met 3 maanden moet uitstellen. Trouwens, deze herstelsituatie met smeltbare koppelingen is een ander voorbeeld van een klasse van fouten die met ECC kunnen worden verholpen.

Dit is geen Google-probleem; Ik vermeld dit alleen omdat veel van de mensen met wie ik praat verbaasd zijn over hoe hardware kan falen.

Als je niet het hele boek wilt doorzoeken, dan is hier het fragment:

In een systeem dat een reeks softwarefouten kan overleven, is de minimumvereiste voor hardware dat fouten van dat onderdeel altijd tijdig worden gedetecteerd en aan de software worden gemeld, zodat de software-infrastructuur ze kan bevatten en passende herstelacties kan ondernemen. Het is niet nodig dat de hardware alle storingen expliciet afhandelt. Dit betekent niet dat de hardware voor dergelijke systemen moet worden ontworpen zonder mogelijkheid tot foutcorrectie. Wanneer bugfixing-functionaliteit kan worden aangeboden tegen redelijke kosten of complexiteit, loont het vaak om deze te ondersteunen. Dit betekent dat als hardwarefoutcorrectie extreem duur zou zijn, het systeem mogelijk een goedkopere versie zou kunnen gebruiken die alleen detectiemogelijkheden bood. De huidige DRAM-systemen zijn een goed voorbeeld van een situatie waarin krachtige foutcorrectie kan worden geleverd tegen zeer lage meerkosten. Het versoepelen van de eis om hardwarefouten te detecteren zou echter veel moeilijker zijn, omdat het zou betekenen dat elke softwarecomponent zou worden belast met de noodzaak om zijn eigen correcte uitvoering te verifiëren. Al vroeg in zijn geschiedenis had Google te maken met servers waar DRAM niet eens pariteit had. Het creëren van een webzoekindex bestaat in wezen uit een zeer grote sorteer-/samenvoegbewerking waarbij meerdere machines langdurig worden gebruikt. In 2000 mislukte de pre-validatie van een van de maandelijkse webindex-updates van Google toen werd ontdekt dat een subset van de geteste zoekopdrachten documenten retourneerde, blijkbaar willekeurig. Na enig onderzoek werd in de nieuwe indexbestanden een situatie gevonden die overeenkwam met het op een bepaalde plaats in de datastructuren op nul zetten van een bit, wat een negatief neveneffect was van het streamen van een grote hoeveelheid data via een defecte DRAM-chip. Er zijn consistentiecontroles toegevoegd aan de indexgegevensstructuren om de kans dat dit probleem zich opnieuw voordoet te minimaliseren, en er hebben zich geen verdere problemen van deze aard voorgedaan. Er moet echter worden opgemerkt dat deze methode geen 100% foutdetectie in de indexeringspas garandeert, omdat niet alle geheugenposities worden gecontroleerd - instructies blijven bijvoorbeeld ongecontroleerd. Dit werkte omdat de indexgegevensstructuren zo veel groter waren dan alle andere gegevens die bij de berekening betrokken waren, dat de aanwezigheid van deze zelfcontrolerende gegevensstructuren het zeer waarschijnlijk maakte dat machines met defect DRAM zouden worden geïdentificeerd en uitgesloten van het cluster. De volgende generatie machines bij Google omvatte al geheugenpariteitsdetectie, en toen de prijs van ECC-geheugen tot een concurrerend niveau zakte, gebruikten alle volgende generaties ECC-DRAM.

Tags: Tags toevoegen