Server performance

[Kermit the frog]

Hoe kan ik best de performance van mijn server op peil houden? Door mijn budget kan ik alleen kiezen tussen een nieuwe CPU of een upgrade van mijn geheugen.

Op dit moment heb ik een 1,53 GHz met 768 MB DDR (Zoiets).

Als ik voor de CPU ga dan wil ik minimaal naar de 2GHz gaan, en voor geheugen minimaal 1512 MB DDR.

Denk je niet dat het niet handig is om te vermelden waar deze server voor gebruikt wordt?

[unpopular]

Ja wat doe je er idd mee.
Ik zou bijna zeggen dat je ene profesionele server aan het draaien bent.
Ik zou eerder zeggen (ondanks dat ik niet weet waar je het voor gebruikt). Denk eerst aan SCSI schijven om het systeem oppijl te houden qua max performence dan alleen maar naar processor snelheid en geheugen capaciteit te kijken.

[Kermit the frog]

Ik draai op dit moment een server ter ondersteuning van een website met intensief databasegebruik, zeg maar 80% van het geheel. Verder is de belasting op de fysieke schijven ook redelijk groot in verhouding tot het gebruik.
En waarom professioneel? Ik wil gewoon een goede performance leveren aan mijn bezoekers (uptime, upstream en verdeling van de serverload). Ik kan er ook een PI neerpleuren met 256 MB RAM, maar dat schiet ook niet op.

En je huidige configuratie trekt dat niet of nog maar net?
Je kan toch het CPU en geheugen gebruik wel in de gaten houden? Aan de hand daarvan bepaal je of een upgrade nodig is.

[Kermit the frog]

Laat ik het zo zeggen, alles loopt goed maar ik heb nu de mogelijkheid om alles nog beter te laten lopen. Het is geen kwestie van net niet of net wel maar meer een extra toevoeging. Mijn vraag was alleen wat nou het beste is als het gaat om de performance, een snellere CPU of meer geheugen.
Op mijn werk draaien ze namelijk op 3GB intern geheugen en een iets minder krachtige CPU. Dus vroeg ik me af of intern geheugen inderdaad beter zou zijn aangezien 1,53 GHz al afdoende is.

[JJzD]

watvoor site draai jij dat je die databasde niet aankan
t.net??

als je nou gewoon eens je gebruik in de gaten hield dan zie je zelf wel wat er aan de hand is
geheugen of cpu volledig gebruikt zal je zelf het beste kunnen bekijken

[Kermit the frog]

JJzD schreef op 10-06-2003 @ 16:08:
watvoor site draai jij dat je die databasde niet aankan
t.net??

als je nou gewoon eens je gebruik in de gaten hield dan zie je zelf wel wat er aan de hand is
geheugen of cpu volledig gebruikt zal je zelf het beste kunnen bekijken

een site met veel dataverkeer, laat ik het daar op houden en nee, geen porno

Maar nogmaals, ik heb geen problemen met de server. Ik vroeg me alleen af wat een betere toevoeging zou kunnen zijn, CPU of RAM.

[de postbode]

Kermit the frog schreef op 10-06-2003 @ 16:14:
een site met veel dataverkeer, laat ik het daar op houden en nee, geen porno

Maar nogmaals, ik heb geen problemen met de server. Ik vroeg me alleen af wat een betere toevoeging zou kunnen zijn, CPU of RAM.

uhm, kijk voor de grap eens hoeveel bijde gebruikt worden. staat je cpu constant op 100% te ploeteren dan doe je daar wat aan. loopt je geheugen flink vol. dan stop je dat er bij. verder denk ik dat het allemaal wel spaak zal lopen met je server. je moet een flinke site + database hebben draaien om meer dan dit nodig te hebben. als je verder een site hebt met veel data verkeer is het misschien een idee om je server aan meer breedband te helpen.

-de postbode-

[Enlightenment]

Geheugen is vaak het meest belangrijk voor internet servers. Zo kan er gecached worden waardoor er minder last wordt gelegd op de (supertrage) hardeschijven. Want zelfs de snelste en duurste SCSI schijf is een slak vergeleken met een Lotus Esprit t.o.v. geheugen.

