table_open_cache Problem

Huschi said:
Geht es etwas genauer?
Click to expand...
Dritter Absatz, erster Satz.

Huschi said:
Ebenfalls bitte genauer: Bei welchen Aktionen?
Click to expand...
Schrieb ich bereits: Reads und Writes.

Huschi said:
Und welche Aktionen führen dabei zur Erhöhung von Open_tables?
Click to expand...
Schrieb ich ebenfalls bereits, lies meinen vorigen Post nochmal.

Huschi said:
Wenn man "das konsequente Vermeiden von TEXT und BLOB Rows" (Rows?) wirklich durchziehen will, in welchem Datenformat soll man größere Daten denn sonst speichern?
Click to expand...
Wann immer möglich im jeweils Passenderem. Gegebenenfalls muss man sein Schema komplett überdenken und Daten eventuell auch mal aufsplitten, oder gar in geeigneteren Formaten lagern. BLOBs lassen sich beispielsweise oft viel effektiver als Binaries auf HDD speichern, als in einem DBMS. TEXT lässt sich häufig in (VAR)CHAR ausdrücken, notfalls halt in Häppchen. DBAs haben nicht grundlos hohe Stundensätze.

Huschi said:
Und wie erklärst Du Dir dann das Verhältnis zu Opened_tables mit fast 5M innerhalb von 24 Stunden?
Click to expand...
Lies die von mir referenzierte Dokumentationsseite nochmal und male Dir die Vorgänge auf Papier auf, dann verstehst Du es. Du kannst auch den Source lesen.
 
Die Frage die mich einfach umtreibt, und vielleicht könnt ihr beiden Profis mir das ja mal verständlich erklären, warum ist die Zahl beim Table Cache hit Rate bei "opened" immer so unglaublich hoch auf diesem Server.

