[MySQL] Welke server ?

[ArjanC]

Hoi,

en ja ik heb de search al gebruikt maar geen goeie informatie kunnen vinden. (of ik zoek niet goed?)

maarok. Ik heb hier een database server staan (MySQL) die op dit moment wel heeeel erg traag is (Compaq Proliant 2500 Ppro 200 (dual) 392Mb Ram).
er staan nu 200.000 records in. (zijn verzonden/ontvangen faxen)

nu zijn deze records van 1 jaar. wij moeten ze 5 jaar bewaren. het is jammergenoeg niet mogelijk om het in jaren te splitsen (kan het pakket niet aan).

als ik nu in deze records iets zoek dan is hij makkelijk een minuut bezig met zoeken.. ik zou dit dus willen versnellen.

wat ik al heb gedaan is een 2de cpu en nog 64mb erbij wat ik had liggen (ECC) maar hij is er eigelijk niet sneller (3sec) op geworden.

het probleem is dat nu alleen mijn faxen hierin staan maar uiteindelijk is het de bedoeling om heel europa erin te zetten, dat zijn zo'n 300.000 extra records per jaar. (dus 500.000 records per jaar)

Wat voor server moet ik daar voor neerzetten ? en kan MySQL wel een Dual Proc aan ? het probleem is dat wij alleen Microsoft windows 2000 server mogen gebruiken dus geen Linux.

[Verwijderd]

200.000 records is natuurlijk niks, waarschijnlijk heb je een index probleem,
is dat een eigen gemaakte applicatie?

Kan je idd een query laten zien hier ?

[ Voor 17% gewijzigd door Verwijderd op 22-08-2003 09:59 ]

[djluc]

Hoe worden die gegevens er uit getoverd? Met welke query's. Mysql is vooral heel erg snel in eenvoudige query's, dus probeer niet met te ingewikkelde joins te werken.

[ArjanC]

de meeste query's zijn in de vorm van Select * from Tblsentfaxes where username ="bla" and servername="D1RTM300"

vrij simpel.. als ik deze query doe dan is hij 36 seconden bezig.

[supakeen]

Ik hoop dat je ook weet dat je een index in je tabel moet hebben en nooit * moet gebruiken maar alleen de velden die je nodig hebt.

[ArjanC]

Hmm.. index ?

jah, ik moet 19 van de 20 velden hebben.

[Erkens]

burp2001 schreef op 22 August 2003 @ 10:05:
Hmm.. index ?

jah, ik moet 19 van de 20 velden hebben.

en je hebt ook altijd alle records nodig van een bepaalde user?

[ArjanC]

jah, hij toont een lijst op scherm (velden zijn vrij simpel meestal een x, 1 ,2,3 ofzo) dan kunnen hun uit de lijst selecteeren welke fax zij willen opvragen.

[Kix@$$]

Ik hoop alleen niet dat je idd bovenstaande query hebt en dus op tekst gaat zoeken in een database, want dit duurt inderdaad lang. Normaal zoek je in ieder geval altijd op getallen omdat dit veel en dan ook echt veel sneller gaat (Bijvoorbeeld op User_ID i.p.v. Username). Maar 36 sec. vind ik wel erg lang.

Als ik jou was zou ik inderdaad eens kijken naar indexes maken op de database. Deze moet je maken op de velden waar je (vaak) op zoekt.
Meer informatie: http://www.mysql.com/doc/en/MySQL_indexes.html

[ Voor 17% gewijzigd door Kix@$$ op 22-08-2003 10:10 ]

[ATS]

Je bedoelt dat je geen index hebt? Een index is een zoek opzoektabel die het zoeken in je data veel sneller maakt. Ze kosten echter wel ruimte en tijd om aan te maken als je data wijzigd of toevoegd. Als je vaak zoekt op afzender en servernaam, dan is het handig om op die velden een index toe te voegen.

[MBV]

met phpmyadmin kan je indexen maken op bepaalde kolommen. als al je searches gaan over username en servername, dan moet je daar indexen op aanleggen. Een index is een klein bestandje waar de server sneller doorheen kan zoeken dan door de hele database.