Om te beoordelen wat jij nodig hebt, kun je het beste naar het huidig gebruik kijken. Op een piekuur kijk je dan b.v. naar het processorgebruikt (windows: 54% 75% etc., Linux/UNIX: 0.74 0.56 0.89 etc.) en naar het gebruik van swapspace (heel belangrijk!) en geheugengebruik.

Aan de hand van deze twee gegevens kun je concluderen wat het meest invloed zal hebben op je server.

Ik neig naar meer geheugen, aangezien dit nu erg goedkoop is. Processor zou ook kunnen, als het SocketA is, zou je 2400+ voor €76 kunnen overwegen, icm met 512MB meer geheugen voor €56. Kun je misschien beide upgraden en houdt je je 1800+ processor over.

[Orion]

euhw.. nieuwe schijf misscchien?

mooie maxtor atlas ofzo

[DEChengst]

Laat eerst een paar dagen een tooltje draaien om performance gegevens te verzamelen. Bepaal aan hand van deze gegevens wat de bottleneck is. Kijk ook of er resources vrijwel niet gebruikt worden.

Zie je bijvoorbeeld dat je geheugen bij lange niet volledig gebruikt wordt dan kan je de caches van je database verhogen zodat queries minder gebruik maken van de HDD.

[unpopular]

Enlightenment schreef op 10-06-2003 @ 16:23:
Geheugen is vaak het meest belangrijk voor internet servers. Zo kan er gecached worden waardoor er minder last wordt gelegd op de (supertrage) hardeschijven. Want zelfs de snelste en duurste SCSI schijf is een slak vergeleken met een Lotus Esprit t.o.v. geheugen.

zonder twijfel :geheugen is sneller dan harddisk.

Maar ondanks dat moet er natuurlijk data van de harddisk gehaald worden en in dat geval zul je wel naar z'n snel mogelijke harddisks moeten kijken.
Dit wil natuurlijk niet meteen zeggen dat je van je plannen moet afwijken voor een nieuwe proc of mem. Maar voor in de toekomst is het mss wel een idee. Ook is SCSI niet meteen nodig kijk ook eens naar bijv. SATA nee het is niet zo snel maar wel veel goedkoper. (bottleneck van een server is vaak bandbreedte en harddisk snelheid)

Je moet proberen dat alles in ballans is.
Zoals eerder vermeld probeer eens de verschillende tools of os metingen.

(
Of als het mogelijk is database (als deze veel trekt) optimaliseren
)

[Enlightenment]

unpopular schreef op 10-06-2003 @ 22:37:
Maar ondanks dat moet er natuurlijk data van de harddisk gehaald worden en in dat geval zul je wel naar z'n snel mogelijke harddisks moeten kijken.
(bottleneck van een server is vaak bandbreedte en harddisk snelheid)

In de praktijk is geheugen bijna altijd de bottleneck, en daarna pure processorkracht.

Je hebt opzich wel gelijk dat de benodigde data op de hardeschijven staan. Maar drukke internet servers kunnen zich niet permitteren om voor elke request de hardeschijf aan te spreken, dan zou je namelijk niet ver komen qua max requests/sec, ook al heb je de snelste 15K rpm schijven @ RAID0.

Om dit probleem te omzeilen, wordt het geheugen als write-buffer en read-cache gebruikt. Met 3GB geheugen (3 x 1024MB ECC Registered DRAM) zou je iets van 75% kunnen cachen. Je begrijpt dat hierdoor de hardeschijven enorm verlost worden. Belangrijk is dat je de harde kern van je DB kunt cachen, zodat de belangrijkste en meest aangesproken data uit je geheugen komt.

Je moet proberen dat alles in ballans is.

Dat klopt. Dat tunen is best een karwei, maar ik vind het wel leuk om te doen.

En veel benchmarken en stressen in verschillende setups en verschillende instellingen.

[ijscoman]

Ik denk dat deze server roomschoots voldoet voor zijn taak. Als je het al beter zou willen hebben kwa hardware zoe ik er meer geheugen in gooien maar het lijkt me zinvoller om te investeren in meer bandbreedte als je je site sneller wilt maken. Ik weet niet wat voor upstream je nu hebt?

[Kermit the frog]

