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

×

Help jij Tweakers Website van het Jaar te worden?

Tweakers is genomineerd voor beste website 2014 in de categorieŽn Nieuws & Informatie, Community en Vergelijking. Stem nu en maak kans op mooie prijzen!

Door , , reacties: 183, views: 39.264 •

Op maandagochtend 21 januari heeft Tweakers een nieuwe databaseserver in gebruik genomen. De site is hierdoor enkele minuten read-only beschikbaar geweest. Inmiddels is het onderhoud succesvol afgerond.

Omdat de huidige databaseserver, Artemis 6, zijn derde verjaardag al enige tijd geleden heeft mogen vieren, is het hoog tijd om hem te vervangen. Het uitzoeken van een waardige opvolger voor deze databaseserver was geen sinecure, de specificaties van Artemis 6 zijn zelfs na 3 jaar nog behoorlijk indrukwekkend. Desondanks zijn we er weer in geslaagd om de specificaties te verbeteren.

De nieuwe databaseserver, Artemis 7, is een 1u IBM x3550 M4, met daarin twee Intel Xeon E5-2643-quadcore-processoren die op 3,3GHz lopen. Omdat geheugen meestal sneller is dan een harde schijf, hebben wij deze server afgeladen met 16 reepjes ddr3-geheugen van 1600MHz en 16GB, zodat de totale hoeveelheid geheugen op 256GB uitkomt. Dat is genoeg om onze hele database in het geheugen te laden en meer dan alle voorgaande Artemis- en Apollo-iteraties bij elkaar. Het nadeel hiervan is wel dat je makkelijk een kopje koffie kunt gaan drinken terwijl de server tijdens de boot het geheugen controleert.

Het is wel leuk om je hele database in het geheugen te laden, maar zodra je de server reboot, wil je je data ook nog ergens veilig hebben staan. Om dit te regelen hebben we de server ook uitgerust met 6 ssd's van 256GB, die in raid 10 hun werk doen. Ten slotte zitten er nog twee sata-harde schijven van 250GB in, waarop het besturingssysteem staat.

Deze nieuwe server hebben wij op maandagochtend rond 9 uur in gebruik genomen. Hierdoor zal de site korte tijd slechts read-only beschikbaar zijn.Artemis 7 - geheugen

Artemis 7 - geheugen 2

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)Apollo 6 (01-06-2010)
Processors 2x Xeon X5570 2,93GHz 2x Xeon X5660 2,80GHz
Geheugen 72GB DDR3-800 48GB DDR3-1066
Raid-controller Dell Perc 6/i Dell Perc H700
Opslag 2x Seagate Savvio 10K.3 300GB
6x Dell / Samsung MCCOE50G5MPQ 50GB
2x Seagate Savvio 10K.3 300GB
6x Dell / Samsung MCB4E50GAD3Q 50GB
 
 Artemis 7 (21-1-2013)
Processors 2x Xeon E5-2643 3,3GHz
Geheugen 256GB DDR3-1600
Raid-controller IBM ServeRaid M5110
Opslag 2x 250GB SATA
6x 256GB SSD

De oude hardware krijgt, zoals gebruikelijk, werk als test- en developmentserver.

Update 21-1 9:42: Het vervangen van de oude server is gelukt. In totaal was er een downtime van iets minder dan 3 minuten voor nodig.

Reacties (183)

Reactiefilter:-11830181+1155+241+34
SSD kan je makkelijk de non enterprise versies nemen en paar op voorraad houden.
Dat is cheaper dan een dure SLC ssd van welk merk dan ook.
Draai hier in een SQL bak gewoon 8X 256GB M4 in raid 10 met wat spares op de plank.
Voor de prijs van 2x M4 had ik niet eens een SLC ssd destijds.
De afschrijving van SSD valt reuze me MLC vs SLC.

Leuke bak voor SQL only
Server 2012 met SQL 2012?

