Downtime 24 oktober wegens plaatsing db-server

Tweakers.net heeft op zaterdagochtend 24 oktober een nieuwe databaseserver in gebruik genomen. De upgrade ging gepaard met een downtime van iets meer dan drie uur.

De huidige database-servers van het forum en de frontpage, bij jullie allen bekend als Apollo en Artemis, zijn inmiddels de leeftijd van respectievelijk drie en twee jaar gepasseerd en dus werd het tijd om beide machines van hun oude dag te laten genieten als dev- en replicatieserver. Onze technische mannen werden wederom belast met de taak om een zo ontzagwekkend mogelijke configuratie uit te zoeken. Dat is gelukt door een Dell PowerEdge R710 vol te douwen met 72GB geheugen, zes 50GB solid state drives en twee quadcore Xeon X5570-processors met een kloksnelheid van 2,93GHz. Het apparaat werd afgetankt met twee 300GB sas-schijven, die opslag zullen bieden voor het besturingsssyteem en de binary logs van MySQL.

Na de ingebruikname van het nieuwe datamonster zal de gehele website met uitzondering van een aantal ondersteunende databases weer op een enkele databaseserver komen te draaien. De MySQL-databases van de frontpage en het forum werden acht jaar geleden uit elkaar getrokken omdat de betaalbare hardware van toen niet in staat was de onstuitbare groei van de site bij te benen. Artemis 1 kreeg in mei 2001 gezelschap van Apollo, een machine met twee 1,0GHz Pentium III-processors, 1,5GB geheugen en twee 18GB Quantum Atlas 10K II-disks. Tegenwoordig maak je hooguit een netbook bang met deze specs maar destijds werden ze geprezen vanwege de hoge kwijlbaarheidsfactor.

Door de opkomst van multi-core processors en solid state drives en het bijna gratis weggeven van geheugen zijn de prestaties van betaalbare serversystemen de afgelopen jaren veel sneller gegroeid dan er nieuwe tweakers werden geproduceerd. Ongehinderd door deze wetenschap leefden de devvers zich bovendien uit op het bouwen van performance-optimalisaties zoals de inzet van memcached, Active MQ en de op Java gebaseerde middleware voor de Pricewatch. De belasting van de databaseservers ging omlaag in plaats van omhoog en dus was performance geen reden meer om de databases gescheiden te houden. Vanuit praktisch oogpunt was de scheiding vaak aan een blok aan ons devvende been.

In geest met de tijd worden de zwaarlijvige configuraties van de huidige Artemis en Apollo fors gedownsized. De huidige machines bezetten ieder 4U aan rackspace door het gebruik van een 1U Dell PowerEdge 1950 in combinatie met een 3U PowerVault MD1000 disk-array. De MD1000 is bij beide machines gevuld met vijftien energieslurpende 15.000 toeren harde schijven in 3,5 inch formaat. Het nieuwe systeem neemt genoegen met een bescheiden 2U aan rackspace en draait dankzij de zes geruisloze solid state drives rondjes om de I/O-prestaties van de harddisk-arrays. Artemis 5 is na de eerder dit jaar geplaatste zoekmachine onze tweede server die is uitgerust met ssd's.

De initiatie van Artemis 6 en de hereniging van de databases zal aanvangen op 24 oktober rond 7.00 uur. Zowel het forum als de frontpage zullen bij het kopiëren van de databases onklaar gemaakt worden. Verwacht wordt dat het onderhoud zo'n vier uur in beslag zal nemen. Tegen de tijd dat je goed en wel bent uitgeslapen zijn wij dus al lang weer up and running.

Hieronder volgt een overzicht van oude hardware die jullie met je postgedrag versleten hebben.

	Artemis 1 (06-12-2000)	Apollo 1 (15-06-2001)
Processors	2x Pentium III 733MHz - 1,0GHz	2x Pentium III 1,0GHz
Geheugen	1,5GB - 4GB PC133 SDR	2GB - 4GB PC133 SDR
Raid-controller	AMI MegaRAID Elite 1500	Adaptec ASR-3200S
Opslag	1x 20GB ata 3x Seagate Cheetah X15 18GB	2x Quantum Atlas 10K II 18GB
	Artemis 2 (14-12-2001)	Apollo 2 (31-08-2002)
Processors	2x Athlon MP 1600+ 1,4GHz	2x Athlon MP 1900+ 1,6GHz
Geheugen	2GB DDR-266	3,5GB DDR-266
Raid-controller	Adaptec ASR-3200S	Adaptec ASR-3200S
Opslag	1x 20GB ata 5x Seagate Cheetah X15 18GB	1x 20GB ata 5x Seagate Cheetah 36XL 36GB
	Artemis 3 (01-11-2003)	Apollo 3 (20-12-2003)
Processors	2x Opteron 246 2,0GHz	2x Opteron 242 1,6GHz
Geheugen	4GB DDR-266	6GB DDR-266
Raid-controller	LSI MegaRAID Elite 1600	LSI MegaRAID Elite 1600
Opslag	2x Seagate Cheetah 18XL 9GB 4x Seagate Cheetah 10K.6 36GB	6x Seagate Cheetah 10K.6 36GB
	Artemis 4 (17-11-2006)	Apollo 4 (17-05-2004)
Processors	2x Opteron 254 2,8GHz	2x Opteron 244 (1,8GHz)
Geheugen	8GB DDR-333	8GB DDR-333
Raid-controller	LSI MegaRAID SCSI 320-2X	LSI MegaRAID SCSI 320-2X
Opslag	2x Seagate Cheetah 10K.6 36GB 6x Seagate Cheetah 15K.3 36GB	2x Seagate Cheetah 10K.6 36GB 6x Seagate Cheetah 15K.3 36GB
	Artemis 5 (28-07-2007)	Apollo 5 (01-09-2006)
Processors	2x Xeon X5355 2,66GHz	2x Xeon 5160 3,0GHz
Geheugen	16GB DDR2-667	16GB DDR2-667
Raid-controller	Dell Perc 5/i Dell Perc 5/e	Dell Perc 5/i Dell Perc 5/e
Opslag	2x Seagate Savvio 10K.2 73GB 15x Seagate Cheetah 15K.5 73GB	2x 73GB 10K SAS 15x Fujitsu MAX3036RC 36GB 15K SAS
	Artemis 6 (24-10-2009)
Processors	2x Xeon X5570 2,93GHz
Geheugen	72GB DDR3-800
Raid-controller	Dell Perc 6/i
Opslag	2x Seagate Savvio 10K.3 300GB 6x Dell / Samsung MCCOE50G5MPQ 50GB

Update 10:15: De upgrade is vrijwel probleemloos verlopen en wij zijn weer up and running!

Reacties (228)

[basb]

Ik heb ervaring met die R710 van dell doordat op me werk toevallig ook precies dat model staat. Die interne raid controller is behoorlijk snel. Zo snel dat het zeer te betwijfelen is of het wel zinvol was om voor ssd's te gaan. Een array met 2.5 inch 15K disken is ook letterlijk wat je noemt rete snel. Een aantal mensen geloofden me niet toen ik zei dat dit ding sneller naar disk schrijft dan een groot san-storage systeen.
Snelheid getest met door hun aangewezen toolling. De betreffende tooling was niet in staat de snelheid te meten. De gehaalde snelheden waren zo hoog dat er als resultaat kwam: inf mb/sec of 1000mbyte/sec. In elk geval met de vrij weinig zeggende sequentiele schrijf-testen komt dit ding uit op minimaal 500mbyte/sec en maximaal zo'n 840-880mbyte/sec. naar traditionele 146Gbyte 15k disken!!

Zoals altijd, mits alles natuurlijk correct geconfigureerd is:) Enn met de juiste disken.

Grote voordeel van tradionele disken is heel simpel, meer gbyte's voor minder geld en toch behoorlijke performance.

Ik ben dus benieuwd wat de tweakers-crew uit deze server weet te persen met ssd-disken erin

[Reactie gewijzigd door basb op 22 juli 2024 14:07]

[Femme]

Het verschil in toegangstijd tussen een 2,5 inch 15.000 toeren disk en een vlotte slc-ssd is nog altijd een factor vijftig of meer. Voor een database-server is een lage toegangstijd veel belangrijker dan een hoge sequentiële doorvoersnelheid.

