Slow Queries

[pietrovek 19]

Witam!

 

Ostatnio trochę zoptymalizowałem my.cnf, serwer znacznie przyspieszył, wszystko wydawało się być dobrze...jednak włączyłem logowanie wolnych zapytań...wróciłem po 11 dniach...i ku mojemu zdziwieniu...

 

# User@Host: db1[db1] @ localhost []
# Query_time: 52.212436  Lock_time: 0.000036 Rows_sent: 0  Rows_examined: 1
SET timestamp=1333242481;
update adm_tpd set ogladalnosc = '193' where ID = '1153';

 

mam 9 wpisów w logu z czasami 2s-52s właśnie przy tak prostych zapytaniach...

 

nie bardzo mam pomysł dlaczego tak się dzieje...

w sumie w statystykach wszystko wygląda OK - nie brakuje RAM, CPU też, dyski wykorzystane w max.10%, w zasadzie też chyba nie mogę się czepiać o 9 zapytań na 141M ale jakoś mnie to nurtuje dlaczego tak proste zapytanie trwało 52s.

 

Nie mam za bardzo na to pomysłu. Ktoś może coś podpowiedzieć?

 

załącze wynk mysqltunner.pl

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.15-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 21M (Tables: 142)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] InnoDB is enabled but isn't being used
[!!] Total fragmented tables: 10

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 11d 19h 23m 9s (141M q [138.660 qps], 194K conn, TX: 182B, RX: 17B)
[--] Reads / Writes: 69% / 31%
[--] Total buffers: 592.0M global + 32.2M per thread (151 max threads)
[OK] Maximum possible memory usage: 5.3G (68% of installed RAM)
[OK] Slow queries: 0% (9/141M)
[OK] Highest usage of available connections: 9% (14/151)
[OK] Key buffer size / total MyISAM indexes: 128.0M/7.0M
[OK] Key buffer hit rate: 100.0% (645M cached / 10K reads)
[OK] Query cache efficiency: 94.8% (130M cached / 137M selects)
[!!] Query cache prunes per day: 435
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1M sorts)
[!!] Joins performed without indexes: 691052
[OK] Temporary tables created on disk: 0% (4K on disk / 2M total)
[OK] Thread cache hit rate: 99% (22 created / 194K connections)
[OK] Table cache hit rate: 74% (369 open / 493 opened)
[OK] Open file limit used: 8% (517/6K)
[OK] Table locks acquired immediately: 99% (17M immediate / 17M locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
Add skip-innodb to MySQL configuration to disable InnoDB
Run OPTIMIZE TABLE to defragment tables for better performance
Increasing the query_cache size over 128M may reduce performance
Adjust your join queries to always utilize indexes
Variables to adjust:
query_cache_size (> 256M) [see warning above]
join_buffer_size (> 20.0M, or always use indexes with joins)

[Miłosz 2311]

Pole ID jest poprawnie zaindeksowane?

[xorg 693]

Indeksy + warto dodać limitowanie, gdy masz pewność, że trzeba tylko jeden rekord zaktualizować.

 

A rozwiązaniem zagadki może być to, że w tym samym czasie były wykonywane inne operacje na serwerze które dociążyły sprzęt i akurat padło na to, proste query, że zamuliło

Edytowano Kwiecień 11, 2012 przez xorg (zobacz historię edycji)

[pietrovek 19]

Młosz,

pole ID ma założony index

 PRIMARY KEY (`ID`)

 

xorg,

Sprzęt to dedyk z hetznera, postawione są na nim 2 witryny korzystające z jednej bazy o wielkości 25MB - poza okresem gdzie generowany jest backup ( godz. 0.00) sprzęt nie wykazuje więcej jak 30% użycia ("piki" są w czasie tworzenia backup'u)...poniżej statsy LA:

 

Edytowano Kwiecień 11, 2012 przez pietrovek (zobacz historię edycji)