[Reactie gewijzigd door 151407 op 18 januari 2013 15:29]

In de post over Artemis 6 hebben ze het over de binary logs van MySQL.

MySQL dus, neem ik aan. :)
tja zou niet mijn keuze zijn maar drukt de kosten wel op licensie gebied.
overheen gelezen dan:)
Indrukwekkende server. Maar wat verbruikt zo een server nu?
Het precieze verbruik per server weet ik niet, maar het rack waar hij instaat trekt 1700W momenteel, en alle servers samen doen 5840W.
wat voor noodstroom hangt daar aan? eatons of APC? of is dat trade secret?:)
Qua noodstroom vertrouwen wij op onze hoster / datacentrumleverancier. Er staat wel wat leuk speelgoed in EUNetworks maar ik weet niet wat precies.

We hebben ook twee aparte feeds, en bijna alle servers en switches hebben redundantie voedingaansluitingen zodat we live blijven als er 1 feed uitvalt.

In ons eigen rack doen hebben we geen interesante noodstroomvoorzieningen, alleen een switched (& metered) PDU om de stroom te verdelen.
Kanonne, das 'n hoop. wat kost dat in de maand betreft de §§§? :o
5840W is in een maand van 31 dagen 4345 kWh
plus minus 0,22 eurocent per kWh

4345 * 0,22 = 995 euro per maand. Maar dat is uiteraard bij full load, kan begrijpen dat ze 's nachts misschien maar de helft of een kwart verstoken.
Als t.net's stroomgrafieken er ongeveer uitzien als de mijne is dat gewoon redelijk constant. (Gemiddeld per 5 minuten-- als je dichterbij gaat kijken zul je wellicht meer fluctuaties zien.)

[Reactie gewijzigd door CyBeR op 18 januari 2013 19:37]

Je vergeet hierbij enkele essentiŽle aspecten:

Kennelijk heeft Tweakers sponsors voor de koeling en stroom (zie Kees z'n verhaal]
[...] stroom/koeling/mensen kosten. Bovendien hebben wij voor de eerste twee een sponsor
Uit Kees z'n antwoord kan ik nog niet herleiden wat die vermogens precies inhouden. Als ik zo herleid zijn dat momentopnames, zonder er bij te vertellen wat de belasting precies is. Berekeningen er op los laten is dan ook gevaarlijk.

Je moet niet rekenen met consumentenprijzen van elektrische energie. Die 22 cent per kWh is een gebruikelijke waarde hier op Tweakers, omdat er dan wordt uitgegaan van een gemiddeld huishouden (met 3600 kWh op jaarbasis). Leuk voor de thuisservers dus. Een groot deel van die 22 cent bestaat uit belasting. Dat werkt met schalen (Rijksoverheid) waardoor de prijs per kWh fors minder wordt als je veel meer energie afneemt. Datacenters kopen energie op veel grotere schaal in, waardoor de prijs van ťťn kWh eerder naar de 10-12 cent gaat.
Gebruikers/afnemers van datacenterruimte hebben hier niet mee te maken, omdat dat het pakkie-an is van het datacenter. Bij een datacenter huur je een rack en betaal je kosten van energie aan het datacenter, niet aan de energieleverancier van het datacenter. De prijs van een kWh (of ampŤres) bij een datacenter hangt dan ook af hoeveel je huurt enzo. Ik heb zo geen inzage in precieze getallen, maar er zullen vast tweakers zijn die dat wel weten.


Er gaat nog veel energie verloren in overhead. Daarvoor betaal je dus ook aan het datacenter.
Een gebruikelijke indicator van de energie-efficiŽnte van een datacenter is de PUE-waarde (Power Usage Efficiency). Deze waarde houdt de gebruikte energie door de componenten gedeeld door de gebruikte energie inclusief de overhead energie. Onder het onderdeel overhead valt ook de energieconsumptie van koeling van het datacenter. Deze indicator kan dus variŽren door de gebruikte energie van de onderdelen te veranderen of de overhead. Energiezuinigere onderdelen zullen zorgen voor een verlaging, maar ook efficiŽntere koeling kan grote gevolgen hebben.

Marktleiders op het gebied van het inrichten van datacenters, waaronder Google, Facebook en Microsoft, hebben op het moment PUE-waardes variŽrend van 1,06 tot 1,2 (gigacom.com, 2012). Zij hebben al vele innovatieve ontwikkelingen toegepast om deze waarde nog verder te verlagen, zoals het gebruik van zeewater en passieve radiatoren als koeling ('free cooling' etc).

[Reactie gewijzigd door Bolletje op 18 januari 2013 19:48]

's nachts verbruik je juist weer wat meer omdat je dan je backups draait en andere belangrijke dingen doet die je overdag niet wilt vanwege de impact op je systeem. Ik denk juist dat de rustigste tijd voor een server zo'n rond de 23:00 - 01:00 en 05:00 - 07:00 is. Dan zijn de minste gebruikers online en hoeft de server geen backupwerk te doen! :)

