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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 183 reacties

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+228+34
Moderatie-faq Wijzig weergave
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:)
Hebben jullie ook een backup server? Hoeveel voedingen heeft deze server?
Ja, de configuratie kan je in bovenstaaande tabel zien in de tweede kolom; Artemis is de 'master database' en Apollo de 'slave'. Bijna al onze servers hebben redundante voedingen (meestal kunnen er 2 in), dit soort belangrijke uiteraard ook. 1- en 2U servers kunnen doorgaans maximaal 2 voedingen kwijt en deze heeft er daarom ook "maar" 2 :)
Trekt de huidige Apollo 6 het dan wel als Artemis 7 uit zou mogen vallen ?
Jahoor, die heeft vergelijkbare specificaties als de Artemis 6 en die trok het tot vandaag ook prima :)

Later dit jaar wordt Apollo 6 zelf ook vervangen door een Apollo 7, dus daar verwacht ik verder geen problemen mee.
3 minuten, dat is echt een downtime van niks. Mag ik vragen waardoor het zo snel ging? Een server opstarten duurt al vaak (soms meer dan) 3 minuten. Ik neem dus aan dat de server al aanstond en deze vervolgens is geswitch? Ik ben toch erg nieuwsgierig naar de setup, het lijkt erg goed in elkaar gezet. :)
Door domweg de nieuwe Artemis als replicatie-slave op de oude Artemis aan te sluiten... En daarna een change-master te doen en de nieuwe Artemis het ip van de oude te geven :)

Het enige waar je dan echt last van hebt is dat je je configuratie met hostnames/ips enzo in de gaten moet houden. En dat was dan ook een van de reden dat er uberhaupt downtime was.
de spreekwoordelijke +1 hiervoor, hoe krijg je een server van dit formaat binnen 3 minuten aan de gang terwijl een doorsnee site hier uren voor nodig heeft? is er gewoon zo'n gebrek aan kennis en vaardigheden bij die andere sites of speelt er wat anders?
Gokje: er is, eens geboot, niet zo veel I/O meer vereist van het OS, en dus de systeemschijf.

Dit kan een domme vraag zijn, maar hoe zorgen jullie ervoor dat de DB altijd 1:1 in sync is met de raid-array van SSD's?
Je bedoelt denk ik dat het geheugen veel sneller is dan de ssd's en de ssd's dus druk zouden zijn om continu de wijzigingen in de database in het geheugen bij te houden?

Ik ben geen expert, maar dat hoeft toch niet 1:1 in sync te lopen? Die raid-controller is vast uitgerust met een BBU waardoor eventuele asynchronisaties bij een power failure weggeschreven kunnen worden naar de ssd's. Hoeveel wijzigingen kunnen er nou helemaal zijn in een paar seconden?
goede controller met genoeg ram erop geprikt:)
Het cache management van de database wordt automatisch door het DBMS gedaan (in dit geval: MySQL), gebaseerd op de instellingen die je maakt in je DBMS-configuratie.
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?
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.
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 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.
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 :)
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.
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.
Zo zo!! Klinkt goed allemaal!! Maar is 256GB Geheugen niet een beetje over kill?
Nee, want zoals in het stuk staat, kan nu de gehele database direct in de RAM
Wat is het voordeel als je de database in het RAM zet? Ik snap hem namelijk niet echt... :+
Hier kan je een voorbeeld vinden:

http://blog.laptopmag.com...ra-memory-into-a-ram-disk

Een conventionele HDD haalt zo'n 100 MB/s write, een SSD komt tot 250 MB/s, en een RAM schijf gaat makkelijk door tot 7000 MB/s
Volgens mij is het grootste voordeel dat het simpelweg bloedsnel is! :9
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.
De leessnelheid van werkgeheugen is vaak sneller dan de leessnelheid van een harde schijf. Als jij dus content opvraagt (query) zal hij het resultaat uit het werkgeheugen halen. Hierdoor kan opgevraagde content sneller verstuurd en dus door jouw browser geladen worden.

[Reactie gewijzigd door Goldin op 18 januari 2013 15:38]

