[Linux] Wat voor server specs?

[Sp00n]

Voor een MMORPG op basis van Open Tibia komt de database (phpmyadmin/mysql) in de toekomst op een linux bak te staan. Bij de pieken zijn er op dit moment ongeveer 600 spelers online. Dan begint de server (op dit moment een W2K3) behoorlijk te laggen. Oorzaak: én de gameserver draait erop én apache én de database. Oplossing: db naar een linux bak.

Nu ben ik aan het kijken naar de specs. Wat is nou het allerbelangrijkste voor een snelle DB server? CPU power? snel/veel Geheugen, of juist access time van de HDD? (Aan de verbinding zal het niet liggen doordat er een interconnect tussen de twee servers komt).

Wat raden jullie mij aan? Duo core? Quad ? 1GB ram? 2GB ram? 7200RPM ? 10K RPM? RAID 0? SCSI? SATA?

Server specs van de W2K3: Quad core Xeon 2,2ghz, 2GB ram, 2x250GB HDD 7200RPM geen raid.

[BarthezZ]

Dat hangt helemaal af van het soort database.
Zijn het voornamelijk reads, writes etc. etc...
Hoemeer in het geheugen kan hoe sneller het word, maar als alles constant geupdate word dan vervalt toch een gedeelte van je cache.

In het verleden heeft t.net een flink aantal database benchmarks vrij gegeven, ik denk dat het zeker verstandig is om hierop te zoeken en te kijken wat daar uit komt.

Ik zou in ieder geval goed investeren in een degelijke disk array (!met hardware raid controller) en in genoeg geheugen om zoveel mogelijk van je database te cachen.

Verder lijkt het nogal op een "wat moet ik kopen" zonder eigen inzet topic dus ik weet niet of het zonder veel extra uitleg en eigen inzet erg levensvatbaar is dit topic.

[phobosdeimos]

1) zoveel mogelijk ram geheugen
2) zoveel mogelijk ram geheugen
3) ...
4) profit!

En zet alsjeblief de apache ook op een aparte server.
P.S. Apache op windows is als pindakaas op een stuk krantenpapier. Echt niet lekker.

[trinite_t]

Als je goedkoop uit wilt zijn, probeer eens een linux distro op je huidige hardware, ik denk dat je verbaasd staat van je snelheidswinst. Gooi er nog wat extra ram bij en je kunt waarschijnlijk wel weer een tijdje vooruit.
Ik heb een keer geexperimenteerd met apache + mysql op windows, m'n toenmalige Athlon xp 2200 werdt er door mijn 2* 350 Mhz uit getrokken qua responsiviteit.

[ Voor 26% gewijzigd door trinite_t op 29-09-2008 21:34 ]

[silentsnake]

Wat phobosdeimos zei. Zorg ervoor dat je, indien mogelijk, je database in geheugen kan draaien. Met read operaties uiteraard. Zorg voor een goede SAS controller met 15K RPM schijven als je budget dat toelaat. Zoniet zijn de WD Raptors een aardig alternatief om die aan een goedkopere SATA controller te hangen (Areca kan ik zeker aanbevelen).

En draai gewoon Linux op je webserver ipv Windows. Gaat vele malen beter. Apache op Windows is leuk voor test en hobby maar zeker niet voor productie omgevingen. Kan natuurlijk wel, maar je gaat mij niet wijsmaken dat Apache op Windows dezelfde schaalbaarheid en performance heeft dan op Linux.

[smokalot]

Hoe weet je eigenlijk dat het een significante verbetering gaat geven als je de database op een andere machine draait? Houdt die 3 van de 4 processoren continu bezig? Gebruikt ie zoveel RAM dat er niks meer over is voor de andere processen, en gaat ie daardoor swappen?

Dat soort dingen wil je ook weten als je nieuwe hardware aan wilt schaffen lijkt me.

[Boudewijn]

Wat is nu eigenlijk je bottleneck?
Heb je wel ervaring met Linuxbeheer, of is daar budget voor?
Wat voor operaties is je DB?