Momentan sieht es so aus:

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

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 2G (Tables: 972)
[--] Data in InnoDB tables: 1G (Tables: 542)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 52)
[--] Data in MEMORY tables: 372K (Tables: 19)
[!!] Total fragmented tables: 78

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 18h 50m 12s (1M q [18.548 qps], 15K conn, TX: 1B, RX: 284M)
[--] Reads / Writes: 42% / 58%
[--] Total buffers: 6.2G global + 12.6M per thread (200 max threads)
[OK] Maximum possible memory usage: 8.7G (27% of installed RAM)
[OK] Slow queries: 0% (1/1M)
[OK] Highest usage of available connections: 9% (18/200)
[OK] Key buffer size / total MyISAM indexes: 2.0G/1.3G
[OK] Key buffer hit rate: 100.0% (1M cached / 38 reads)
[OK] Query cache efficiency: 83.1% (829K cached / 998K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 1% (373 temp sorts / 24K sorts)
[OK] Temporary tables created on disk: 11% (8K on disk / 74K total)
[OK] Thread cache hit rate: 99% (18 created / 15K connections)
[!!] Table cache hit rate: 3% (12K open / 381K opened)
[OK] Open file limit used: 27% (8K/32K)
[OK] Table locks acquired immediately: 99% (402K immediate / 402K locks)
[OK] InnoDB data size / buffer pool: 1.3G/4.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    table_cache (> 16384)

Kein anderer meiner Server hat dort selbst nach Monaten Dauerbetrieb einen so hohen Wert stehen, wie hier nach 18 Stunden und teilweise laufen da die gleichen Anwendungen.


Noch eine kleine Zusatzfrage:

Temporary tables created on disk: 11% (8K on disk / 74K total)

Ist das nicht ein Wert, der einem Sorgen machen müsste und ist es richtig, das nur MyISAM diese produziert?

Trotz das ich folgende Werte erhöht habe:

max_heap_table_size = 128M
tmp_table_size = 128M

Bleibt der Wert bei 10% -12%
 
Last edited by a moderator:
Was ergeben denn:
Code: 
mysql -uroot -p -e "SHOW VARIABLES LIKE 'performance_schema';"
mysql -uroot -p -e "SELECT TABLE_NAME FROM information_schema.tables WHERE TABLE_SCHEMA = 'performance_schema';"
 
Last edited by a moderator:
Ok. Erster Befehle ergibt, dass das performance_schema auf On steht.

Der zweite Befehl ergibt die Ausgabe der Tabellen:

Code: 
+----------------------------------------------------+
| TABLE_NAME                                         |
+----------------------------------------------------+
| accounts                                           |
| cond_instances                                     |
| events_stages_current                              |
| events_stages_history                              |
| events_stages_history_long                         |
| events_stages_summary_by_account_by_event_name     |
| events_stages_summary_by_host_by_event_name        |
| events_stages_summary_by_thread_by_event_name      |
| events_stages_summary_by_user_by_event_name        |
| events_stages_summary_global_by_event_name         |
| events_statements_current                          |
| events_statements_history                          |
| events_statements_history_long                     |
| events_statements_summary_by_account_by_event_name |
| events_statements_summary_by_digest                |
| events_statements_summary_by_host_by_event_name    |
| events_statements_summary_by_thread_by_event_name  |
| events_statements_summary_by_user_by_event_name    |
| events_statements_summary_global_by_event_name     |
| events_waits_current                               |
| events_waits_history                               |
| events_waits_history_long                          |
| events_waits_summary_by_account_by_event_name      |
| events_waits_summary_by_host_by_event_name         |
| events_waits_summary_by_instance                   |
| events_waits_summary_by_thread_by_event_name       |
| events_waits_summary_by_user_by_event_name         |
| events_waits_summary_global_by_event_name          |
| file_instances                                     |
| file_summary_by_event_name                         |
| file_summary_by_instance                           |
| host_cache                                         |
| hosts                                              |
| mutex_instances                                    |
| objects_summary_global_by_type                     |
| performance_timers                                 |
| rwlock_instances                                   |
| session_account_connect_attrs                      |
| session_connect_attrs                              |
| setup_actors                                       |
| setup_consumers                                    |
| setup_instruments                                  |
| setup_objects                                      |
| setup_timers                                       |
| socket_instances                                   |
| socket_summary_by_event_name                       |
| socket_summary_by_instance                         |
| table_io_waits_summary_by_index_usage              |
| table_io_waits_summary_by_table                    |
| table_lock_waits_summary_by_table                  |
| threads                                            |
| users                                              |
+----------------------------------------------------+
 
Und das erzeugt gar keinen Output? Nichtmal eine Fehlermeldung oder Querylaufzeit? Absolut nichts?
Code: 
mysql -uroot -p -e "SELECT * FROM performance_schema.events_statements_history_long WHERE CREATED_TMP_DISK_TABLES > 0 LIMIT 10\G"
 
Joe User said:
Und das erzeugt gar keinen Output? Nichtmal eine Fehlermeldung oder Querylaufzeit? Absolut nichts?
Code: 
mysql -uroot -p -e "SELECT * FROM performance_schema.events_statements_history_long WHERE CREATED_TMP_DISK_TABLES > 0 LIMIT 10\G"
Click to expand...


So ist es. Es wird das PW abgefragt und dann ist man auch schon wieder auf dem Promt:
Code: 
 mysql -uroot -p -e "SELECT * FROM performance_schema.events_statements_history_long WHERE CREATED_TMP_DISK_TABLES > 0 LIMIT 10\G"
Enter password:
root@Debian-70-wheezy-64-minimal /home/files #
 
Hier geht es ja auch nicht wirklich voran. Daher kann man ja nochmal etwas Offtopic werden:

Joe User said:
Dritter Absatz, erster Satz.
Click to expand...
Je nachdem wo man anfängt zu zählen (eigentlich hat jeder im Deutschunterricht mal gelernt, wie man richtig zitiert, oder?) kommt man auf den Satz "The table_open_cache and max_connections system variables affect the maximum number of files the server keeps open." oder "table_open_cache is related to max_connections."
Aber beide Sätze begründen nicht im geringsten Deine Aussage:
Joe User said:
Die Werte [Anm.: "table_* Werte"] zu hoch zu setzen, ist irgendwann auch kontraproduktiv.
Click to expand...
Hier schuldest Du uns also weiterhin eine Erklärung oder Revidierung Deiner Aussage.

Deine nächste Aussage:
Joe User said:
Durch TEXT/BLOB werden temporäre Tabellen [Anm.: ergänzt mit "bei Reads und Writes"] on disk erzeugt
Click to expand...
Deiner Meinung nach werden sogar bei einfachen Reads temp-Dateien erstellt? Na zum Glück sind die Programmierer von MySQL AB bzw. Oracle besser als Deine Gedanken. Es ist nämlich nicht so. Abgesehen von Joins, aber das ist hinlänglich bekannt.
Und bei "Writes" sind Dir die Programmierer ebenfalls ein paar Schritte voraus. Bei MyIsam war das nie der Fall (das liegt in der Natur der Engine) und bei InnoDB war es glaub ich auch nie der Fall. Und wenn, dann nur in der Anfangsphase.

Darauf Aufbauend Deine dritte Aussage, dass Read/Writes die Open_tables beeinflussen würden ist ebenfalls Bockmist.
Erstens wären diese Temp-Dateien (die es ja nicht gibt) keine echten Tables und fallen so nicht in den Table-Cache. Zweitens, hätten die höchstens Einfluss auf OpenED_tables.

Dann war da noch die Alternative für TEXT/BLOB-Felder:
Bei Binaries (á lá Bilder, etc.) bin ich voll bei Dir. Aber sobald durchsuchbarer Text genutzt werden soll, ist es vorbei.
Gut, Varchar statt TEXT ist seit MySQL 5.1 zumindest theoretisch möglich. (Vorher war Varchar noch auf 255 Bytes begrenzt.) Der Unterschied ist für die Engine und auch für die Performance meistens egal.
Was mich wirklich stört ist mal wieder Deine absolute Entfernung von jeder Praxis. Du schlägst tatsächlich jemanden vor das Modell zu ändern, der fertige Scripte (Unifex schrieb was von Piwik und Foren-Software) einsetzt.

Joe User said:
Lies die von mir referenzierte Dokumentationsseite nochmal und male Dir die Vorgänge auf Papier auf, dann verstehst Du es.
Click to expand...
Da Du nicht wesentlich auf die Frage eingehst bzw. noch nicht mal Ansätze von Erklärungen hast, gehe ich davon aus, dass Du selber keine vernünftige Antwort darauf hast. Bringt es Dich um sowas einfach mal zuzugeben?


Fazit:
Es zeigt sich einfach mal wieder das "MySQL-Gott" die falsche Bezeichnung für Dich ist. Ein breites aber rein oberflächliches Wissen und wenig praktische Erfahrung paaren sich mit Besserwisserei.

huschi.
 
Ähhh Huschi, ich will eure Battle nicht unnötig stören aber wie wäre es von deiner Seite aus mit noch ein paar Praxistipps zu meinem Fall.

Kann eigentlich auch der Einsatz von Nginx + PHP5-FPM anstatt Apache + php irgendwie einen Einfluss auf das gezeigte Verhalten des MySql Servers haben?
 
Huschi, Reads/Writes auf TEXT/BLOB erzeugen immer Temp-Tables on disk, daran ändert auch Dein geflame nichts.

Aber gut, da Du mal wieder auf unnötigen Streit aus bist, werde ich mich aus diesem Thread erstmal zurückziehen und Dir die Lösung des Problems überlassen, denn als Consultant und Forensiker hast Du natürlich erheblich mehr Ahnung, als so ein dahergelaufener Joe User.

Good luck Huschi und sorry Unifex.
 
Joe User said:
Aber gut, da Du mal wieder auf unnötigen Streit aus bist, werde ich mich aus diesem Thread erstmal zurückziehen und Dir die Lösung des Problems überlassen, denn als Consultant und Forensiker hast Du natürlich erheblich mehr Ahnung, als so ein dahergelaufener Joe User.
Click to expand...

Könnte nicht ein Mod die Diskussion um die interne Funktionsweise in einen separaten Thread auslagern?
Ich gehe doch mal davon aus, daß Huschi und Joe erwachsen genug (und vermutlich auch beide kompetent genug) sind, die Diskussion auf einer sachlichen Ebene zu belassen und letztendlich gemeinsam Licht in die internen MySQL-Abläufe bringen können.
Ich jedenfalls wäre schon an einem Ergebnis dieser Diskussion interessiert, um auch für mich ein wenig Wissenszuwachs daraus zu schöpfen :)
 
