table_open_cache Problem

U

Unifex

New Member
Ich habe hier ein merkwürdiges Phänomen und ersuche Hilfe bei den Experten.

Der MySql Server hat in seiner my.cnf den Wert für table_open_cache = 5000 stehen.

mysqltuner sagt allerdings:

Code: 
[!!] Table cache hit rate: 0% (1K open / 5M opened)

PHPMyAdmin sagt:

Code: 
Problem:
Hohe Anzahl an Tabellen-Öffnungen.

Öffnen von Tabellen erfordert Festplatten I/O, welches langsam ist. Erhöhung von Table_open_cache könnte dies vermeiden.

Häufigkeit von Tabellenöffnungen: 5.35 pro Sekunde, dieser Wert sollte weniger als 10 pro Stunde sein

Hmm, ich finde jetzt 5000 als Wert nicht gerade wenig. Trotzdem scheint er null aus dem Cache zu lesen. Alle Datenbanken zusammen kommen im Leben nicht auf 5000 Tabellen. Oder ist meine Rechnung irgendwie falsch?
 
Bitte immer die vollständige Ausgabe von mysqltuner oder tuning-primer posten. Auch die vollständige my.cnf hilft weiter und azusätzlich noch Infos zum System.
Ich tippe darauf, dass die Dateideskriptoren reglementiert sind. Entweder durch das System oder per open_files_limit.

huschi.
 
okay, hier die angeforderten Daten:

Server hat 32 GB Ram 8 Cores

Output mysqltuner.pl