[daft_dutch]

ik vind 600 niet echt beschikbare veel.
php/mysql mmorpg zijn er al jaren ook met veel meer dan 600 concurrent users.
heb je dus echt geen gloed nieuwe zooi nodig.

beheer van een lamp omgeving is echt niet lastig gewoon een goede distro (debian) kiezen. beheer past op een a4 tje zolang alles goed gaat.

[ Voor 30% gewijzigd door daft_dutch op 30-09-2008 23:49 ]

[eamelink]

daft_dutch schreef op dinsdag 30 september 2008 @ 23:47:
beheer van een lamp omgeving is echt niet lastig gewoon een goede distro (debian) kiezen. beheer past op een a4 tje zolang alles goed gaat.

Ja, zolang alles goed gaat kan ik ook wel een kernfusiereactor draaiende houden

Belangrijker is echter of je in staat bent om problemen te vinden en op te lossen binnen een redelijk tijdgebrek als er problemen optreden, want om één of andere reden vallen problemen nogal vaak samen met een moment dat je service gigantisch populair aan het worden is, en je echt geen downtim wilt

[Boudewijn]

En kunt zorgen dat alles goed blijft gaan (Security).
Ik vind het wel een terecht punt van mezelf, hoor.

[donotwant]

Waarom gebruik je Windows Server 2003 als je het niet nodig hebt?

Alles leuk en aardig en het zal waarschijnlijk makkelijk te beheren zijn, mooie grafische UI blabla, maar de performance lijdt er zwaar onder.

Ik zou: de hele shit omzetten naar linux, er 4GB ram bij prikken (ik weet natuurlijk niet hoe groot je daba is), en er een paar 10k of 15k schijven in raid 10 in hangen, probleem opgelost.

[Sp00n]

Bedankt voor de antwoorden tot zover.

Op dit moment wordt de beschikbare RAM nog niet helemaal gebruikt. Er is 2GB aanwezig waarvan er tussen de 400MB en 800MB vrij blijft. Dus de lag komt niet door het swappen. Het is een Quad core en de average load is ongeveer 5%, dus ook dat moet het probleem niet geven. Then again... Noch W2K3, noch phpmyadmin is echt geoptimalisseerd voor quad core...

Het is zoals al eerder is gezegd eerder W2K3 die ervoor zorgt dat het gaat laggen én ik denk dat het ook ligt aan het feit dat én apache én de database én de gameserver allemaal op één systeem draaien.

Met linux heb ik weinig ervaring, maar ik ken gelukkig iemand die me daar goed mee kan helpen. Kwestie van één keer iptables fatsoenlijk opzetten en wat andere policies lijkt me ?

Over die 10K RPM, 15K RPM en Raid 10... Het moet wel betaalbaar blijven. Anders bel ik IBM wel ff op of ze een Blue Gene bij me komen plaatsen. Dan is het probleem ook wel opgelost denk ik.

W2K3 was omdat we niet hadden verwacht boven de 300 spelers uit te komen. Nu we merken dat het toch aardig populair is moeten we iets doen aan de performance. Dat doen we in de vorm van overstappen op een goed OS

Edit: database is ongeveer 450MB and growing...

[daft_dutch]

Sp00n schreef op woensdag 01 oktober 2008 @ 23:56:
Bedankt voor de antwoorden tot zover.

Op dit moment wordt de beschikbare RAM nog niet helemaal gebruikt. Er is 2GB aanwezig waarvan er tussen de 400MB en 800MB vrij blijft. Dus de lag komt niet door het swappen. Het is een Quad core en de average load is ongeveer 5%, dus ook dat moet het probleem niet geven. Then again... Noch W2K3, noch phpmyadmin is echt geoptimalisseerd voor quad core...

Niet schikken dat linux straks 100% mem gebruikt. (w2k3 gebruikt dus 20% tot 40% niet. zonde toch)

verwijt dat phpmyadmin maar aan de reeds gemelde mysql performance onder windows.