Last edited by a moderator:
Huschi ist Mod. Mich würde die Diskussion übrigens auch sehr interessieren. ;)

Zu deiner Frage: Deine Webserver- / PHP-Wahl ist dafür völlig egal.
 
Los jetzt, reicht euch die Hände und versucht euer Wissen zur Problemlösung einzusetzen.

Ich habe gestern auf unseren uralt Server einmal die neue Piwik Version installiert.

Schon ging der open Wert auch dort etwas in die Höhe:

Das ist der Wert nach 24 Stunden.
[!!] Table cache hit rate: 19% (395 open / 2K opened)


Mit der alten Version war der Wert nach 185 Tagen so:

[OK] Table cache hit rate: 39% (770 open / 1K opened)

Vielleicht hilft das den Profis ja weiter:

http://piwik.org/docs/plugins/database-schema/

Da ist auch von FLOAT und BLOB die Rede.
 
Auf meiner Testinstallation von Oben läuft ebenfalls ein aktuelles Piwik, weshalb ich es (diesmal) als Ursache ausschliessen wollen würde.

1.) Deaktiviere bitte erstmal alle Cronjobs/Scripts welche OPTIMIZE und FLUSH ausführen.

2.) Dann bitte MySQLd einmal restarten und kurz darauf Folgendes ausführen:
Code: 
mysqlcheck --analyze --all-databases -uroot -p
Lindert das die Symptome etwas, oder bleibt Alles beim Alten?

