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 Test