ik denk dat dit wel handig is.
Het installeren van linux is een eitje.

Hoelang kan dat spel down gaan. of heeft het rounds?

in iedergeval een testomgeving is wel raadzaam.
Er is vast wel iemand met een nieuwe retesnelle laptop. en iemand die een laptop heeft en hem niet gebruikt.

btw jongens moeten we niet over filesystemen en partitionering hebben?
voor TS:
dat je systeem niet hangt als er een disk vol is, je altijd en snel boot en om te zorgen dat de "eventuele" swap snel is. Dit is namelijk wel iets wat je niet snel opnieuw gaat doen.

[mkromkamp]

Sp00n schreef op woensdag 01 oktober 2008 @ 23:56:
Bedankt voor de antwoorden tot zover.

Op dit moment wordt de beschikbare RAM nog niet helemaal gebruikt. Er is 2GB aanwezig waarvan er tussen de 400MB en 800MB vrij blijft. Dus de lag komt niet door het swappen. Het is een Quad core en de average load is ongeveer 5%, dus ook dat moet het probleem niet geven. Then again... Noch W2K3, noch phpmyadmin is echt geoptimalisseerd voor quad core...

Even voor de zekerheid, draai je die server thuis.?
Als dit het geval is ligt het dan niet gewoon aan je upload snelheid dat er lagg onstaat.? Ik kan me voorstellen dat wanneer er 300 spelers zijn dit nogal wat bandbreedte neemt (correct me if i am wrong).

Voor de rest is het zeker de moeite om de stap na linux te maken.

[AndriesLouw]

mkromkamp schreef op donderdag 02 oktober 2008 @ 00:30:
[...]


Even voor de zekerheid, draai je die server thuis.?

Lijkt mij niet, gezien er zo veel applicaties op draaien.

Maar ontopic:
Voor een snelle DB-server is inderdaad veel RAM erg handig, vooral omdat linux alles cached (vandaar dus ook dat linux waarschijnlijk 85 tot 95% van je ram gaat gebruiken). Enorm veel CPU power is, mits je niet al te veel berekeningen (SUM, AVG), sorteringen of zoeken doet, niet een vereiste. Gezien het feit dat het een MMORPG is, verwacht ik vooral dat het lezen en opslaan van data van 1 gebruiker is. Bij queries met veel JOIN's is het wel handig (valt eigenlijk ook onder "sorteringen/zoeken").

Snelle HD's zijn handig, als je een grote DB hebt, anders stel je MySQL gewoon zo in dat hij zo veel mogelijk tabellen in het RAM houdt.

2GB RAM is wel minimaal voor een flinke DB-server, stop er eens 4GB in (mits budget toelaat).

Wellicht heb je nog meer informatie over je DB? Bijvoorbeeld percentages SELECT/UPDATE/INSERT, grafiekjes met connections en command/handler statistics. Dan kunnen wij je ook verder helpen.

En heb je eigenlijk al eens geprobeerd je huidige MySQL-config te optimizen? Indexen gecontroleerd, QueryCache juist staan, en de "MySQL runtime informatie" in phpMyAdmin doorgenomen? Vertelt je vaak al een hoop over waar je verbeteringen kunt aanbrengen.

Edit:
En als je helemaal snel wilt zijn, gooi Apache/Lighttpd ook naar de linux bak, daar is ie voor gemaakt . En linux cached dus mooi je scripts in het RAM (als je daar voldoende van hebt ingestopt).

[ Voor 6% gewijzigd door AndriesLouw op 02-10-2008 00:55 ]

[Sp00n]

Wederom bedankt voor de antwoorden

't moet een dedi server worden. De server staat op dit moment dus ook gewoon in een datacenter en niet thuis. Hangt aan een 100MBit lijntje. We gebruiken gemiddeld ongeveer 20GB aan dataverkeer p/dag. (2TB toegelaten per maand, dus das ook geen probleem )