Vier stuks Samsung slc-ssd's aan een Areca ARC-1680 512MB in raid 5 waren zestig procent sneller dan veertien Fujitsu MAX3036RC 15.000 toeren sas-schijf aan een Dell Perc 5/e (de schijven in de oude Apollo) volgens onze eigen benchmarks. In de nieuwe dbserver hebben we zes ssd's en zal verschil nog een stukje groter zijn.

[basb]

De database-benchmarks laten een veel kleiner verschil zien Dan je op basis van de disken zelf zou verwachten. Exact het resultaat wat ik verwachtte. Het punt is wat ik wil maken, dat je er goed nagedacht moet worden of ssd' s wel noodzakelijk zijn. Een tradiotionele oplossing met snelle disken en een snelle interne hardware-raid controller met flinke cache performed ook heel erg goed. Dat stukje cache neemt voor het grootste deel het probleem van de langzame access-tijden weg, Daarmee wordt ook het belangrijkste voordeel van ssd's, zeer lage toeganstijden, ongedaan gemaakt.

Ook m.b.t. de 15K disken zijn er vernieuwingen, performance van die disken loopt zeer uiteen. In worstcase naar 50%. Op tomshardwareguide staat er ergens recente een test van 15k disken waarbij 1 type de rest letterlijk weg blies.


Ik vind het verder helemaal niet erg dat de database op ssd's komt te staan met een flinke raidcontroller erachter. Kan ik nog sneller de informatie binnen halen van tweakers En op de totale kosten van een gemiddelde bedrijfsvoering zijn de meerkosten van ssd's verwaarloosbaar.

[Reactie gewijzigd door basb op 22 juli 2024 14:07]

[Femme]

Er worden hier wel even veertien 15.000 toeren met vier ssd's vergeleken waarbij de ssd's zestig procent sneller zijn in workloads met een hoge concurrency waarin de harde schijven goed kunnen schalen.

Een Dell PowerVault MD3000 met 15x 73GB 15.000 toeren sas-harde schijven en raidcontroller met externe poorten kost bijna 8800 euro zonder korting. Dat is 3000 euro minder dan de meerprijs van 4x 50GB ssd in een PowerEdge R710 en dat terwijl Dell de schandalige prijs van 1350 euro per ssd rekent.

Verder kun je 3U aan rackspace besparen en zo'n 300 watt aan continu energieverbruik.

De cache op de raidcontroller helpt om de responstijden van schrijf I/O's tot bijna nul te reduceren. De responstijd van ongecachede read I/O's worden er niet beter op en daar hebben we die ssd's voor.

[Reactie gewijzigd door Femme op 22 juli 2024 14:07]

[Anoniem: 15758]

Is het niet zo dat bij database servers de actieve dataset (~20-50%) in de RAM hoort te passen en daardoor de hoeveelheid read I/O beperkt blijft en de I/O voornamelijk uit writes zal bestaan?

Aangezien dat random writes zijn, is Intel daar wel heer en meester in. Nu gaat het hier om SLC disks die geen trage read-erase-write cycles hebben en dus met een simpelere controller af kunnen, maar kijkende naar MLC zijn er grote verschillen. Zo kwam ik deze benchmark tegen van een SSD met Samsung MLC controller vergeleken met de Intel X25-M G2:
http://images.anandtech.c...ew_072209165207/19508.png

Ik mag aannemen dat de Samsung SLC controllers het veel beter doen. Als jullie I/O voor 80% uit random writes bestaat, zal dat het type I/O zijn waar je je op moet focussen. Ik heb nog geen resultaten gezien van Samsung SLC disks op dit gebied maar ben wel benieuwd.

Dat gezegd hebben SSDs natuurlijk wel extreem veel meer potentie voor het soort workloads wat jullie in petto hebben.

Wat ik me nog wel afvraag; welke meerwaarde biedt de SLC-based X25-E nu nog buiten hogere sequentiële write snelheden, ten opzichte van de MLC-based X25-M G2; die op bepaalde gebieden zijn SLC-broertje overtroeft.

[Femme]

Is het niet zo dat bij database servers de actieve dataset (~20-50%) in de RAM hoort te passen en daardoor de hoeveelheid read I/O beperkt blijft en de I/O voornamelijk uit writes zal bestaan?

Met 72GB RAM zal er onder normale omstandigheden waarschijnlijk niet zo heel veel read I/O plaatsvinden. Overigens valt dat nu ook heel erg mee. De read I/O piek wel meer dan de write I/O en op momenten die er echt toe doen (opstarten databases na een reboot) zijn hoge (random) leesprestaties belangrijker dan schrijfprestaties.

Zo kwam ik deze benchmark tegen van een SSD met Samsung MLC controller vergeleken met de Intel X25-M G2: http://images.anandtech.c...ew_072209165207/19508.png

Dat zijn volgens mij benchmarks van de Summit met een oude firmware. Samsung heeft zeker niet de meest briljante ssd-controller van de wereld en ik had liever ook X25-E's gezien, maar in vergelijking met een harde schijf zijn de prestaties gewoon erg goed. In de praktijk zal de cache van de raidcontroller in veel gevallen de mindere schrijfprestaties van de Samsung ssd-controller tov de X25-E kunnen maskeren.

Wat ik me nog wel afvraag; welke meerwaarde biedt de SLC-based X25-E nu nog buiten hogere sequentiële write snelheden, ten opzichte van de MLC-based X25-M G2; die op bepaalde gebieden zijn SLC-broertje overtroeft.

De keuze voor slc-geheugen in servertoepassingen met veel schrijf I/O wordt primair gemaakt vanwege de langere levensduur van dit type flashgeheugen. Ik heb voor de grap een drietal Vertexen 30GB getest op een Areca raidcontroller en daarbij 75 procent van de capaciteit gealloceerd (zodat er relatief gezien een vergelijkbare reservecapaciteit is als bij een X25-E en de slc-ssd van Samsung). Een Vertex consumenten-ssd'tje is dan gewoon fors sneller dan de ssd's die wij in de nieuwe Artemis hebben. Zie resultaten.

[flowerp]

Is het niet zo dat bij database servers de actieve dataset (~20-50%) in de RAM hoort te passen en daardoor de hoeveelheid read I/O beperkt blijft en de I/O voornamelijk uit writes zal bestaan?

Het is inderdaad zo dat veel RAM enorm helpt en dat de IO naar de disks voor een groot gedeelte opvangt. Je hebt echter ook nog zoiets als cold performance (data die nog niet in de cache staat). Afhankelijk van je workload en je soort data,kan dat ook heel erg belangrijk zijn.

Vergeet daarnaast niet je vacuum tijden en je backup / restore tijden. Daar gaat RAM je absoluut niet helpen!

Wat ik me nog wel afvraag; welke meerwaarde biedt de SLC-based X25-E nu nog buiten hogere sequentiële write snelheden, ten opzichte van de MLC-based X25-M G2; die op bepaalde gebieden zijn SLC-broertje overtroeft

Betrouwbaarheid. SLC is VEEL simpelder en er kan minder stuk. Maximale erase cycles bij MLC is zo'n 10.000 terwijl dit bij SLC 100.000 is. Bij ons komen er echt ALLEEN SLC SSD's in de servers. MLC is gewoon uitgesloten, zelfs al zou MLC iets beter presteren (wat meestal echter niet zo is).

[basb]