Heb je al de bottleneck geprobeerd te zoeken? Is dit probleem niet opgelost met een snellere harde schijf, of is je CPU load 100%?

edit:
waarom is 150 aanslagen/min nog steeds niet genoeg?

[ Voor 11% gewijzigd door MBV op 22-08-2003 10:14 ]

[ArjanC]

Elke werkdag worden er tussen de 1000 en 2000 records toegevoegd.
maakt dat het instellen van indexen dan moeilijker ?

maar jullie denken dat dat ouwe beesie het wel aankan ?

[hennink]

Als dit snel wilt gebruiken moet je even phpmyadmin op je bak zetten.
Vanuit daar ga je naar de bewuste database, klikt op je tabel en dan doe je het volgende.
Create an index on 2(dit vul je in) columns
Vervolgens selecteer je username en servername en mysql creert de index voor je.
Als SQL query kan je het zo doen:
ALTER TABLE `Tblsentfaxes` ADD INDEX ( `username` , `servername` )

Meer omtrent de werking van een B-TREE vind je hier:
http://www.semaphorecorp.com/btp/algo.html
Deze structuur gebruikt MySQL ook voor je index

Hardware antwoord: Kijk eens naar een appro

[ Voor 15% gewijzigd door hennink op 22-08-2003 10:17 ]

[hennink]

Index stel je maar een keer in , 1000 tot 2000 inserts moet zelfs jouw machine nog om lachen

[ArjanC]

De server heeft een Raid 5 configuratie met 4x 4,7Gb SCSI 10k RPM hdd's. 2x Pentium Pro 200Mhz en 392Mb Ram.
als ik een query uitoefen dan staat hij de volle 36 seconden op 100% .

[Kix@$$]

burp2001 schreef op 22 August 2003 @ 10:12:
Elke werkdag worden er tussen de 1000 en 2000 records toegevoegd.
maakt dat het instellen van indexen dan moeilijker ?

Nee hoor, MySQL update zelf zijn indexes als jij een nieuw record toevoegd. Je moet alleen wel eerst een index aangemaakt hebben.

Maak ook geen index aan op alle velden want dan wordt het invoegen traag en wordt je index bestand heel groot. Maak ze alleen aan op de velden waar je echt op zoekt. (Zie commando CREATE INDEX)

maar jullie denken dat dat ouwe beesie het wel aankan ?

Ja hoor, makkelijk. Een database trekt (normaliter) niet eens zoveel uit een pc. MS SQL Server draait bijvoorbeeld zelfs op 16 MB geheugen op een 133 Mhz systeem.

[MBV]

staat hij bij allebei de proc's op 100%, of maar bij 1? Als het bij allebei op 100% is, dan weet je dat MySQL dualproc ondersteund. Als het maar bij 1 proc 100% is, dan ondersteund MySQL zoals je hem daar hebt lopen dat niet. OC'en?

[Kix@$$]

MBV schreef op 22 August 2003 @ 10:18:
staat hij bij allebei de proc's op 100%, of maar bij 1? Als het bij allebei op 100% is, dan weet je dat MySQL dualproc ondersteund. Als het maar bij 1 proc 100% is, dan ondersteund MySQL zoals je hem daar hebt lopen dat niet. OC'en?

Mja volgens mij maakt DUAL-proc toch niet zoveel uit om die 36 sec te veranderen. Het maakt alleen uit als hij echt verschillende queries tegelijkertijd moet verwerken.

[ArjanC]

ik ben gevraagt om te kijken welke server goed genoeg zou zijn voor deze Database. daarom zou ik wel willen weten of hij Dual Xeon zou ondersteunen..

[Sybr_E-N]

Ik zou er eerst maar eens voor zorgen dat je database zelf goed genormaliseerd is voordat je van hardware gaat wisselen. Je kunt wel gaan investeren in nieuwe hardware maar de performance winst die je gaat boeken is minimaal.

[Kix@$$]

burp2001 schreef op 22 August 2003 @ 10:27:
ik ben gevraagt om te kijken welke server goed genoeg zou zijn voor deze Database. daarom zou ik wel willen weten of hij Dual Xeon zou ondersteunen..