Over wat voor soort acties mysql moet doen: als ik het goed begrijp wordt alles één keer opgehaald als de user joint en wordt alles pas weer weggeschreven als de user uitlogged. Over hoeveel read/write acties en %'s het daarbij gaat weet ik niet. Kan ik dat ergens vinden? Volgens mij onthoud de client namelijk alles tot het moment van uitloggen. Dan wordt de DB weer aangesproken.

Downtime mag wel een paar uur zijn, maar ik ben van plan om gewoon die W2K3 bak nog ff in de lucht te houden en op de achtergrond de linux bak in te regelen. Als jullie dus iets over partitioning en filesystems etc kunnen zeggen graag. Er is geen subscription service oid, alleen vrijwillig doneren, dus dan mag een beetje downtime wel. Liever zo min mogelijk natuurlijk!

Ik heb geen ervaring met het "optimaliseren" van mysql Het enige wat ik veranderd heb, is het standaard geheugen dat ie mag aanspreken. Normaal is dat 16MB volgens mij? Dat staat nu op 128MB volgens mij. Dat is de enige "tweak", als je het al zo mag noemen, die ik heb toegepast. (in php.ini dacht ik) Als jullie nog tips hebben?

De grootste table is de table met player items. Die bestaat inmiddels uit een paar miljoen records. Ik ben nu net ook begonnen met het opschonen van de DB. Maar volgens mij maakt het niets uit qua timing om een row te veranderen/inserten bij een table die leeg is dan bij een table waar een miljoen records in staan? Of is dat onzin?

[garp]

Lees ik nu goed dat je je MySQL tweak in de php.ini toevoegt? Dat is niet helemaal de bedoeling; als het goed is heb je een my.cnf ergen op je systeem. Daarin doe je de aanpassingen voor mysql. Tenminste, dat is onder linux zo.

Wat handig is om eens mee te spelen is een MySQL tuning script. Ik heb ook problemen gehad met MySQL geheugengebruik en snelheid en mij heeft het enorm geholpen.