Als ik zo de discussie volg wordt de database van tweakers.net tot een mega database gepraat waarbij de gehele database continu gelezen en geschreven wordt naar disk. Maak mij niet wijs dat de database van tweakers.net zwaarder belast wordt dan een gemiddeld san-storage systeem waar de databases van 30.000 tot 100.000 concurrent gebruikers p[ zitten te werken. Dan valt het aantal mensen dat concurrent tweakers zit te kijken waarvan veruit grootste deel niet verder komt dan de nieuwsartikelen op de frontpage nog reuze mee. Zoals hier geredeneerd wordt betekent dat de gebruikers in een standaard enterprise omgeving voor elke commit een bakje koffie moeten gaan drinken. Voor websites zoals tweakers is het typisch juist dat bijna continu dezelfde (nieuws) pagina's opgevraagd worden en doorgaans ook het recentere deel. Het aantal hits op pagina''s ouder dan 6 maanden zal echt niet veel zijn.

Bij een site zoals tweakers.net moet het voor elkaar te krijgen zijn om 99,9% uit cache te serveren met 40-50gbyte memory en het lijkt me onwaarschijnlijk dat het plaatsen van berichten zo ontzettend veel write i/o genereerd dat je daar per se ssd's voor nodig hebt. Dat zou betekenen dat op tweakers vele tienduizenden berichten per seconde geplaatst worden. noway... Als het aantal i/o's dat suggeren wordt het echt tijd de sql-queries nog is goed onder de loop te nemen waar er nou wat fout gaat. Het bijhouden van de karma van de ingelogde gebruikers zal vast wel veel genereren, maar hoeveel zijn dat er eigenlijk en genereerd dat werkelijke meerdere megabytes aan random i/o seconde?

Het eenmalig alles van disk halen na een cold boot? Nog nooit problemen mee gezien. Initieel kijkt zeker bij tweakers vrijwel iedereen naar de zelfde pagina' s waardoor binnen kortste keren de database al weer 99,9% vanuit cache staat te serveren. Bij een site zoals tweakers zou dat wel is veel minder dan 30 seconden kunnen zijn. Ik zou zeggen, jammer dan, dat na een herstart een pagina aanleveren even een halve seconde langer duurt voor elke gebruiker. Probleem lost zich in kwestie van seconden zichzelf op.

De random write i/o's zijn met een goed geconfigueerd raid-systeem ineens helemaal niet meer zo duur. Je krijgt pas problemen als de stroom write i/o's groter is dan de disken vol continu aan random write i/o kan verwerken. Dan spreek je echt over gigantische hoeveelheden data. Die heeft tweakers.net gewoon niet of de code moet nog is een keer goed bekeken worden door de programmeurs.

ssd' s zijn absoluut sneller dan tradiotionele disken, maar het lijkt erop dat er een idee gaat leven dat je ssd's nodig hebt om enterprise performance te leveren. Dat is dus niet het geval, Het is echt voor specifieke toepassingen dat ssd' s ideaal zijn. Voor een site zoals tweakers, kun je dat geld beter stoppen in meer memory zodat het disksysteem echt alleen haast nog maar write i/o hoeft te doen en de cache policy's daar optimaal op kunt aanpassen. dat een ssd systeem met benchmarks sneller is.. ja en? ... heb je het echt nodig en ook profijt van? Of kan het prima via een goedkopere methode precies dezelfde respons geleverd worden aan de gebruiker?

In de toekomst, als ssd's veel goedkoper worden en nog beter worden kan de situatie natuurlijk wel nog gaan veranderen, maar op dit moment heeft ssd het probleem dat het niet inloopt op de gewone disken m.b.t. capaciteit/prijs/ verhouding. En het voordeel van ssd m.b.t. random i/o wordt nog altijd grotendeels teniet gedaan door dikke raid controllers met grote caches, die onder veel omstandigheden zelfs een betere random write i/o performance leveren dan een ssd ooit zou kunnen. (tenzij ssd net zo snel wordt als normaal geheugen..). Dan is ssd een ook stuk sneller met lezen dan gewone disken m.b.t. random access, maar tja met servers die tegenwoordig voor weinig geld van heel erg veel geheugen voorzien worden is ook die invloed beperkt.

[Reactie gewijzigd door basb op 22 juli 2024 14:07]

[ACM]

Voor websites zoals tweakers is het typisch juist dat bijna continu dezelfde (nieuws) pagina's opgevraagd worden en doorgaans ook het recentere deel. Het aantal hits op pagina's ouder dan 6 maanden zal echt niet veel zijn.

Voor de "frontpage" heb je daar inderdaad redelijk gelijk mee. Het forum is echter een ander verhaal, door het vrij actief gebruiken van de zoekmachine en google-resultaten is de long-tail naar (veel) oudere topics vrij groot. Ik meen dat zo'n 30-40% van de topic-opvragingen ouder dan een week zijn.

Bij een site zoals tweakers.net moet het voor elkaar te krijgen zijn om 99,9% uit cache te serveren met 40-50gbyte memory en het lijkt me onwaarschijnlijk dat het plaatsen van berichten zo ontzettend veel write i/o genereerd dat je daar per se ssd's voor nodig hebt.

Die geheugen-aanname zal zeker kloppen, het is dat 72GB vs 48GB een zeer geringe meerprijs had, waardoor we daarvoor kozen. SSD's hebben echter het voordeel dat we met een gerust hart onze twee array's van 15 schijven kunnen inruilen tegen een van 6 ssd's.

Het eenmalig alles van disk halen na een cold boot? Nog nooit problemen mee gezien. Initieel kijkt zeker bij tweakers vrijwel iedereen naar de zelfde pagina' s waardoor binnen kortste keren de database al weer 99,9% vanuit cache staat te serveren. Bij een site zoals tweakers zou dat wel is veel minder dan 30 seconden kunnen zijn. Ik zou zeggen, jammer dan, dat na een herstart een pagina aanleveren even een halve seconde langer duurt voor elke gebruiker. Probleem lost zich in kwestie van seconden zichzelf op.

Dat lost zich inderdaad vanzelf op... Maar met de forum-data was dit niet een kwestie van enkele seconden. Dan hadden we het over een half uur tot zelfs een heel uur. Waarbij het eerste kwartier echt serieus traag was. (en dat dus met zo'n 15-disk array als hierboven staat beschreven).
Als we vooraf wat trucjes uithaalden om de belangrijkste indexen en stukken data alvast voor te laden werd het uiteraard minder. Maar je hebt niet altijd de luxe om dat te kunnen doen en bovendien verlengt dat de downtime zelf.

ssd' s zijn absoluut sneller dan tradiotionele disken, maar het lijkt erop dat er een idee gaat leven dat je ssd's nodig hebt om enterprise performance te leveren. Dat is dus niet het geval, Het is echt voor specifieke toepassingen dat ssd' s ideaal zijn. Voor een site zoals tweakers, kun je dat geld beter stoppen in meer memory zodat het disksysteem echt alleen haast nog maar write i/o hoeft te doen en de cache policy's daar optimaal op kunt aanpassen. dat een ssd systeem met benchmarks sneller is.. ja en? ... heb je het echt nodig en ook profijt van? Of kan het prima via een goedkopere methode precies dezelfde respons geleverd worden aan de gebruiker?

Als het eenmaal allemaal opgewarmd is, zal je idd niet heel veel voordeel meer van de ssd's hebben. Echter doe je nu net alsof het hardstikke duur is om deze 6 ssd's aan te schaffen... terwijl we anders waarschijnlijk een vergelijkbaar disk-array als de vorige hadden aangeschaft en dan dus meer disks dan in de behuizing passen hadden moeten nemen en alleen al daardoor enkele duizenden euro's aan disk-behuizing + schijven kwijt te zijn.
Al met al is het helemaal niet zo veel duurder en vaak zelfs goedkoper zolang je data op de weinige SSD's past.

In de toekomst, als ssd's veel goedkoper worden en nog beter worden kan de situatie natuurlijk wel nog gaan veranderen, maar op dit moment heeft ssd het probleem dat het niet inloopt op de gewone disken m.b.t. capaciteit/prijs/ verhouding. En het voordeel van ssd m.b.t. random i/o wordt nog altijd grotendeels teniet gedaan door dikke raid controllers met grote caches, die onder veel omstandigheden zelfs een betere random write i/o performance leveren dan een ssd ooit zou kunnen. (tenzij ssd net zo snel wordt als normaal geheugen..). Dan is ssd een ook stuk sneller met lezen dan gewone disken m.b.t. random access, maar tja met servers die tegenwoordig voor weinig geld van heel erg veel geheugen voorzien worden is ook die invloed beperkt.

Hoeveel "dikke raid-controllers met grote caches" zijn er? De duurdere lsi's zitten nog steeds op hooguit 256MB of 512MB, de duurste Areca's hooguit op 1GB.

[Reactie gewijzigd door ACM op 22 juli 2024 14:07]

[basb]

"terwijl we anders waarschijnlijk een vergelijkbaar disk-array als de vorige hadden aangeschaft en dan dus meer disks dan in de behuizing passen hadden moeten nemen en alleen"

Dat is precies het punt!
Disken en raid controllers zijn een stuk sneller geworden vergeleken met 3-4 jaar geleden. Ik heb 3 jaar geleden een oude server de deur uitgegooid, met een smart array systeem met 5x9Gbyte 10K disken . het hele raid-systeem was compleet voorbijgestreefd door een enkele losse ide disk!

SSD is ongetwijfeld veel sneller dan disk, maar voor de grootte van de database is het raar als je met normale disken performance problemen krijgt.
Ik las een stukje eerder restore tijden van 10 uur voor een lullie 100gbyte. Dan klopt er iets niet. Dit behoort binnen 25 minuten te kunnen inclusief het laden van tapes. Het lijkt wel of tweakers record voor record de restore doet? Dan krijg je wel belachelijk veel random i/o...

Verder dat een forum tot 6 uur traag is na een herstart is ook vreemd. Dat duidt idd op belabberde disk performance. 6 uur lang via random i/o kan een beetje disk systeem die 100gbyte al mintens 50x volledig van disk gelezen hebben. Waardoor zijn koude starts zo kostbaar bij tweakers? Nu wordt het via hardware opgelost, is overigens wel veel goedkoper dan een software probleem oplossen

Ik ben zelf meer dan eens problemen tegen gekomen dat applicatieontwikkelaars vrolijk een tabel meer dan 100.000.000 miljoen keer laten lezen op 1 dag doordat ze foutjes hadden gemaakt in de codering , maar verdomden het probleem op te lossen. Ook in die gevallen hadden ze ook de luxe dat het betreffende platform het probleem voor ze verdoezelde. Overigens met een ongelovelijk traag disksysteem en en een fractie van de cpu-kracht vergeleken met wat tweakers heeft staan. Gewoon die ene tabel in memory houden,

Maar zoals eerder gezegd, hardware is veel goedkoper dan software aanpassen.

Op random write i/o op te vangen heb je niet zo heel erg veel cache nodig, als je random write i/o meer is dan wat een goed disksysteem kan verwerken over een periode is er toch echt iets vreemds aan de hand. Met bijv. grote batchverwerkingen kan ik me wel voorstellen dat ssd's wel een veelvoud sneller zijn dan HDD's. Hangt er vanaf wat je in de database wilt doen.

[flowerp]

Maar zoals eerder gezegd, hardware is veel goedkoper dan software aanpassen. .

Niet altijd!

Het is een combinatie van factoren. Die hardware in aanschaf is misschien wel goedkoop qua kale kosten, maar vergeet niet dat die server daar niet zomaar magisch in het rack staat volledig operationeel he?

Bij de servers die wij neerzetten gaat toch wel een flinke periode aan uitzoeken, benchmarken en tweaken vooraf. Dan komt nog de feitelijke migratie en aanpassingen van de structuur erbij (denk ook aan documentatie, toegang, uitgeven van host name, etc). Allemaal stuk voor stuk hele kleine dingetjes, en met een verdere professionalisering van ons serverpark wordt elke extra server weer een stukje makkelijker om er bij te zetten, maar toch... als we 20K voor een server uitgeven gaat daar toch nog een zeer significant stukje mensen werk in zetten, die ook theoretisch ingezet had kunnen worden voor het verbeteren van de software.

Alleen, in de praktijk werk dat toch anders.

We hebben een groep developers die continu bezig is om de DB te ontzien van last (b.v. door slim gebruik te maken van de second level en query caches van Hibernate, in combinatie met een clustered Jboss Cache), maar ook door native queries die we nog steeds gebruiken steeds verder te optimaliseren en tevens gebruik te maken van een hierarchy aan tables met voorberekende data (we gebruiken nu een soort 'kubus' in vier dimenties, waarvoor je voor 1 table 16 voorberekende afgeleide tables hebt). Vervolgs doen we nog wat aan (smart) pre-fetching zodra een onderzoeker zich bij het systeem aanmeldt.

Aan de andere kant hebben we een groep van zeg maar tweakers. Die continu kijken in de markt naar de snelste hardware oplossingen en naar het tunen van nieuwe en bestaande systemen. Denk hierbij aan settings voor IO concurency, extend sizes voor het FS, optimale blocksizes, etc.

De performance problemen worden dus bij ons van beide kanten aangevallen. We gaan niet met crappy hardware proberen alles software matig op te lossen, maar we gooien ook niet zomaar bergen hardware tegen crappy software. Nee, we proberen zo goed en kwaad als het kan -beiden- te optimaliseren.

Je kunt je algoritme's nog zo slim en optimaal gemaakt hebben, maar als je een dataset van 200GB aan ruwe meetdata moet processen voor een bepaald experiment dan is dat gewoon 200GB aan data die nodig is. Hoe slim je algo ook is, die 200GB moet er wel doorheen gepomped worden, en dan is een beetje IO reserve geen overbodige luxe.

[flowerp]

Hoeveel "dikke raid-controllers met grote caches" zijn er? De duurdere lsi's zitten nog steeds op hooguit 256MB of 512MB, de duurste Areca's hooguit op 1GB.

De Areca 1231 en 1680 kunnen 4GB aan ram aan. Als je dan voor een redelijke snelle config gaat met 3 raid controllers, zit je op 12GB aan cache op je array. Qua kosten zit je dan op zo'n 2000,- tot 2500,- (afhankelijk van je leverancier). Dat zijn wederom geen extreem hoge bedragen voor een bedrijfs server.

[flowerp]

De random write i/o's zijn met een goed geconfigueerd raid-systeem ineens helemaal niet meer zo duur.

Random write IOPS blijven natuurlijk een zwak punt, maar natuurlijk gaan die 6 SSDs van deze nieuwe tweakers server in een raid config draaien lijkt me, dus ik snap je punt niet helemaal eigenlijk.

Daarnaast gaat je hele verhaal amper in op de vacuum, back en restore die ik eerder noemde. Met 48GB ram en 16 15k SAS disks zaten wij met een DB van om en nabij de 100GB op een restore tijd van 10 uur. Met 24 SSDs was dat aanvankelijk geslonken tot 1 uur, maar toen bleek de CPU 1 core helemaal belast. De restore parallel doen (over 8 cores) bracht de restore tijd terug naar 15 minuten.

Die 16 sas disken zaten op dat moment helemaal vol qua IOPS, terwijl het SSD array met 24 disks nog steeds IOPS ruimte over had, en nu de CPU ook met 8 cores volledig belast de bottleneck bleek.

Voor vacuum geldt ook zoiets. Bij de SAS HDD disks waren tables van meer dan 4GB eigenlijk al niet meer even te vacuumen. Bij de SSDs gaat dat met 2 vingers in de neus. De tables in kwestie locked dan wel even (vacuum full), maar de overige IO vertraagt nog niet eens meetbaar, laat staan merkbaar.

Daarnaast komt nog eens dat de 24 SSDs veel minder stroom verbruiken dan die 16 15K HDDs die ze vervingen. Omdat we tegenwoordig op het amperage betalen, kunnen we nu binnen het gegeven stroom budget meer kwijt.

[Reactie gewijzigd door flowerp op 22 juli 2024 14:07]

[Femme]

ssd' s zijn absoluut sneller dan tradiotionele disken, maar het lijkt erop dat er een idee gaat leven dat je ssd's nodig hebt om enterprise performance te leveren. Dat is dus niet het geval, Het is echt voor specifieke toepassingen dat ssd' s ideaal zijn. Voor een site zoals tweakers, kun je dat geld beter stoppen in meer memory zodat het disksysteem echt alleen haast nog maar write i/o hoeft te doen en de cache policy's daar optimaal op kunt aanpassen. dat een ssd systeem met benchmarks sneller is.. ja en? ... heb je het echt nodig en ook profijt van? Of kan het prima via een goedkopere methode precies dezelfde respons geleverd worden aan de gebruiker?

Kennelijk heerst bij jou het beeld dat ssd's heel veel duurder zijn dan harde schijven. Dat valt heel erg mee zodra je eenmaal zoveel disks nodig hebt dat het niet meer in de serverbehuizing zelf past. Een externe enclosure met sas expanders voor vijftien schijven kost al minimaal 2000 euro. Je hebt veel meer harde schijven nodig dan ssd's, het totaal zal meer ruimte innemen en meer energie verbruiken. Een enkele Intel X25-E haal je al meer performance in database workloads dan met vijftien 15.000 toeren harde schijven.

Ssd's besparen geld.

Tweakers.net zal zich onder normale omstandigheden ook wel redden op configuraties met lagere I/O-prestaties, maar dan kom je veel dichter tegen de grens waarbij bezoekers door onvoorziene omstandigheden vertragingen gaan merken. Het lijkt me verstandig om een server die drie jaar mee moet draaien te overdimensioneren zodat hij voorbereid om een toekomstige groei van de belasting en moeiteloos loadpieken kan opvangen.

[klakkie.57th]

Je heb gelijk dat database in het geheugen zouden moeten passen maar da ga je al snel over erg dure servers praten en dan zijn ssd's een mooie oplossing. Servers die meerdan 72GB geheugen aankunnen zijn echt boven budget meestal. Databases maken van 100 GB gaat blijkbaar eg vlot de laatste tijd

[basb]

Dell R710 Max memory: 144Gbyte:-)
Bron: Dell.com

Concurrenten van dell hebben met vergelijkebare servers vergelijkbare capaciteiten.

[ACM]

72GB (18x4GB) geheugen kost in de configurator 2776 euro extra, 144GB (18x8GB) geheugen kost al 11972 euro extra en 196GB (12x16GB) geheugen kost zelfs 43072 euro extra... Dus hoewel de capaciteit idd bestelbaar is, is het wel gelijk een serieus stuk duurder.
Bij die concurrenten geldt ook dat 2 en 4GB per GB evenduur zijn, of de 4GB's zelfs iets goedkoper, maar dat 8GB en 16GB modules een stuk duurder zijn.

[Osxy]

Dit gaat alleen om database werk en dat is dus meer afhankelijk van de accestime, die blijft bij SSD's sneller

[basb]

Er zit 256Mbyte battery-backupped-cache op de controller. Hierdoor zal random access zoals een database dat doet ook zeer snel zijn, in theorie in elk geval, op deze server. Ik heb niet de beschikking over ssd's en ook niet over een database op dat systeem die voldoende load veroorzaakt. Apparaat staat letterlijk uit zijn neus te eten de hele dag, 30-40 users resulteerd in een load van 0,01 of 0,00. Er is echt een serieus zware database nodig om dit systeem het moeilijk te maken

De config waar ik het apparaat in heb staan is trouwens standaard raid 5. Met raid 01 of 0+1 zou er in theorie nog veel meer uit te persen zijn. Ook kun je de cache van de controller instellen m.b.t. read/write verdeling. Ook heb je nog mogelijkheden m.b.t. stripe-sizes en blocksizes. Echter met een load van 0,01 ga je je daar echt niet druk over maken en ga je verder met andere zaken op je werk:)