Zoiets dus? http://forums.devshed.com/t30986/s.html

Ik heb nergens gevonden dat hij het aan zou kunnen maar ook nergens dat hij het niet aan zou kunnen.
Maar als je wilt kijken welke server goed genoeg is voor jou database, volgens mij heb je dan al een goede server. Alleen even je indexes aanmaken en klaar, en opzich is dat 5 min. werk ofzo.

Voor de rest ben ik het met Sybr_E-N eens.

[ Voor 4% gewijzigd door Kix@$$ op 22-08-2003 10:39 ]

[ArjanC]

hennink schreef op 22 August 2003 @ 10:14:
Als dit snel wilt gebruiken moet je even phpmyadmin op je bak zetten.
Vanuit daar ga je naar de bewuste database, klikt op je tabel en dan doe je het volgende.
Create an index on 2(dit vul je in) columns
Vervolgens selecteer je username en servername en mysql creert de index voor je.
Als SQL query kan je het zo doen:
ALTER TABLE `Tblsentfaxes` ADD INDEX ( `username` , `servername` )

Meer omtrent de werking van een B-TREE vind je hier:
http://www.semaphorecorp.com/btp/algo.html
Deze structuur gebruikt MySQL ook voor je index

Hardware antwoord: Kijk eens naar een appro

Ow, ik ben totaal niet bekent met PHP en op onze server staat ook geen PHP geinstalleert (wij gebruiken ASP).

om de databases te maken enz. gebruik ik Navicat.

[ArjanC]

Kix@$$ schreef op 22 August 2003 @ 10:39:
[...]

Zoiets dus? http://forums.devshed.com/t30986/s.html

Ik heb nergens gevonden dat hij het aan zou kunnen maar ook nergens dat hij het niet aan zou kunnen.
Maar als je wilt kijken welke server goed genoeg is voor jou database, volgens mij heb je dan al een goede server. Alleen even je indexes aanmaken en klaar, en opzich is dat 5 min. werk ofzo.

Voor de rest ben ik het met Sybr_E-N eens.

ik ben nu aan het kijken naar indexen, iemand bekent met Navicat

[Kix@$$]

burp2001 schreef op 22 August 2003 @ 10:39:
[...]


Ow, ik ben totaal niet bekent met PHP en op onze server staat ook geen PHP geinstalleert (wij gebruiken ASP).

om de databases te maken enz. gebruik ik Navicat.

Als je in Navicat direct SQL statements kunt executen dan kun je daarmee je indexes maken.
Zoek op de MySQL website maar eens op CREATE INDEX. Is 5 min. werk en niet eens zo moeilijk.

[Verwijderd]

burp2001 schreef op 22 August 2003 @ 10:39:
[...]
Ow, ik ben totaal niet bekent met PHP en op onze server staat ook geen PHP geinstalleert (wij gebruiken ASP).
om de databases te maken enz. gebruik ik Navicat.

Kan je in dat "navicat" geen index overzicht (en dan ff van die tabellen die je gebruikt in je bovenstaande query) maken, en dat hierzetten. Dan weten we
hier weer wat meer over je eventuele index probleem. Er is nog steeds niet
vastgesteld namelijk of je indexprobleem hebt ja of nee.

[hennink]

kerel,

neem toch aan dat je gewoon een query direct kan uitvoeren, of dit nu met een php schil gaat of direct op de db. Maakt voor MySQL geen ruk uit.

[Kix@$$]

Als je in navicat kijkt, in het Design Table scherm, heb je daar een tabblad met Indexes.
Daar kun je zo een index toevoegen. Geef hem een leuke naam (Bijvoorbeeld voor veld servername doe je dan idxServerName) en kies het veld erbij.

Doe daarna een save en klaar .

Je kan ook een nieuwe Query maken en daar de CREATE INDEX statement invoegen.

[ Voor 14% gewijzigd door Kix@$$ op 22-08-2003 10:53 ]

[ArjanC]

is dat alles ? (zit nu in een mySQL boek te kijken) maar moet ik dan in ASP iets veranderen in de Query ??

[Kix@$$]

burp2001 schreef op 22 August 2003 @ 10:54:
is dat alles ? (zit nu in een mySQL boek te kijken) maar moet ik dan in ASP iets veranderen in de Query ??

