[MySQL/PHP]Performance problemen upgrade script

[bartvb]

Ik ben bezig met het schrijven van een upgrade script voor een forum. Vreemde is dat tijdens de conversie het processorgebruik niet boven de (ongeveer) 2% uitkomt zelfs niet als we gruwelijke hoeveelheden regexps aan het doen zijn..

Wat doen we nu?

code:

SELECT 200 posts uit de database
{
  Lock de posts en posts_text tables
  mysql_fetch_array()
  {
    Converteer BBcode van deze post
    Update posts en posts_text tabellen
  }
  Unclock tabellen
}

Ik weet dat ik de tabellen gewoon gelocked kan laten staan maar dit unlocken is wel handig als je tijdens de conversie met een monitor een beetje in de gaten wil houden wat je script aan het doen is..

Iemand een idee wat hier aan de hand is? Tijdens de conversie zie je niets bijzonders met SHOW PROCESSLIST:

code:

mysql> show processlist;
+-----+--------+-----------+-----------+---------+------+-------+------------------+
| Id  | User   | Host   | db      | Command | Time | State | Info        |
+-----+--------+-----------+-----------+---------+------+-------+------------------+
| 142 | bartvb | localhost | forum     | Query   | 0    | NULL  | show processlist |
| 167 | bartvb | localhost | forum     | Sleep   | 0    |    | NULL      |
+-----+--------+-----------+-----------+---------+------+-------+------------------+

Heeeeel weird dus. Je zou verwachten dat MySQL en de httpd (Apache) als een gek om CPU cycles zouden vechten..

Any thoughts?

[wasigh]

een regex is volgens mij niet anders als een (binaire?) boom en dat is niet zo zwaar voor de processor dacht ik.

een update is ook niet al te zwaar..

en waarschijnlijk moeten ze beide continue op de IO wachten?

[just my 2 cents]

[marcusk]

[eigenlijk offtopic]

Op zaterdag 20 oktober 2001 00:22 schreef wasigh het volgende:
een regex is volgens mij niet anders als een (binaire?) boom en dat is niet zo zwaar voor de processor dacht ik.

regexen worden idd dmv boomstructuren geimplementeerd, maar dat zegt niet echt veel over hoeveel het vergt van de processor. 3D scenes bijvoorbeeld worden ook met boomstructuren opgeslagen

[wasigh]

Op zaterdag 20 oktober 2001 00:37 schreef marcusk het volgende:
[eigenlijk offtopic]
[..]

regexen worden idd dmv boomstructuren geimplementeerd, maar dat zegt niet echt veel over hoeveel het vergt van de processor. 3D scenes bijvoorbeeld worden ook met boomstructuren opgeslagen

Nee, dat klopt. maar het is nog een verschil of je een regex echt gaat parsen of desnoods recursief gaat benaderen als of dat je een boom pakt, dat bedoel ik eigenlijk

[bartvb]

Hmm. Lijkt me sterk.. Die hele DB is in no time in te lezen.. Nou ja.. Hij kan zichzelf in iedergeval goed bezighouden als ie zou willen.

Enig idee hoe ik dit eventueel zou kunnen checken?
Maar ik gok dat het systeem zelf niet echt een bottleneck is..

[wasigh]

bereken eens hoelang elk statement duurt door de systeemklok te gebruiken?

[Verwijderd]

Voor iedere keer dat je een insert doet zit het systeem waarschijnlijk te wachten op een fsync() die alle buffers op disk fixeert. Volgens mij moet er ook in mysql wel zoiets zijn als een bulk insert, die pas fsynct op het moment dat het jouw uitkomt i.p.v. na iedere insert.

[bartvb]

Beetje oud topic.. Wilde alleen ff melden dat het probleem opgelost is

Bleek dat we bij iedere posting en iedere user een uniek ID aanmaakte dat nodig is voor de BBcode. Probleem daarmee was dat die functie gebruik maakte van uniqid() en die functie lijkt 20ms totaal NIETS te doen als ie aangeroepen wordt.

Niet leuk als je een paar duizend users en een paar honderduizend posts aan het converteren bent

Anyway, dit verklaart dus waarom de CPU heel de tijd niets stond te doen...