Fragen zur Optimierung / concurrent_insert und table cache

labu
Posts: 11
Joined: 2011-06-24 15:57

Fragen zur Optimierung / concurrent_insert und table cache

Post by labu »

Hallo,

vor 2 Jahren habe ich hier schon einmal fachkundige Hilfe erhalten. Aus diesem Grund möchte ich auch bei meinem zweiten Server um Rat fragen.

Auf einem eigenen Server mit 4 GB Ram und Dual Core Cpu läuft ein Forum. Das Forum hat zu den Abendzeiten maximal 150 User online. Da es bei einigen Seitenimpressionen immer mal wieder zu kurzen Wartezeiten (2 sekunden) kommt, habe ich den SQL Server im Verdacht. Statische Seiten laufen immer super Schnell. Der Apache ist sauber.

Ich habe bereits das primer script und mysqltuner vor einigen Wochen installiert und bereits viel optimiert. Jetzt bleiben 2 Fragen übrig. Hier weiss nicht nicht weiter.

Die Hauptforentabellen sind myisam. Der Rest ist innodb.

1. Table Locking

Der Tuning primer hat eine Current Lock Wait ratio von 1:381 festgestellt.

Ich soll in Erwägung ziehen, low priority updates = 1 zu setzen. Auf innodb zu wechseln oder concurrent_instert = 2 zu wählen.
Low priority updates habe ich bereits vor einigen Tagen gesetzt und den Server neu gestartet.

Trotzdem ist die ration noch bei 1:381. Ein Wechsel auf innodb wäre zwar möglich, ich würde aber gerne auf myisam bleiben. Grund: Es kann immer wieder zu Problemen beim konvertieren kommen und dann stehe ich blöd da, wenn das Forum für Tage steht. myisam hat auch den Vorteil der Volltextsuche (auch wenn es im forum nicht benötigt wird).

Die Frage ist nun. Soll ich concurrent_insert = 2 setzen oder hat das Nachteile? z. B. in der Performance oder gibt es sonstige Probleme die dadurch auftauchen können?

Habt Ihr unabhängig davon einen Tipp?

2. Table Cache

Es gibt zwei Datenbanken.

DB 1 hat 30 Tabellen
DB 2 hat 60 Tabellen

= 90 Tabellen.

Auf dem Server gibt es aber ingesamt 759 Tabellen. Dies kommen wohl von Plesk. Müssen die überhaupt gecacht werden?
Der Primer sagt:

Current table_cache value = 900 tables
You have a total of 759 tables
You have 900 open tables.
Current table_cache hit rate is 42%
, while 100% of your table cache is in use
You should probably increase your table_cache

Soll ich erhöhen oder nicht?

Vielen lieben Dank für die erneute Hilfe.

Grüße
Top

ddm3ve
Moderator
Moderator
Posts: 1115
Joined: 2011-07-04 10:56

Re: Fragen zur Optimierung / concurrent_insert und table cac

Post by ddm3ve »

Zu 2.

Wie sieht die RAM Auslastung aus?
4 GB empfinde ich nicht als sonderlich viel.

Die Konfiguration des aktuellen Servers das eingesetzte OS und die Version wären im übrigen hilfreiche Informationen,
Du kannst und ich würde den table_cache vergrössern, beache aber ggf. das openfiles limits.

Zu 1.
concurrent_insert = 2 wäre in Deinem Fall wohl die einzigste Option.
Risiko könnte lediglich sein, dass die iops auf der Platte zu viel werden. Also hier die Platte das Bottleneck wird.
Ein Versuch ist es Wert und kann man im Zweifel auch wieder zurück nehmen.
Zumindest sollte das Table Locking abnehmen.
02:32:12 21.12.2012 und dann sind Deine Probleme alle unwichtig.
Top

labu
Posts: 11
Joined: 2011-06-24 15:57

Re: Fragen zur Optimierung / concurrent_insert und table cac

Post by labu »

Hallo ddm3ve,

danke für Deine Antwort.

Erstmal die Spezifikationen:

Intel(R) Core(TM)2 CPU 4400 @ 2.00GHz
Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-39-generic-pae i686)

zu 2,

Die Ram Auslastung ist nicht hoch. Immer im Bereich zwischen 20-40%. Ich habe die "top" Werte täglich im Blick und 40% ist sehr selten. Meistens im Bereich von 25% RAM Auslastung.

Du würdest den Table Cache also auch vergrößern, obwohl nur 90 Tabellen wirklich in Benutzung sind? die plesk tabellen werden denke ich nur benötigt wenn ich mich auf plesk einlogge..oder? open files limit ist klar.

zu 1, Wenn ich concurrent_instert = 2 setze, woran erkenne ich, dass ich es besser wieder ausschalten sollte?

Danke

Viele Grüße
Top

ddm3ve
Moderator
Moderator
Posts: 1115
Joined: 2011-07-04 10:56

Re: Fragen zur Optimierung / concurrent_insert und table cac

Post by ddm3ve »

Du hast mich falsch verstanden.
Mit der Server Konfiguration meinte ich die mysqld Konfiguration. Das ist sicherlich ausschlaggebend.

