12GB + SATA of 8GB + SAS?

Pagina: 1
Acties:

  • GrimaceODespair
  • Registratie: December 2002
  • Laatst online: 13-02 10:55

GrimaceODespair

eens een tettenman, altijd ...

Topicstarter
Ik heb voor mij de volgende offertes liggen met een vergelijkbare prijs:


Windows 2008 / IIS7
Server AServer B
CPU2x XEON L5640
8C/16T 2.26 5.86GT/s
1x XEON X3440
4C/8T 2.53 2.5GT/s
RAM12GB DDR38GB DDR3
HDD5x 600GB SATA 10k
(Raid10 + HS)
5x 600GB SAS 10k4
(Raid10 + HS)


Hier zullen voornamelijk reguliere ASP.NET-applicaties op gaan draaien: niet bijzonder druk bezochte websites met een database erachter (andere server, zelfde configuratie).

Nu twijfel ik dus tussen deze 2 configuraties.

In onze huidige setup (uit het hoofd: raid 1 + raid 5, 4GB DDR2) merken we heel goed dat de harde schijf een bottleneck is bij het opstarten van ASP.NET applicaties (en wellicht bij alle on-the-fly compilatie). Maar daarvoor hebben we een RAMDisk (van QSoft) draaien die al geruime tijd prima doet waar-ie voor bedoeld is. Door tijdelijke bestanden hierop te huisvesten, kunnen opstarttijden meer dan gehalveerd worden. Dat doen we dus ook voor de belangrijkste sites.

Met dat verhaal in het achterhoofd, zit ik dus in een zware dubio: investeren we in snellere opslagruimte, waarvan ik de impact moeilijk op voorhand kan inschatten (omdat performance natuurlijk niet _alleen_ om de IO van ASP.NET draait), of investeren we in meer RAM om zoveel mogelijk in-memory te kunnen laten gebeuren? In dat laatste geval trek ik de RAMDisk op naar 4GB en zullen alle sites er gebruik van maken.

Is er iemand die hier hands-on ervaring mee heeft of een ander zinnig woord hierover te zeggen heeft?

Tenslotte: de CPU utilization ligt momenteel rond de 10%, dus ik verwacht geen merkbaar verschil tussen de processors. Maar voel je vrij om me tegen te spreken :)

Wij onderbreken deze thread voor reclame:
http://kalders.be


Verwijderd

Er zijn in dit geval een paar vragen die je jezelf dient te stellen. Vraag 1 is bijvoorbeeld : Voldoet server b nog als de drukte op de site's zich verdubbelt? Als het antwoord ja is, dan zou ik voor server b gaan.
Vraag 2 zou zijn : Wat kost server a en wat kost server b? Als het prijsverschil tussen de 2 zeer klein is, dan is het altijd te overwegen om toch server a te nemen.
Daarnaast is er nog de vraag wat je wilt en wat je verwacht van de servers, degene die het best voldoet, zou dan je keuze bepalen, echter dien je wel rekening te houden met vraag 1 en 2.
Je maakt dus als het ware een pro / con lijstje waarbij de meeste pluspunten het wint.

  • GrimaceODespair
  • Registratie: December 2002
  • Laatst online: 13-02 10:55

GrimaceODespair

eens een tettenman, altijd ...

Topicstarter
Verwijderd schreef op maandag 16 augustus 2010 @ 11:47:
Er zijn in dit geval een paar vragen die je jezelf dient te stellen. Vraag 1 is bijvoorbeeld : Voldoet server b nog als de drukte op de site's zich verdubbelt? Als het antwoord ja is, dan zou ik voor server b gaan.
Ik verwacht dat beide servers nog enige tijd zullen voldoen. Mijn grootste vraagteken is eigenlijk wat zwaarder weegt: de snellere SAS of de grotere RAMDisk. Ik kan daar wel wat theorieën rond opbouwen, maar ik was nieuwsgierig of er hier uitgesproken meningen over bestaan.
Vraag 2 zou zijn : Wat kost server a en wat kost server b? Als het prijsverschil tussen de 2 zeer klein is, dan is het altijd te overwegen om toch server a te nemen.
Prijsverschil is verwaarloosbaar.
Daarnaast is er nog de vraag wat je wilt en wat je verwacht van de servers, degene die het best voldoet, zou dan je keuze bepalen, echter dien je wel rekening te houden met vraag 1 en 2.
Je maakt dus als het ware een pro / con lijstje waarbij de meeste pluspunten het wint.
Volgens mij heb je precies de reden te pakken waarom ik hier kom leuren ;)