[Reactie gewijzigd door basb op 22 juli 2024 14:07]

[klakkie.57th]

volgens mij zijn en blijven de disks toch steeds te bottleneck en SSD's zouden dit deels moeten verhelpen al zal de interface dan wel weer de beperkende factor worden.

Het is niet echt mijn domein maar laten we je vb een keetrje nemen en gebruiken voor een simpele rekensom.

We nemen een doorsnee DB server met 64 GB memory, cpu' s doen er nu even niet toe.
je hebt 300 GB databases staan op deze server.

Nu gaan we simultaan een aantal queries draaien waardoor er van de 300GB slechts 30% gebruikt wordt dus zo'n 100GB en je hebt maar 64GB geheugen ...
Dan zullen die disks toch behoorlijk beginnen werken en dan lijkt zelfs die 500MB/s gewoon dramatisch. Niet alleen opdat dat lekker sequentieel is maar opdat dat soort snelheid gewoon niet boeiend is aangezien we sequentieel queries draaien die onmogelijk uit het geheugen kunnen komen en alles vanuit disk moet gelezen worden.

het codewoord is gewoon het aantal io's/sec en dat is nu net waar disks nog steeds verschrikkelijk slecht in zijn zelfs die 15K Sas schijven. Nu ben ik niet zeker maar hoeveel io's zouden ze halen 300/s dan moet je dus al een gigantische pool van disks hebben wil je wat snelheid halen en je kan ook maar beter geen 4K clusters gebruiken want dan wordt het helemaal dramatisch.