Der Tablecache wird nur so genutzt wie die Tabellen genutzt werden. Es ist also bei hohem Datenbankzugriff keine Seltenheit, dass der Tablecache deutlich mehr Objekte cacht, als physisch vorhanden sind. Also 1000 Tabellen gecacht werden obwohl da nur 100 vorhanden sind.

Das bedeutet für Dich, es werden nur die Tabellen gecacht je je nach transaktionstatus und aufkommen vom DBMS System gehalten werden müssen. Es ist also irrelevant ob dort die Plesk Tabellen vermeindlich nur Ballast dar stellen.
-> Dem ist im übrigen nicht so, da auch ohne viel Last, die Plesk Tabellen z.B. durch Mailserver etc. trotzdem angesprochen und genutzt werden.

Die regelt das DBMS im übrigen vollkommen eigenstädig. Hier hast Du keinen Einfluss und das wiederum bedeutet, table_cache anpassen.

2. concurrent_insert = 2
Das merkst Du dann, wenn neben dem mysqld ggf. auch die Systemlast (ioWait) ansteigt. Wenn die Load dauerhaft auf einem Faktor grösser 1,5 * Anzahl Cores Bei Dir also ca. 2-3 und / oder IOWait ständig im 2 Stelligen % Bereich bewegt.
Letztenendes, wenn Du merkst, dass die Anwendung / SQL Abfragen deutlich langsamer werden als ohne. Und natürlich der mysqld deutlich bei top etc. in der CPU Auslastung dominiert.
Das war aber sehr pauschal geschrieben und dient eigentlich als Fallback Kriterieum zur Umstellung. Wenn sich das in 1-2 Jahren mit zunehmender Last so entwickelt liegt es nicht unbedingt an dem Paramter und ist eine Rollback auch nicht zielführend.
02:32:12 21.12.2012 und dann sind Deine Probleme alle unwichtig.
Top

labu
Posts: 11
Joined: 2011-06-24 15:57

Re: Fragen zur Optimierung / concurrent_insert und table cac

Post by labu »

Hallo,

danke für Deine tolle Erklärung. Ich habe jetzt den Table Cache mal auf 1200 erhöht und die open files limit dementsprechend auf 3600 gesetzt. concurrent-instert = 2 wurde gesetzt.

Hier die my.cf.
Ist damit soweit alles ok oder gibt es einen größeren fauxpas? Sofern Du noch eine Idee zur Optimierung hast, immer her damit. Hab 1000 Dank

Code: Select all

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port      = 3306
socket      = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice      = 0

[mysqld]
set-variable=local-infile=0
#
# * Basic Settings
#

#
# * IMPORTANT
#   If you make changes to these settings and your system uses apparmor, you may
#   also need to also adjust /etc/apparmor.d/usr.sbin.mysqld.
#

user      = mysql
pid-file   = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port      = 3306
basedir      = /usr
datadir      = /var/lib/mysql
tmpdir      = /tmp
language   = /usr/share/mysql/english
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
# bind-address      = 127.0.0.1
#
# * Fine Tuning
#
key_buffer      = 64M
max_allowed_packet   = 32M
thread_stack      = 128K
thread_cache_size   = 8
max_connections        =  160

table_cache      = 1200
open_files_limit   = 3600

tmp_table_size      = 64M
max_heap_table_size   = 64M

join_buffer_size   = 2M
read_buffer_size   = 2M
sort_buffer_size   = 2M
read_rnd_buffer_size   = 4M
myisam_sort_buffer_size = 64M

innodb_buffer_pool_size   = 64M

low_priority_updates    = 1
concurrent_insert   = 2

#max_connections        = 150
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit       = 4M
query_cache_size        = 32M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log      = /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
#log_slow_queries   = /var/log/mysql/mysql-slow.log
#long_query_time = 1
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id      = 1
#log_bin         = /var/log/mysql/mysql-bin.log
expire_logs_days   = 10
max_binlog_size         = 100M
#binlog_do_db      = include_database_name
#binlog_ignore_db   = include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
#skip-innodb
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet   = 16M

[mysql]
#no-auto-rehash   # faster start of mysql but no tab completition

[isamchk]
key_buffer      = 16M

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the NDB Data Nodes (ndbd processes)
# not from the NDB Management Nodes (ndb_mgmd processes).
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1


#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/



Nach dem setzen von concurrent-insert = 2 steht dort noch immer 1: 353. Jetzt nur noch der Hinweis auf innoDB. Der Restart war zwar gerade erst aber bedeutet das, dass ich jetzt um die InnoDB nicht drum herum komme? Wie schwerwiegend ist diese Ratio?
Last edited by labu on 2013-08-21 17:54, edited 1 time in total.
Top

ddm3ve
Moderator
Moderator
Posts: 1115
Joined: 2011-07-04 10:56

Re: Fragen zur Optimierung / concurrent_insert und table cac

Post by ddm3ve »

Jetzt warte einfach mal 24 Stunden ab.

Soviel Zeit solltest Du der Datenbank schon mal geben.
Nebenbei bemerkt, die Datenbank kann auch nicht alles im table_cache abhandeln.
Also warte mal ab, wie sich die Hitrate verändert und der table_cache füllt.
02:32:12 21.12.2012 und dann sind Deine Probleme alle unwichtig.
Top