MySQL performance problemen met load data infile

[bami82]

Beste WHTérs,

Ik loop met de implementatie van een nieuwe applicatie tegen wat performance issues aan met MySQL.

In deze applicatie wordt load data infile gebruikt om een Comma Seperated file in te lezen. Dit is een soort van batch job die dagelijks zal gaan draaien.

Ik heb een voorbeeld CSV file van 48mb (650k records), duurt ongeveer een uur om in te lezen, dat is opzich geen probleem, het probleem is dat tijdens dat inlezen mijn disken gewoon 100% busy zijn en alle andere write queries die tussendoor worden uitgevoerd ontzettend traag zijn (response tijden van +-20 sec.)

Is er een manier om dit op te lossen zodat die response tijden van de overige queries gewoon snel blijven? Ik ben bang dat zelfs als ik extra disken toevoeg, de execute time van het laden van de csv file korter wordt echter de IO nog steeds naar 100% zal gaan en daardoor de response tijd nog steeds te lang zal zijn voor de overige write queries.

Wat Info:

MySQL 5.0.37 (64 bits)
Hardware: Sun Fire V240
OS: Solaris 10
Filesystem: UFS
Disks: 2 x 73GB 10k SCSI

Alvast bedankt.

[kjkoster]

Dag bami82,

Ik zou zeggen:

1) Check http://www.maatkit.org/ of ze een bulk loader script hebben, of als dat niet zo is...

2) Verander je eigen loader om de data langzamer te laden. In plukjes van 10, 50, 100 of 200 records met een commit en eventueel een sleep van .5 seconde ertussen.

3) Lees de documentatie voor multi-inserts (of hoe dat dan ook heet) en INSERT DELAYED.

4) Kom daarna terug voor meer ideeën. :-)
Kees Jan

[bami82]

Thanks voor de info. INSERT DELAYED zal niet werken agenzien we innoDB gebruiken. Ik zal is gaan kijken of het probleem op te lossen is door het in chunks van x seconde te gaan doen.

[wonko]

je hebt ook extended inserts, waarbij je verschillende datalijnen samenvoegt in één insert statement. Dan gaat het natuurlijk niet meer via CSV, maar zo kan je in bulk invoegen in de database.

Als het een vervanging is van een volledige tabel, kan je ook eerst in een afzonderlijke tabel inladen, en dan via enkele rename-table operaties de tabel in de plaats van de andere schuiven.

Indexen uitzetten voor het invoegen, en je tx_commit gedrag van innodb aanpassen, en terug aanzetten zal ook vermoedelijk helpen...

[johan.smits]

ik heb ooit een soortgelijke applicatie moeten maken met persoons info van 60k regels.
Ik had hier een PHP script voor gemaakt welke her parsen voor mij deed (file regels hadden bewerkingen nodig) en dan in de database schreef of een update deed aan een bestaand record.
Het importeren hiervan duurde ongeveer 15 sec.
Dit komt ook waarschijnlijk omdat elke insert los gezien word en als er een read query staat de wachten de DB dit zelf netjes oplost.
Het kosten de server wel behoorlijk wat CPU, maar het was ook zo voorbij.
ik zou eens proberen om met PHP regels te lezen en ze een voor een in een database te stoppen.

[PreServer]

Als je keys gebruikt kan je die disablen voordat je gaat inporteren, en deze later rebuilden, kan ook aardig wat snelheid schelen.
Is alleen die database traag, of alle? Als alleen die db traag is kan je ook de data imorteren in een andere tijdelijke (eventueel heap) database importeren en dan renamen (of insert into xxx select * from heapTable in geval van heap db)
Je kan kan ook kijken of innodb niet in de weg zit met autocommit oid, of juist met 1 grote transactie.

[t.bloo]

Probeer eens het proces dat de import doet een andere "nice" waarde te geven.

In blokken werken kan ook helpen.

Maar als je disk IO zo hoog wordt, dan lijkt het er op dat de database uit z'n dak gaat. Dat zou niet moeten horen met een "straight" insert, ook al zijn het 650k regels.