Onderwerp: Advies nodig voor juiste setup van Mysql server. Hardware heb ik al.

Hallo,

Ik heb een server met de volgende specs:

1 x SUPERM X7DCU XEON 5100 (http://www.supermicro.com/products/m...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.

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.

Oorspronkelijk geplaatst door CeeReM.com

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.

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/...functions.html
https://www.postgresqlconference.org...nce-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/d...mization.shtml
http://dev.mysql.com/tech-resources/...2000-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/...artitions.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-m...imization-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

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...3/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...-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.

@ 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?

Oorspronkelijk geplaatst door CeeReM.com

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.

Oorspronkelijk geplaatst door Mikey

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.

Oorspronkelijk geplaatst door The-BosS

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!)

Oorspronkelijk geplaatst door Mikey

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!)

Oorspronkelijk geplaatst door CeeReM.com

@ 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