Laat dat vaak maar weg. Geheugen is bloedsnel als je het vergelijkt met traditionele hardeschijven en zelfs SSDs maken geen schijn van kans tegen RAM geheugen.
En RAM geheugen is dan weer retesloom in vergelijking met cache.
En waar denk je dat de gegevens die in cache staan in zit??
In geheugen, het geheugen van de server en/of geheugen van de HD.....
Niet als je je complete database in het geheugen wil laden en ook nog voorbereid wil zijn op de toekomst.
Maar dan vraag ik me af wanneer gaat het geheugen te klein worden voor de volledige database (als die nu al 200G groot is) en wat gebeurd er dan? Swap? Of kan men bepaalde delen van de db aanmerken als zijnde prioritair?
Ik spreek nu uit ervaring met MSSQL(zover ik weet draait Tweakers op iets anders). Maar in MSSQL zal het geheugen zich vullen zodra de database wordt gebruikt. Het duurt een tijdje voordat dus een deel/gehele database in het geheugen is ingeladen.

De eerste keer duurt het dus wat langer om gegevens uit de database te halen dan de 2e keer, de 2e keer leest hij het namelijk uit het geheugen.
Momenteel staat er zo'n 33% in het geheugen bij Tweakers, of misschien iets minder. Voor velen is dit "best practice".

Een hele database in het geheugen inladen is het ideale scenario, maar wanneer de database groter wordt zal de rest wat niet in het geheugen staat uit de hdd's worden gelezen. In dit geval de 256GB SSD's. Flink snel dus :P

PS: Correct me if I'm wrong, maar dit zal niet veel anders zijn op de DB van Tweakers.
Eerst zeg je dat het anders zal zijn, en daarna stel je dat het niet veel anders zal zijn bij de DB van Tweakers ;) Welke is het nou?

In elk geval draaien ze geen MSSQL. Er is ook niet echt een reden toe, want het is niet goedkoper dan MySQL, en gaat ook niet sneller dan MySQL.
Momenteel is het geheugen ook al te klein om de hele database in te laden, dus dat is geen enkel probleem.

De database staat normaliter op de hardeschijven en word vanaf de harde schijf gelezen door de mysql server. Omdat de harde schijven langzaam zijn zal hij, wat hij aanspreekt, in het geheugen laden om zodoende 'gecached' te houden. Op het moment dat hij iets moet hebben wat niet in die cache staat dan zal hij dat van de harde schijf lezen en vervolgens in de cache zetten.

Dat is de normale situatie voor de meeste databases, maar omdat we nu meer geheugen in de databaseserver konden stoppen dan dat de database groot is, zou het nu mogelijk zijn om de volledige database in het geheugen te laden, waarbij hij eigenlijk alleen nog maar naar de schijven hoeft om data weg te schrijven.
...maar omdat we nu meer geheugen in de databaseserver konden stoppen dan dat de database groot is...
Kun je aangeven hoeveel MB/GB aan data er ieder jaar bij komt? Hebben jullie daar statistieken van?
Dit is ook geen enkel probleem. De inhoud van oude nieuwsberichten en hele oude forumtopics zal vrijwel nooit opgevraagd worden, dus dat mag best wat langer duren. Het belangrijkste is dat je indexen wel in het geheugen blijven staan. Na een tijdje draaien regelt een goede database engine dat zelf wel.

Wel kan het zinvol zijn om zelf toe te wijzen op welk device een bepaald databaseonderdeel (tabel, index, ...) opgeslagen moet worden. BLOBs die je weinig gebruikt kun je op een wat trager device zetten (HDD) en de indexen of belangrijke tabellen op een SSD.

Een andere oplossing is natuurlijk een batterij brute SSDs en flink wat geheugen, zodat alles snel is. Blijkbaar heeft Tweakers daarvoor gekozen :)
Dus heel tweakers.net staat op minder dan 2 terabyte? Op mijn pc staat al meer dan 2 terabyte! Het is in ieder geval wel mooi dat er nu SSD's in gaan aangezien deze een stukje sneller zijn dan HDD's.
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.
Overigens lijkt mij dit dus ongeveer de nieuwe server te zijn: http://www.redbooks.ibm.com/abstracts/tips0851.html

@kees, welke SSD's zitten erin? Ik wil wel eens weten of tweakers.net uitkomsten van hun eigen reviews gebruikt.

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

[vrijdag]
Lol, kan je een backupje op je pc draaien 8)7
[/vrijdag]
Tweakers is ook geen pornosite, hè?
Tweakers.net is toch juist porno voor een echte nerd? :P 8)7
@oeroeg
Voor een aantal tweakers zijn die specs anders wel degelijk porno...
Mwah .. vroeger, toen t.net nog zelf hun servers bouwde, toen was het porno. Nu is het gewoon een off the shelf kast met indrukwekkende specs, that's all. Eerlijk gezegd niet heel veel spannender dan een gemiddelde ESXi blade bij ons.