Nu misschien heb ik het verkeerd , maar dit is toch wat ik onthouden heb van de laatste tech sessies.


Dit is de reden waaro SSD's de toekomst zullen worden.

[ACM]

Eigenlijk is de belangrijkste reden om ssd's te nemen, om er voor te zorgen dat het kort na opstarten van de database-omgeving ook snel is. Niet pas na een uur of langer wachten...
De hoeveelheid RAM-geheugen maakt ze tijdens het dagelijks gebruik inderdaad tot op zekere hoogte overbodig.

Let er overigens op dat database-servers niet zo veel aan hoge sequentiele transfers hebben, de toegangspatronen zijn doorgaans meer willekeurig.

[AeroWB]

Waarom geen intel SSD's ?
Die zijn toch veel snelller in DB werk dan de crappy Samsungs.

zie:
http://www.anandtech.com/.../showdoc.aspx?i=3631&p=19
http://www.xbitlabs.com/a...-ssd-roundup_8.html#sect0

[Femme]

Dell levert alleen Samsung ssd's. Los aanschaffen is niet echt een optie ivm support en het feit dat je dan weer zes overbodige harde schijven moet bestellen waar je de swapbays dan van mag leegroven om er X25-E's in te zetten. Het klopt dat de X25-E beter presteert dan slc-ssd's van Samsung.

[CTVirus]

Je kan lege 3th party swap bays kopen bij sommige webwinkels in de US, maar je hebt idd geen support op die drives. Plus dat je raid managment aan geeft dat de disk not supported is.

Wij doen dit, maar niet bij onze database servers. Hoewel je van het prijsverschil bijna twee servers kan kopen.

http://www.scsi4me.com/de...-2950-6900-p-n-kf248.html

[moto-moi]

Dat zijn de bays voor de 1950's inderdaad, maar niet voor de R710 die we nu gebruiken

[CTVirus]

Compabiliteit staat ook de r710 bij.

En als ik jullie foto vergelijk met degene die wij gebruiken, dan lijken ze zoveel op elkaar dat ik het wel geloof.

[Reactie gewijzigd door CTVirus op 22 juli 2024 14:07]

[AeroWB]

Oh ja, das klote idd, je krijgt die bays natuurlijk niet dan moet je idd overbodige disks bestellen das zonde.
Ik bouw de severs meestal zelf dan heb je alle bays gewoon bij de kast.
Dan kan je in de toekomst als je meer storage performance nodig hebt een stel nieuwe intel ssds en snellere raidcontroller kopen of je koopt weer een hele nieuwe server.
Tja als je met support een probleem hebt trek je eerst je eigen addons eruit en dan bel je dell/ibm/hp

[Blasterxp]

Ook Sandisk, ten minste, die had ik in mijn laptop (32gb)... en traaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaag

[ACM]

Hoe kom je er bij dat dit crappy Samsungs zijn? In jouw voorbeeldbenchmarks zie ik uberhaupt geen Enterprise-uitvoering van Samsung, en een entry-level SSD met een samsung-controller.
Deze Samsungs zijn in Femme's benchmarks overigens prima SSD's, de Intel X-25E's zijn vooral nog wat sneller.

Magoed, het is niet alsof je het voor het kiezen hebt bij de diverse leveranciers en we geven toch wel de voorkeur aan een volledig door een leverancier ondersteunde server, ipv op diverse onderdelen verschillende mates van ondersteuning te hebben. Dus gezien het feit dat deze in eigen benchmarks zich prima gedragen, hebben we geen moeite gedaan om intel-ssd's in een dell-server te krijgen.

[AeroWB]

o.a. OCZ summit is een samsung OEM drive.
Ik weet dat de samsung benchmarks in mijn links MLC en geen SLC zijn maar ik kon geen up2date benchmark vinden met meerdere SLC drives.
SLC is natuurlijk beter en sneller dan MLC, maar het probleem wat vooral Anand beschrijft gaat over de controller problemen, als Samsungs controllers veel langzamer zijn dan die van Intel op random I/O maakt het weinig uit of je MLC of SLC gebruikt.
Daarnaast presteert de Samsung drive in Anands test op random IO writes minder dan een velociraptor terwijl de Intels het 30x beter doen, dat leek me boeiend in een DB server.
En het verhaal van dat artikel op anandtech gaat ook over dat de performance inzakt naar verloop van tijd en dat de Samsung daar meer last van hadden dan de intel en je zelf de firmware niet kan upgraden voor een nieuwere die er minder last van heeft icm met TRIM.
Ik snap dat je liever 1 leverancier hebt maar als je een meer dan een factor 2 performance verschil kan pakken door de dell server alleen met de SAS disks te bestellen en er zelf wat intels bij te knallen lijkt me dat de moeite waard.
Maargoed het blijft een erg mooi servertje waaar je wel weer even mee vooruit kan en ik ben blij dat ik m niet hoef te betalen

