Welke server(s) ?

[NLAnaconda]

Hallo Tweakers.

Ik heb een vrij grote website die last heeft van trage response tijden en dit wil ik graag oplossen. Ben dagen bezig met optimaliseren maar ik krijg hem op het moment niet heel veel sneller terwijl mijn site toch blijft groeien.

Mijn huidige server:
1x Intel Core 2 duo 6600, 2.4Ghz FSB1066, 4MB
2x 4096GB DDR-2 667Mhz
2x Western Digital 80 GB Sata 2 7200 rpm

Hierop draait Windows 2003 server.
Een MySQL Database van 8 GB
en verder dient hij ook als IIS server.

Nu heb ik een budget van 3000 euro en vraag me af wat ik beter kan doen.
- Of een server erbij halen. Deze oude server gebruiken als webserver (IIS) en de andere als database server.
- Een server erbij halen en daarop én de database én IIS zetten.
- 2 mindere servers halen, 1 voor server en 1 voor IIS.

Hebben jullie hiervoor tips en op welke hardware configuratie ik moet letten?

[Meneer iCy]

Al wat perfomance metingen gedaan of wil je gewoon lukraak vervangen? Je moet eerst weten wat je bottleneck is, maar ik vermoed je HD.

[ Voor 32% gewijzigd door Meneer iCy op 04-04-2011 19:32 ]

[NLAnaconda]

Het is een budget server uit 2007. Dus ik wou sowieso iets hebben wat meer klaar is voor de toekomst.
Inderdaad heeft de HDD het aardig zwaar en de processor gaat het soms ook niet makkelijk af.

[prutser001]

Ik weet niet hoe 'professioneel' je het wilt aanpakken maar ik vindt SuperMicro servers wel erg fijn.

Heb hier nog een paar X7DAE machientjes draaien en doen al jaren dienst, zowel prive als zakelijk.
De service is ook uitstekend, als we ze kopen meestal via : https://www.ahead-it.eu/nl/home/
Er zit een makkelijke configurator op de website als je een beetje wil spelen

Zelf iets bouwen is ook leuk maar het is maar net waar je intresses liggen.


*
Ik haal daar zelf meestal alleen de kast+mobo/cpu/mem en HD's los (goedkoper)

[ Voor 8% gewijzigd door prutser001 op 04-04-2011 20:08 ]

[NLAnaconda]

De oude server heb ik ook bij ahead besteld en dat wil ik ook weer met de volgende doen.
Maar stel jij had 3000 euro, wat zou je dan kopen?
En zou je die nieuwe server gebruiken als database server en de oude als webserver. Of alles op die nieuwe server.

Heb nog even naar wat preformance logs gekeken.
De Processor Queue Length is veel te hoog.

[remco_k]

NLAnaconda schreef op maandag 04 april 2011 @ 20:08:
Maar stel jij had 3000 euro, wat zou je dan kopen?

Ik zou zeer zeker eerst vast gaan stellen wat nu de bottleneck is, om te voorkomen dat als je 3000 euro lichter bent, je nog steeds (dezelfde) problemen hebt.

De CPU load, in procenten, hoe hoog is die gemiddeld?
En hoe hoog zijn de kernel tijden daarvan? (de rode lijn in de taskmanager)
Is de server aan het swappen, of heeft hij aan z'n 2x 4096GB geheugen (8 TB? ) genoeg?
De MySQL database is 8GB groot, evenals (gok ik) je geheugen. Geen idee hoeveel en hoevaak er iets uit de database moet komen, maar dit lijkt me een probleempje -> Te weinig geheugen.

[ Voor 79% gewijzigd door remco_k op 04-04-2011 20:32 ]

[NLAnaconda]

De CPU load zit op 100% voor 90% van de tijd.
De kernel tijden zitten rond de 20 tot 40%.
Process wat de meeste CPU claimed is de Mysqld-nt.exe samen met w3wp.exe

[remco_k]

NLAnaconda schreef op maandag 04 april 2011 @ 20:32:
De CPU load zit op 100% voor 90% van de tijd.
De kernel tijden zitten rond de 20 tot 40%.
Process wat de meeste CPU claimed is de Mysqld-nt.exe samen met w3wp.exe

