Cookies op Tweakers

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

Meer informatie

Door , , reacties: 228, views: 40.231 •

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.

Artemis 6 Dell PowerEdge R710 behuizing dicht

Artemis 6 Dell PowerEdge R710 geheugen en heatsinks

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.

Loadontwikkeling Artemis en Apollo 2001 - 2009

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.

Artemis 6 Dell PowerEdge R710 drive bays

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!

Lees meer over

Reacties (228)

Reactiefilter:-12280226+1203+235+31
1 2 3 ... 7
:9 dat ding is gewoon pure hardwarepr0n :D

Succes met het ombouwen in elk geval, het zal de performance in elk geval vast ten goede komen.|
Inderdaad dit ding is echt meesterlijk, hopelijk gaat tweakers dan nog sneller :D
Over 9 jaar maak je hier misschien alleen nog maar een netbookje mee bang ;)
Weet ik wel zeker! :) Dan heb je 'beetje' snelheid beetje performance, beetje opslag ;)

[Reactie gewijzigd door DJ-Visto op 23 oktober 2009 17:51]

Vinden jullie tweakers al niet snel genoeg ??

Op naar nog meer opslag :D
ja het is nu snel zat, maar als je kijkt naar de 'running costs' van de oude servers is de nieuwe overstap een hele grote verbetering. Dat heet 'rationalisatie'

bij gelijke of betere performance een veel kleinere rackspace (= duur!) en in totaal ook een veel lager energieverbruik.

Als het verschil groot genoeg is heb je in no time de investering terugverdiend.
Geldt dat voor Tweakers.net ook? Voor zover ik weet zijn ze hoofdzakelijk gesponsored, toch?
toch niet (meer) ;) We betalen alweer geruime tijd voor onze servers :)
Ik denk dat hij VNU bedoelt?
Ik denk dat hij VNU bedoelt?
VNU is een bedrijf, waar t.net een bedrijfsonderdeel van is. Derhalve zal t.net gewoon geld moeten opbrengen voor 'mama' VNU. En dit haalt geld weg van die winst, die ze dus zullen moeten kunnen verantwoorden. :)
We hebben vanaf het begin (relatief) veel kosten gehad aan hosting. Eerst voor de huur van een dedicated server, later voor hardware. Een paar systemen werden volledig gesponsord, anderen gedeeltelijk. Sinds 2003 kopen we eigenlijk alles al zelf. In het bovenstaande lijstje werden alleen de eerste vier servers gebouwd met gedeeltelijk gesponsorde hardware.

De grap is dat het beeld dat we op gesponsorde hardware draaien nogal lang blijft hangen, evenals het idee dat ons nieuws bij elkaar geklust zou worden door onbetaalde studenten ;) .
Dan kan je het menu nog wel een plezier doen door oude energieslurpende hardware te vervangen door efficiente nieuwe hardware ;). Wel een heel mooi aantal RAM-reepjes in dat ding...
rackspace, energieverbruik :?

* moto-moi wijst naar dat geinige icoontje rechtsbovenaan elke pagina. Not our concern ;)
* moto-moi wijst naar dat geinige icoontje rechtsbovenaan elke pagina
Welk icoontje? :P
Hosted by TRUE. dat icoontje denk ik :)
weet niet of je de racks van tweakers.net wel eens hebt gezien maar dan had je ook geweten dat rackspace echt geen probleem is ;)
Over 9 jaar is dat alweer een mobiele telefoon ;)
En 9 jaar geleden hadden ze u zot verklaard.

Al zie ik mij 9 jaar van nu toch geen laptop met 72GB ram geheugen bezitten.

[Reactie gewijzigd door ng128 op 24 oktober 2009 19:12]

Dan ondersteund de 128 bit versie van Windows(Consumentenversie) maar 32 GB ?, en dan is mischien de 256 bit versie uit die 64 GB ondersteund ?
Wat heeft Windows met een server te maken???
Gewoon even voor de goede orde:
32 bit slaat op de lengte van een adres; dus dat wilt zeggen dat je 2^32 bytes in het geheugen kan aanspreken; even vlug uitrekenen: 2^32 byte = 2^2 * 2^30 byte = 4*2^30 byte = 4*2^20 kibibyte = 4*2^10 mebibyte = 4 gibibyte; dus de adreslimiet van je RAM-geheugen zonder speciale trucjes (zoals PAE).

64 bit ondersteunt dus een adresruimte van 2^64 byte, dus 16 exbibyte; hetgene we nog niet zo snel gaan bereiken (en wat de huidige operating systems ook niet ondersteunen trouwens), laat staan dat we op dat moment zitten smeken voor 128 of 256 bit; 64 bit biedt voor lang genoeg alles wat we nodig hebben, denk ik (het is nooit slim om van die uitspraken af te doen als feit).
Geekporn :9~
Zo eentje wil ik ook wel thuis!


En, ligt het aan mij of heeft apollo het volgens die chart niet zo heel druk de laatste tijd?

[Reactie gewijzigd door bbr op 23 oktober 2009 17:36]