Wenn Obiges getestet, dann:

3.) Du schriebst, dass die MyISAM-Tabellen nur zum Migrieren auf eine andere/aktuelle Forensoftware benötigt werden. Lege von diesen bitte ein Backup (mysqldump) an und konvertiere sie anschliessend testhalber mal nach InnoDB oder lösche sie temporär. Bringt das etwas?

4.) Bitte nochmal die vollständigen Ausgaben von mysqltuner und tuning-primer posten.
 
okay, bis auf Tuning-Primer werde ich das mal machen.

Der Läuft ja aus irgendwelchen Gründen nicht.

Ist schon die neuste Version, die auch 5.6 bedienen können soll, aber funktioniert trotzdem nicht.

Habe das Problem auch in diesem Thread mal beschrieben.
 
Joe User said:
Ersetze in tuning-primer bitte mal die erste Zeile durch diese:
Code: 
#!/bin/bash
Click to expand...


Geändert aber gleiches Verhalten

Code: 
 ./tuning-primer.sh

Using login values from ~/.my.cnf
- INITIAL LOGIN ATTEMPT FAILED -
Testing for stored webmin passwords:
 None Found
Could not auto detect login info!
Found potential sockets: /var/run/mysqld/mysqld.sock
Using: /var/run/mysqld/mysqld.sock
Would you like to provide a different socket?: [y/N] n
Do you have your login handy ? [y/N] : y
User: xxxx
Password: xxxxxxxxxxxxxxxxxxxxxx

Would you like me to create a ~/.my.cnf file for you? [y/N] : n
- FINAL LOGIN ATTEMPT FAILED -
Unable to log into socket: /var/run/mysqld/mysqld.sock

Echt verrückt. Ist auch nur der Tuning Primer, der da Probleme macht.