EDIT: Ik reageer op het verkeerde bericht. Deze reactie was bedoeld op het bericht van Tricq hierboven. :)

[Reactie gewijzigd door KoploperMau op 18 januari 2013 20:58]

Bedoel je niet 22 eurocent per kWh, 0.22 lijkt me wat weinig....
Artemis 6 neemt gemiddeld 203W op. Het maximum lag afgelopen week op 313W (gedurende een zware data-import) en het minimum op 185W (diep in de nacht).

Maar e.e.a. kan aardig fluctueren, want zelfs in het "last minute" lijstje noemt ie een gemiddelde van 210W, piek van 280W en minimum van 193W.

Van Artemis 7 hebben we uiteraard nog geen verbruikscijfers onder normale belasting :P
Leuk speelgoed hoor...

kwijl kwijl

S6 met de opstart

;)
Je kan 'm gewoon op de IBM-site configureren en dan de prijs in dollars zien. Uiteraard krijg je nog wel wat korting als je meerdere servers per jaar koopt, maar dan heb je een indicatie :)
Heb het zelf even geprobeerd op Build Your Own System x3550 M4. Het lukte me niet helemaal om aan dezelfde configuratie te komen, met name omdat ik de storage configuratie met 2 x hdd en 6 x ssd niet ingevoerd kreeg (andere behuizing/verkeerde controller gekozen?).

Maar goed, ondanks dat kon ik wel een schatting van de prijs maken en die komt dan ergens rond de 15000 dollar. Hopelijk kunnen jullie weer een paar jaartjes vooruit voor dat geld!
Ik snap te weinig van dit soort dingen, maar 256GB DDR3-1600 klinkt goed!

Zou leuk zijn als tweakers een keer aandacht besteed aan caching, hoe je dingen doet met een server enz.
Ivm jullie Phoenix project.

Dat was toch om ervoor te zorgen dat als er plots een meteoor te pletter stort op locatie a (waar jullie servers stallen), dat de servers op locatie b het overnemen. Zou dat er dan niet voor moeten zorgen dat er geen read only tijd is?

Dit is geen flame, maar gewoon iets dat ik mij afvraag.


Mooi speelgoed overigens!
Jullie zouden is een review moeten doen val jullie server racks, zou zeker geapprecieert worden door veel tweakers ;)
Geinig dat jullie qua cpu en geheugen tot eenzelfde configuratie zijn gekomen als wat FOK! binnenkort in gebruik neemt. Wij zien alleen geen noodzaak voor SSD's omdat we met innodb_buffer_pool_restore_at_startup de data sequentieel in kunnen lezen, en die drie keer dat het voor zal komen de vijf minuten extra downtime voor lief nemen. Ik vraag me af hoe jullie tegenover De Persgroep een extra investering van duizenden euro's kunnen verantwoorden om toekomstige downtime met vijf minuten te verkorten.
"duizenden euro's" is wel wat overtrokken. Zelfs als je teruggaat naar 2x600GB SAS is het prijsverschil minder dan 2500 euro ($3136). Strikt beschouwd is dat inderdaad "duizenden", maar jouw opmerking suggereert dat het aanzienlijk meer is dan dat :)