En, ligt het aan mij of heeft apollo het volgens die chart niet zo heel druk de laatste tijd?
Misschien omdat ze toen nieuwe software erop plempten (zoals memcache enzo) die de databaseservers ontlastten? Je ziet bij Artemis sowieso een flinke dip bij het installeren van die Java middleware.
Helaas zal je thuis niet zo veel aan dit ding hebben. Veel te weinig upload snelheid, staat ie voor 90% op idle...
Inderdaad geweldig beestje. Heb er onlangs zelf ook een met 3 TB aan schijfruimte ingericht en in beheer genomen, wordt onze backupserver. Komt volgend jaar nog een tweede R710 bij met 1,5 TB aan schijven die onze ESX-server wordt. Jammer dat op de foto's het frontje er niet op zit, dat is namelijk ERG mooi!

[Reactie gewijzigd door poktor op 23 oktober 2009 22:04]

ESX is leuk, maar speel voor de grap eens met HyperV-server 2008 R2 en System Center Virtual Machine Manager :)
Je zult zien dat HyperV meer mogelijkheden en meer performance geeft voor mindere prijs dan ESX. Ook werkt P2V 100x keer beter en sneller :)

het is maar een tip...
En dan moet je plots scom installeren om mee te zijn met het drs-verhaal. En laat ons nog niet spreken over memory overcommitment (itt tot wat MS vertelt wordt dit zowat overal gebruikt) of network teaming.
Erg handig om lokale storage te gebruiken met ESX, of zie ik het verkeerd ?
Als je een enkele ESX bak hebt is het geen probleem, maar als je een mooi DRS 'cluster' wilt maken gaat dat niet.
frontjes van dell zijn iritant, dekken juist de onderdelen van de machine af die ik graag wil kunnen bereiken, zoals de aan-uit knop en vaak ook disks. Die krengen gaan we dus nooit gebruiken, en gelukkig kun je ze tegenwoordig ook uit je order halen.
damn.. het is idd hardware pr0n.. godnondeju.. wat een heerlijke specs zeg...
Leuk servertje idd, Heb er toevallig ook eentje gekocht vorige week (R710), iets minder gepimped dan deze :)
Vorige week vrijdag besteld, dinsdag had ik hem binnen. Verbazingwekkend snel geleverd door Dell.
Die R710 performed als een beest.
nice!!
waar halen jullie dit geld vandaan zeg *kwijl* :P
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.
Eigenlijk besparen we een beetje geld he? :P 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.
niet zo duur, je praat wel over meer dan 16 duizend euro 8)7 8)7
Mooie server en lekker compact ook,
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.
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 :D
:D 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 :X

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.
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 Conqueror op 23 oktober 2009 17:38]

16 duizend euro? :P 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 23 oktober 2009 17:38]

16k duur? Dat is waarschijnlijk het maandsalaris (of toch weeksalaris?) van de baas van Femme. Valt allemaal dus wel mee :).
Dacht dat die ook last hadden van de economische crisis?
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
even rekenen ...

72GB ... verdeeld over 16 geheugenbanken, dat maakt elk 4,5GB ?

ofwel .. 14x 4GB en 2x 8GB?
18x 4GB ;) Nehalem heeft doorgaans een veelvoud van 3 banken per cpu, hier dus 3x3 per cpu, maakt 18 in totaal.

[Reactie gewijzigd door ACM op 23 oktober 2009 17:10]

18x4gb ... goed, maar ik tel toch ťcht maar 16 sloten (2x 8)
zie foto hierboven.
Beter tellen :)

Rechts zijn 9 sloten zichtbaar, links 8, maar daar is achter de opstaande rand van de casing nog zat ruimte voor een 9e...
je hebt gelijk .. beter kijken & tellen !
Eerder 72GB/9sloten per processor = 4GB/geheugenslot
En die dingen heten altijd nog sloten...
Volgens mij kun je nog wel eeuwig bezig blijven met idereen vertellen dat het sloten zijn ipv banken ;)
Dan is het te hopen dat er ook eens naar geluisterd wordt, die dingen banken noemen is gewoon pertinent fout namelijk, want dat zijn heel andere dingen :P
Allereerst wil ik de crew heel veel succes wensen met de migratie naar deze nieuwe server. Hopelijk komt Murphy niet langs! ;)
Dan is het te hopen dat er ook eens naar geluisterd wordt, die dingen banken noemen is gewoon pertinent fout namelijk, want dat zijn heel andere dingen :P
En waarom is het zo 'fout' dan? Je weet toch wat er bedoeld word? Zonder dat heeft men er nog niets aan natuurlijk. ;) Dat jij het een slot noemt, maakt het niet fout als een ander er bank voor zegt.
Maar een geheugenbank is iets anders. Een geheugenbank is een opeenvolgend stuk geheugen wat als geheel behandeld wordt, maar wat niet overeen hoeft te komen met precies een module in een slot. Een geheugenbank is tegenwoordig vaak net zo breed als een cacheline of een woord van een bepaalde architectuur, of een andere handige hoeveelheid zoals een rij geheugen in een chip.
succes met de migratie heren (en dames :p ) mochten jullie nog de oude hardewaren op een natuurvriendelijke manier willen afdanken dan houd ik mij (en met mij velen denk ik zo ;) ) van harte aanbevolen :D
Ik heb al moeite om om half acht te beginnen met werken op zaterdag.... 8-)
En wat zijn de kosten van zo'n fraaie server?
1 maand reclame-inkomsten van Dell :+
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 23 oktober 2009 17:23]

