2009/7/14 Miloska :
> On 7/14/09, Miloska wrote:
>> > inkabb MySQL kerdes, kevesbe Linux, de azert hatha.
>> >
>
> Nem tudom erdekel-e valakit mire jutok, irok amig az admin ram nem szol :)
>
> InnoDB index monitorozasa kozel semm annyira trivialis ahogy en gondoltam.
Nos akkor (remelem) utols
Miloska wrote:
>> Gondolom azert, mert a fizetos falcon-t hasznalnak. Az emlegetett
>> xtradb-t nem probaltad?
>
> Ahogy en latom a falcon-bol csak alfa/beta van. Hol van belole (akar
> fizetos) mukodo?
Sorry, tenyleg beta meg, akkor nem tudom.
--
Gabor HALASZ
> Gondolom azert, mert a fizetos falcon-t hasznalnak. Az emlegetett
> xtradb-t nem probaltad?
Ahogy en latom a falcon-bol csak alfa/beta van. Hol van belole (akar
fizetos) mukodo?
xtradb-t megneztem, ezt a konkret hibat nem oldja meg. A meg nem
implementalt innodb_stats nevu patchben piszkalja
Miloska wrote:
>
> Ami nagyon furcsa nekem, hogy ez masnak miert nem okoz problemat,
> hiszen ezek alapjan minden dinamikusan novekedo InnoDB tablaval es
> hozza tartozo join-okkal hasonlo problemanak kellene fellepnie.
Gondolom azert, mert a fizetos falcon-t hasznalnak. Az emlegetett
xtradb-t
On 7/14/09, Miloska wrote:
> > inkabb MySQL kerdes, kevesbe Linux, de azert hatha.
> >
Nem tudom erdekel-e valakit mire jutok, irok amig az admin ram nem szol :)
InnoDB index monitorozasa kozel semm annyira trivialis ahogy en gondoltam.
Roviden osszefoglalva ismert, hogy az indexek statisztik
> inkabb MySQL kerdes, kevesbe Linux, de azert hatha.
>
Elkezdtem figyelni a
show index from TABLE
kimenetet es azt talaltam, hogy a 'Cardinality' nagyon nagyokat ugral,
szazezerrol huszra, aztan vissza, egy perc alatt akar tobb 'kort' is
megfutva.
Az az erzesem, hogy ebbe futottam bele:
http
Miloska wrote:
>
> Mit kellene keresnem?
>
Minden muveletet, mert az alapjan szinkronizalja a slaveket:
By default, OPTIMIZE TABLE statements are written to the binary log so
that they will be replicated to replication slaves. Logging can be
suppressed with the optional NO_WRITE_TO_BINLOG ke
Miloska wrote:
>>
>> Nem jo jel, ha checkelni kell az adatbazist. percona+xtradb?
>>
>>
> Nem checkelnem en ha nem romlana el. Hetek ota fut a DB es egyszer
> csak elojon ez a problema.
Valami nagy gaz van, vagy a vas hibazik, vagy a centos, vagy osszeturtak
a mysqlt (centost nem tudom, de a debi
> > Nem nagyon talalok sehol doksit rola, hogy mit es hogyan kellene
> > monitorozni, honnan lehet kiszedni a MySQL-bol, hogy o eppen mit
> > gondol a tablakrol, hol lehetne latni mit is valtoztat az analyze
> > table.
>
>
> A binlogba beirja.
>
Nezem, de nem latom, csak az 'analyze table $nam
> Valoban nem, de ilyenkor a queryt kell optimalizalni, nem az adatbazist.
>
Nezpoont kerdese, de vegulis jogos, tovabb olvasva a doksit:
MySQL uses index cardinality estimates only in join optimization. If
some join is not optimized in the right way, you can try using ANALYZE
TABLE. In the few c
Miloska wrote:
> Sziasztok,
>
> inkabb MySQL kerdes, kevesbe Linux, de azert hatha.
>
> Van egy adatbazis "5.0.77-community-log MySQL Community Edition (GPL)"
> csak InnoDB, disken 64G, 115 tabla, CentOS 5 64 bit az OS, csak MySQL
> fut.
>
> A jelenseg az, hogy neha lelassul a DB.
>
> Slow quer
Sziasztok,
inkabb MySQL kerdes, kevesbe Linux, de azert hatha.
Van egy adatbazis "5.0.77-community-log MySQL Community Edition (GPL)"
csak InnoDB, disken 64G, 115 tabla, CentOS 5 64 bit az OS, csak MySQL
fut.
A jelenseg az, hogy neha lelassul a DB.
Slow query log-ban levo keresket nezem explain
12 matches
Mail list logo