Wij onderbreken deze thread voor reclame:
http://kalders.be


  • rapture
  • Registratie: Februari 2004
  • Laatst online: 22:04

rapture

Zelfs daar netwerken?

Met een ander draadje naar dezelfde 10k rpm schijven maak je het niet sneller. Hooguit heb je het verschil tussen oudere 10k rpm WD Raptor en nieuwere 10k rpm schijven. Stel dat je 5 ms nodig hebt om de koppen naar het volgende bestand te verplaatsen en er zijn 1000 ms in een seconde. Maximaal 200 kleine bestandjes per seconde (aannemend dat je geen tijd nodig hebt om te lezen, eigenlijk moet de schijf gemiddeld een halve toer maken). Als deze bestandjes 4 KB groot zijn, dan kan de snelste 10k rpm schijf tot maximaal 800 KB/s gereduceerd worden. Het is verdomd moeilijk om een harde schijf dubbel zo snel te maken.

Geheugen is richting factor 10000 sneller wegens accesstimes van bv 10 milliseconden naar bv +/- 100 nanoseconden grootteorde gaat. Geheugen heeft gewoon geen concurrentie in performance.

Een andere mogelijkheid is een kleine SSD toevoegen voor de tijdelijke bestanden. Deze is factor 100 (in IOPS) sneller dan harde schijven in kleine bestanden, maar je hebt het nadeel van vluchtig geheugen niet meer. Factor 100 is genoeg om eender welke harde schijf 'uit het water te blazen', maar geheugen blijft een andere categorie. Je kan over een voldoende grote ramdisk beschikken, waarom zou je geld in een SSD steken dat factor 100 tov het geheugen achterblijft?

Ik zou meer cores en geheugens boven een mooier SAS-draadje naar de harde schijven verkiezen. De tijd dat het draadje een verschil maakte, was de tijd van SCSI toen er weinig goede RAID-controllers en goede harde schijven voor PATA beschikbaar was. Nu heeft SATA goede RAID-controllers en 10k rpm WD Raptor. En harde schijven zijn niet meer het enige dat je performance bepaalt. Geheugen is zo goedkoop geworden, dat we veel dingen in het geheugen kunnen laten draaien en je kan nog een SSD tussen smijten die ook stapels harde schijven 'uit het water kunnen blazen'.

[ Voor 13% gewijzigd door rapture op 16-08-2010 12:10 ]


Verwijderd

Als ik je reactie zo lees, dan lijkt het mij het beste te zijn om server a te nemen, dan weet je zeker dat je voor de komende 10 jaar goed zit. Vraag 1 is iets wat je zelf het beste kan beantwoorden, maar als je alles in een RAMdisk wilt hebben vanwege de snelheid, dan lijkt het antwoord me toch wel gegeven. Mijn mening is hier niet echt geldig, ik host geen website's, noch maak ik gebruik van SAS schijven of een RAMdisk. Ik kan alleen antwoorden uit wat ik weet of denk.
Voor het laatste geldt : Ik denk (maar dat ben ik), gezien de gegevens die je verstrekt, dat je beter voor server a kan gaan. Je hebt een grotere RAMdisk, prijsverschil is verwaarloosbaar en je bent met server a gewoon weer voor jaren klaar.

"Volgens mij heb je precies de reden te pakken waarom ik hier kom leuren"

Owww Jolly, wat heb ik gewonnen met dit antwoord? Een magnetron of toch de koelkast? :P

  • GrimaceODespair
  • Registratie: December 2002
  • Laatst online: 13-02 10:55

GrimaceODespair

eens een tettenman, altijd ...

Topicstarter
rapture schreef op maandag 16 augustus 2010 @ 12:01:
Geheugen is richting factor 10000 sneller wegens accesstimes van bv 10 milliseconden naar bv +/- 100 nanoseconden grootteorde gaat. Geheugen heeft gewoon geen concurrentie in performance.
Exact. Alleen is het zo dat die RAMDisk maar gebruikt wordt voor een _deel_ van de activiteiten (namelijk: on-the-fly compilatie). Met andere woorden: ik kan me voorstellen dat "holistisch" bekeken, snellere HDD wél meerwaarde heeft. Bovendien, ik kan alsnog een RAMDisk van 4GB instellen wanneer ik voor die SAS ga. In dat geval heb ik nog altijd 4GB vrij voor andere zaken (wat al 1GB meer is dan huidige situatie)
rapture schreef op maandag 16 augustus 2010 @ 12:01:
Met een ander draadje naar dezelfde 10k rpm schijven maak je het niet sneller.
De vraag is dus eigenlijk of SAS überhaupt nog een wezenlijk voordeel heeft tov SATA?