ijscoman schreef op 11-06-2003 @ 01:58:
Ik denk dat deze server roomschoots voldoet voor zijn taak. Als je het al beter zou willen hebben kwa hardware zoe ik er meer geheugen in gooien maar het lijkt me zinvoller om te investeren in meer bandbreedte als je je site sneller wilt maken. Ik weet niet wat voor upstream je nu hebt?

256 kbit/s maar nu we een extra investeerder erbij krijgen kunnen we upgraden naar 384 kbit/s * ik weet het...gewoon gierig *

Maar voorlopig 256 kbit/s

[ijscoman]

Kermit the frog schreef op 11-06-2003 @ 09:39:
256 kbit/s maar nu we een extra investeerder erbij krijgen kunnen we upgraden naar 384 kbit/s * ik weet het...gewoon gierig *

Maar voorlopig 256 kbit/s

Dat bedoel ik dus je upstream is de bottleneck, de server zelf is dus een zware overkill voor de gebruikte bandbreedte. Mischien is het varstandig om bij planet ADSL een abonnement te nemen: 1mbit downstream en 512kb/s upstream. Ik meen zelfs dat de snelheden alweer met 50% zijn verhoogt

[Enlightenment]

Of je neemt een Cistron 1024/1024 abo.
BBned gaat binnenkort zijn 512kbit cap eraf halen namelijk.

Let wel dat dit niet geheel legaal is; je mag alleen voor persoonlijke en hobbydoeleinden servers opzetten. Dus als jouw server een commerciëel karakter heeft, mag dit niet.

Maar ik vind het moeilijk te geloven dat de server qua resources aan z'n max zit op een 256kbit lijntje, dat is niks namelijk.

[ijscoman]

Enlightenment schreef op 11-06-2003 @ 16:00:
Of je neemt een Cistron 1024/1024 abo.
BBned gaat binnenkort zijn 512kbit cap eraf halen namelijk.
.

WAAR WANNEER HOE DUUR?????

ijscoman schreef op 11-06-2003 @ 16:15:
WAAR WANNEER HOE DUUR?????

ZO bijzonder is dat niet emt ADSL hoor
www.tweakdsl.nl

[ijscoman]

McLaren schreef op 11-06-2003 @ 16:40:
ZO bijzonder is dat niet emt ADSL hoor
www.tweakdsl.nl

Waar zie ik dan een abonnement met 1mbit upstream?
Het gaat mij dus om een 1mbit/1mbit abbo...

[Enlightenment]

McLaren schreef op 11-06-2003 @ 16:40:
ZO bijzonder is dat niet emt ADSL hoor
www.tweakdsl.nl

Dat is zeker wel bijzonder, dat wordt nergens in nederland en volgens mij heel europa aangeboden.

TweakDSL gaat ook t/m 512kbit upstream. 1024kbit upstream (uncapped, de max van de ADSL specificatie) gaat Cistron bij wijze van proef aanbieden aan een selectief aantal abonnees. Als het bevalt, voeren ze het in voor alle abonnees.

[unpopular]

Enlightenment schreef op 11-06-2003 @ 00:53:

Je hebt opzich wel gelijk dat de benodigde data op de hardeschijven staan. Maar drukke internet servers kunnen zich niet permitteren om voor elke request de hardeschijf aan te spreken, dan zou je namelijk niet ver komen qua max requests/sec, ook al heb je de snelste 15K rpm schijven @ RAID0.

Nee tuurlijk niet zou er uitzien als dat zou moeten
Maar goed er zullen wel gegevens opgehaald moeten ook meot regelmatig het geheugen ververst worden vergeet neit dat 3 Gig niet zomaar ff binnen 1mirco seconde kan bijgevult worden dus soms moet er toch echt ff op gewacht worden.

Maar idd meer geheugen zou natuurlijk makkelijker kunnen zijn in dit geval.

Ook kun je mss eens kijken naar de profecionele servers van bijv. sun of comprak ( ) of andere toch grote merken wat hun gemiddelde qua verhouding geheugen en processor is.
(hier zul je wel meestal de SCSI schijven tegen komen maar met jou uplink is dat echt niet nodig , lijkt mij zo maar het staat wel leuk)

kijk bijv naar dit "instapmodel" van sun

