Foondump --> mysql versnellen

#1

rgj: mijn gebruikersid is gewijzigd van rjg naar none

mysql-create.sql gebruik je om de tabellen in mysql te maken.
Hierbij worden ook meteen de indexen aangemaakt.

Elk record wat foondump toevoegd moet gecontroleerd worden op de indexen. Dit kost tijd.

Het is slimmer om in mysq-create.sql alleen de tabellen aan te maken (en een eventuele index die nodig is voor foondump).

Als foondump klaar is kan je dan met bv mysql-create-index.sql de indexen erop zetten. (dit kan natuurlijk ook in fs2002.php).

Volgens mij kan foondump (afhankelijk van de hardware ) 5 to 20 uur sneller worden.
:smiley:

#2

Hoi None,

Volgens mij kan foondump (afhankelijk van de hardware ) 5 to 20 uur sneller worden.

Wessel heeft dit ook al eens aangekaart. Ik heb wel een mail hierover. Als ik wat meer tijd heb zoek ik het voor je op.

Wat ook een belangrijk punt is dat sommige mensen super computer deskundige zijn (misschien happy few) maar ook end user zijn die bij wijze van spreken hun pc nog niet kunnen opstarten.

Je kan beter iets maken wat werkt voor iedereen en dat wat meer tijd kost dan iest wat super snel werkt en waarbij we een volle forum krijgen met vragen. Ik kan mij het windows98 probleem bij vorige foondump versie nog goed herinneren, dat heeft als onbedoeld veel tijd gekost.

De vriendelijke groet Jan Marco

#3

Hier heb ik het inderdaad al eens met Wessel over gehad. Wessel had de source en jij niet, dus ik vermeld er nog even bij dat Foondump momenteel al batched inserts in blokken van 1000 gebruikt. Dat neemt de meeste pijn mbt het bijwerken van de indices weg.

Even in mijn Sent Items gespit:

Wel heb ik al eerder wat metingen gedaan na diverse opmerkingen over het
traag gaan van het rippen, om na te gaan of dat nu in de KPN/Telemedia/CMG
code zit of in mijn eigen export functies. Als test heb ik de gids tot en
met ‘Aalsmeer’ gedumpt en gekeken hoe lang e.e.a. duurt. (En ja, meerdere
malen gedaan en gemiddeld, gezorgd dat e.e.a. in hard disk cache zat en meer
van dat soort details)

  • helemaal geen output code : 0:45
  • output naar CSV bestand: 0:46
  • output naar MySQL: 1:02
  • output naar MySQL zonder indices: 1:00

Ik besef dat hoe groter de database (dus daar is t/m Aalsmeer rippen niet
echt representatief) hoe meer tijd het bijwerken van de index kost maar als
je het achteraf moet doen kost het ook tijd. Weliswaar gaat het dan iets
efficienter maar ik denk dat de meting aantoont dat het verschil marginaal
is. Daarentegen wordt de code weer complexer doordat je achteraf indexen
moet aanmaken. En ik zie de forum berichten al van al die mensen die het
vergeten en waarbij de database niet meer performt.

Waarom gaat het dan zo langzaam? De gids wordt nu alfabetisch doorlopen, en
dat is (dus) niet sequentieel. Daar zit dus een hoop IO wait. Onder water
worden er blokken van disk gelezen, die worden in geheugen gedecomprimeerd
en vervolgens worden de records eruit gehaald. De laatste keer dat ik de
code goed bekeken heb werden er wel blokken gecached maar alleen in
gecomprimeerde vorm. Daar zit dus relatief veel processor overhead, omdat
als ik tien records opvraag in blokken A, B, A, B, A, B, A, B, A, B er dus
10 x een blok geladen en gedecompressed wordt. Het is echter de enige manier
waarop ik de gids kan doorlopen op het niveau van de Java JNI API.

Mijns inziens valt er met de huidige aanpak dus niet echt veel performance
winst te halen, hooguit 20% maar zeker geen factor. Die verhoudt zich slecht
tot de moeite die je ervoor moet doen tijdens het ontwikkelen.

#4

Toch maar even een life test uitgevoerd op een AMD Athlon XP 2500,512 Mb intern, 80GB 7200 HD, Windows 2000 server schoon en ongelast. Een 2e server doet elk uur een query om de voortgang op te vragen.

Foondump moet alles dumpen naar Mysql. In de standaard configuratie is er 26,5 uur nodig. Hierna heb ik alles herhaald zonder de indexen. Die zijn daarna aangemaakt. Totale tijd was ca 13 uur.