Mittlerweile läuft der Mysql Server fast eine Stunde. Sieht bis jetzt nicht so aus, als wenn unser Problem behoben wäre.

HTML: 
 >>  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.6.14-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 2G (Tables: 972)
[--] Data in InnoDB tables: 1G (Tables: 542)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 52)
[--] Data in MEMORY tables: 248K (Tables: 19)
[!!] Total fragmented tables: 80

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 53m 57s (8K q [2.616 qps], 903 conn, TX: 10M, RX: 2M)
[--] Reads / Writes: 49% / 51%
[--] Total buffers: 6.2G global + 12.6M per thread (200 max threads)
[OK] Maximum possible memory usage: 8.7G (27% of installed RAM)
[OK] Slow queries: 0% (0/8K)
[OK] Highest usage of available connections: 2% (4/200)
[OK] Key buffer size / total MyISAM indexes: 2.0G/1.3G
[!!] Key buffer hit rate: 62.7% (59 cached / 22 reads)
[OK] Query cache efficiency: 65.7% (2K cached / 3K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1K sorts)
[OK] Temporary tables created on disk: 9% (226 on disk / 2K total)
[OK] Thread cache hit rate: 99% (4 created / 903 connections)
[OK] Table cache hit rate: 33% (9K open / 29K opened)
[OK] Open file limit used: 21% (6K/32K)
[OK] Table locks acquired immediately: 100% (4K immediate / 4K locks)
[OK] InnoDB data size / buffer pool: 1.4G/4.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate

Kann das noch etwas laufen lassen und dann Punkt 3 und 4 angehen.
 
Der Installationspfad (/opt/mysql/server-5.6/bin) der MySQL-Binaries ist in der PATH-Variable enthalten? mysqladmin ist installiert?
 
Joe User said:
Der Installationspfad (/opt/mysql/server-5.6/bin) der MySQL-Binaries ist in der PATH-Variable enthalten? mysqladmin ist installiert?
Click to expand...

Den hatte ich so gesetzt:

Code: 
echo 'export PATH=$PATH:/opt/mysql/server-5.6/bin' | tee /etc/profile.d/mysql.server.sh


Nachdem ich jetzt gestern noch alle Punkte abgearbeitet habe, hier der Output nach 12 Stunden:

Code: 
 >>  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.6.14-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 517K (Tables: 8)
[--] Data in InnoDB tables: 1G (Tables: 522)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 52)
[--] Data in MEMORY tables: 372K (Tables: 13)
[!!] Total fragmented tables: 71

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 12h 46m 1s (55K q [1.209 qps], 7K conn, TX: 108M, RX: 17M)
[--] Reads / Writes: 51% / 49%
[--] Total buffers: 6.3G global + 12.6M per thread (200 max threads)
[OK] Maximum possible memory usage: 8.7G (27% of installed RAM)
[OK] Slow queries: 0% (0/55K)
[OK] Highest usage of available connections: 1% (3/200)
[OK] Key buffer size / total MyISAM indexes: 2.0G/787.0K
[OK] Key buffer hit rate: 97.3% (823 cached / 22 reads)
[OK] Query cache efficiency: 68.5% (20K cached / 30K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 7K sorts)
[OK] Temporary tables created on disk: 11% (3K on disk / 27K total)
[OK] Thread cache hit rate: 99% (3 created / 7K connections)
[!!] Table cache hit rate: 4% (4K open / 101K opened)
[OK] Open file limit used: 0% (282/32K)
[OK] Table locks acquired immediately: 100% (22K immediate / 22K locks)
[OK] InnoDB data size / buffer pool: 1.3G/4.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    table_cache (> 16384)

MyISAM ist praktisch nicht mehr vorhanden.
So würde das später auch in der Praxis erst mal aussehen.

Die Werte von open table cache hit und die vielen Tables auf Disk sind aber praktisch gleich.

Das wundert mich nicht wirklich, denn die MyISAM Datenbanken waren ja nicht aktiv in Benutzung.
 
You must log in or register to reply here.
Back
Top