Sun Fire V100 Server :
650-MHz UltraSPARC® IIi processor
512 KB of Level 2 cache
2GB of memory
CD-ROM drive
Solaris 9 Operating Environment supported
2 x 40 GB IDE drives

iets groter
Sun LX50 Server :
2x 2.8-GHz Intel Xeon processors
533-MHz Front Side Bus
6 GB of interleaved registered DDR-266 ECC SDRAM memory
three 3.5-in. x 1.0-in. 36-GB or 73-GB 10K RPM drives available
Two independent, 64-bit, 100-MHz PCI-X I/O slots on two PCI-X buses
Dual, integrated 10/100/1000-Mbps Base-T Ethernet interfaces
Integrated ATI Rage XL video controller
350 W power supply
1U form factor

Maar zoals je ziet zie je jet verschil echt terug komen tussen de combinatie processor , geheugen , disk maar ook zeker netwerksnelheid.

[Enlightenment]

Access time van het geheugen gaat om nanoseconden, bij hardeschijven om milliseconden, een factor 1000 verschil. En ook als we kijken naar random read/write performance laat het geheugen eenzelfde beeld zien. 3GB lezen of schrijven duurt net iets meer dan 1 seconde. Bij een supersnelle hardeschijf 1 minuut, en dan neem ik voor het gemak 50MB/s aan, wat natuurlijk heel hoog is.

SCSI schijven worden van oudsher in servers gebruikt. Niet eens omdat de interface sneller is, meer omdat deze schijven gebouwd zijn om 24/7 te draaien en vaak een veel hoger toerental hebben dan de IDE schijven, 10k of 15k RPM zijn nu ook geeneens zo duur.

Het gaat wel veranderen, de Raptor met 10K rpm en Serial ATA aansluiting doet het zeker niet slecht, performance zit tussen SCSI RAID en IDE RAID in. Maar pas bij de introductie van Serial ATA II zal er masaal worden overgestapt, denk en hoop ik.

[unpopular]

Ik snap ook wel wat je bedoeld maar ik doelde op de refresh rate van het geheugen dit moet ook ergens vandaan komen , zo ver ik weet is dit de harddisk, dus zoals jij al aan geeft is het geheugen sneller(logisch) maar zou er een volledige(of groot deel) refresh plaats vinden dan zal er een geruime disk aanvragen komen. Want hoe meer geheugen hoe meer harddisk aanvragen er volgen. En het huidige geheugen is erg vluchtig.
Hier voor is een snelle harddisk nodig, of in ieder geval makkelijk.

Dus ja het is wel een belangrijk gegeven maar software pakketten als oracle gebruiken ook altijd een log voor undo en redo informatie (dit kan per instelling verschillen) op de harddisk. Maar ook een buffer wordt op de harddisk opgeslagen. (Er is dus ook een log in het geheugen.)





Maar ik vrees zoals wij wel vaker doen dat we teveel van het onderwerp afdwalen wat echt nuttig is voor de topic starter niet dat ik dat erg vind.

[Chimera]

Unpopular, Enlightenment heeft gelijk. Alle DB systemen cachen zo veel mogelijk data in het werkgeheugen, en bij een high-load systeem wil je gewoon absoluut niet dat het systeem op een trage (als is het een 15k rpm SCSI schijf) HD moet wachten. Daarom zal de hoeveelheid geheugen vrijwel altijd een bottleneck zijn, die HD wordt erg weinig aangesproken, voornamelijk bij schrijfacties, en deze worden parrallel gedaan.

[unpopular]

Toch vreemd dat oracle de uitleg geeft dat zij zelf een "groot deel" naar de harddisk cache wat dus ook in die tekening te zien is. Ik heb het hier over een logfile en een deel van de buffer en uiteraard een stuk lezen uit de db wanneer nodig.
Maar goed ik heb ook een foutje gemaakt *schaam* net het geheugen want dat komt niet van de harddisk maar via processor terug in geheugen.
Vandaar dat er dan ook het misverstand over die hdd access is ontstaan.

Maar goed een SCSI schijf is natuurlijk wel een stabiele techniek maar zeker nu de S-ATA schijven goed in opkomst komen is daar ook iets voor te zeggen.

Maar het is wel zo dat je een goede combinatie zult moeten nemen zodat je ook een stabiele server krijgt.

