[MySQL/PHP] Table crash

[Noxious]

Ik heb een probleempje met een tabel in een MySQL database.
Deze crasht regelmatig sinds een week ofzo. Hieronder een recente 'check table':

MySQL:

mysql> check table GeoCache;
+------------------+-------+----------+-------------------------------------------------------+
| Table            | Op    | Msg_type | Msg_text                                              |
+------------------+-------+----------+-------------------------------------------------------+
| web1db1.GeoCache | check | warning  | Table is marked as crashed                            | 
| web1db1.GeoCache | check | warning  | 1 client is using or hasn't closed the table properly | 
| web1db1.GeoCache | check | error    | Size of indexfile is: 13312        Should be: 15360   | 
| web1db1.GeoCache | check | error    | Corrupt                                               | 
+------------------+-------+----------+-------------------------------------------------------+
4 rows in set (0.02 sec)

Als ik deze repair doet 'ie het weer prima, maar een dag later is het weer mis.
Ik heb ḿ bewust nog niet gerepareerd om misschien meer informatie er uit te kunnen krijgen met jullie, maar de structuur van de tabel is ongeveer de volgende:
ID (UNSIGNED INT AUTO_INCREMENT PRIMARY_KEY)
Address (TINYTEXT)
Latitude (SIGNED FLOAT(8,5))
Longtitude (SIGNED FLOAT(8,5))
FirstUse (DATETIME)
LastUse (DATETIME)

Op de tabel word de volgende actie uitgevoert:
Een phpfunctie die de longtitude/latitude van een adres opvraagt (met een select from where address = ) en indien niet aanwezig deze opvraagt mbv de Google Maps API en dan opslaat in deze tabel als caching.
FirstUse geeft aan waneer 'ie gemaakt is, LastUse geeft aan waneer ie voor het laatst gebruikt is. Op die manier kunnen we een soort purge uitvoeren met een cronjob (deze is er nog niet) die alles wat ouder dan een maand en langer dan een maand niet meer gebruikt weggooit. Deze velden willen we eigenlijk nog ombouwen in unsigned ints zodat we met epoch time kunnen werken.

Kan iemand mij tips geven of ik iets rampzalig verkeerd doe, of dat het wel snor zit maar mij de kant op wijzen waar de fout mogelijk kan zitten?
Alvast bedankt!

[MueR]

Ik schop deze even naar Serversoftware en Windows Servers. In Webdesign, Markup & Clientside Scripting heeft ie weinig te zoeken.

Welke client is er nog actief op die table? Wat voor queries worden er uitgevoerd? Wat voor engine draait de tabel op? Doe nog eens wat meer info..

[GlowMouse]

En de output van ulimit -a? En heb je je hardware al getest?

[Noxious]

Actually is het een Linux (Ubuntu 8.04 LTS) server maargoed:P

Er is geen client actief, dit blijft ook staan nadat ik zelfs de hele server reboot of mysql stop en start.
De tabel maakt gebruik van de MyISAM engine.

Overigens heb ik de tabel zojuist gerepaired en ik heb al zoń vermoeden wat er mis is.

De indeling blijkt te volgende te zijn:
Request (VARCHAR 255 PRIMARY_KEY)
Latitude (TINYTEXT)
Longtitude (TINYTEXT)
FirstUse (DATETIME)
LastUse (DATETIME)

Dit lijkt me verre van optimaal, ik ga eens wat aanpassingen doen.

[Noxious]

GlowMouse schreef op zaterdag 18 september 2010 @ 16:28:
En de output van ulimit -a? En heb je je hardware al getest?

code:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 8256
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 8256
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

De server zelf is een VPS bij een 3e partij, ik kan dus niet heel veel testen.

Edit: woeps, excuse me voor de dubbelpost

[ Voor 12% gewijzigd door Noxious op 18-09-2010 16:34 ]