Bekijk Volledige Versie : Advies nodig voor juiste setup van Mysql server. Hardware heb ik al.
CeeReM.com
13/08/11, 17:42
Hallo,
Ik heb een server met de volgende specs:
1 x SUPERM X7DCU XEON 5100 (http://www.supermicro.com/products/motherboard/Xeon1333/5100/X7DCU.cfm)
1 x INTEL CPU Harpertown L5410 2.33G 12M 1333FSB 50W
2 x 2GB 240p PC2-5300 CL5 18c 256x4 DDR2-667 1Rx4 1.8V ECC RDIMM, Qimonda, BTD, HYS72T256000EP-3S-B
6 x HD 36 GB SEAGATE SAVVIO SAS 15K 3Gb raid 10 (waarvan 1 hot spare!)
1 x IOSASB70 IO ARECA RAID BATTERY BACKUP UNIT
Nu heb ik de volgende vragen:
1. Ik wil 2 x vm's (allebei aardig belaste mysql servers) hier op laten draaien, op een encrypted partitie. Is dit erg nadelig voor de performance?
2. Volgens mij is dit nog een best aardig systeem (wel wat verouderd) en vroeg me af of jullie tips hebben welke onderdelen ik het beste kan upgraden. Geheugen staat sowieso op de planning, echter is er max 667mhz ondersteund. Zou er op 1 of andere manier toch nog 800mhz op kunnen draaien?
3. Ik twijfel om op dit systeem géén vmware te installeren, maar direct in te richten als 1 mysql server. Reden dat ik liever VM heb, is dat ik het makkelijk kan migreren naar een andere server indien nodig. Hoe kijken jullie hier naar?
Alvast bedankt voor jullie reacties
1. Ik wil 2 x vm's (allebei aardig belaste mysql servers) hier op laten draaien, op een encrypted partitie. Is dit erg nadelig voor de performance?
Encryptie maakt het nooit sneller, maar hangt van wat factoren af wat de impact is (o.a CPU). Wel gedaan maar nooit gemeten dus kan alleen maar uit theoretisch oogpunt gissen. Naar mijn weten gaat de DB in het RAM en daar is geen encryptie dus de impact blijft enigszins beperkt. Writes moeten vroeg of laat wel naar de disk, maar daar heb je de disk cache voor. Je kan de impact ook een beetje opvangen met DB caching.
Maar belangrijker: Staat de server in een Datacenter? Zo ja, niet doen. Staat het op een onveilige plek? Wel doen. Dat is verreweg belangrijker dan de vraag of het de boel vertraagt (imo). Lijkt mij als ik dit zo hoor dat het ding in een DC moet staan.
2. Volgens mij is dit nog een best aardig systeem (wel wat verouderd) en vroeg me af of jullie tips hebben welke onderdelen ik het beste kan upgraden. Geheugen staat sowieso op de planning, echter is er max 667mhz ondersteund. Zou er op 1 of andere manier toch nog 800mhz op kunnen draaien?
handleiding van de server/mobo er bij pakken en kijken...
3. Ik twijfel om op dit systeem géén vmware te installeren, maar direct in te richten als 1 mysql server. Reden dat ik liever VM heb, is dat ik het makkelijk kan migreren naar een andere server indien nodig. Hoe kijken jullie hier naar?
Als het alleen om 2 MySQL servers gaat zou ik het niet doen. VM vertraagt queries en het migreren van een DB is niet moeilijk. Als je er nou redundantie voor terug zou krijgen, zou het nog wat opleveren. Maar dat lijkt niet het geval hier. Je kan ook naar OpenVZ kijken. Heb je niet de performanceproblemen maar wel de voordelen van virtualisatie.
Meer nog, ondanks dat het iets ouder is, kan dit systeem prima als DB server dienen. De IO lijkt me goed gecovered te zijn, en een iets meer ram gaat hier een mooie DB machine van maken.
CeeReM.com
13/08/11, 21:40
1. Bedankt voor je reactie. Hij staat inderdaad in een datacenter. Echter wel een gedeeld rack, alhoewel de plannen zijn een geheel rack te betreden binnen een half jaar.
2. Dan blijft het bij 667 :).
@ wonko, het is idd een leuke server. Helaas piept hij nu omdat 2 hds kapot zijn, zit te wachten op de nieuwe onderdelen.
1. Bedankt voor je reactie. Hij staat inderdaad in een datacenter. Echter wel een gedeeld rack, alhoewel de plannen zijn een geheel rack te betreden binnen een half jaar.
Dan moet je meer inzitten met Men in The Middle dan dat iemand er met je hd's/server vandoor loopt. Maar cruciale data/informatie zou ik enkel de records encrypten en niet je volledige partitie/hd. Naast het feit dat het veiliger wordt, is het dan bijna onmogelijk om nog een partitie/hd recovery uit te voeren (logisch want dat is juist het nut van encryptie), maar je zal dan net een paar sectors hebben die op die partitie/hd kapot zijn en heel de dataset kan beschadigd zijn. En vanaf dat je een backup ergens anders bewaard moet je die dan ook op een encrypted partitie zetten want anders gaat het nut verloren. Veel hangt natuurlijk af van welke type data het is uiteraard.
SebastiaanStok
14/08/11, 11:31
Een database wil je liever niet in VM draaien.
Tenzij de virtual harddisk direct is gekoppeld aan de hardware zelf.
Hoeveelheid ram is afhankelijk van de hoeveelheid data die je uiteindelijk gaat gebruiken.
En dan niet alleen het eindresultaat, maar ook wat nodig is voor sorteren, etc.
Een simpele query: SELECT username FROM users ORDER BY id ASC LIMIT 0,20
Lijkt misschien klein, maar als in de tabel 100.000 records staan moet hij die eerst allemaal uitlezen, sorteren en dan weer een limiet op uitvoeren!
Als dit in het geheugen past is het zo gedaan, maar als er te weinig ruimte is dan schrijft de database dit tijdelijk naar de disk.
En dat gaat voor vele acties echt een impact geven.
Het beste wat je kunt doen om dit voorkomen is, de query's zo optimaal schrijven.
Iemand heeft ooit een trucje uitgelegd hoe je indexen kan afdwingen bij een ORDER BY (iets met WHERE) (kijk of ik die nog kan vinden).
En vooral, blijft monitoren. Een query is nooit optimaal in één keer. Index kunnen in de toekomst nodig zijn/of juist beter worden verwijderd (te weinig gebruikt en kosten te veel tijd). Of een query moet worden herschreven omdat deze te langzaam is, en in uiterste gevallen moet je zelfs gaan de-normaliseren (pas in heeeeeeeel uiterste gevallen, 150 TB aan data die alleen zo groot is omdat het is gescheiden).
"1 x IOSASB70 IO ARECA RAID BATTERY BACKUP UNIT"
Bij PostgreSQL wordt altijd gebruik gemaakt van WAL (write ahead log), deze is nodig voor succesvolle recovery.
Maar heeft als nadeel dat voor elke actie deze eerst moeten worden gelogd, en dan pas wordt uitgevoerd.
Als je disk een batterij back-up heeft (of lees ik het nu verkeerd?), kan je deze WAL uitschakelen.
Want de data wordt altijd weggeschreven vanuit de buffer, dus is het veilig om dit te doen.
En je wint enorm aan snelheid.
Ik weet niet of MySQL InoDB/Falcon de mogelijkheid hebt om dit in te stellen, MyISAM niet (die gebruikt geen WAL).
Maar als het er is, zou ik het zeker aanraden (mitst je goede back-ups maakt uiteraard).
Voor de encryptie.
Het beste is om alleen de data die 'gevoelig' is te versleutelen.
MySQL bied hier zelf al functionaliteit voor, en heeft als voordeel dat je database zelf kan decrypten en dus de records weer kan gebruiken.
http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html
https://www.postgresqlconference.org/content/achieve-pci-compliance-postgresql (gaat over PostgreSQL maar kan ook worden gebruikt voor MySQL).
En tot slot.
Meestal is de hardware niet het probleem, maar dat de software verkeerd is ingesteld.
Er is geen silver bullet die altijd werkt, test, optimaliseer, en herhaal.
http://www.cs.ait.ac.th/laboratory/database/manual/manual_MySQL_Optimization.shtml
http://dev.mysql.com/tech-resources/presentations/presentation-oscon2000-20000719/
Split databases and tables over different disks. In MySQL you can use symbolic links for this.
Wat ik hier mis, gebruik voor indexen kleine disk omdat die sneller zijn.
En http://dev.mysql.com/doc/refman/5.1/en/partitioning-subpartitions.html
Wat erg handig is voor vele records die als groep kunnen worden gezien (10.000 records van één jaar).
DOE NOOIT MET EEN TRIGGER EEN NIEUWE TABEL AANMAKEN. Hiermee loopt namelijk je database in een dead-lock.
Maak de nieuwe tabel ruim vooraf aan, en doe eventueel controleren. (Kan automatisch).
Hopelijk kan je hier iets mee :)
Je kunt het beste even een paar uur besteden aan Googlen over dit onderwerp, zodat je wat goede input krijgt van echte MySQL-experts, dat zullen de meesten van ons niet zijn. Bijvoorbeeld via serverfault.com, forums.mysql.com, dbforums.com en via chat #mysql (600-700 mensen aanwezig) op irc.freenode.net zul je zeker meer goed advies kunnen krijgen.
Encryptie zou ik niet doen voor MySQL, maar overweeg eens MySQL networking te doen op een private network in een 192.168.1.x. Op die manier kunnen alle servers in het rack erbij en hoeft de MySQL server niet eens bereikbaar te zijn vanaf het web. Dit zou eventueel met een publiek IP kunnen en een firewall, maar waarom zou je back-up- en mysql-servers een publiek IP willen geven.
Verder weet ik niet heel veel van het optimaliseren van MySQL performance. Je hoort vaak dat indexen en de queries veel belangrijker zijn dat de optimalisatie van de server zelf. Daarbij zou ik ook zeker goedkoop een paar GB extra geheugen op de kop proberen te slaan.
Normaliter zou ik iedereen aanraden om virtuele machines te draaien, ondanks dat ik nog steeds mensen onterecht te pas en te onpas hoor roepen dat virtualisatie slecht is voor performance. Maar indien je slechts 2/meerdere database servers zou draaien, kun je overwegen om te gaan voor MySQL-multi (aparte MySQL server instanties). Dan is er weinig reden om over te gaan op virtualisatie. Dat kan voor database servers alleen maar een negatieve impact hebben.
Lees de volgende pagina ook even door http://www.serverfocus.org/top-100-mysql-optimization-tips. Dingen zoals slow_query log zullen je erg kunnen helpen. Zeker indien je op elke pagina een query hebt die bijna een volledige seconde duurt, is dat meestal makkelijk te verhelpen door een paar indices of het herschrijven van de query.
Je moederbord lijkt trouwens geen 800mhz geheugen te ondersteunen.
• Up to 48GB 667/533MHZ DDR2 ECCC Register SDRAM
SebastiaanStok
14/08/11, 13:35
Over indexen moet je niet te licht denken.
Dit is de grootste fout die men kan maken (naast varchar() voor datums).
"Indexes aren't a magical performance fairy dust. "
http://archives.postgresql.org/pgsql-performance/2011-03/msg00336.php
Index is bedoeld om dingen snel te vinden, maar alleen omdat een index bestaat wil dat niet zeggen dat hij daadwerkelijk wordt gebruikt.
Alleen als de query planner vind dat het zinvol is gebruikt hij de index, als een tabel scan (sequential scan) sneller is (omdat het aantal records laag is) dan gebruikt hij dat ondanks dat er een index aanwezig is.
Of als een index op meerdere velden is en hij alleen één veld nodig heeft wil hem ook nog wel is overslaan omdat de index te groot is voor gebruik. (niet altijd overigens)
Anderzijds, als de combinatie juist is, heeft juist weer een positief effect. 100% index usage altijd is een Utopia, en komt vrijwel niet voor.
Indexen gebruiken en dan hopen dat het goed gaat, is doodzonde, indexen moeten worden bijgehouden en dat kost ook tijd.
Daarom is het soms zelfs verstandiger om indexen te verwijderen als ze niet worden gebruikt.
Maar het juiste gebruik uitleggen, dat is een ander verhaal, niet iedere query is het zelfde.
Iets dat één voorbeeld uitstekend werkt, loopt in een ander geval compleet in de soep.
http://odetocode.com/code/237.aspx
http://www.simple-talk.com/sql/learn-sql-server/sql-server-index-basics/
Er zijn tal boeken over High Performance MySQL geschreven, en tal van andere boeken over SQL performance algemeen.
Want echt doorgronden hoe een Query planner werkt, en hoe dat jouw applicatie gaat beïnvloeden kan ik niet in één reactie uitleggen :) (en mijn kennis reikt ook niet zover).
En zoals ik al zij, test, optimaliseer, en herhaal.
@Dennis: Bedankt voor de link.
Ik neem aan dat je twee hotspares hebt ? Raid10 met 5 schijven kan niet.
CeeReM.com
14/08/11, 15:42
@ mikey, Ik vergis me, het zijn 5 schijven waarvan 1 hotspare :) Overigens zijn er 2 kapot en draait het systeem nu dus op 3 schijven, wat eigenlijk wel gek is. Overal lees ik dat je er minimaal 4 schijven nodig zijn voor een werkende raid 10 array?
Overal lees ik dat je er minimaal 4 schijven nodig zijn voor een werkende raid 10 array?
Klopt maar nu zit je op een degraded array en theoretisch gezien kan je bij raid 10 50% van de hd's verliezen. Het is te zeggen, zolang er geen 2 hd's zijn die zelfde mirrored info hebben die kapot zijn.
Maar dan nog kun je geen raid10 maken met 5 schijven en 1 hotspare.
Maar dan nog kun je geen raid10 maken met 5 schijven en 1 hotspare.
CeeReM.com zegt 4 hd's voor raid 10 + 1 hd voor hotspare in totaal 5 hd's dus.
CeeReM.com zegt 4 hd's voor raid 10 + 1 hd voor hotspare in totaal 5 hd's dus.
Openingspost zegt:
6 x HD 36 GB SEAGATE SAVVIO SAS 15K 3Gb raid 10 (waarvan 1 hot spare!)
Zou dus moeten zijn:
6 x HD 36 GB SEAGATE SAVVIO SAS 15K 3Gb raid 10 (waarvan 2 hot spare!)
Of:
6 x HD 36 GB SEAGATE SAVVIO SAS 15K 3Gb raid 10 (geen hot spare!)
Openingspost zegt:
6 x HD 36 GB SEAGATE SAVVIO SAS 15K 3Gb raid 10 (waarvan 1 hot spare!)
Zou dus moeten zijn:
6 x HD 36 GB SEAGATE SAVVIO SAS 15K 3Gb raid 10 (waarvan 2 hot spare!)
Of:
6 x HD 36 GB SEAGATE SAVVIO SAS 15K 3Gb raid 10 (geen hot spare!)
@ mikey, Ik vergis me, het zijn 5 schijven waarvan 1 hotspare :) Overigens zijn er 2 kapot en draait het systeem nu dus op 3 schijven, wat eigenlijk wel gek is. Overal lees ik dat je er minimaal 4 schijven nodig zijn voor een werkende raid 10 array?
Je moet niet enkel de OP lezen he ;)
CeeReM.com
15/08/11, 00:01
haha :) - @Dennis en @Rollerscapes bedankt voor de uitgebreide reacties, ik reageer morgen nog even inhoudelijk!
als er nu 2 kapotte hds in zitten, heb je best kans dat de rest ook snel stuk gaat. Als je de server gaat gebruiken voor productie zou ik ze snel vervangen (kijk dan gelijk eens naar ssd, dat vind mysql ook erg lekker, let wel op trim en raid combinaties)
SebastiaanStok
18/08/11, 09:22
Weet je heel zeker dat MySQL juist met ssd omgaat?
Ik heb gehoord dat sommige DB's hier nog moeite mee hebben omdat ze de snelheid niet goed kunnen bepalen en dan een verkeerd query plan maken.
Vooral het gebruik van indexes op ssd kan onverwachte resultaten geven.
Een database wil je liever niet in VM draaien.
Wat een ouderwetse gedachte. Tegenwoordig kun je op een goede (!!) VM vrijwel alles draaien. Ook hele drukke DB servers. De overhead is nihil en de voordelen zijn groot.
Weet je heel zeker dat MySQL juist met ssd omgaat?
Ik heb gehoord dat sommige DB's hier nog moeite mee hebben omdat ze de snelheid niet goed kunnen bepalen en dan een verkeerd query plan maken.
Vooral het gebruik van indexes op ssd kan onverwachte resultaten geven.
"ik heb gehoord" dat jij 2 vriendinnetjes tegelijk hebt... ;)
Ik heb gehoord in IT heeft geen tot nauwelijks waarde zonder enige onderbouwing......
SebastiaanStok
18/08/11, 13:31
Sh*t, betrapt :whistling:
Nee serieus, ik heb dit gehoord van iemand die zelf DBA is en grote database systemen onderhoud.
Zoals ik al zij 'sommige DB's', het werkt wel maar je kan onverwachte resultaten krijgen als de index op een SSD staat (omdat die niet zo groot hoeven te zijn).
De query planner denkt dat de index op normale disk staat en daardoor hem als 'langzamer' bestempeld dan de SSD daadwerkelijk is.
Omdat hij een langzame verwacht en in werkelijkheid heel snel is, gaat z'n hele plan anders uitpakken.
En let vooral op 'sommige', ik zeg niet dat dit voor MySQL ook zo is.
Vandaar ik vraag 'Weet je heel zeker dat MySQL juist met ssd omgaat?'.
http://www.pfz.nl/archief/1326160-postgresql-vs-mysql/ (sorry van de titel)
Een SSD voor databases, da's apart, PgSQL heeft een intens lange discussie gehad over bijzonder gedrag van PgSQL op een SSD, de bizar-korte seektijden brachten de queryplanner van streek. Hebben jullie daar nog een RAID aan gehangen en hoe ga je om met het garbage-cleanen en de leeftijd van de SSD ivm het hoge aantal fsyncs?
Ik weet niet in hoeverre de queryplanner borkt als de seektijden van de index zo laag worden. Het zal wel niet zoveel uitmaken, maar als je toch geld gaat uitgeven dan zou ik de SSD gebruiken voor datgene waar je disk-doorvoer-bottleneck zit en dat is niet de laadtijd van de index.
Maar, ook SSD is niet onfeilbaar dis ook daar zou je RAID moeten toepassen en dan loopt het voor 160GB al aardig in de papieren,. met terabyte SSD's tegen 9000 euro is het nog geen optie, een dikke RAID array met BBU kun je voor een fractie van de prijs opzetten en dat performt niet eens zo gek veel slechter.
Nu zit er wel een verschil in PostgreSQL en MySQL, maar de werking van een query-planner verschild niet veel van elkaar.
Tegenwoordig kun je op een goede (!!) VM vrijwel alles draaien. Ook hele drukke DB servers. De overhead is nihil en de voordelen zijn groot.
Een bekend probleem van VM is de disk container, het host OS moet deze als bestand wegschrijven waardoor er een snelheidsvermindering optreed.
Als de disk direct is gekoppeld aan de hardware heb je dit probleem inderdaad niet meer.
Een database wil je liever niet in VM draaien.
Tenzij de virtual harddisk direct is gekoppeld aan de hardware zelf.
Nog een ander probleem is dat de disk-controller aangeeft dat de data is weggeschreven, maar in werkelijkheid nog in de cache van het host zit.
Transactionele storage engines kunnen hierdoor last krijgen van data corruptie bij een crash van de host, dit was vroeger te minste zo.
Ik weet niet of dit inmiddels al verbeterd is?
Even snel met Google gezocht en kwam dit topic tegen bij onze Amerikaanse vrienden :) (nog niet helemaal gelezen overigens, even geen tijd).
http://www.webhostingtalk.com/showthread.php?t=1053550
En http://www.slideshare.net/gslin/mysql-and-ssd-presentation-567083 (twee jaar oud).
De ontwikkelingen van SSD zijn de laatste paar jaren enorm versneld, dat ik ze niet meer kan bijhouden, dus ik kan het fout hebben.