Hoort allemaal bij de professionalisering, ik zou t.net ook minder serieus nemen als ze nu nog zelf servers in elkaar gingen schroeven. Zo is de markt nu, hardware wordt steeds meer commodity. Tegenwoordig kun je met een nieuwe Acer of ASUS kant-en-klaar PC ook alle games op High draaien met Full HD resolutie. De tijd dat je nog uren in je zolderkamertje onderdelen uit zat te zoeken d.m.v. Pricewatch v1 en fora ligt lang achter ons.
Mwa, overdrijven is ook een kunst hoor, ik ken persoonlijk niemand die op een kant en klaar PC'tje van een groot merk gamet. Als ik ook bv bij Acer kijk, dan vind ik deze:
http://us.acer.com/ac/en/US/content/series/predatorg
Extreme gaming power!!! Met een GT630... Riiiiiight, ik denk dat je blij mag zijn als je nieuwe games op de laagste settings nog enigszins soepel aan het draaien krijgt daarop.
Asus dan?
http://www.asus.nl/Deskto...io_CG8250/#specifications
Beter, maar een GTX460 als beste keus is nog altijd bedroevend en daar ga je echt geen nieuwe games op high op spelen.
Neuh, in de PC game wereld stelt nog altijd bijna iedereen zijn eigen PC samen of laat een computer op maat maken door een winkel (wat op hetzelfde neerkomt alleen schroeft iemand anders voor je).
Wat heeft een (game-) PC met een productieserver te maken? Echt helemaal niks.
Lees dan eerst de reactie van Afman voordat je dit neer plempt!
Je kan vaak nog naar supermicro gaan als je wat meer tweakers gevoel wilt.
Ja ik krijg al een kick als ik naar de afbeeldingen kijk en dan lees wat het is, Oh my.
De database is inderdaad maar ongeveer 200G groot. De storage is wel iets groter hoor - Die neemt momenteel zo'n 7TB in totaal.

En nee, wij gebruiken de uitkomsten van onze eigen reviews niet voor serverhardware, puur omdat de meeste fabrikanten (dell, ibm, hp) je geen keuze geven anders dan '256GB SSD', eventueel nog een keuze tussen mlc/enterprice mlc/slc maar veel verder gaat het niet helaas.

[Reactie gewijzigd door Kees op 18 januari 2013 16:00]

En nee, wij gebruiken de uitkomsten van onze eigen reviews niet voor serverhardware, puur omdat de meeste fabrikanten (dell, ibm, hp) je geen keuze geven anders dan '256GB SSD', eventueel nog een keuze tussen mlc/enterprice mlc/slc maar veel verder gaat het niet helaas.
Het is in elk geval bij HP vrij eenvoudig te achterhalen welke OEM ze gebruiken. Dat is dus Intel.
En Servers SSD's zijn DUUR bij Dell... :|
Kees, hoe lang verwacht je dat de SSDs meegaan? Hoe vaak vervang je ze?
Elke 3 jaar. De huidige SSD's zijn ongeveer op 2/3'de van hun gespecificeerde aantal writes.
Wat is het verschil als ik vragen mag? :)
ik gok dat de database alle text-based zooi is; reacties, forum topics, pricewatch e.d.
storage zullen alle plaatjes, filmpjes en backups zijn
Je moet denken aan images, video's etc. Alles wat je niet in de database opslaat staat op de storage.

200G is een mooie database voor zo'n uitgebreide site. Knap werk.

edit: Te laat :Y)

[Reactie gewijzigd door Remz op 18 januari 2013 15:30]

Je kan een image toch als binary opslaan? (zal er wel niet sneller op worden..)
Het vervelende is dat je DB server dan meer werk moet gaan doen. Nu worden alle bestanden van een aparte file server geserveerd. Dat is een stuk beter te schalen.
Afaik draait die fileserver ook hele simpele webserver software, geen Apache, zodat alles in noodtempo geserveerd kan worden :)

Dat was enkele jaren geleden wat ik las iig, weet niet of ze dat anno 2013 nog doen.

Edit:

Hmm niet meer dus :)
HTTP/1.1 200 OK
Server: Apache
X-Tweakers-Server: pontus

[Reactie gewijzigd door Engineer op 18 januari 2013 17:24]

Is Apache zo'n trage webserver dan?
Niet heel traag, maar Apache is een beetje een doorsnee webserver. Je kan er zo'n beetje alles mee, en dat levert wat baggage. Je hebt webservers die gespecialiseerder zijn in bepaalde taken, die bijvoorbeeld heel snel statische files kunnen laten zien. Of gewoon heel simpel en licht zijn.

http://en.wikipedia.org/w...on_of_web_server_software
Apache is vooral veelzijdig. En vooral goed in bepaalde taken, PHP runnen bijvoorbeeld. Echter, apache is ook groot, en daarmee heeft het veel overhead. Voor de ingewikkeldere taken (draaien van PHP bijvoorbeeld) is dat ideaal. Echter, voor het simpelweg terugsturen van statische files, kun je net zo goed een lichter gewicht server gebruiken (zoals NginX, of lighttpd).
Ik kan de link niet meer vinden, maar zag onlangs een benchmark langskomen waarin nginx amper sneller was dan Apache2. Er was één voorwaarde: in Apache2 moest het parsen van .htaccess files uitgeschakeld zijn.
De database bevat voornamelijk tekst (al het nieuws, review, .plans, meuk, product informatie, etc). De storage bevat alle bestanden die we serveren, zoals plaatjes en video's. Dat maakt het verschil :)
Artemis 4 is binnen een jaar al vervangen door Artemis 5. Was er iets mis mee?
Nee. Het was domweg Apollo 4 met wat betere processoren (die we toevallig nog hadden liggen) :P

Destijds hadden we het forum en de rest van Tweakers nog op gescheiden databases, Apollo voor het forum en Artemis voor de rest. In die tijd was het forum zodanig zwaar voor het I/O-systeem van Apollo dat we min of meer gedwongen waren die te vervangen. Artemis 3 kon het toen op zich nog wel redelijk aan, maar de hardware van Apollo 4 was wel een stuk sneller, dus het wat zonde om dat niet om te ruilen.

Uiteindelijk hebben we een klein jaar na Apollo 5 alsnog een vergelijkbare configuratie voor Artemis 5 genomen om weer verse (en snellere) hardware met fatsoenlijke support-contracten te hebben :)
Met die Artemis 5 hebben we toen de diverse databases op een machine (Artemis) gefuseerd en werd Apollo 5 de replicatie-slave. Sindsdien is Artemis dus onze master-database en Apollo slave.

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

Leuke bak. Wij hebben afgelopen zondag iets soortgelijks geplaatst voor FOK!.

De investering in SSD's; wij hebben bewust ervoor gekozen voor SAS 15K schijven te gaan, simpelweg omdat dat een paar ruggen scheelt. Hoe groot is de snelheidswinst van de SSD's tov onze SAS 15K schijven? En zijn SSD's al wel betrouwbaar genoeg voor dergelijke kritische taken?
SSD's zijn voor database-toepassingen meestal (veel) sneller, omdat er aardig wat semi-random gelezen moet worden. Pas als je gaat clusteren (de oude database-term, dus de layout op disk aanpassen aan de hand van een index) zal SAS met zijn lineaire leeskracht in het voordeel komen.
Door de berg aan RAM-geheugen zal je dit uiteraard vooral merken zodra iets niet in InnoDB's bufferpool zit en de kans daarop is na een paar dagen draaien vrij klein.

De betrouwbaarheid is natuurlijk altijd afwachten, maar de huidige databaseserver heeft ook al SSD's en die heeft na 3 jaar nog altijd geen problemen gegeven. Ondanks dat de nieuwe SSD's MLC ipv SLC zijn, zijn er wel wat belangrijke verschillen: ze hebben veel meer capaciteit en dus ook meer ruimte om de schrijfacties te verspreiden, ze zijn nieuwer en dus (hopelijk) voorzien van betere slijtageverspreidingsalogritmes, ze staan in RAID10 ipv in RAID5 waardoor er minder "write amplification" is

Op dit item kan niet meer gereageerd worden.



Microsoft Windows 10 Home NL Apple iPhone 6s Star Wars: Battlefront (2015) Samsung Galaxy S6 Edge Apple Watch Project CARS Nest Learning Thermostat Microsoft Windows 10 Pro EN

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