[Femme]

De performance degradatie van een consumenten-ssd kun je niet vergelijken met die van een enterprise-ssd. De Samsung-ssd's van Dell hebben een reservecapaciteit van bijn dertige procent terwijl consumenten-ssd's nauwelijks reserve hebben. Door de grote reservecapaciteit valt de performance-degratie heel erg mee. Een schone nieuwe drive is altijd sneller dan een drive waarbij er eerst een erase cycle moet plaatsvinden voordat een blok beschreven kan worden, maar de drive wordt gezien de beperkte performance degradatie niet geplaagd door een te kort aan vrije geheugenblokken.

Wat je bij een flash-ssd wilt voorkomen is dat gegevens weggeschreven moeten worden in geheugenblokken die gedeeltelijk valide data bevatten. In dat geval moet je die data eerst inlezen, dan het geheugenblok wissen en opnieuw programmeren. En dat dus terwijl er effectief maar een deel van de inhoud van een geheugenblok wordt gewijzigd. De Samsung slc-ssd's kunnen dankzij de grote reservecapaciteit altijd wel geheugenblokken vinden die volledig invalide data bevatten.

Verder klopt het wel dat de X25-E nog een stuk sneller is dan deze Samsung-ssd's. Helaas wordt de X25-E niet door Dell geleverd en is het nog niet zo makkelijk en handig om de schijven in een Dell-server (of een andere machine van een grote oem) te vervangen.

[flowerp]

Als er al voor de (iets) langzamere Samsung SSD is gekozen, waarom dan slechts 6?

Voor een grote bekende site van een nog grotere moederonderneming (VNU) is dat niet best wel matigjes eigenlijk? ~€ 300 x 6 = 1800,-. Dat is een bedrag wat wij (niet al te groot bedrijf wat als semi-wetenschappelijke organisatie levert aan de wetenschap, waar de budgetten en dus onze winst niet torenhoog is), makkelijk uitgeven alleen al als experimenteer platform voor onze chief hi-tech technology (of te wel, onze über-tweaker ).

De dev server van ons heeft al 12 SSDs en de productie servers 24 SSDs (Intel X25-E op 3xAreca 1680) en dat zijn echt niet heel erg overdreven dure servers.

edit: lees verderop in het topic dit:

en dat terwijl Dell de schandalige prijs van 1350 euro per ssd rekent.

hmmm... dat is inderdaad wel schandalig... dat is bijna een factor 5 meer dan de 300,- die ik boven noemde en zou dus goed overeenkomen qua prijs met 24 SLC SSD's voor een 'normale' prijs.

[Reactie gewijzigd door flowerp op 22 juli 2024 14:07]

[Femme]

Ik weet niet wat wij na korting voor de ssd's hebben betaald maar de standaard prijs is zo'n 1300 euro ex btw. Een X25-E 32GB is in de losse verkoop verkrijgbaar vanaf zo'n 265 euro ex btw. Bij Sun ging het er overigens even schandalig aan toe met de prijzen die zijn voor (X25-E) ssd's vragen. Bij een oem wordt je nu eenmaal genaaid.

Wat betreft prestaties zullen de zes ssd's snel zat zijn.

[FireDrunk]

Waarschijnlijk heeft dat ook te maken met het feit dat SSD's (vooral theoretisch) een kortere levensduur hebben dan SAS schijven... Misschien dat OEM's zich daarom indekken om zeker te zijn dat ze niet failliet gaan aan RMA's

[SKiLLa]

Wat ik eigenlijk verrassender vind, is dat 6x 50GB = 300GB aan storage genoeg is om (bijna) alle forum & frontpage data te hosten ! Had eerlijk gezegd wel verwacht dat het bij elkaar meer richting de 600GB zou gaan

Verder kopen de wat grotere bedrijven/multionationals vaak dual-quadcore servers zo ongeveer per dozijn; 8 cores & 32 GB RAM is bijna de 'standaard'-configuratie, RAM kost vrijwel niets meer en met quad-cores per socket heb je ook rekenkracht genoeg (i.t.t. vroeger !) ... wat het duur maakt, is de betrouwbare storage (SAN/SSD/etc.) die gepaste performance levert.

[ACM]

De vorige servers hardware liepen, zoals je kan zien, niet bepaald op de achterste benen. Dus het heeft weinig zin er nog veel meer geld tegenaan te smijten, terwijl we het voor de ruimte niet nodig hebben en de performance van dit nieuwe systeem ook al ruim voldoende zou moeten zijn
Voor 12 of zelfs 24 SSD's hadden we ook ineens de boel niet meer in een 2U behuizing kwijt gekund en sowieso konden we dan niet bij een OEM terecht maar hadden we weer de boel zelf moeten bouwen.

We hebben overigens niet die volle 1350 hoeven betalen, hoeveel wel weet ik niet, we hebben uiteraard alleen maar een totaalprijs van de server gekregen

[Kees]

Omdat dell die niet heeft.

[cheeks]

Omdat Dell waarschijnlijk deze levert en dus ondersteuning biedt, kunt als bedrijf niet echt maken om zo maar eigen hdd's te kopen en deze in je server te drukken. Vooral als je ook nog support verwacht.

[Anoniem: 135756]

Draaien jullie niks in een server cluster?
Dat had ik eigenlijk wel verwacht.

Webspul in een NLB cluster en het statefull spul (databases) in een server cluster.
Hoe is redundancy van server uitval nu geregeld dan?

[Kees]

Wie zegt dat we niets in een cluster draaien? We hebben een webserver cluster, waarbij de loadbalancer bepaald of een webserver al dan niet leeft - nee, geen standaard spul, geen appliance ervoor, geen gekke software met fencing op de webservers.

Wel software die in je in vrijwel iedere appliance terugvind zoals LVS (waar ik tijdens het instaleren van de loadbalancers ook 2 bugs voor heb moeten fixen; en waar vrijwel iederen black box appliance op draait).

Verder geen heartbeat/pacemaker cluster voor de webservers. Dat is gewoon niet nuttig in onze situatie. Wel komt er een pacemaker oplossing voor de shared disk, maar dan veranderd er op de webservers vrij weinig.

De databases worden gerepliceerd naar een andere server (welke vervolgens voornamelijk voor backups gebruikt worden; als de data op de replicatie server niet meer dan 30 minuten achterloopt wordt de replicatie gestopt, backup gemaakt en replicatie weer aangezet - en voila, volledig consistente backup zonder dat iemand er iets van merkt). En in de toekomst kunnen we van die server ook gewoon de databases trekken mocht de mainserver plat gaan (mischien read-only, maar dat moeten we nog zien).

Dus redundancy:
2x loadbalancer
4x webserver (4x identiek)
2x mysql server (replicatie)
2x active-passive NFS server (naja.. server.. 2x een vm op een andere server)

Enige belangrijke server die niet gemakkelijk gerepliceerd kan worden is de zoekmachine, maar mocht die echt plat gaan dan hebben we nog altijd een backup van de database en kunnen we in korte tijd een andere server inrichten als zoekmachine.

[Anoniem: 135756]

"Wie zegt dat we niets in een cluster draaien?"

