TeamSpeak 3 - SQL CRITICAL (w nocy)

[Gość]

Witajcie,

 

Mam problem z serwerem TeamSpeak 3. Praktycznie codziennie w nocy (w zakresie godzin 00:00 - 8:00) wyłącza się samoczynnie, w logach za każdym razem kończy się na wpisie:

|CRITICAL|SQL|   | failed to retrieve virtualservers, halted! error: database error

Pragnę dodać, że nasza baza danych MySQL działa bez żadnych problemów. W logach zapytań widzimy zapytania od serwera TeamSpeak 3. Nawet jeżeli na kilka minut wyłączymy serwer MySQL to serwer TS3 w tym czasie się nie wysypuje.

 

Dziwne jest to, że dzieje się to za każdym razem w nocy, ostatnie godziny i dni kiedy wystąpił CRITICAL: 00:11 23.01, 02:48 22.01, 07:45 21.01, 04:32 20.01.

 

Nie bardzo wiemy co możemy już zrobić z tym problemem. Support TeamSpeak 3 jakoś nie śpieszy się z pomocą.

 

Pełne logi z dnia dzisiejszego do momentu wyłączenia serwera (CRITICAL) - http://wklej.org/hash/6d989e7aa7d/

Edytowano Styczeń 23, 2014 przez Gość (zobacz historię edycji)

[SanKen 63]

Serwer mysql jak i TS są na jednej maszynie, sprawdzałeś jak wygląda sprawa z logami MYSQL ? Bo z tego co widzę TS ewidentnie traci mysql z zasięgu. I podczas próby zapytania się wysypuje. Miałem podobnie pomogła zmiana w ustawieniach MYSQL

.

[Gość]

Serwer MySQL jest uruchomiony na osobnej maszynie (ale w obrębie tej samej sieci LAN).

Nie sprawdzałem jak wyglądają zapytania przed/w momencie crasch (napiszę jak znów się pojawi).

 

Status serwera MySQL jeżeli chodzi o konfigurację wygląda następująco:

 >>  MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
[OK] Logged in using credentials from debian maintenance account.

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

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 892M (Tables: 61)
[--] Data in InnoDB tables: 186M (Tables: 152)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 164

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 7d 3h 51m 23s (5M q [9.167 qps], 263K conn, TX: 1B, RX: 558M)
[--] Reads / Writes: 46% / 54%
[--] Total buffers: 4.3G global + 2.7M per thread (150 max threads)
[OK] Maximum possible memory usage: 4.7G (14% of installed RAM)
[OK] Slow queries: 0% (305/5M)
[OK] Highest usage of available connections: 36% (54/150)
[OK] Key buffer size / total MyISAM indexes: 3.0G/1.7G
[OK] Key buffer hit rate: 99.8% (23M cached / 52K reads)
[!!] Query cache efficiency: 12.0% (251K cached / 2M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 462 sorts)
[OK] Temporary tables created on disk: 6% (1K on disk / 26K total)
[OK] Thread cache hit rate: 98% (3K created / 263K connections)
[!!] Table cache hit rate: 17% (271 open / 1K opened)
[OK] Open file limit used: 5% (180/3K)
[OK] Table locks acquired immediately: 99% (3M immediate / 3M locks)
[OK] InnoDB data size / buffer pool: 186.0M/256.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_limit (> 2G, or use smaller result sets)
    table_cache (> 1536)

[Pan Kot 1535]

TS się wysypuje przy utracie połączenia. Możesz tego nie widzieć bo TS nie używa cały czas bazy danych, ale przy 1szym requeście się wywali.

 

Wina połączenia lub serwera MySQL.

[SanKen 63]

To że baza jest na LAN nie daje ci 100% pewności że to nie wina właśnie tego. Baza wygląda na dobrze zoptymalizowaną,ale przydało by się coś jednak jeszcze poprawić.

[Gość]

Baza wygląda na dobrze zoptymalizowaną,ale przydało by się coś jednak jeszcze poprawić.

 

Co masz na myśli?

Edytowano Styczeń 25, 2014 przez Gość (zobacz historię edycji)

[SanKen 63]

Nie jesteś osobą która posiada 1 serwer TS na jednej bazie mysql wiec przydało by się jeszcze poprawić optymalizacje MYSQL bo być może jest to też powodem, TS3 wykonuje dość dużo zapytań.