Knappe jongen, ik kom toch echt uit op 21000 dollar met 6 50gb ssd's, 72gb geheugen en de vermeldde cpu's.
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 23 oktober 2009 22:49]

damm, (hoezo crisis :z ) wel plaatjes schiete he , (pics or it didn't happen)

maar wel brute specs , die server zal wel weer een tijdje tegen kunnen

Tegen de tijd dat je goed en wel bent uitgeslapen zijn wij dus al lang weer up and running.


echte tweakers slapen niet :+
die moeten alleen een paar uurtjes aan de stroom :Y)
Oh, de crisis raakt ons ook wel hoor. Maar we kunnen moeilijk ineens gaan besparen op de spil van ons netwerk, want als die niet op zijn minst voldoet aan de eisen dan gaan we dat nog veel harder voelen :P

Hij is waarschijnlijk wel een beetje overgespecificeerd, magoed, het blijft lastig inschatten wat de load van twee machines de komende jaren op eentje gaat doen.

Enneuh, de machine hangt er al een tijdje. De reden dat er downtime is, is omdat daadwerkelijk de data over moet. Daar foto's van maken is tamelijk saai.

[Reactie gewijzigd door ACM op 23 oktober 2009 17:16]

Ik wil prima een plaatje schieten van mijn wekker en een screenshot maken met puttyschermen open, geen probleem hoor :P De plaatsing is allang geweest.
Zolang je maar oppast dat je geen wachtwoorden in je screenshot te lezen is lijkt het me een goed idee :+
Klopt, slaap slechts zo'n 4 uurtjes per dag.. :Y)
Waarom geen intel SSD's ?
Die zijn toch veel snelller in DB werk dan de crappy Samsungs.

zie:
http://www.anandtech.com/...wdoc.aspx?i=3631&p=19
http://www.xbitlabs.com/a...-ssd-roundup_8.html#sect0
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.
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 :)
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.
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 23 oktober 2009 22:11]

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.
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
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.
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 :)
Omdat dell die niet heeft.
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.
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 :)
Ook Sandisk, ten minste, die had ik in mijn laptop (32gb)... en traaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaag :P
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
Dat zijn de bays voor de 1950's inderdaad, maar niet voor de R710 die we nu gebruiken :)
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 26 oktober 2009 16:30]

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.
Jup, het is bijna beter dan pr0n.
Toch ben ik benieuwd wat we over 8 jaar aan hardware terug vinden in de servers. Die vooruitgang gaat zo ontiegelijk snel!
Die vooruitgang gaat zo ontiegelijk snel!
Dat valt nog vies tegen.

De Areca 1680 raid controller is al enkele jaren(!) oud en nog steeds op bijna alle punten de snelste raid controller die je kunt kopen. De Intel X25-E is nu ook een goed jaar uit. In die tussentijd zijn noch Intel noch concurrenten met een betere SLC SSD gekomen. Er is ook geen enkele aanwijzing dat Intel op de korte termijn met een betere en snellere SLC gaat komen.

Wel zou er nu eindelijk over een dik half jaar een snellere raid controller van Areca gaan komen. Intel richt zich momenteel alleen op de goedkopere MLC SSD's, die ze voornamelijk goedkoper en groter maken, maar niet sneller of beter.
Doordat Intel de ontwikkeling van IOP's heeft gestaakt hebben we dit jaar weinig vernieuwing gezien bij de fabrikanten van raid-adapters. De belangrijkste vernieuwingen van dit jaar is denk ik de nieuwe serie van LSI Logic. Volgend jaar gaat een interessant jaar worden. Areca gaat Marvell IOP's gebruiken, LSI Logic heeft al een eigen oplossing bedacht en wat Adaptec gaat doen is me nog niet duidelijk. 3ware is overgenomen door LSI Logic en zal neem ik aan sterven of iets op basis van LSI Logic tech uitbrengen. Een gemis is dat niet omdat 3ware nooit iets indrukwekkends op de markt heeft gebracht.
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 23 oktober 2009 17:44]

Dit gaat alleen om database werk en dat is dus meer afhankelijk van de accestime, die blijft bij SSD's sneller :)
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 23 oktober 2009 17:48]

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.
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.
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.
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 23 oktober 2009 18:19]

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 23 oktober 2009 18:25]

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.
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.
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).
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 24 oktober 2009 01:45]

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 24 oktober 2009 01:53]

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 24 oktober 2009 10:06]

"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.
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.
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.
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.
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 :)
Dell R710 Max memory: 144Gbyte:-)
Bron: Dell.com

Concurrenten van dell hebben met vergelijkebare servers vergelijkbare capaciteiten.
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.
1 2 3 ... 7

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneApple iOS 8

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

Beste nieuwssite en prijsvergelijker van het jaar 2013