Problem mit table_cache!?

[grunzl]

Hallo zusammen,

ich hatte in den letzten Wochen ziemlich mit stark schwankenden Serverlasten zu kämpfen und mir auch so einige Infos aus dem Beitrag geholt. Nachdem ich dann u.a. den table_cache auf 4000 erhöht hatte, stellte sich endlich die erhoffte Ruhe ein und mein MyBB-Forum läuft wieder zufriedenstellen.

Seit den entsprechenden Konfig.änderungen beobachte ich den Server immer wieder mit dem tuning-primer-Skript und dem MySQLTuner. Eine ganze Zeit lang lag die table_cache hit rate auf 97%. Innerhalb von 1-2 Tagen sinkt diese aber nun zusehends.

Hier die Ausgabe von MySQLTuner:

[OK] Table cache hit rate: 58% (480 open / 818 opened)

mittlerweile liegt sie sogar bei 46% und ich befürchte, dass sich damit evtl. wieder Probleme ankündigen.

Wie man nachfolgend sehen kann, sagt das tuning-primer Skript aber etwas anderes.

TABLE CACHE
Current table_cache value = 4000 tables
You have a total of 365 tables
You have 480 open tables.
The table_cache value seems to be fine

Mir ist jetzt nicht ganz klar, wie ein weiteres Vorgehen auszusehen hat und hoffe hier auf Hilfe. Kann ich den table_cache immer weiter in die Höhe treiben oder ist das der falsche Weg?

Auf meinem Strato vServer (850MB zugesicherter RAM) laufen folgende Dinge:

- Debian Etch (4.0) als Betriebssystem
- Apache 2
- ProFTPd
- MySQL
- Postfix und Courier
- PHP mit Suhosin-Patch und eaccelerator
- SysCP
- phpMyAdmin
- Roundcube
- Munin und Webalizer
- 1 MyBB Live-Forum und 2 nicht öffentliche Testforen

 

[grunzl]

Hat so gar keiner einen Tipp für mich oder braucht Ihr ggf. noch andere Infos?

Dankeschön im Voraus!

 

[grunzl]

schade

War jetzt wohl nicht gerade ein guter Einstieg für mich mit dieser Frage.

 

[wstuermer]

Hi,

was ist denn dein Problem? Scheint doch alles wunderbar zu laufen laut deiner bisherigen Infos.


--W

 

[grunzl]

Hallo wstuermer,

Danke erst einmal für Deine Antwort.

Meine Frage war ja, ob ggf. Probleme zu erwarten sind. Mittlerweile meckert mir der MySQLTuner den table_cache an. Leider verstehe ich nicht ganz warum. Aktuell ist table_cache=4000 eingestellt, 492 Tabellen sind offen gegenüber 2000, die geöffnet wurden (habe ich die Ausgabe so richtig verstanden?).

-------- Performance Metrics -------------------------------------------------
[--] Up for: 27d 13h 1m 26s (13M q [5.674 qps], 959K conn, TX: 2B, RX: 1B)
[--] Reads / Writes: 65% / 35%
[--] Total buffers: 90.0M global + 1.8M per thread (40 max threads)
[OK] Maximum possible memory usage: 160.0M (10% of installed RAM)
[OK] Slow queries: 0% (47/13M)
[OK] Highest usage of available connections: 82% (33/40)
[OK] Key buffer size / total MyISAM indexes: 32.0M/65.3M
[OK] Key buffer hit rate: 99.7% (73M cached / 190K reads)
[OK] Query cache efficiency: 64.9% (5M cached / 8M selects)
[OK] Query cache prunes per day: 16
[OK] Sorts requiring temporary tables: 0% (204 temp sorts / 466K sorts)
[OK] Temporary tables created on disk: 11% (17K on disk / 156K total)
[OK] Thread cache hit rate: 99% (3K created / 959K connections)
[!!] Table cache hit rate: 19% (492 open / 2K opened)
[OK] Open file limit used: 10% (850/8K)
[OK] Table locks acquired immediately: 99% (6M immediate / 6M locks)
[OK] InnoDB data size / buffer pool: 304.0K/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    table_cache (> 4000)

Der aktuelle avg. Load beträgt 0.39 und die Ladezeiten einer Seite betragen im Schnitt zwischen 1 und 5sec. Manchmal geht der Load (5Min.) auch kurzfristig deutlich über 2 und ich denke, es hängt damit zusammen, ob gerade mehrere User bildlastige Beiträge aufrufen.

Als ich die letzten Male Last-Probleme mit dem VServer hatte, war u.a. das Hochsetzen des table_cache die Lösung des Problems und deshalb beobachte ich das und wollte wissen, wie das mit dem table_cache ist, weil sich gerade dieser im MySQLTuner auffällig verhält.

 

[grunzl]

Jetzt versuche ich mein Glück einfach noch einmal:

Die table cache hit rate steht z.Z. wieder bei 10% und es wird erneut dazu geraten, den table cache auf über 4000 zu setzen.

Was führt denn dazu, dass die hit rate immer wieder so abnimmt? Ist denn das Hochsetzen des table cache immer die einzige Möglichkeit oder wirken da auch andere Stellschrauben?

Danke im Voraus für ein paar Tipps oder auch Erklärungen!