OT large mysql

Honza Pazdziora adelton na informatics.muni.cz
Pátek Leden 17 15:55:40 CET 2003


On Fri, Jan 17, 2003 at 03:56:32PM +0100, yeti na seznam.cz wrote:
> > Co je to za verzi? Neni to zpusobeno tim, ze se vysledek toho dotazu
> > nejak cachuje a spatne invaliduje? Kazdopadne byste z toho asi mel
> > udelat normalni mysqlbug a reportovat to.
> 
> Ano, je dost pravdepodobne, ze je to z cache, ale to si server musi ohlidat.

Verze 3.23.54 cache nema. Ta je az ve 4.*.

> Jako my.cnf pouzivam my-huge.cnf (This is for large system with memory of 
> 1G-2G where the system runs mainly). Nektere hodnoty jsem jeste zvysil:
> 
> [mysqld]
> skip-locking
> set-variable    = key_buffer=384M
> set-variable    = max_allowed_packet=64M
> set-variable    = table_cache=512
> set-variable    = sort_buffer=2M
> set-variable    = record_buffer=2M
> set-variable    = myisam_sort_buffer_size=64M
> set-variable    = thread_cache=8
> server-id       = 1
> set-variable    = net_buffer_length=128M
> set-variable    = net_read_timeout=36000
> set-variable    = net_write_timeout=36000
> 
> Verze 3.23.54
> 
> Zkompilovano s parametry
> ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data 
> --with-charset=czech
> 
> Uz jsem na stejny problem narazil kdysi (1/2 roku zpet) u jine databaze  
> MySQL.
> MySQL pri milionech radku nebo velikosti DB radove ve stovkach MB se chova 
> nejak _divne_ :)

Ta cisla, co jste poslal vypadala, jako by se nejak divne mazaly
indexy (a pocitalo se podle nich). Kazdopadne, pokud jste schopen to
zreprodukovat (asi ne ta, ze poslete dump s 9 M radku, ale nejakym
skriptem), tak je mysqlbug nejlepsi reseni.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
      ... all of these signs saying sorry but we're closed ...
------------------------------------------------------------------------


Další informace o konferenci Databases