Ik heb mijn post nog wat ge-edit tussendoor.

Ik schat in dat je (veel) te weinig geheugen hebt. Als je wilt dat alles een snelle response heeft (dat is: zonder kernel (lees: IO), moet je MySQL database geheel in het geheugen passen.
Dat lukt nu niet, want er is ook nog zoiets als Windows, IIS en andere zaken die aanstaan.

Heb je het database model zelf ontworpen? Zo ja, kijk even naar indexen en kijk of je de database op een andere manier kan optimaliseren. Zo nee, doe het dan ook.
Je zou de eerste niet zijn die dan van een 100% load naar 10% max gaat...

[Rob]

8GB is ook heel veel voor een database, is die van Tweakers ook niet zoiets?
Staat er misschien een of andere logging aan?

[remco_k]

Rob schreef op maandag 04 april 2011 @ 20:36:
8GB is ook heel veel voor een database

Dat hangt er vanaf wat er in de database zou moeten zitten en of het systeem erop in is gericht.
Op het werk draaien we databases die groter zijn dan 80GB. Zonder enige problemen.
Zijn wel wat dikkere machines dan die van de TS.

[NLAnaconda]

Ja ik kan waarschijnlijk de database flink kleiner maken door bepaalde dingen te archieveren.

Page Faults/sec voor proces mysqld-nt zit op een avarage van 450,000.
Ik ga eens kijken waar ik de database kan laten krimpen en kijken of dit wat performance scheelt.

Zijn er nog meer mogelijkheden dan de database archiveren?

Als ik een database archieveer in een andere table, dan hoeft die table toch niet gecashed te worden? Of gebruikt die database nog steeds geheugen.

[ Voor 28% gewijzigd door NLAnaconda op 04-04-2011 21:54 ]

[nielsl]

misschien een gekke gedachte: maar hoe optimaal is je database? Wat voor queries worden daar op uitgevoerd? Zijn dat killer queries met joins, group by's en subqueries of gaat dat om gewone SELECT a FROM b queries? Hoe zit het met je indexen? Als er wordt gejoined of vergeleken in queries, waarop wordt dat gedaan? String comparison duurt natuurlijk langer dan integer comparison.

Hoeveel hits heb je op een dag? Per hit / pageload, hoeveel queries worden er gedraaid? Hoe hoog staat je query cache van mysql? Kortom, genoeg vragen waar je antwoord op kan geven voordat je overgaat tot aanschaf van andere hardware

*edit* ik weet niet of je een 32 bits versie van Server 2003 draait, maar hier kun je lezen dat je onder server 2003 max 2GB RAM kan gebruiken voor de mysql daemon. Mogelijk zou 64 bits software (lees: server 2008 R2) hier uitkomst kunnen bieden.

*edit 2* Mogelijk is het interessant om een aantal van je grotere SELECT queries in bijvoorbeeld een query browser even als EXPLAIN te draaien. Hier wat meer over Mysql db optimalisatie

[ Voor 34% gewijzigd door nielsl op 04-04-2011 22:12 ]

[NLAnaconda]

Ga ik mee bezig. Bedankt!

[Fish]

Rob schreef op maandag 04 april 2011 @ 20:36:
8GB is ook heel veel voor een database, is die van Tweakers ook niet zoiets?
Staat er misschien een of andere logging aan?

8 Gig is absoluut niet "veel" Ik werkte met een database waar ~400GB inzat.
tweakers stats -> http://tweakers.net/stats/?Action=Serverstats

[Rob]

fish schreef op maandag 04 april 2011 @ 22:21:
[...]


8 Gig is absoluut niet "veel" Ik werkte met een database waar ~400GB inzat.
tweakers stats -> http://tweakers.net/stats/?Action=Serverstats

het is maar wat je met de database doet. Maar een beetje database van een website (zonder binair opgeslagen plaatjes in de database) doet echt geen 8GB

[Fish]

Rob schreef op maandag 04 april 2011 @ 22:57:
[...]


het is maar wat je met de database doet. Maar een beetje database van een website (zonder binair opgeslagen plaatjes in de database) doet echt geen 8GB

Dit was zonder plaatjes. produktie data aangeboden en verzameld primair met behulp via de webbrowser. mag je dat een website noemen ?

Ok 40Gb was echt "actief" de andere meer verzamelde info waarvan uiteidelijk een paar procent van werdt gebruikt maar weg mag het niet.

[ Voor 14% gewijzigd door Fish op 04-04-2011 23:07 ]

[Rob]

fish schreef op maandag 04 april 2011 @ 23:05:
[...]

Dit was zonder plaatjes. produktie data aangeboden en verzameld primair met behulp via de webbrowser. mag je dat een website noemen ?

Ok 40Gb was echt "actief" de andere meer verzamelde info waarvan uiteidelijk een paar procent van werdt gebruikt maar weg mag het niet.

Maar geen normale openbare website dus, daar doel ik wel op. Dat banken, verzekeringsmaatschappijen en dergelijke grote databases hebben, dat is zeker.

Maar dit is een website die op 1 server draait

[Fish]

Rob schreef op maandag 04 april 2011 @ 23:18:
[...]


Maar geen normale openbare website dus, daar doel ik wel op. Dat banken, verzekeringsmaatschappijen en dergelijke grote databases hebben, dat is zeker.

Maar dit is een website die op 1 server draait

Nou ja feitelijk wel (als je de failover niet meeteld) en de data op een san

[Gomez12]

Hoeveel van je database is echt actief en hoeveel is nice to have.
Bij bijv een t.net zou ik me (in de toekomst) kunnen voorstellen dat ze het naar "2 dbases gaan splitsen", 1 actief (zeg laatste 5 jaar) en 1 archief (zeg de rest).

Maar sowieso kijk eens naar je query's, activeer de slow query log en gooi daar eens wat explains over heen.
Ik kan me niet echt voorstellen dat een dbase die voor 80/90% in memory past bij goede query's een probleem wordt.
Kijk ook eens goed naar de-normalisatie en naar dingen als externe zoekmachines etc. Een dbase presteert bijv erbarmelijk met een full text search vergeleken met externe zoekpakketten.

[NLAnaconda]

Het merendeel van de 8GB is inderdaad archief. De site is een community en daarvan wordt een soort log bijgehouden met acties van gebruikers die ze uitvoeren. Deze acties table is de grootste table.
Verder heb ik de slow query log inderdaad aangezet en ben ik met een analyser bezig te kijken welke queries veel tijd in beslag nemen.

[CyBeR]

Rob schreef op maandag 04 april 2011 @ 20:36:
8GB is ook heel veel voor een database, is die van Tweakers ook niet zoiets?
Staat er misschien een of andere logging aan?

Mweh.

Filesystem            Size  Used Avail Use% Mounted on
/dev/cciss/c0d1p1     274G  127G  147G  47% /srv/mysql/data

Ligt er nogal aan wat er in staat, hoe lang dat al gedaan wordt, etc. 8GB is niet veel en t.net is veel groter dan dat.

[ Voor 6% gewijzigd door CyBeR op 05-04-2011 00:10 ]

[NLAnaconda]

Ik ben flink bezig de database op te schonen en betere indexes in te stellen.
Moet zeggen dat het CPU niveau minder wordt en hij meer af kan handelen.
Maar toch zakt de CPU niet genoeg. Ik wil mijn site ook in Europa lanceren en daardoor moet hij nog meer bezoekers aan kunnen.
Zijn er ook nog manieren om IIS sneller te krijgen.
Het w3wp.exe proces knabbelt net zoveel aan de CPU. Ik heb nu 4 workers bij de application pools ingesteld maar eerlijk gezegd probeer ik daar maar wat mee en heb ik geen idee of dat performance scheelt.
Hebben jullie tips voor het aantal workers of andere IIS optimalisaties?

Is er trouwens ook iets voor IIS wat ipv "slow queries" slow scripts of slow functies op kan sporen?

[ Voor 7% gewijzigd door NLAnaconda op 05-04-2011 17:26 ]

[nielsl]

IIS afstellen lijkt me op dit moment niet relevant. Mogelijk kun je je code tegen het licht aanhouden. Kan deze efficienter? Kunnen er queries uit? enz enz enz.

Welk OS draai je nu overigens, want die 8GB is leuk, maar als je 32 bits software hebt, heb je er alsnog niets aan.

[NLAnaconda]

Windows Server 2003 R2 Standard x64 Edition. Dus benut wel alles.

Inderdaad wil ik de code optimaliseren. Zijn er daarvoor programma's / monitors die mij kunnen vertellen welke functie het traagst is?

[nielsl]

in welke taal is je applicatie geschreven?

[NLAnaconda]

vb.net

Het werk geeft wel resultaat. De CPU grafiek heeft al "ups and downs" gisteren was dat alleen nog een hele dikke up waarbij nu nog logging's aanstaan ook. Daarvoor al bedankt.

[ Voor 108% gewijzigd door NLAnaconda op 05-04-2011 17:54 ]

[Remco]

NLAnaconda schreef op dinsdag 05 april 2011 @ 17:37:
Inderdaad wil ik de code optimaliseren. Zijn er daarvoor programma's / monitors die mij kunnen vertellen welke functie het traagst is?

Beetje zelf zoeken mag best: websites

[axis]

Van die drieduizend piek zou ik iig 500 piek besteden om een consultant over de vloer te krijgen die samen met jou kan zoeken naar de bottleneck, de finetuning van sql server en iis, door al je performance counters heen lopen, etc. Dan kun je daarna voor de rest van het geld weer een nieuwe machine kopen, maar dan maak je iig een gefundeerde beslissing.

[Gomez12]

axis schreef op woensdag 06 april 2011 @ 18:01:
Van die drieduizend piek zou ik iig 500 piek besteden om een consultant over de vloer te krijgen die samen met jou kan zoeken naar de bottleneck, de finetuning van sql server en iis, door al je performance counters heen lopen, etc. Dan kun je daarna voor de rest van het geld weer een nieuwe machine kopen, maar dan maak je iig een gefundeerde beslissing.

Dat is een groot risico, het is wel verstandig MITS je de juiste consultant kan vinden. Met 500 piek heb je niet erg veel speelruimte, je krijgt waarschijnlijk iets meer als een halve dag.

Verwacht van een gemiddelde consultant maar geen wonderen als hij maar een halve dag naar je setup kan kijken. Als jouw documentatie niet 100% naar zijn wens is, heb je al een grote kans dat hij die tijd aan het spenderen is om jouw documentatie te vertalen naar je setup.

Het is niet alsof een performancecounter iets aanwijst dat het dan automatisch ook verstandig is om dan maar blind die hw te upgraden...

Zoals anderen al hebben gezegd, dit moet (mits je geen extreem gekke dingen doet) gewoon snel kunnen draaien. Of je doet die gekke dingen met een reden ( en dan weet je al waar de bottleneck zit ) of je doet iets geks/onhandigs in je code wat ook een consultant niet zomaar gaat zien en waar hw ertegenaan gooien niet al te veel aan gaat veranderen...

[_JGC_]

Mja, kijk eerst eens wat je veel uitgevoerde queries zijn en welke queries veel tijd kosten. Desnoods leg je in MySQL een querylog aan en ga je met mk-query-digest een overzicht maken van de top-zoveel queries die je databaseserver flink bezig houden.
Verder, welke versie van MySQL draai je en gebruik je wel InnoDB voor je tabellen? MySQL lager dan 5.5 draait gewoon bagger op windows en MyISAM is ook gewoon bagger, zowel voor performance als voor data-integriteit.

[Gomez12]

_JGC_ schreef op woensdag 06 april 2011 @ 21:53:
Verder, welke versie van MySQL draai je en gebruik je wel InnoDB voor je tabellen? MySQL lager dan 5.5 draait gewoon bagger op windows en MyISAM is ook gewoon bagger, zowel voor performance als voor data-integriteit.

Afaik is myisam nog steeds vele malen sneller als InnoDB zolang je simpele dingen doet hoor...

InnoDB is geen automatische speedup. Op complexe operaties is InnoDB sneller, maar op simpele CRUD-operaties is MyISAM weer sneller.

Er is niet 1 kant en klare oplossing. Een mysql versie hoger dan 5.5 gaat geen magische versnelling geven, InnoDB gebruiken gaat geen magische versnelling geven. Het is gewoon eerst eens kijken waar nu het probleem zit en dan pas actie nemen...

[_JGC_]

Ik weet niet in hoeverre jij MySQL ontwikkeling volgt of het ook daadwerkelijk gebruikt, maar MySQL en Windows zijn nog nooit echt een serieus koppel geweest. Pas bij 5.5 schijnen de grootste performance issues en beperkingen op Windows platformen opgelost te zijn.
Verder is MyISAM inmiddels uitgefaseerd als standaard table handler. Ten eerste is het waardeloos voor dataconsistentie, bij een verkeerde MySQL shutdown heb je kans op dataverlies of corrupte tabellen. Ten tweede schaalt MyISAM extreem slecht naar meerdere cores en meerdere threads vanwege de vele locking issues.

Maargoed, op zich ben ik het wel met je eens hoor, je kunt er wel een bult hardware tegenaan gooien en een betere MySQL server, maar een performance probleem in je applicatie is pas echt lekker te debuggen als je tegen de limieten van je database of hardware aanloopt. Zo heb ik laatst nog een webapp mogen optimaliseren waarvan de ontwikkelaar riep dat het aan de ouderwetse Xeon server lag, terwijl ik met een profiler eruit haalde dat ie voor een simpele $user->isAdmin() call meteen alle gerelateerde records van die admin user uit de database ging slepen (en dat waren er met 30K rows per call nogal wat). Dat leverde overigens vergelijkbare problemen op als de TS beschrijft: 1 core voor 100% naar MySQL en 1 core voor 100% naar Apache alleen al als je inlogde op die webapplicatie. 100% CPU van MySQL om de hele resultset naarbuiten te stampen, en die andere 100% CPU voor PHP/Apache om die hele resultset naarbinnen te hengelen.
Daarom is het ook handig om querylogging aan te zetten en met Maatkit te gaan kijken wat er nou loos is. Met mk-query-digest kan je precies zien welke queries met welke aantallen de meeste tijd innemen op de server.

[NLAnaconda]

Ben de laatste tijd bezig geweest met het optimaliseren en ik moet zeggen dat het aardig gelukt is. De pieken zijn eruit en CPU uitschieters boven de 60% zijn aardig verwaarloosbaar.

Ik heb in Mysql 5 andere indexes ingesteld wat het meeste heeft gedaan.

Het zoeken in het forum is nog de zwaarste query die na 304 keer aangeroepen te zijn geweest in totaal 0.3 seconden in gebruik heeft genomen.
Voor de rest staat vrijwel alles in de buurt van de 0.

Ik gebruik wel mysql 5.0 dus misschien een scheelt het ook nog als ik die upgrade naar een versie boven 5.5 zoals hierboven vermeld (alle beetjes helpen).

Verder heb ik de code enigszins nagekeken en dat heeft ook nog wat gescheeld.

Ik ben nu nog aan het kijken of ik meer kan cachen.

Voor de geïnteresseerden: ik gebruik innoDB.

Verder allemaal bedankt om me met de neus de goede kant op te wijzen.

[nielsl]

fijn dat het heeft geholpen (en je daarmee de aanschaf van een server hebben bespaard, we sturen de rekening wel ). Zoekopdrachten (meestal full text) zijn gewoon ongelooflijk heftig, caching kan daar inderdaad van grote dienst van zijn. Desalniettemin moet je nagaan hoevaak er wordt gezocht en waarop men dan zoekt. Mogelijk kun je je zoekquery daarop aanpassen en keuzes maken. Als je één kolom niet meeneemt, die bijvoorbeeld maar eens in de week wordt gebruikt in een hit, en je daarmaa X% performance winst kan halen, zou het mogelijk interessant zijn om dat veld niet mee te nemen in je query

Wat je ook kan doen, is van het zoeken een twee traps raket te maken. Als men in een zoekveld gewoon kan zoeken op wat simpele (en snelle velden), kun je er met een advanced search formulier wat complexere en uitgebreide queries op loslaten. Mogelijk vindt het gross van de mensen al antwoord op zijn vraag in de simple search, mensen die niets vinden kunnen door met advanced search. Het is iets minder klantvriendelijke qua UI, maar dat is een politieke keuze die je op je website moet maken

[remco_k]

Leuk om te zien dat de inspanningen resultaat hebben.
Zo zie je maar weer dat andere zielen andere gedachten hebben en je net even dat zetje de andere kant uit kunnen geven waar je zelf anders niets was gegaan. De ene keer is dat niet de oplossing, de andere keer wel.
Nu dus wel. En da's mooi!

[Gomez12]

@TS : Nieuwsgierig vraagje dan, wat heb je gedaan in al die dagen dat je aan het optimaliseren was?

Ik zie namelijk niet veel meer dan de standaard optimalistie-tips in dit topic voorbij komen. Als ik het goed begrijp heb je zelfs enkel wat indexen geplaatst...

Ik ben gewoon even benieuwd wat je wel aan het optimaliseren was.
Let op: Niet lullig bedoeld, ik wil gewoon even weten wat er in iemands hoofd rondgaat

[NLAnaconda]

Wat ik heb gedaan:
- Als eerste heb ik in mysql de slow querylog aangezet. En gekeken welke querys veel tijd nodig hadden.
- Daarna heb ik die query's aangepast. indexes veranderd/toegevoegd.
- Weer controleren of dit resultaat boekte en zo nodig weer aanpassingen gedaan.
- Toen de mysql een stuk beter liep heb ik op internet gezocht naar andere tips waarmee ik de code sneller kon laten lopen. (bijvoorbeeld meer gebruik maken van stringbuilder ipv string + string)
- Weer kijken of hier prestatie winst mee was gemaakt.
Zodoende ben ik aan het "spelen" gegaan.

Ik heb niet alleen indexen veranderd/toegevoegd maar hier was in verhouding de meeste snelheidswinst mee gemaakt.

[Gomez12]

NLAnaconda schreef op maandag 11 april 2011 @ 16:11:
Wat ik heb gedaan:
...
Ik heb niet alleen indexen veranderd/toegevoegd maar hier was in verhouding de meeste snelheidswinst mee gemaakt.

Does not compute with me.

Je hebt dus feitelijk eerst zelf gedaan wat hier aangeraden werd, hierna kwam je tot de conclusie dat je een extra server nodig had. Dan wordt hier gezegd om nogmaals te doen wat je al gedaan hebt en dan heb je opeens geen extra server meer nodig?

Maar ik ben in ieder geval blij dat we je geld uitgespaard hebben...

[NLAnaconda]

Nee, het lijstje wat ik hierboven beschrijf heb ik gedaan nádat mij dat hier verteld werd te doen.

Dus om het compleet te maken:
Mijn site draaide goed.
Mijn site werd groter.
Mijn server kreeg er meer en meer moeite mee.
Ik dacht ik koop een nieuwe server
Hier werd mij verteld wat ik moest doen
Daardoor heb ik gedaan wat ik in dat lijstje 2 berichten terug heb beschreven.
Alles ging beter draaien.
Gomez12 (jij dus ) vraagt mij wat ik in de dagen heb gedaan dat ik aan het optimaliseren was.
En we belanden hier.

[NLAnaconda]

Hele late reactie maar voor als iemand ooit dit topic terug vindt en zelfde problemen heeft.

Ik heb in Mysql Administrator de "Flush log at" gewijzigd van "transaction commit flushes logs" gewijzigd naar "Write to Log and flush every second" en dit heeft enórm veel gedaan.
De CPU komt niet meer boven de 2 procent uit en de website's zijn super snel.

[CyBeR]

Dat is wel wat nadelig bij een power failure of crash van je server of mysql.

[ Voor 9% gewijzigd door CyBeR op 21-05-2011 21:26 ]