Voor zover ik navicat ken (Ik heb hem 3 min. geleden voor het eerst geinstalleerd) is dat alles inderdaad. In de queries hoef je niks te veranderen, MySQL gaat vanzelf in de Indexes zoeken.

[ Voor 12% gewijzigd door Kix@$$ op 22-08-2003 10:56 ]

[Verwijderd]

Wel frapant, hoe hier advies wordt gegeven om "even" een produktie (neem ik aan) database uit de losse hand aan te passen, zonder dat bekend is wat het precies probleem is.

"bezint eer ge begint"

- Stel eerst het probleem eens vast (misschien dat die indexen er wel al zijn) ?
- Zorg voor een backup als je database aanpassingen gaat maken.
(Je moet altijd snel terug kunnen gaan naar voorgaande situatie)

[ Voor 4% gewijzigd door Verwijderd op 22-08-2003 11:08 ]

[Kix@$$]

Verwijderd schreef op 22 August 2003 @ 11:08:
Wel frapant, hoe hier advies wordt gegeven om "even" een produktie (neem ik aan) database uit de losse hand aan te passen, zonder dat bekend is wat het precies probleem is.

"bezint eer ge begint"

- Stel eerst het probleem eens vast (misschien dat die indexen er wel al zijn) ?
- Zorg voor een backup als je database aanpassingen gaat maken.
(Je moet altijd snel terug kunnen gaan naar voorgaande situatie)

Aangezien TS niet wist wat Indexes zijn ga ik er vanuit dat ze er niet zijn, als ze er wel waren/zijn dan hoor ik dat vanzelf. En backup maken is inderdaad waar dat je dat moet doen, maar dat lijkt me logisch opzich, maar ik wast inderdaad vergeten in mijn post te zetten.

[ArjanC]

Ik had al een backup gemaakt en even het programma wat die database gebruikt even uitgezet

[hennink]

Ken weinig applicaties die door het toevoegen van een nieuwe index compleet over de zeik gaan.
Wellicht met deze code:
if(numberOfIndices() > 0)
exit(0);
}
else
{
gaVerder();
}

[MBV]

hennink schreef op 22 August 2003 @ 11:54:
Ken weinig applicaties die door het toevoegen van een nieuwe index compleet over de zeik gaan.
Wellicht met deze code:
if(numberOfIndices() > 0)
exit(0);
}
else
{
gaVerder();
}

Ik denk dat er weinig serieuze programmatuur rondzwerft die dat erin heeft staan. Of het moet een progje zijn dat de database helemaal zelf wil beheren. Is het van Microsoft?

[hennink]

En al wat geprobeerd?

[ArjanC]

Ik heb vandaag even tussen de wormen door tijd gehad voor de Db server

okee, dit is wat ik getest heb :

simpele Query

(Select * from Tblsentfaxes where Servername="<servername>"and Fullname="fullname")

indexing :

IdxServername = Servername
IdxServerandfullname = Servername, Fullname

tijden :

53000 records.
zonder Index 34 Sec.
met index 27 Sec.

de server staat dan constant op 50-55 % utilized en gebruikt ook de 2de CPU.

Dit moet sneller kunnen

[ Voor 16% gewijzigd door ArjanC op 25-08-2003 10:41 ]

[Verwijderd]

burp2001 schreef op 25 August 2003 @ 10:39:

Dit moet sneller kunnen

Zet 's een losse index op die FullName tabel, ik weet niet of MySql indexen combineert maar het lijkt mij sneller te gaan met 2 losse indexen.
(weet niet precies hoe de indexing werkt in mysql, maar in sommige db's is het
beter om bij dit soort bevragingen de indexen los dus per tabel te hebben).

Je zit nu dus op een kleine 2000 reads per seconde, op zich niet echt slecht voor zo'n ruime query.

BTW. Doe je die tests direct op de server , of over het netwerk heen ?
Hoe groot is 1 record ongeveer in bytes?

ps. Ik ga er even vanuit dat je een test omgeving hebt opgezet? Of in ieder geval zo'n situatie gecreeerd, dat testen/uitproberen geen invloed heeft op de productie omgeving.