Wij onderbreken deze thread voor reclame:
http://kalders.be


  • rapture
  • Registratie: Februari 2004
  • Laatst online: 22:04

rapture

Zelfs daar netwerken?

Ik vraag af hoe je de ramdisk met de harde schijven synchroniseert. Als er iets opgevraagd wordt dat niet in de Ramdisk staat, eventjes uit de harde schijven ophalen. Als er iets naar de ramdisk geschreven wordt, dan wordt het naar de harde schijven weggeschreven. De harde schijven moeten alleen de weinige schrijfacties en ontbrekende data ophalen. Hoeveel is dat weinige schrijfacties en ontbrekende data?

Schrijf je elk stukje data direct in de harde schijf of verzamel je de data en elke minuut wordt er 1 keer weggeschreven? 1 keer per minuut is weinig IOPS zodat 5400 rpm groene SATA-schijven ook kunnen voldoen. Aannemend dat je fora, blogs, fotodumpsites,... niet een Gigabitverbinding aan het volblazen zijn. De datastroom tussen ramdisk en harde schijven in kaart brengen.
GrimaceODespair schreef op maandag 16 augustus 2010 @ 12:16:
De vraag is dus eigenlijk of SAS überhaupt nog een wezenlijk voordeel heeft tov SATA?
Als ik naar Wikipedia: Serial attached SCSI kijk, zit het voordeel voornamelijk in hogere spanning zodat je 10m ipv 1m lange kabels en backplanes kan gebruiken.

[ Voor 27% gewijzigd door rapture op 16-08-2010 12:40 ]


  • GrimaceODespair
  • Registratie: December 2002
  • Laatst online: 13-02 10:55

GrimaceODespair

eens een tettenman, altijd ...

Topicstarter
rapture schreef op maandag 16 augustus 2010 @ 12:25:
Ik vraag af hoe je de ramdisk met de harde schijven synchroniseert. Als er iets opgevraagd wordt dat niet in de Ramdisk staat, eventjes uit de harde schijven ophalen. Als er iets naar de ramdisk geschreven wordt, dan wordt het naar de harde schijven weggeschreven.
Dat is een hele goede vraag. De RAMDisk wordt eigenlijk helemaal niet ingezet voor als data-cache, maar puur voor het compileren van ASP.NET-code. Je kan een ASP.NET-site in principe op verschillende manier inrichten, maar het komt er altijd op neer dat er minstens bij het opstarten een stukje code gecompileerd moet worden.

In ons geval wordt de bron dan geladen van de harde schijf, en vindt het compileren plaats op de RAMDisk. Ook de output blijft op die RAMDisk staan. Afhankelijk van de configuratie moeten er bij het opvragen van bepaalde pagina's nog stukken code gecompileerd worden. Maar vanwege de RAMDisk moet dus na een herstart alles opnieuw gecompileerd worden, tenzij de inhoud op een HDD gemirrord wordt (doen we momenteel niet).

Compileren van bepaalde code gebeurt altijd maar 1x voor die code. Bij volgende requests van die code wordt meestal de gecompileerde code uitgevoerd (tenzij er een recompile nodig is).

De snelheidswinst zit hem dus eigenlijk puur in de IO tijdens het compileren, en wellicht in veel beperktere mate in het laden van de gecompileerde code na compilatie.
rapture schreef op maandag 16 augustus 2010 @ 12:25:
Als ik naar Wikipedia: Serial attached SCSI kijk, zit het voordeel voornamelijk in hogere spanning zodat je 10m ipv 1m lange kabels en backplanes kan gebruiken.
Ok, denk dat we langzaam naar een conclusie zijn aan het toewerken (8> Heb in ieder geval veel aan je input, tnx!

[ Voor 4% gewijzigd door GrimaceODespair op 16-08-2010 13:29 ]

Wij onderbreken deze thread voor reclame:
http://kalders.be

Pagina: 1