---

Hej!

Bruger MySQL 3.22.32 på Tru64.

Jeg kørte lige en optimize på en table i dag, og efter ca. 10 minutter :

010307 17:00:00 Out of memory; Check if mysqld or some other process uses
all available memory. If not you may have to use 'ulimit' to allow mysqld to
use more memory or you can add more swap space
mysqld ended on Wed Mar 7 17:00:21 MET 2001


Jeg tjekkede naturligvis :

iratxe.tm.es> ulimit
unlimited


iratxe.tm.es> /usr/sbin/swapon -sv
Swap partition /dev/rz8b (default swap):
Allocated space: 48768 pages (381MB)
In-use space: 316 pages ( 0%)
Free space: 48452 pages ( 99%)

Swap partition /dev/rzb11c:
Allocated space: 256841 pages (2006MB)
In-use space: 312 pages ( 0%)
Free space: 256529 pages ( 99%)


Total swap allocation:
Allocated space: 305609 pages (2387MB)
Reserved space: 47242 pages ( 15%)
In-use space: 628 pages ( 0%)
Available space: 258367 pages ( 84%)


Ingen limit og over 2 GB ledig swap og intet i brug aktivt.

Jeg havde forinden kørt optimize på et par mindre tabeller og det gik fint.

Jeg prøvede endnu en gang på samme tabel, og MySQL core dumpede igen. Det
samme skete da jeg prøvede at lave et nyt index.

Herefter tjekkede jeg memory-udviklingen :

http://www.dassic.dk/iratxe_memory.png


Som det ses dræner den store optimize (kl. ca. 17:00) maskinen for det
ledige RAM der er (ca. 1 GB) hvilket bliver brugt til UBC buffering og når
der ikke er mere dør MySQL.
Dette forstår jeg ikke helt, da MySQL bare burde fortsætte. Hvis MySQL
behøver den RAM der automatisk allokeres til UBC får den det, da UBC kun
bruger RAM hvis der ikke er programmer der bruger det, og hvis de ønsker det
frigiver UBC det transparent.

Har MySQL 3.22.32 en bug på dette område, og i så fald er det evt. fixet i
en nyere udgave ?
Det virker også mistaenkeligt at fejlen sker lige omkring 1 gigabyte (de
temporære filer var ca. 1 GB store da MySQL core dumpede).
Jeg har kompileret MySQL med large file 64-bit support, og filsystemet
understøtter filer på 2 TB, så det er ikke her begrænsingen ligger.


l8r/Jspr