Dat is toch 50% sneller. (Ik heb de detailoutput van de 2e server in excel als iemand dat wil zien).

Op basis hiervan heb ik mysql-create.sql gesplitst in mysql-create-table.sql en mysql-create-index.sql. (Ook die stuur ik op verzoek toe).

#5

Hallo None,

En is de database hierna ook werkzaam of moet je eerst nog een reindex opdracht starten om het geheel werkzaam te krijgen.

Het export procces naar een database toe is eigenlijk maar een eenmalige aktie> Het doet er eigenlij niet toe of dit nu 13 of 26 uur kost het procces draait maar 1 maal.

wat veel belangrijker is dat het import procces op een goede manier loopt en dat er wellicht meer tijd (proccestijd) wordt besteed om er wellicht dubbele record’s en dergelijke te herkennen en te onderscheppen.

Hier heeft de laatste export er ongeveer 28 uur overgedaan en dan ook nog gelijk naar een remote MySql database. Dit vindt een goede preformance.

Voor de makers van deze geweldige export routine meer dan lof. Binnen kort komt de 2004-zm3 uit en ben weer reuze benieuwd of de export wederom lukt en of dit nu binnen 14 uur lukt of 28 uur dat maakt mij niet als daarna de database maar klaar staat voor gebruik.

Groeten John

#6

Hoi John, None, RGJ,

Ik kan de argumentatie van John goed volgen. Daarentegen vind ik het heel goed dat None testen doet om het eindproduct te verbeteren --)

Binnen kort komt de 2004-zm3 uit

RGJ, Misschien is het handig om de nieuwe Foondump versie te gaan testen met de 2004-zm3 . Kan None testen of het goed werkt en of er nog verbeterslagen in zitten. Laat even weten wat jij van voorgaand voorstel vindt,

De vriendelijk groet Jan Marco

P.S.

wellicht meer tijd (proccestijd) wordt besteed om er wellicht dubbele record’s en dergelijke te herkennen en te onderscheppen.

Ik heb dit nog weinig gezien.

#7

Inderdaad, Als je het één doet hoef je het andere niet te laten…
Het meest belangrijke is dat het werkt!!! Pas daarna worden andere zaken belangrijk, zoals snelheid en “easy-to-use”.
Onderstaande zaken gaan dus alleen over versnellen!

A) mysql versnellen
Het enige wat ik heb gedaan is het maken van de tabellen en het maken van de indexen splitsen. De stappen zijn dus

  1. maken van te tabellen
  2. foondump draaien
  3. indexen maken (extra stap)

Graag stuur ik jullie mijn code van mysql-create-table.sql en mysql-create-index.sql toe. Ik kan alleen geen bijlagen aan dit document toevoegen.

B) Java versnellen
Ik heb de code niet gezien maar zie dat er veel re-reads zijn. Is het niet mogelijk om een hele tabel b.v. WL in zijn geheel in het geheugen in te lezen en dan de verwerking te beginnen. Windows heeft dan misschien niet genoeg intern geheugen en begint te swappen, maar dit is volgens mij efficienter als dat het nu gebeurd.

Samenwerken en gebruik maken van elkaars sterke punten, dan maak je een goed --> ijzersterk produkt.

#8

Hoi RGJ,

Ik zie dat jij wel een email adres hebt gezet in de member list, echter ik krijg geen email adres in outlook.

Graag stuur ik jullie mijn code van mysql-create-table.sql en mysql-create-index.sql toe

RGJ, misschien handig om een email adres te hebben waar men info/source verbetervoorstellen heen kan sturen. Is hiervoor te gebruiken? Misschien een gebruiker opvoeren “source_moderator” met deze email account?

De vriendelijke groet Jan Marco

#9

Ik heb de gevraagde code verzonden. Is de code van Foondump openbaar?
Volgende week ga ik een poosje op vakantie en wil er wel doorheen lezen om te kijken of ik nog tips voor jullie heb.

#10

Hoi None,

Is de code van Foondump openbaar?

Java = openbaar, want je kan het ‘altijd’ decompileren tot sourcecode.

Zie ook:
http://forums.virtualconspiracy.com/foondump/viewtopic.php?t=9