[ Voor 80% gewijzigd door Verwijderd op 25-08-2003 11:09 ]

[_-= Erikje =-_]

Tsja, MySQL houd niet van tekst zoeken, mijn P166 met 96 mbyte ram doorzoekt het telefoonboek (6.1 miljoen records met een index op het telefoon nr) in een paar seconden. Zoek je op naam kun je koffie gaan doen.
Het lijkt mij dan het handigst om Servername & Fullname in apparte tabellen op te nemen en alleen op die id's te zoeken

[ArjanC]

het probleem is dat een programma de database vult. deze kan je niet veranderen dat hij de namen in een aparte tabel neerzet..

ik heb nu de indexen gesplit (zoals maui71 zei) en dan duurt het 33 sec

maar nu de Db niet sneller kan moeten we gaan kijken naar een andere Server.
wat kunnen jullie mij aanraden ? P4, Xeon, Dual Xeon ?

[Verwijderd]

burp2001 schreef op 25 August 2003 @ 11:09:
het probleem is dat een programma de database vult. deze kan je niet veranderen dat hij de namen in een aparte tabel neerzet..

ik heb nu de indexen gesplit (zoals maui71 zei) en dan duurt het 33 sec

maar nu de Db niet sneller kan moeten we gaan kijken naar een andere Server.
wat kunnen jullie mij aanraden ? P4, Xeon, Dual Xeon ?

Die ene seconde is te verwaarlozen denk ik.

Die query voer je die uit op de server, of op een client?

Wat is je gemiddelde record grootte?
Wat voor netwerkverbinding ligt er ? (indien op client).

[ArjanC]

de query voer ik uit via een web server. (andere server)

Hmm. hoe kan je zien wat de gemiddelde record grote is ?

100Mb op een Switched netwerk..

[Yoeri]

offtopic:
nieuws: Overheid introduceert handleiding tegen cybercriminaliteit

dit was nu net wat ik bedoelde met mijn reactie... bedrijven vragen snel ff iemand die wel wat van computers kent om hun computerpark te regelen, en schrikken dan als er iets misgaat...
no flame intended, maar hoe kun je nu iemand aanstellen om te checken welke server voldoet voor een productiedatabase, die nog nooit van indexen gehoord heeft

Gezien de problemen waar je mee kampt, en je eigen kennis (zoals je zelf aangeeft uiterst beperkt) is mijn advies dan ook om iets of wat professionelere hulp te gaan zoeken. Mijns inziens het enige realistische, serieuze advies dat hier van toepassing kan zijn.

Directeur: Kun je me ff die kost van xxx euro verklaren?
Burp: Wel, die van tweakers zeiden dat het moest.

[ Voor 37% gewijzigd door Yoeri op 25-08-2003 11:24 ]

[Verwijderd]

burp2001 schreef op 25 August 2003 @ 11:14:
de query voer ik uit via een web server. (andere server)

Hmm. hoe kan je zien wat de gemiddelde record grote is ?

100Mb op een Switched netwerk..

hm, zou ik zo 123 ook niet weten in mysql, maar je kan het toch ongeveer bepalen aan de hand v/d record indeling (tabel structuur).

Probeer diezelfde query is direct op de Server te doen, en kijk dan ;s hoelang ie er over doet.

[ArjanC]

Robbedoeske schreef op 25 August 2003 @ 11:19:

offtopic:
nieuws: Overheid introduceert handleiding tegen cybercriminaliteit

dit was nu net wat ik bedoelde met mijn reactie... bedrijven vragen snel ff iemand die wel wat van computers kent om hun computerpark te regelen, en schrikken dan als er iets misgaat...
no flame intended, maar hoe kun je nu iemand aanstellen om te checken welke server voldoet, die nog nooit van indexen gehoord heeft

ben pas sinds kort met MySQL bezig. omdat de economie zo lekker loopt krijgen we ook geen cursussen., daarom moeten we alles met boeken en internet doen.

weet je ook gelijk waarom ik niks van indexing af weet.