Code: 
[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
[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: 1008K (Tables: 19)
[!!] Total fragmented tables: 82

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 12d 21h 43m 44s (15M q [13.756 qps], 273K conn, TX: 18B, RX: 5B)
[--] Reads / Writes: 34% / 66%
[--] Total buffers: 22.1G global + 2.9M per thread (300 max threads)
[OK] Maximum possible memory usage: 22.9G (73% of installed RAM)
[OK] Slow queries: 0% (1/15M)
[OK] Highest usage of available connections: 17% (51/300)
[OK] Key buffer size / total MyISAM indexes: 4.0G/1.3G
[OK] Key buffer hit rate: 100.0% (22M cached / 1K reads)
[OK] Query cache efficiency: 77.5% (7M cached / 10M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 1% (5K temp sorts / 368K sorts)
[OK] Temporary tables created on disk: 11% (122K on disk / 1M total)
[OK] Thread cache hit rate: 99% (51 created / 273K connections)
[!!] Table cache hit rate: 0% (1K open / 5M opened)
[OK] Open file limit used: 19% (1K/10K)
[OK] Table locks acquired immediately: 99% (7M immediate / 7M locks)
[OK] InnoDB data size / buffer pool: 1.3G/16.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    table_cache (> 5000)

my.cnf :

Code: 
[client]
port                            = 3306
socket                          = /var/run/mysqld/mysqld.sock

[mysqld]

# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
innodb_buffer_pool_size = 16G

# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin

# These are commonly set, remove the # and set as required.
basedir        = /opt/mysql/server-5.6
datadir = /opt/mysql/server-5.6/data
port = 3306
# server_id = .....
socket = /var/run/mysqld/mysqld.sock
pid-file = /var/run/mysqld/mysqld.pid
bind-address  = 127.0.0.1
default-storage-engine = InnoDB
user        = mysql
tmpdir        = /tmp
tmp_table_size=32M
max_heap_table_size=32M
key_buffer = 2048M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 256
myisam-recover = BACKUP
read_rnd_buffer_size = 256K
max_connections = 300
table_open_cache = 5000
sort_buffer_size = 256K
read_buffer_size = 256K
key_buffer_size = 4096M
join_buffer_size = 2048K
query_cache_limit    = 64M
query_cache_size = 2048M
query_cache_type=1
#log_slow_queries    = /var/log/mysql/mysql-slow.log
long_query_time = 2
expire_logs_days = 10
max_binlog_size = 100M
innodb_file_per_table
innodb_data_file_path = ibdata1:10G:autoextend
innodb_log_buffer_size=16M
innodb_flush_method=O_DIRECT
innodb_flush_log_at_trx_commit=1
innodb_log_file_size = 4GB
innodb_buffer_pool_size = 16G
innodb_additional_mem_pool_size = 8M
innodb_support_xa = 0
innodb_lock_wait_timeout = 100
query_cache_min_res_unit = 2K

Momentan laufen da nur ein paar Testforen drauf und ein Tracking, was die hohe Schreibrate erklärt.

MyISAM sind nur die alten Foren, die nur noch für den Import in die Neuen Foren gebraucht werden.

Zukünftig werden da drei Foren auf InnoDB laufen.

Vielleicht noch eine Zusatzfrage im Bezug auf meine MySql Version 5.6. Ich bin auf folgende Aussage gestoßen, die den Query Cache betrifft, in Verbindung ab Version 5.5 von MySql:

Personally disable the MySQL query cache, it is just crap and is designed for systems with 1 or 2 cpus at the most - old design. Everything is protected by a single mutex and almost everyone who strives for performance disables it and lets the query run as it is quicker as most of the time the cache is being invalidated due to row updates etc (remember, as soon as a row is updated/inserted/deleted then the query cache has to invalidate anything in cache). It is awful. Unfortunately if you are on stock MySQL 5.1 even disabling it leaves the mutex in place, you either need to migrate to Percona (great software, I use this) or stock MySQL 5.5.
Click to expand...

Könnte er damit recht haben?
 
Die geringe Anzahl von Tabellen und der hohe Wert für Opened_tables weißt tatsächlich auf ein Problem hin. und wie ich in der my.cnf sehe, ist kein open_files_limit gesetzt. Damit gilt der Default-Wert der dem Table-Cache negativ beeinflusst.
Nur der Vollständigkeit halber: Ein weiterer Grund kann ein häufiges Ausführen von "flush tables" oder "optimize tables" sein.

Zum Query-Cache:
Das ist ein altes und zwiespältiges Thema. Jede pauschale Aussage dazu ist aber definitiv falsch.
In erster Linie geht es immer um die Anwendungen die sich der Datenbank bedienen. Im "normalen Serverumfeld" ist der Query-Cache i.d.R. hilfreich.
(An alle Haarspalter: sehr allgemein formulierte pauschale Aussage, die bei engerer Betrachtung sich als teilweise falsch raus stellen kann.)

huschi.
 
Huschi said:
Die geringe Anzahl von Tabellen und der hohe Wert für Opened_tables weißt tatsächlich auf ein Problem hin. und wie ich in der my.cnf sehe, ist kein open_files_limit gesetzt. Damit gilt der Default-Wert der dem Table-Cache negativ beeinflusst.
Click to expand...

phpMyAdmin zeigt mir bei dem Servervariablen für das open File einen Wert von 10310 an.

Huschi said:
Nur der Vollständigkeit halber: Ein weiterer Grund kann ein häufiges Ausführen von "flush tables" oder "optimize tables" sein.
Click to expand...

optimize macht das Backup jede Nacht, aber nur für eine einzige Datenbank die eher nicht so ins Gewicht fällt.


Wie würdest du jetzt an das Problem ran gehen?
 
Einfach wild irgendwelche Optionen in die my.cnf zu schreiben, zudem noch doppelt oder veraltet oder falsch, bringt gar nichts.
MySQL kennt schon seit Ewigkeiten mehrere Optionen für die unterschiedlichen Aspekte des Table-Cache (Hint: table_open_cache allein reicht nicht).

Das Open-Files-Limit hat im Fall des OP mal rein gar nichts mit dem Table-Cache zu schaffen, wir sind nicht mehr in der Steinzeit.


my.cnf gemäss aktueller Doku neu aufbauen, einspielen, fertig.


Zum Query-Cache: It depends.
Ausprobieren ist hier angesagt.
 
Geht es auch etwas konstruktiver, als zu sagen alles ist Mist?

Hier ist nicht jeder als "MySql Gott" wie du auf die Welt gekommen.
 
Klar, wenn man so höflich fragt wie Du gerne (bitte die Pfade selbst anpassen):

Zuerst ein Backup der Datenbanken anlegen
Code: 
mysqldump --flush-logs --master-data=2 --lock-all-tables --delete-master-logs --events --all-databases -uroot -p > /tmp/mysqldump.sql
MySQLd stoppen.
Danach die InnoDB-Files und Logs löschen
Code: 
rm /data/db/mysql/ibdata[0-9] /data/db/mysql/ib_logfile[0-9]
Sicheres temporäres Verzeichniss für MySQL anlegen:
Code: 
mkdir -p /data/tmp/mysql
chmod 1770 /data/tmp/mysql
chown mysql:mysql /data/tmp/mysql
Von mir für Dein System als Basis empfohlene my.cnf erstellen:
Code: 
[client]
port                            = 3306
socket                          = /tmp/mysql.sock

[mysql]
prompt                          = \u@\h [\d]>\_
no_auto_rehash

[mysqld]
user                            = mysql
port                            = 3306
socket                          = /tmp/mysql.sock
bind-address                    = 127.0.0.1
basedir                         = /usr/local
datadir                         = /data/db/mysql
tmpdir                          = /data/tmp/mysql
slave-load-tmpdir               = /data/tmp/mysql
secure-file-priv                = /data/tmp/mysql
log-bin                         = /data/db/mysql/mysql-bin
relay-log                       = /data/db/mysql/relay.log
relay-log-index                 = /data/db/mysql/relay.index
relay-log-info-file             = /data/db/mysql/relay.info
master-info-file                = /data/db/mysql/master.info
#master-host                     = <hostname>
#master-user                     = <username>
#master-password                 = <password>
#master-port                     = 3306
#auto_increment_increment        = 10
#auto_increment_offset           = 1
server-id                       = 1
back_log                        = 500
sync_binlog                     = 1
binlog_cache_size               = 4M
binlog_stmt_cache_size          = 4M
max_binlog_size                 = 500M
binlog-format                   = MIXED
expire_logs_days                = 30
slow-query-log                  = 1
slow-query-log-file             = /data/db/mysql/slow-query.log
slave_compressed_protocol       = 1
safe-user-create                = 1
delay-key-write                 = ALL
myisam-recover                  = FORCE,BACKUP
key_buffer_size                 = 2048M
max_allowed_packet              = 64M
max_heap_table_size             = 64M
tmp_table_size                  = 64M
thread_stack                    = 192K
table_cache                     = 8192
table_open_cache                = 8192
table_definition_cache          = 8192
query_cache_type                = 1
query_cache_size                = 64M
query_cache_limit               = 4M
query_cache_min_res_unit        = 2K
thread_cache_size               = 150
max_connections                 = 200
ft_max_word_len                 = 20
ft_min_word_len                 = 3
long_query_time                 = 1
local-infile                    = 0
log-warnings                    = 2
log-slave-updates
log-queries-not-using-indexes
skip-external-locking
skip-symbolic-links
innodb_thread_concurrency       = 8
innodb_buffer_pool_size         = 4G
innodb_buffer_pool_instances    = 4
innodb_additional_mem_pool_size = 16M
innodb_data_home_dir            = /data/db/mysql
innodb_log_group_home_dir       = /data/db/mysql
innodb_data_file_path           = ibdata1:2000M;ibdata2:2000M;ibdata3:10M:autoextend
innodb_flush_method             = O_DIRECT
innodb_log_file_size            = 256M
innodb_log_buffer_size          = 16M
innodb_log_files_in_group       = 2
innodb_flush_log_at_trx_commit  = 2
innodb_max_dirty_pages_pct      = 90
innodb_file_per_table           = 1
innodb_purge_threads            = 1
innodb_strict_mode              = 1
innodb_old_blocks_time          = 1000
innodb_stats_on_metadata        = 0
innodb_write_io_threads         = 8
innodb_read_io_threads          = 8
innodb_io_capacity              = 200
innodb_open_files               = 8192

[mysqldump]
max_allowed_packet              = 64M
quote_names
quick

[isamchk]
key_buffer_size                 = 256M

[myisamchk]
key_buffer_size                 = 256M

[mysqlhotcopy]
interactive_timeout
MySQLd starten.
MySQLdump zurückspielen:
Code: 
mysql -uroot -p < /tmp/mysqldump.sql
Nach 48 Stunden bitte den vollständigen Output von mysqltuner und tuning-primer sowie die my.cnf (sofern mehr als Pfade angepasst) posten.
 
Also erst mal danke für die Anregung. Einige Parameter kenne ich überhaupt nicht. Ich werde mich einmal einlesen, was die genau machen, damit ich das auch im Ganzen verstehe und dann umsetzen kann.
 
Soweit ist das Meiste umgesetzt.

Anzumerken ist noch etwas bei folgenden Parametern:

table_cache = 8192
table_open_cache = 8192

Machen zusammen in einer cnf so keinen Sinn, da table_open_cache einfach der Parameter ist in neueren MySql Versionen für table_cache

Da ich eine Version 5.6 Einsetze habe ich noch folgenden Parameter mit eingefügt:

explicit_defaults_for_timestamp = TRUE

Jetzt gibt es beim Start nur noch zwei Warnungen im Log:

Nr.1

Code: 
[Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.

Habe ich mir noch nicht angeschaut

Nr.2

Code: 
Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.

Wenn ich das richtig verstehe, soll das wohl bedeuten den Eintrag "innodb_additional_mem_pool_size = 16M" durch "innodb_use_sys_malloc = ON" zu ersetzen.

Das habe ich so aber noch nicht getestet. Scheint aber irgendwie eine neue Speicherverwaltung zu sein.
 
Nr1 bedeutet, dass der Parameter in zukünftigen Versionen (vermutlich ab 5.7/6.0) umbenannt wird.
Nr2 bedeutet, dass die genannten Parameter in zukünftigen Versionen (vermutlich ab 5.7/6.0) nicht mehr verwendet werden und dann auch eine andere Speicherverwaltung eingesetzt wird.

Für Deine aktuelle Version 5.6 und dessen Konfiguration hat das erstmal keine Relevanz.
 
Ich habe jetzt einfach mal innodb_use_sys_malloc = ON gesetzt und "innodb_additional_mem_pool_size = 16M" augeklammert.

Die Warnung ist weg.

Scheint soweit zu funktionieren.


Einziges Problem (hatte ich vorher aber schon) ist das Tuning-Primer nicht funktioniert. Er hat wohl als einziges Programm Probleme mit der Socks.

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: xxxxxxxxx
Password: xxxxxxxxxxxxxxxxxxxxx

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 merkwürdig denn alle anderen Programme funktionieren und in der my.cnf steht das auch soweit richtig drin.

Die sieht bis jetzt übrigens so aus:

Code: 
[client]
port                            = 3306
socket                          = /var/run/mysqld/mysqld.sock

[mysqld]
user		                        = mysql
port = 3306
socket                          = /var/run/mysqld/mysqld.sock
bind-address                    = 127.0.0.1
basedir		                      = /opt/mysql/server-5.6
datadir                         = /opt/mysql/server-5.6/data
tmpdir		                      = /opt/mysql/tmp
slave-load-tmpdir               = /opt/mysql/tmp
secure-file-priv                = /opt/mysql/tmp
log-bin                         = /opt/mysql/loginfo/mysql-bin
relay-log                       = /opt/mysql/loginfo/relay.log
relay-log-index                 = /opt/mysql/loginfo/relay.index
relay-log-info-file             = /opt/mysql/loginfo/relay.info
master-info-file                = /opt/mysql/loginfo/master.info
#master-host                     = <hostname>
#master-user                     = <username>
#master-password                 = <password>
#master-port                     = 3306
#auto_increment_increment        = 10
#auto_increment_offset           = 1
default-storage-engine          = InnoDB
server-id                       = 1
back_log                        = 500
sync_binlog                     = 1
binlog_cache_size               = 4M
binlog_stmt_cache_size          = 4M
max_binlog_size                 = 500M
binlog-format                   = MIXED
expire_logs_days                = 30
slow-query-log                  = 1
slow-query-log-file             = /opt/mysql/loginfo/slow-query.log
slave_compressed_protocol       = 1
safe-user-create                = 1
delay-key-write                 = ALL
myisam-recover                  = FORCE,BACKUP
key_buffer_size                 = 2048M
max_allowed_packet              = 64M
max_heap_table_size             = 64M
tmp_table_size                  = 64M
thread_stack = 192K
table_open_cache                = 8192
table_definition_cache          = 8192
query_cache_type                = 1
query_cache_size                = 64M
query_cache_limit               = 4M
query_cache_min_res_unit        = 2K
thread_cache_size               = 150
max_connections                 = 200
ft_max_word_len                 = 20
ft_min_word_len                 = 3
long_query_time                 = 1
local-infile                    = 0
log-warnings                    = 2
log-slave-updates
log-queries-not-using-indexes
skip-external-locking
skip-symbolic-links
innodb_thread_concurrency       = 8
innodb_buffer_pool_size         = 4G
innodb_buffer_pool_instances    = 4
#innodb_additional_mem_pool_size = 16M
innodb_use_sys_malloc           = ON
innodb_data_home_dir            = /opt/mysql/server-5.6/data
innodb_log_group_home_dir       = /opt/mysql/server-5.6/data
innodb_data_file_path = ibdata1:10G:autoextend
innodb_flush_method             = O_DIRECT
innodb_log_file_size            = 256M
innodb_log_buffer_size          = 16M
innodb_log_files_in_group       = 2
innodb_flush_log_at_trx_commit  = 2
innodb_max_dirty_pages_pct      = 90
innodb_file_per_table           = 1
innodb_purge_threads            = 1
innodb_strict_mode              = 1
innodb_old_blocks_time          = 1000
innodb_stats_on_metadata        = 0
innodb_write_io_threads         = 8
innodb_read_io_threads          = 8
innodb_io_capacity              = 200
innodb_open_files               = 8192
explicit_defaults_for_timestamp = TRUE


[mysqldump]
max_allowed_packet              = 64M
quote_names
quick

[isamchk]
key_buffer_size                 = 256M

[myisamchk]
key_buffer_size                 = 256M

[mysqlhotcopy]
interactive_timeout
 
Okay, sind noch keine 48 Stunden aber das eigentliche Problem mit den Tables scheint nicht gelöst zu sein:

Ausgabe: [!!] Table cache hit rate: 3% (1K open / 50K opened)

Empfehlung: Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
table_cache (> 8192)


Ich kann den Wert doch wohl nicht auf 50.000 stellen oder?
 
Du kannst die beiden table_* Werte erstmal verdoppeln, also auf 16384
Die Werte zu hoch zu setzen, ist irgendwann auch kontraproduktiv.
Stattdessen solltest Du die Ursachen für die vielen Table-Öffnungen reduzieren.
Am Effektivsten ist hier das konsequente Vermeiden von TEXT und BLOB Rows, da diese grundsätzlich auf die HDD geschrieben werden müssen, da sie nicht gecached werden können. Dadurch steigen die Zähler der table_* Werte bei jedem einzelnen Zugriff auf diese Tabellen, völlig egal ob Read oder Write. Bei im Cache liegenden Tabellen ist das hingegen nicht der Fall, da die Tabellen hier im Optimalfall nur einmal beim ersten Zugriff geöffnet werden müssen und dann offen bleiben.


EDIT: Zum Vergleich mal mysqltuner von meinem Testsystem mit nahezu identischer my.cnf (MySQL 5.5.34), mit nur ganz wenigen selten benötigten TEXT/BLOB Rows:
Code: 
[root@devnull:~] # ./scripts/mysqltuner.pl

 >>  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

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

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1M (Tables: 1)
[--] Data in InnoDB tables: 1G (Tables: 361)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MEMORY tables: 0B (Tables: 1)
[!!] Total fragmented tables: 50

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 6d 5h 43m 50s (1M q [2.390 qps], 64K conn, TX: 2B, RX: 357M)
[--] Reads / Writes: 54% / 46%
[--] Total buffers: 4.2G global + 2.7M per thread (200 max threads)
[OK] Maximum possible memory usage: 4.7G (55% of installed RAM)
[OK] Slow queries: 1% (16K/1M)
[OK] Highest usage of available connections: 7% (15/200)
[OK] Key buffer size / total MyISAM indexes: 8.0M/1.4M
[OK] Key buffer hit rate: 100.0% (195K cached / 0 reads)
[OK] Query cache efficiency: 28.4% (194K cached / 684K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 27K sorts)
[OK] Temporary tables created on disk: 3% (2K on disk / 60K total)
[OK] Thread cache hit rate: 99% (15 created / 64K connections)
[OK] Table cache hit rate: 40% (271 open / 666 opened)
[OK] Open file limit used: 0% (5/11K)
[OK] Table locks acquired immediately: 100% (1M immediate / 1M locks)
[OK] InnoDB data size / buffer pool: 1.4G/4.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
 
Last edited by a moderator:
Ich weiß der Großteil der Community hält es für Kontraproduktiv wenn wir Beide in einem Thread schreiben. Daher habe ich mich seit Deinem bisher erfolglosen Eingreifen auch zurück gehalten. Aber nun musst Du mir zwei Dinge erklären:

Joe User said:
Die Werte zu hoch zu setzen, ist irgendwann auch kontraproduktiv.
Click to expand...
Warum beim Table-Cache?

das konsequente Vermeiden von TEXT und BLOB Rows, da diese grundsätzlich auf die HDD geschrieben werden müssen, da sie nicht gecached werden können. [...]
Click to expand...
Das gilt doch nur für Content-Caches wie z.B. der Query-Cache.
Der Table-Cache ist nur ein Dateideskriptor-Cache. Der hat mit dem Inhalt rein gar nichts zu tun.
Provokatives "Oder?".

@Unifex:
Unifex said:
Machen zusammen in einer cnf so keinen Sinn, da table_open_cache einfach der Parameter ist in neueren MySql Versionen für table_cache
Click to expand...
Du hast es richtig erkannt. Die Variable "table_cache" ist seit 5.1.3 depricated und sollte und braucht nicht mehr verwendet werden.

Was mich bei Deiner Statistik wundert, ist: Nur 1K Tabellen sind geöffnet, obwohl Du 8K eingestellt hast.
Aber sicherlich hat Joe eine Erklärung.

huschi
 
Huschi said:
Warum beim Table-Cache?
Click to expand...
http://dev.mysql.com/doc/refman/5.6/en/table-cache.html

Huschi said:
Provokatives "Oder?".
Click to expand...
Jain ;-) Durch TEXT/BLOB werden temporäre Tabellen on disk erzeugt, welche nach ihrer Nutzung wieder von der Disk geputzt werden. Durch Letzteres werden auch die FDs im Table-Cache als ungenutzt markiert und beim nächsten Zugriff auf die Tabelle wieder neue FDs vergeben und im Table-Cache eingetragen. Somit hat der Inhalt beziehungsweise das Schema einer Tabelle durchaus Einfluss auf den Table-Cache.
Du darfst mich aber gerne verbessern.

Huschi said:
Was mich bei Deiner Statistik wundert, ist: Nur 1K Tabellen sind geöffnet, obwohl Du 8K eingestellt hast.
Aber sicherlich hat Joe eine Erklärung.
Click to expand...
Ja, von seinen ~1600 Tabellen waren halt nur ~1000 als offen im Table-Cache markiert. Ein völlig normales Verhältnis.
 
Joe User said:
http://dev.mysql.com/doc/refman/5.6/en/table-cache.html
Click to expand...
Geht es etwas genauer?

Durch TEXT/BLOB werden temporäre Tabellen on disk erzeugt
Click to expand...
Ebenfalls bitte genauer: Bei welchen Aktionen?
Und welche Aktionen führen dabei zur Erhöhung von Open_tables?

Und eine weitere Frage stellt sich natürlich ebenfalls:
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?

edit:
Ja, von seinen ~1600 Tabellen waren halt nur ~1000 als offen im Table-Cache markiert. Ein völlig normales Verhältnis.
Click to expand...
Und wie erklärst Du Dir dann das Verhältnis zu Opened_tables mit fast 5M innerhalb von 24 Stunden?

huschi.
 
Last edited by a moderator:
Also das sind gute Hinweise.

Auf dem Server sind nur ein paar Testforen. Wirklich als aktive Anwendung ist momentan nur Piwik am laufen.

Das ding macht fast nichts anderes als jede Sekunde mehrere Aktionen in die Datenbank zu schreiben.

Daten in Tabellen, die kaum mal gelesen werden, es sei den es findet eine Aufbereitung für Statistiken statt.

Es wäre auch vollkommener Blödsinn, die alle cachen zu wollen.
Wichtiger sind ja später die anderen Anwendungen auf dem Server und die werden ja viel mehr lesenden Zugriff haben.

Wenn dann irgendwann 5M Tabellen geöffnet wurden ist natürlich klar, das der Cache in Relation dazu fast gegen 0 tendiert (8k).

Vielleicht sollte ich Piwik auf einen anderen Server laufen lassen.

Übrigens gibt es einen echt feinen Parameter für dieses Open Files "Problem" ab der Version 5.6.6

table_open_cache_instances = x

Wobei X die Anzahl Cores sein sollte.

Das verteilt die Instancen auf die Kerne.

Danach sieht es dann nur noch so aus bei mir:

[!!] Table cache hit rate: 19% (8K open / 41K opened)
 
Meine Theorie bezüglich Piwik, muss ich vielleicht revidieren.

Ich habe mal eben mysqltuner auf unserem alten Tracking System laufen lassen, wo nur Piwik läuft. Das läuft schon 185 Tage durch

Es ist eine schmaler Vserver mit alter Datenbank und keinem Innodb.

Dort wir Apache eingesetzt anstatt Nginx......

Das Ergebnis war erstaunlich was die Open Files und Table cache hit angeht:

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.1.58-1ubuntu1-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 5G (Tables: 351)
[--] Data in MEMORY tables: 1M (Tables: 2)
[!!] InnoDB is enabled but isn't being used
[!!] Total fragmented tables: 16

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 185d 8h 56m 20s (63M q [3.953 qps], 10M conn, TX: 45B, RX: 20B)
[--] Reads / Writes: 48% / 52%
[--] Total buffers: 394.0M global + 8.4M per thread (300 max threads)
[!!] Maximum possible memory usage: 2.9G (145% of installed RAM)
[!!] Slow queries: 8% (5M/63M)
[!!] Highest connection usage: 96%  (289/300)
[OK] Key buffer size / total MyISAM indexes: 256.0M/1.6G
[OK] Key buffer hit rate: 99.6% (796M cached / 2M reads)
[OK] Query cache efficiency: 65.7% (20M cached / 30M selects)
[OK] Query cache prunes per day: 8
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 5M sorts)
[OK] Temporary tables created on disk: 0% (49 on disk / 5M total)
[OK] Thread cache hit rate: 99% (7K created / 10M connections)
[OK] Table cache hit rate: 39% (770 open / 1K opened)
[OK] Open file limit used: 11% (1K/10K)
[OK] Table locks acquired immediately: 99% (27M immediate / 27M locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Add skip-innodb to MySQL configuration to disable InnoDB
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce your overall MySQL memory footprint for system stability
    Reduce or eliminate persistent connections to reduce connection usage
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    max_connections (> 300)
    wait_timeout (< 28800)
    interactive_timeout (< 28800)
 
You must log in or register to reply here.
Back
Top