Frigøre memory

kigger lige med her...

Mener du kan køre en

RESET QUERY CACHE

Prøv at test.

Det har jeg prøvet, men det giver ingen ændring af memory-forbruget.

hmm..Du bør nok kigge på
http://dev.mysql.com/doc/refman/5.0/en/memory-use.html

Kig på commandoen mysqladmin flush-tables..

hov.. skulle ikke ha været et svar.. :)

'reset' og 'flush' er grundlæggende samme funktionalitet, som jeg forstår det, og ingen af dem har effekt her - måske fordi der er tale om innodb-tabeller (?)

Hvilke værdier har de relevante parametre i my.ini ?

Det jeg er interesseret i er om MySQL giver fejl, når den når disse limits eller om den ignorerer disse limits.

Med mit nuværende setup er der ret langt op til limit, som ikke nås før efter måske 2-3 ugers uafbrudt og uforstyrret drift. Hvis jeg dog foretager en 'stor' query undervejs, vil limit nås ret hurtigt. Limit for mysqld-nt er ca. 1.153.000 KB, kan jeg se. Fejl i den forbindelse er 'long semaphore wait', som vist er en relativ hyppig MySQL-fejl.

Både 'flush' og 'reset' returnerer umiddelbart uden fejl, men memory frigøres ikke.

Parametre:
max_connections=100
query_cache_size=0
table_cache=256
tmp_table_size=18M
thread_cache_size=8

myisam_max_sort_file_size=100G
myisam_sort_buffer_size=35M
key_buffer_size=25M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size=256K

innodb_additional_mem_pool_size=16M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=8M
innodb_buffer_pool_size=1G
innodb_log_file_size=256M
innodb_thread_concurrency=16

innodb_file_per_table

Min PC har i øvrigt 4GB RAM.

Hvordan er dit program kodet? Frigører du dine statements? mener at jeg har været ude for samme problem..

har du prøvet at køre: SHOW VARIABLES LIKE 'query%';

Frigør statements, hvad mener du præcis med det? Jeg tilgår databasen med et Java-program, hvor jeg (ved hver opdatering) åbner en connection, som jeg lukker igen osv. Mener at det helt standard.

SHOW VARIABLES LIKE 'query%' giver i mit tilfælde:
query_alloc_block_size 8192
query_cache_limit 1048576
query_cache_min_res_unit 4096
query_cache_size 0
query_cache_type ON
query_cache_wlock_invalidate OFF
query_prealloc_size 8192

Det var lidt det jeg mente, så fint nok.

Kan ikke lige komme på mere.

Er du ikke sød at kommenterer hvis du finder ud af at løse problemet.

MVH
Mathias

Skrivning til mindre work-tabel, som senere kopieres til master-tabel har generelt stor virkning på memory-forbruget. Denne løsning er dog kun mulig, når man som jeg ikke har brug for at foretage queries mod data i master-tabellen men kun mod data i work-tabellen - altså hvor master-tabellen blot er et inaktivt data-lager.

Det grundlæggende ønske om at frigøre memory uden genstart af MySQL har jeg ikke kunnet løse, men jeg har lavet en Java-løsning, hvor MySQL kan genstartes uden tab af data. Løsningen tager også hånd om den situation, hvor MySQL er optaget af noget andet, f.eks. intern oprydning, som jeg har observeret fra tid til anden. Løsningen er lavet således:
Alle skrivninger til databasen afvikles i selvstændige tråde. En tråd venter på flg. måde:
1. Hvis MySQL er afbrudt inden skrivning, loop'es i tråden indtil DriverManager.getConnection() accepteres.
2. Hvis MySQL afbrydes eller er optaget af noget andet, f.eks. intern oprydning, efter connection er accepteret men under skrivning, vil PreparedStatement.executeUpdate() blokere.
3. For at sikre at antallet af connections begrænses er etableret en BlockingQueue, som trådene skal igennem. Herved er der ikke noget loft over antallet af tråde, idet trådene blot vil vente på, at BlockingQueue ikke blokerer længere, inden DriverManager.getConnection() forsøges.
4. Timestamp defineres så snart en tråd kaldes og er derved uafhængig af, at skrivning fysisk måske først sker på et senere tidspunkt.

Lukker spm.