Het is natuurlijk ook niet nuttig om een 3.06Ghz met 3GB aan geheugen en een Harddisk van dma66.

[Chimera]

unpopular schreef op 12-06-2003 @ 16:24:
Toch vreemd dat oracle de uitleg geeft dat zij zelf een "groot deel" naar de harddisk cache wat dus ook in die tekening te zien is. Ik heb het hier over een logfile en een deel van de buffer en uiteraard een stuk lezen uit de db wanneer nodig.

Tuurlijk wordt alles naar de HD weggeschreven, vooral voor de log is dat ontzettend belangrijk, maar dit wordt parallel gedaan. Die logs worden gebufferd, de hele zwik wordt dan in een blok weggeschreven, en het systeem levert fijn de data door vanuit 't geheugen.

[unpopular]

Moet je goed luisteren als jij commentaar hebt op Oracle moet je echt bij hun zijn ik vertel gewoon wat zij hebben staan.

[Enlightenment]

unpopular schreef op 12-06-2003 @ 16:41:
Moet je goed luisteren als jij commentaar hebt op Oracle moet je echt bij hun zijn ik vertel gewoon wat zij hebben staan.

Jij voert een argument aan, met als bron Oracle. Hij reageert daar inhoudelijk op, daar is toch niets verkeerds mee?

Relax, hij is er niet om je af te kraken, en ik ook niet.

Het is zo dat de file I/O geoptimaliseerd wordt. Zo heb je op BSD/UNIX het Unix File System met een techniek die SoftUpdates heet. Deze techniek wacht met het wegschrijven van de data tot daarvoor de beste omstandigheden zijn. Zo kan bij veel file I/O's de efficiëntie en daarmee de snelheid aanzienlijk toenemen. Windows heeft Write Behind Cache, wat gebaseerd is op hetzelfde principe.

Nog even over die "volledige refresh" van het geheugen, wat bedoel je daarmee?

DRAM is een techniek waarbij om de zoveel nanoseconden alle cellen moeten worden gerefreshed, eerst worden gelezen en daarna worden herschreven. Dit moet, omdat anders de data verloren is. Dit is ook de reden dat alle data weg is als je de computer uit doet. Bij SRAM is dit niet het geval (niet te verwarren met S-DRAM), waardoor het veel sneller is dan DRAM geheugen, het wordt vaak in cache toegepast maar de prijs per KB is aanzienlijk hoger en neemt vele malen meer ruimte in beslag.

Als je het bovenstaande verhaal bedoelde, dan kan ik je zeggen dat dit totaal onafhankelijk gebeurt van de geheugen I/O, het enige waar je dit aan merkt is dat DRAM vele malen minder snel is dan SRAM, dat gemakkelijk 30GB/s haalt.

Of de topicstarter iets aan deze discussie heeft weet ik niet, als hij graag iets anders wilt hoor ik dat graag, misschien vind hij een wat diepere kijk op server performance wel interessant.

[Kermit the frog]

Ow, ik heb er geen problemen mee dat jullie zo afdwalen hoor

[de postbode]

Kermit the frog schreef op 16-06-2003 @ 21:41:
Ow, ik heb er geen problemen mee dat jullie zo afdwalen hoor

tsja, je moet iets als de topic starter niet reageerd

[Kermit the frog]

de postbode schreef op 16-06-2003 @ 21:45:
tsja, je moet iets als de topic starter niet reageerd

Ik snap er toch al geen bal meer van

[Pruttelpot]

Geheugen is over het algemeen een stuk belangeirjker voor servers, vooral voor buffers en caching, wat de prestaties van een server flink op(kan)voeren.

Voor databases, waar jij het voor gebruikt zoals je zegt is geheugen ook belangerijk, kan er namelijk meer in het (snelle)geheugen geladen worden, waardoor er minder op de (trage)hardeschijf gekeken hoeft te worden.

Kortom, prop er een paar gb bij en klaar ben je. (een dual PPro 200 met 640mb ecc edo ram is perfect namelijk voor heel veel)

Maar je upstream is in eerste instantie denkik je grootste bottleneck

[Vaag mannetje]

Gooi er 2gig Corsair CL2 ram erin.
Die processor kan nog wel een tijdje mee. (Moet je je load eens checken)