Ik heb zelf deze (http://day32.com/MySQL/) gebruikt. http://wiki.mysqltuner.com/MySQLTuner is net zoets, maar dan in perl zo te zien. Daar heb jij misschien meer aan.

Edit: bovengenoemde scripts zijn Linux-only zo te zien.

Misschien is dit wat voor je: http://www.webyog.com/en/

[ Voor 9% gewijzigd door garp op 02-10-2008 11:31 ]

[Speedener]

Volgens mij begint de keuze of er een nieuwe server nodig is, met de vragen: hoe ziet je database eruit (MyISAM, InnoDB etc), waarom lagged het spel nu en is er niet nog met database/query optimalisatie iets te bereiken? Is er sprake van table locking, zijn er full table searches, is de server gewoon te langzaam, etc?

Afhankelijk van hoe je database eruit ziet maak je een keuze over de hardware. Is het InnoDB: veel geheugen; Is het MyISAM is het geheugen van minder belang. Zijn de tabellen erg groot, dan zijn is zijn snelle hardeschrijven in raid 10 interessant.

Zo zijn er per punt afwegingen die gemaakt moeten worden.

Ik zou beginnen met het in kaart brengen van het daadwerkelijke probleem. Zonde als je een dikke bak koopt en het lost niets op.

[Freezerator]

Dan zou ik eerst een beginnen met mysql te optimisen Ik denk dat je daar nog een hoop performance winst kan halen.

Maar voor een db server: RAM en snelle IO, dus als het budget raid 10 (met sata schijven bv) toelaat, doen.
http://www.vbulletin.com/forum/showthread.php?t=69073 <-- Mysql tips

[Sp00n]

Het is innoDB. En jullie hebben absoluut gelijk over het optimaliseren. Ik ga daar eerst even naar kijken, bedankt voor de links. (In eerste instantie dus op een W2K3 server optimaliseren, later de linux bak)

Als ik een RAID10 wil hebben, dan ben ik echt wel de hoofdprijs kwijt Ik wil niet meer dan € 1000,- tot € 1500,- uitgeven. RAID5 is ook al aardig prijzig, want de meeste servers komen maar met 2 schijven? (Heb nu alleen maar bij DELL gekeken)

Over die tweak in php.ini. Dat las ik ergens. Zal eens duiken in my.cnf.

Volgens mij is de server niet te langzaam, maar ik denk gewoon dat het aan het OS ligt. Er ligt een quad core xeon 2,13Ghz in, 2GB geheugen. Ik zie nooit full CPU load (zelfs niet 1 core full load) en nooit alle RAM used. Conclusie lijkt mij dan dat W2K3 gewoon K is. Waarbij ik natuurlijk wel nog even mijn 1e alinea van deze post herhaal... Met optimaliseren zal zelfs op de windows bak nog wel winst te halen zijn. Maar Linux is nou eenmaal superior wat betreft apache en database's.

HDD's zal ook wel een issue zijn. Maar daarvoor moet die RAM toch worden ingeschakeld? Cachen die handel (alles voor apache) en alles wat ge-read kan worden voor de DB. Er blijft 400MB tot 800MB vrij.

[AndriesLouw]

Sp00n schreef op donderdag 02 oktober 2008 @ 11:50:
(..)
HDD's zal ook wel een issue zijn. Maar daarvoor moet die RAM toch worden ingeschakeld? Cachen die handel (alles voor apache) en alles wat ge-read kan worden voor de DB. Er blijft 400MB tot 800MB vrij.

Ja, dat zou moeten, maar dat doet W2K3 dus niet, in tegenstelling tot Linux.

[Question Mark]

Controleer je disk queu length eens (via perfmon).

Als cpu en memory geen probleem geeft en de performance is ondermaats, zal het waarschijnlijk Disk I/O zijn. Hoe en wat zijn je disken nu ingedeeld?

[_JGC_]

Als je genoeg geheugen hebt is disk I/O niet eens een issue. Sinds we hier overgestapt zijn van 12GB naar 32GB geheugen in onze databaseserver, draait alles een stuk beter en wordt er nagenoeg niet meer van harddisks gelezen. Hangt uiteraard ook af van of je veel inserts doet, maar bij een website waarbij vnml selects worden gedaan zie je weinig disk I/O als je genoeg geheugen hebt.

[Arnout]

Sp00n schreef op donderdag 02 oktober 2008 @ 11:50:
Volgens mij is de server niet te langzaam, maar ik denk gewoon dat het aan het OS ligt. Er ligt een quad core xeon 2,13Ghz in, 2GB geheugen. Ik zie nooit full CPU load (zelfs niet 1 core full load) en nooit alle RAM used. Conclusie lijkt mij dan dat W2K3 gewoon K is.

Ik blijf me verbazen over het niet eens weten wat de bottleneck is, en vervolgens de meeste vette configuraties voorbij zien trekken.
Ik zou eerst de bottleneck boven water proberen te halen. Het zou jammer zijn als die er bij de nieuwe server nog is (hoewel, als je er maar veel hardware tegenaan gooit lossen alle problemen zich wel op).

[ Voor 16% gewijzigd door Arnout op 14-10-2008 15:35 ]

[_JGC_]

Arnout schreef op dinsdag 14 oktober 2008 @ 15:33:
[...]
Ik blijf me verbazen over het niet eens weten wat de bottleneck is, en vervolgens de meeste vette configuraties voorbij zien trekken.
Ik zou eerst de bottleneck boven water proberen te halen. Het zou jammer zijn als die er bij de nieuwe server nog is (hoewel, als je er maar veel hardware tegenaan gooit lossen alle problemen zich wel op).

Als hij nu al zegt dat niet al zijn geheugen gebruikt wordt, zou ik in zijn geval eerst eens kijken waarom MySQL maar een deel van het geheugen gebruikt.
Je kunt wel mooi 32GB geheugen hebben zoals in mijn geval, maar als je MySQL dan instelt met 32MB innodb_buffer_pool_size en 16MB key_buffer_size heb je er geen fluit aan en is je OS druk bezig om alles constant vanaf disk te lezen.