Niemand.
En mijn vraag betrof een [b]server cluster[/b" (geen NLB cluster)
Omdat een database typisch iets is wat ik in een server cluster zou draaien vroeg ik me af of jullie dat uberhaupt niet deden.

De file server dus, via VM's. Is dat 2 VM's op 1 machine? want dan heb je erg weinig aan het server cluster; de machine mag alsnog niet uitvallen.
Maar de DB server(s) dus niet in een server cluster. Leuk die database replicatie, wat als de server nou *poef* doet? Heel snel een nieuwe server regelen? of heb je die al klaar staan? Zo ja, kan je die net zo goed in een server cluster gooien met de bestaande. zo nee:

[Reactie gewijzigd door Anoniem: 135756 op 22 juli 2024 14:07]

[Kees]

Als de server poef doet en hij is echt dood, dan gebruiken we de replicatiemachiene als main database, In eerste instantie read-only, maar als de mainserver niet makkelijk te redden is dan kunnen we hem ook gewoon als master gebruiken terwijl wij aanspraak maken op ons Dell contract om die server te fixen. De replicatie server is dan wel 'oud' maar zou deze load ook nog wel aankunnen als we een paar scripts uitzetten.

En nee, dat is niet ideaal, ideaal zou twee gelijke machines zijn in een active-active setup, maar dan moeten we twee van deze beesten ophangen en daar is het budget niet voor.

[Rinzwind]

Niet, en je ziet hoe goed dat gaat Gewoon degelijke hardware, goede software en de boel juist beheren. Bepalen hoeveel downtime je accepteert. Een uurtje eruit? Jammer dan. En het kan ook altijd fout gaan buiten jouw mooie cluster om.

[cariolive23]

En wat zijn de kosten van zo'n fraaie server?

[pasta]

Als je zoekt op Google en daar de eerste link volgt, die aanpast naar eigen wens (iig qua specs gelijk aan die van Tweakers.net) zou je uitkomen op ongeveer 12 a 13000 dollar. Nu zal daar wel wat van af gaan (btw, etc.) dus zou je kunnen uitgaan van zo'n 10000 dollar.

Let wel; dit is maar een wilde gok. Het is niet dat ik iets van inside-info heb.

[Reactie gewijzigd door pasta op 22 juli 2024 14:07]

[Mental]

Knappe jongen, ik kom toch echt uit op 21000 dollar met 6 50gb ssd's, 72gb geheugen en de vermeldde cpu's.

[Rataplan_]

Wij hebben er een stuk of 50 van deze draaien, niet allemaal met deze specs. Onze ESX hosts zijn echter ook met 2x quadcore 2.93GHz en 72GB RAM (ook de 18x4 configuratie). Nou krijgen wij een aardige korting bij Dell, maar dan komen we niet boven de 6 a 7k uit voor zo'n machine, en dat is dan inclusief Dual 10GB TwinAX DA nic.

edit:

hmm die SSD disks zijn natuurlijk wel duurder, die gebruiken wij niet

Het zijn geweldige servers. Prijs/prestatie is geweldig, Nehalem CPU's rennen echt rondjes om alles heen. In combo met dat tripple band geheugen echt een dijk van een beest. Helaas is de 4 socket variant er nog niet van uit... Daarvoor moeten wij nog steeds terugvallen op de 'ouwe' R900...
Hoe dan ook, de kosten vallen tegenwoordig best mee, verreweg de grootste kostenpost is de support die je erop afneemt..
Heren, succes morgen!

[Reactie gewijzigd door Rataplan_ op 22 juli 2024 14:07]

[dasiro]

1 maand reclame-inkomsten van Dell

[deus4]

Wow mooi beestje. Daar is mijn mooie gameservertje een kleine jongen bij. Maar kan iemand mij het nut uitleggen van 6 solid state disks gecombineerd met 2 sas schijven? Volgens het artikel worden de sas schijven gebruikt voor het OS en de SQL logs. Ik neem aan dat het 2 sas schijven zijn om ze in mirror te draaien en daarbij is 300GB/disk tegenwoordig vrij goedkoop. Maar wat ga je daarnaast met 6 relatief kleine solid state disks aanvangen?

[Femme]

De zes ssd's bieden samen 250GB aan opslagcapaciteit in raid 5. Onze databases bevatten puur tekstgebaseerde data. Een groot deel van die data betreft door mensenhand ingevoerde tekst. Als je handmatig honderden gigabytes aan data wilt produceren ben je wel even bezig. De opslagcapaciteit van de ssd's is dus meer dan voldoende.

De harde schijven zitten erin omdat het jammer is om dure ssd's te gebruiken voor een boot-array. Een gescheiden array voor boot+binlogs is aan te raden omdat je dan makkelijk de datadrives anders kunt inrichten en de binlogs dan online blijven als de data array stuk is.

[cariolive23]

RAID 5 voor de database? Dat zorgt dan in elk geval voor (relatief) slechte write-performance, databases houden niet van RAID 5. RAID 1+0 lijkt mij meer voor de hand liggen wanneer je hoge performance nodig hebt, het is alleen wel ietsjes duurder.

[Femme]

De prestaties van raid 5 en raid 10 met een vergelijkbaar aantal drives verschillen niet zoveel als je een goede raidcontroller gebruikt. Het hangt een beetje af van de verhouding tussen reads en writes van de betreffende toepassing. Raid 5 heeft hogere leesprestaties dan raid 10 maar wat meer overhead op schrijfacties. De overhead op de schrijfacties valt heel erg mee op een goede raidcontroller die over een mooie hoeveelheid write-back cache beschikt. Een schrijfactie wordt dan gewoon in enkele honderdsten van een milliseconde afgehandeld zolang de cache de schrijfactie kan opvangen. Als je drives dan niet vol onder belasting staan merk je weinig van deze schrijfacties.

Het mooie van ssd's in combinatie met raid 5 is de minimale lage penalty van de read-modify-write-cycle die nodig is voor het bepalen van pariteit van een stripe die gedeeltelijk wordt gewijzigd. Reads zijn zeer snel op ssd's vanwege de lage toegangstijd en de writes zijn snel vanwege de raid-cache.

Met een X25-E hoef je trouwens al helemaal niet bang te zijn voor slechte schrijfprestaties. De X25-E presteert fenomenaal op random writes.

[Reactie gewijzigd door Femme op 22 juli 2024 14:07]

[ACM]

Naast Femme's uitleg speelde nog mee dat het dan wel heel kostbaar wordt met die SSD's. Dan gooi je niet de capaciteit van eentje, maar van drie weg. En zouden we dus met minder dan 150GB ruimte eindigen (er kunnen max 8 disks in deze behuizing) voor een 100GB dataset... die nog altijd groeit.

Dus dat werd gevaarlijk in verband met de capaciteit en duur in verband met de prijs om dat wel uitgebreider met raid 10 te doen

[Barleone]

Ik vermoed iets met cache.
disclaimer: iets met een klok en een klepel
@hieronder:
Mja, sowieso profiteert de database zelf al behóórlijk van solide 'schijfjes'.

[Reactie gewijzigd door Barleone op 22 juli 2024 14:07]

[mzziol]

Database database database . Dat is alles als het goed is. Omdat een database heel veel IOPS nodig heeft, is er voor SSD's gekozen.

[Kees]

Daar komt de database op te staan die momenteel zo'n 100 gig totaal is.

[Anoniem: 6977]

Snelheidstestje op GOT met zoekopdracht over laatste 10 jaar:

Er is gezocht op: de
Er zijn ongeveer 399.923 resultaten, verdeeld over 401 pagina's.
Woord frequenties: de: 1220727
Database van 1339440 documenten doorzocht in 0,480s.

Geen klachten.

[Kees]

Maar dat is niet deze databaseserver die geupgraded is, dat is Aphrodite, onze zoekserver: plan: Fotoverslag serveronderhoud 10-07-2009 (de Dell R610)

Daar is geen vervangings .plan van geweest, maar die is dan ook zonder downtime over te zetten.

[Anoniem: 135756]

Hear, hear!
Dat zijn Google-achtige snelheden.

[Anoniem: 221425]

Hulde!

[IJnte]

Succes ermee! Zullen we er als "gebruikers" ook nog veel van merken (sneller pagina laden etc, meer pricewatch features) We hebben gelukkig ook al tijden geen grote crash meer gehad, en ook al tijden geen data kwijtgeraakt!
Goed dat jullie bezig zijn met jullie serverpark toekomstproof te maken

[ACM]

De queries zullen wel weer wat sneller worden, maar ik denk dat we in het bereik zitten dat je er meestal niet zoveel meer van merkt. De laadtijd wordt voor de meeste pagina's vooral gedomineerd door de extra resources (javascript, css, plaatjes, etc) en browser-rendertijden.
Er zijn uiteraard nog wel wat pagina's die relatief pittige queries uitvoeren en daar zou nog wel wat winst merkbaar kunnen zijn.

Wel zal de performance van deze server veel beter zijn op het moment dat ie net gestart is, bijvoorbeeld na een softwareupdate. Domweg omdat de data nu van SSD's komt ipv van HDD's, waarbij juist de initiele druk van willekeurig lezen van al die data een heel stuk beter zou moeten werken.

[humbug]

Voor een "grote" internetsite vind ik het toch vreemd dat er steeds downtime is bij een update van iets. Draait tweakers dan echt niets redundant en dan er niet gewoon een server offline worden genomen of worden bijgeschakeld zonder offline te moeten? Dat moet toch beter kunnen...

[moto-moi]

Uiteraard kan het beter, betaal jij? Verder zijn wij niet zo groot als een google, een last.fm, een hyves om grote clusters te kunnen bouwen, wij hebben maar enkele machines waarmee we die paar miljoen pageviews per dag doen. Uiteraard vinden wij het ook vervelend als we down zijn, maar (buiten problemen zoals er nu nog spelen met ocfs2) we zijn weinig down, alleen met grote updates van code, of het vervangen van een belangrijke machine zoals de centrale database.

[Bezulba]

ja want 4 uur downtime in jaren is echt vreselijk enzo.. vooral die betalende klanten die op zaterdagmorgen bij hun posts willen is het echt behelpen zo..

Als een bank nog elke nacht dicht mag, dan moet je niet gaan zeuren dat een hobbysite zo heel af en toe wat uurtjes downtime heeft.

[Strikertje]

nice!!
waar halen jullie dit geld vandaan zeg *kwijl*

[wildhagen]

Mwah, het is VNU hé, die hebben geld genoeg als je ziet wat die voor winsten draaien

En zo enorm buitengewoon duur ziet die setup er nu ook weer niet uit, voor server-begrippen uiteraard.

Hele aardige machine idd.

[Anoniem: 261542]

Mwah, het is VNU hé, die hebben geld genoeg als je ziet wat die voor winsten draaien

bij mijn weten heeft vnu niks meer met tweakers.net te maken.

tweakers.net is van vnu media bv. het is in handen van private equity investors. het is niet beursgenoteerd en er zijn dus ook geen openbare kwartaal cijfers van vnu media bv beschikbaar. dus of er winst gemaakt wordt en hoeveel kun je niet weten.

http://nl.wikipedia.org/wiki/VNU_Media

[Brilsmurfffje]

niet zo duur, je praat wel over meer dan 16 duizend euro
Mooie server en lekker compact ook,

[ACM]

16 duizend euro? Zoveel hebben wij er niet voor hoeven betalen hoor, en dan is ie niet eens gesponsoord. Magoed, we hebben gewoon een bepaald stel eisen aan zo'n server, dit is zo'n beetje de belangrijkste server van allemaal, en degene die het minst makkelijk te vervangen of uit te breiden is, dus we kunnen het ons ook weer niet echt permiteren om hem krap aan voldoende krachtig te maken.

Overigens lijkt het me sterk dat VNU Media in een jaar als dit nog "tientallen miljoenen winst" maakt, maar er is uiteraard wel geld beschikbaar om de continuiteit en performance van de site te garanderen.

[Reactie gewijzigd door ACM op 22 juli 2024 14:07]

[wildhagen]

En dat is voor servers van deze specs echt niet zoveel. Je moet het niet vergelijken met een PC-tje wat je zelf ff in elkaar zet.

Daarnaast, VNU maakt tientallen miljoenen winst, denk je dat 16.000 euro dan zoveel voor ze is? Want die server helpt ook weer winst te genereren.

Plus, zoals ACM hierboven al zegt, spaart men weer een server uit, wat dus weer scheelt in housingkosten, stroom, beheerskosten, etc etc.

[Damic]

Vergeet niet dat kunnen ze waarschijnlijk nog eens aftrekken van de belastingen ook (bij ons toch het Belgen landje) en er is minder energie nodig ) natuurlijk dat die sponsoren