Afgezien daarvan spreken we gewoon budgetten af voor serverhardware en verantwoorden we de details van aankopen alleen intern en naar het directe management. De Persgroep ziet dus alleen de budgetten langskomen en op een gegeven moment een factuur verschijnen ;)
Zolang we binnen de gestelde budgetten blijven - en die budgetten reeel lijken - gaat men echt niet een uitgebreide verantwoording van ieder detail vragen en/of ons dwingen om wat op de aanschafkosten te besparen als we niet helemaal met uitgebreid cijferwerk kunnen verantwoorden waarom we kiezen voor SSD's tov SAS-disks.
Overigens was het bij de laatste servers zonder SSD's eerder een half uur tot een uur problematisch. Maar toen bestond (of kenden we) de innodb_buffer_pool_restore_at_startup-parameter nog niet, dus we hebben eigenlijk nooit uitgebreid getest hoe het daarmee zou gaan.

[Reactie gewijzigd door ACM op 18 januari 2013 17:07]

Dus Artemis 6 staat binnenkort in de Vraag en Aanbod? :+
"De oude hardware krijgt, zoals gebruikelijk, werk als test- en developmentserver."
Wat als de server plotseling uitvalt, dan ben je toch een deel van je data van je database kwijt? Ik bedoel, alles wat wordt geschreven naar je database (wat in je geheugen staat) moet ook geschreven worden richting de schijven toe. Om dit synchroom te houden ben je je voordeel kwijt van het in het geheugen draaien, of zie ik iets over het hoofd?
MySQL heeft een redo-log die naar de schijven wordt weggeschreven (wat dankzij een battery-backed raid controller heel snel gaat). Pas wanneer die is weggeschreven, is een db-transactie gecommit. Valt de stroom uit, kunnen mbv de redo-log alle wijzigingen opnieuw gemaakt worden.
In de meeste databases wordt veel minder vaak geschreven dan gelezen/gezocht, en de ssd's hoeven nu dus alleen de updates naar de database bij te kunnen houden.

Als ik bijvoorbeeld een reactie post op deze pagina, hoeft maar ťťn rij toegevoegd te worden aan een tabel met reacties. Maar om vervolgens de HTML-code te (re)genereren, moeten alle relevante comments opgezocht worden (met behulp van een database-index), vervolgens moet de scores bij reacties worden opgezocht, enzovoorts. Weinig schrijven, maar veel lezen.

Voor een gemiddeld bezoekje aan de pricewatch zijn waarschijnlijk tientallen of misschien wel honderden database queries nodig, maar geen daarvan hoeft wijzigingen door te voeren in de database. Al die queries kunnen dus lekker efficiŽnt in het geheugen uitgevoerd worden.
In het geheugen staat puur de cache, dit is in principe read only, schrijf operaties gaan direct naar de desbetreffende dtaabase (MySQL, NoSQL). Bij een uitval ben je dus puur je cache kwijt en geen data. Deze wordt simpelweg weer opgevraagd uit de database, in het geheugen geschreven en vervolgens daar weer uitgelezen.
Onzin, ook schrijfacties gaan naar het geheugen (+ de redo log). Als je hetzelfde record 100x aanpast dan hoeft dat uiteindelijk maar 1x weggeschreven te worden.
Dat varieert per database. MySQL bundelt e.e.a. - zoals je zegt - wel in de uiteindelijke handeling die het record wegschrijft. Maar ook de redo log staat natuurlijk op disk, dus uiteindelijk wordt de schrijfactie wel naar disk geschreven.