Kun je de compressiealgoritme niet achterhalen door die java classes te decompilen met bijvoorbeeld, JAD (http://kpdus.tripod.com/jad.html )???

De vriendelijke groet Jan Marco

#11

Het pas creeren van de indices na afloop van het vullen van de database is niet alleen beter qua snelheid van rippen. Het heeft t.o.v. de huidige situatie ook een voordeel voor enkele sql queries op de gevulde database. De query optimizer gebruikt de kardinaliteit van de indices om te bepalen in welke volgorde table joins moeten plaats vinden en welke index gebruikt moet worden (mysql kan slechts 1 index per query per table gebruiken). Deze kardinaliteit wordt door mysql los bijgehouden en niet geupdate tijdens inserts. Op dit moment moet je dat oplossen door na de rip op elke table "ANALYZE TABLE " los te laten. Als je dan toch al na de inserts een extra query op de tabellen moet los laten kan je beter 2 vliegen in één klap vangen en de indices achteraf aanmaken. Bij het aanmaken van een index wordt namelijk wel de kardinaliteit geupdate.

#12

Ok, dat laatste argument was net dat beetje extra overtuiging wat ik nog nodig had. Ik zal e.e.a. splitsen en het resultaat laten weten.

#13

Hoi Xim, RGJ,

Ik zal e.e.a. splitsen en het resultaat laten weten.

Ik zit bij mijn broer in MySQL te dumpen. Ondertussen zoek ik met Megafoon in de entries die er al inzitten. En dat gaat vooralsnog super snel.

Mijn vraag: Indien de splitsing is aangebracht kan ik tijdens het dumpproces supersnel zoeken of krijg ik met table scan’s te maken.

De vriendelijke groet Jan Marco

#14

zolang je nog niet alles of ten minste het grootste gedeelte hebt gedumped geeft de zoek snelheid een vertekend beeld.

Of table scans nodig zijn ligt natuurlijk een beetje aan hoe je SQL queries er uit zien. Maar als je niets uitzonderlijks doet, dan is voorzover ik weet geen full table scan nodig met de huidige indices. Voor het witte gedeelte althans, bij zoeken in pink heb je drie tabellen nodig (categories,subscribercategories,pinkscubscriber) dus dan is het wat ingewikkelder. Ik ben nog bezig naar pink te kijken.

Overigens is dit geen garantie dat het zoeken ook supersnel zal gaan. Maar zoeken op telefoonnummer, daar gaat het in megafoon toch om?, is wel lekker snel.

#15

Hoi Xim,

Bedankt voor jouw terugkoppeling —)

Maar zoeken op telefoonnummer, daar gaat het in megafoon toch om?, is wel lekker snel.

Ja, zeker dat het daar ook om gaat. Ik ben erg enthousiast over Megafoon. Mijn broer snapte ook wat hij moest doen. Een collega van mij heb ik laatst Mysql in een dosbox laten zien. Zijn reactie was: “Dat ziet er niet uit!”.

Goede database ontwerp en MFC GUI programming zal m.i. steeds belangrijker worden.

De vriendelijke groet Jan Marco

#16

Ik heb zelf foondump tegelijk draaiend gehad op een 333 P3 en een 1.8 GHz P4 en het verschil in snelheid was behoorlijk klein. Kan het wezen dat er een vertraging in de DLL-s zit om het dumpen te ontmoedigen (sleep(…)) ?

#17

Hoi n3sci0,

Ik heb zelf foondump tegelijk draaiend gehad op een 333 P3 en een 1.8 GHz P4 en het verschil in snelheid was behoorlijk klein. Kan het wezen dat er een vertraging in de DLL-s zit om het dumpen te ontmoedigen (sleep(…)) ?

Telemedia wil het liefst ook zo snel mogelijk records op het scherm hebben. Dus lijkt mij niet goed met dat doel te verenigen.

Misschien is het meer I/O bound en dat is minder van de CPU power afhankelijk.

De vriendelijke groet Jan Marco

#18

Dit vermoeden heb ik ook wel eens.
Stel je bouwt 10 ms vertraging in per record. Op 6.42 miljoen records betekent dat een totale vertraging van zo’n 18 uur.

Op 100 records (en dat is al een grote query voor de CDFoon GUI) is het slechts een seconde. Dat merkt niemand.

Straks brengen we ze nog op een idee :wink:

#19

Hoi RGJ,

Stel je bouwt 10 ms vertraging in per record. Op 6.42 miljoen records betekent dat een totale vertraging van zo’n 18 uur.

Stel dat ze vertraging in bouwen kan je dan niet het programma in bijvoorbeeld 10 gelijke dump delen splitsen van het totaal en het programma 10 maal opstarten. De ene programma wacht even echter de andere kunnen gewoon doorwerken.

De vriendelijke groet Jan Marco