maar is het zo'n rare vraag ? welke server heb ik hiervoor nodig ?
het is niet dat ik hier even een paar servers heb liggen om te testen.. (jammergenoeg niet)

daarom vraag ik deze vraag op tweakers (daar zitten de mensen die het wel weten) en verdomd ik heb weer wat geleert !

Directeur: Kun je me ff die kost van xxx euro verklaren?
Burp: Wel, die van tweakers zeiden dat het moest.

het gaat erom dat mij gevraagt is om het programma wat sneller te laten lopen zodat mensen er ook gebruik van kunnen maken zonder te schelden.

[ Voor 13% gewijzigd door ArjanC op 25-08-2003 11:29 ]

[Verwijderd]

burp2001 schreef op 25 August 2003 @ 11:26:

Hardware updaten is niet altijd de oplossing, soms ligt het probleem ergens anders en kan je hardware blijven kopen. Plus de bijkomende kosten voor nieuwe hardware , migratie van applicaties en databases kosten ook tijd en geld. Neem de daarbij behorende backup/rollback voorzieningen die migraties met zich meebrengen mee, en de prijs van nieuwe hardware kan je met een factor 3 vermenigvuldigen.
Dus eerst het echte probleem 100% vaststellen voor je het kunt gaan oplossen.

[ArjanC]

Verwijderd schreef op 25 August 2003 @ 11:29:
[...]


Hardware updaten is niet altijd de oplossing, soms ligt het probleem ergens anders en kan je hardware blijven kopen. Plus de bijkomende kosten voor nieuwe hardware , migratie van applicaties en databases kosten ook tijd en geld. Neem de daarbij behorende backup/rollback voorzieningen die migraties met zich meebrengen mee, en de prijs van nieuwe hardware kan je met een factor 3 vermenigvuldigen.
Dus eerst het echte probleem 100% vaststellen voor je het kunt gaan oplossen.

en daarom ben ik ook zo blij dat jullie mij op het gebruik van indexen hebben gewezen. dit scheelt toch ook al weer een aantal seconden.

maar jammergenoeg is het niet mogelijk om het programma wat de database beschrijft te veranderen.

[Verwijderd]

burp2001 schreef op 25 augustus 2003 @ 11:32:
[...]
en daarom ben ik ook zo blij dat jullie mij op het gebruik van indexen hebben gewezen. dit scheelt toch ook al weer een aantal seconden.

maar jammergenoeg is het niet mogelijk om het programma wat de database beschrijft te veranderen.

Kan je die query 's ff op de server uitvoeren, en kijken of het dan sneller is dan op de client (webserver in jouw geval).

Op die manier kan je bepalen of het aan de server ligt, of aan de doorvoersnelheid van machine/netwerk. (omdat de machine maar 50% belast is, als ie de query uitvoert).
En meet eventueel daarnaast (indien mogelijk) de rauwe doorvoersnelheid van het netwerk vanaf die sql server machine naar de webserver.

Al die getallen moet je ff verzamelen en op basis daarvan kan je kijken wat er moet gebeuren.

[ Voor 17% gewijzigd door Verwijderd op 25-08-2003 11:37 ]

[Gomez12]

Ff vraagje tussendoor, moet de data realtime zijn, anders zou ik er eens naar gaan kijken om eens in de zoveel tijd een zooi hulptabellen aan te gaan maken. Omdat je praat over records met een historie van 5 jaar. Met een historie van 5 jaar hoeft het volgens mij niet helemaal realtime meer te zijn.

Gewoon een cronjobje aanmaken wat eens in het uur enkele hulptabellen bijwerkt zodat je queries op getallen kunnen draaien ipv tekst. Als je hier dan een index overheen gooit moet het wel significant sneller gaan.

Vb. Op een 400 Mhz. Celeron heb ik in 0,1 sec een aantal records gevonden in 9.000.000 records door goede hulptabellen aan te maken.

[hennink]

Gooi eens een dump van je tabelstructuur erbij, ben erg benieuwd.

wat betreft je hardware, of je nu een ferrari wilt kopen of in je maxima QX wilt blijven rondkarren. Zolang je ze zonder verlichting over een pikdonker veld laat rijden met overal kuilen erin , tja. Vul zelf maar in