[Beaves]

Jij hebt echt een mooie naïeve kijk op de huidige stand van zaken als je denkt dat een bedrijf als VNU in de huidige tijd nog tientallen miljoenen winst maakt

Niet voor niets hebben ze recent herfinancieringen moeten doorvoeren bijvoorbeeld.

Feit is wel dat besparen door niet te investeren vaak nog dommer is en deze server zal echt niet de financiële reserves gaan aanspreken.

[Anoniem: 24394]

Pas geleden hebben wij een HP 9000 moeten aanschaffen, helaas was de apps laag nog niet snel genoeg klaar voor ombouw en die koste ons 100K. 16K is dan dus een schijntje.

De normale servers die wij aanschaffen zitten allemaal rond de 10K dus ik schik hier totaal niet van voor een professionele omgeving als TNET

[Reactie gewijzigd door Anoniem: 24394 op 22 juli 2024 14:07]

[Brons]

16k duur? Dat is waarschijnlijk het maandsalaris (of toch weeksalaris?) van de baas van Femme. Valt allemaal dus wel mee .

[ACM]

Eigenlijk besparen we een beetje geld he? Want we vervangen twee machines door een, waarbij de losse budgetten van die twee hoger waren dan het budget van deze ene
Of eigenlijk vervangen we drie door twee, want er blijft nog een de replicatie-omgeving draaien.

[bbr]

Dacht dat die ook last hadden van de economische crisis?

[VNA9216]

Misschien een idee om het status van de SSD's te loggen ergens oid. (dus aangeven of ze goed werken, en welke defecten (if any) er optreden.)

Zelf heb ik wat slechte ervaringen met SSD's in high performance omgevingen gehad, dus ik ben heel benieuwd hoe deze jongens zich houden. Na anderhalf tot 2 jaar zal er zeker wel het een en ander verbeterd zijn, maar toch... Misschien wel leuk om het een beetje bij te houden op een pagina met de huidige server specs en het eventueel uit te zetten tegen defecte normale harddisks in de oude servers.

[GlowMouse]

Waren dat SLC of MLC SSD's? Hoster pcextreme gebruikt al tijden SLC SSD's in hun databaseserver en is erg tevreden over de snelheid.

[VNA9216]

Ik ben niet 100% zeker meer van het type cellen, maar ik dacht dat het MLC was. Het tegenvallen was niet zozeer de snelheid, maar de betrouwbaarheid, binnen een paar maanden waren ze allemaal al een keer vervangen. doorgebrande controllers en defect geheugen, dr kwam vanalles voorbij.
Na 3 kwart jaar zal het ongeveer geweest zijn werd weer terug geschakeld op normale harddisks omdat we SSD's aan het vervangen bleven terwijl normale harddisks zonder problemen 4+ jaar meedraaiden (en dan preventief vervangen werden)
Dus helaas toendertijd geen succes. Ik vroeg m af of de huidige kwaliteit al wat beter is voor dit soort omgevingen. Daarom leek het me wel wat voor tweakers om zoiets eens gelijk bij te houden en dan over een jaartje oid eens een review oid te plaatsen met de ervaringen etc.

[Femme]

Welk merk ssd's waren het?

Slc ssd's hebben sowieso een veel langere levensduur dan mlc ssd's. De nieuwere generatie ssd's hebben ook een veel lagere write amplification factor dan oudere ssd's. Als je flashgeheugen domweg lineair gaat mappen naar blokadressen krijg je een dramatisch overhead op kleine schrijfacties die de inhoud van geheugenblokken gedeeltelijke wijzigen. Dit zorgt ervoor dat er in het flashgeheugen veel meer data wordt geschreven dan je op basis van de wijzigingen in het bestandssysteem zou verwachten.

Een modere ssd mapt wijzigingen naar geheugenpages in lege geheugenblokken, zodat er alleen data wordt weggeschreven die werkelijk wordt gewijzigd. Ik kan me voorstellen dat verbeteringen in dit soort technieken en in wear levelling ervaring zorgen dat moderne ssd's met hetzelfde type flashgeheugen en langere levensduur hebben dan de ssd's die jullie hebben gebruikt.

[VNA9216]

De schijven waren als ik me niet vergis OCZ schijfjes. De fabrikant kon zelf de hoeveelheid uitval ook niet verklaren, aan de hand van de teruggestuurde exemplaren was het helaas ook niet mogelijk om te zien wat de oorzaak was.

Maar dan blijkt toch hoe gevoelig je bent voor dat soort dingen, want sinds die gebeurtenis heb ik SSD's eigenlijk nooit meer een kans gegeven, ook niet voor prive gebruik.