De manier van MySQL zorgt er wel voor dat je niet helemaal hoeft te wachten tot de disk is bijgewerkt, de caches in RAM-geheugen worden ook al direct bijgewerkt.
Volgens mij is dat niet zo. Het schrijven gebeurd ook direct in het geheugen. En ook bij het openene van een artikel wordt een INSERT uitgevoerd, views moeten ook bijgehouden worden. Zoals jij het beschrijft moet je dus als nog op de write naar de schijven toe wachten.
Daarom doen wij de viewlogging ook asynchroon via een messagequeue zodat de gebruiker er geen last van heeft en wij die kleine inserts kunnen bundelen tot een grote multi-insert :)
De vraag is natuurlijk, zullen wij - de gebruikers - het merken dat de server upgegrade is?
zullen we die snelheid merken?
nee daar merk je NIETS van het is bij mij namelijk allemaal al instant en sneller dan instant bestaat niet.

het is dan ook niet voor de snelheid maar om andere redenen dat er een nieuwe komt denk ik.
Er zijn een paar queries die met de nieuwe MySQL-versie wat sneller kunnen zijn, de verschillen in hardware zal je waarschijnlijk minder van merken :)
Er zijn een paar queries die met de nieuwe MySQL-versie wat sneller kunnen zijn, de verschillen in hardware zal je waarschijnlijk minder van merken :)
Tja, waarom laadt je dan de database compleet in het geheugen? :? Als het performance-wise eigenlijk toch een minimaal verschil is? Dan is deze server imo wel erg overrated en duur voor zijn doel. ;)
Het is de bedoeling dat deze server weer 3 jaar meegaat. We kunnen niet in de toekomst kijken, maar gaan er van uit dat we nog steeds blijven groeien in datasets en bezoekersaantallen. Daarnaast weten we ook nog niet zo goed welke veranderingen we gaan doormaken en of er bepaalde complexe site-onderdelen bijkomen of meer aandacht van bezoekers gaan krijgen.
Daar moeten we dus uiteraard wel op voorbereid zijn, we willen niet ineens ad-hoc nog een nieuwe databaseserver moeten aanschaffen... dan ben je zo weer een paar weken verder voor ie ook echt in gebruik genomen kan worden.
Daarnaast zijn er altijd onverwachte pieken in de belasting, waarbij elk beetje extra capaciteit bijzonder welkom is.

Het is uiteraard de verwachting dat alle queries een beetje sneller worden. Maar dat zullen we vooral merken bij queries die jij als bezoeker niet in je pageview triggert. Bijvoorbeeld de queries die nodig zijn om jaren aan prijshistorie in de grafiekjes te verwerken die onder een prijslijst van een product staan.

Voor de meeste queries die bezoekers "meemaken" geldt al dat ze erg snel zijn of dat ze gecached zijn en via memcached of onze "java backend" lopen. En alleen de eersten zal je dus iets van merken als ze sneller zijn, maar dan heb je het over milli- of zelfs microsecondes per query :P
Er zijn nog wel wat queries waar MySQL 5.1 geen efficient executie-plan voor kan verzinnen en 5.5 wel, die zijn wat zeldzamer maar daar kunnen relatief grote verschillen in zitten. Vergelijk het maar met het toevoegen van een index op een tabel, daar zal je meer van merken dan domweg snellere hardware inzetten.

We doen uiteindelijk gemiddeld maar 9,9 queries per pageview en dat kost per pageview gemiddeld zo'n 0.00786196 seconde en daar tellen we mongodb dan ook nog eens bij. Je kan je met dat soort cijfers dan vast wel voorstellen dat je als bezoeker in ieder geval weinig van de gemiddelde performance-winst gaat merken ;)

Overigens zit de standaarddeviatie van die query-count op 16.1951, dus er zijn uiteraard pagina's waar je er misschien wel wat van zou kunnen merken.

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 OneAsus

© 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