tuning primer table_cache hit rate is 4%

fulltilt
Posts: 356
Joined: 2006-08-27 02:06

tuning primer table_cache hit rate is 4%

Post by fulltilt »

tuning primer sagt:
Current table_cache value = 2500 tables
Current table_cache hit rate is 4%, while 100% of your table cache is in use
You should probably increase your table_cache

das scheint mir schon mit 2500 sehr hoch ...
Kann mir jemand dazu eine gute Config vorschlagen?

AMD Athlon(tm) 64 Processor 3700+
2048 MB Ram
2x SATA 160 GB
Debian 4 - Kernel 2.6.22.6

Code: Select all

my.cnf

key_buffer      = 128M
join_buffer_size        = 4M
sort_buffer             = 2M
read_buffer_size        = 2M
read_rnd_buffer_size    = 8M
myisam_sort_buffer_size = 64M
max_allowed_packet   = 1M
thread_stack      = 128K
thread_cache_size   = 10
max_connections         = 80
table_cache            = 2500
thread_concurrency     = 10
max_heap_table_size       = 128M
tmp_table_size            = 128M
open_files_limit          = 5000
#
# * Query Cache Configuration
#
query_cache_type          = 1
query_cache_size          = 48M
query_cache_limit         = 48M
max_connect_errors        = 10
log_warnings              = 2
long_query_time           = 2


tuning primer results:

Code: Select all

OPEN FILES LIMIT
Current open_files_limit = 5090 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
You currently have open more than 75% of your open_files_limit
You should set a higher value for open_files_limit in my.cnf

TABLE CACHE
Current table_cache value = 2500 tables
You have a total of 9222 tables
You have 2500 open tables.
Current table_cache hit rate is 4%, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
/usr/bin/tuning-primer.sh: line 325: bc: command not found
Current max_heap_table_size =  M
/usr/bin/tuning-primer.sh: line 325: bc: command not found
Current tmp_table_size =  M
Of 49017 temp tables, 48% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.
Top

braindead
RSAC
Posts: 257
Joined: 2002-10-22 09:49
Location: vorm Rechner

Re: tuning primer table_cache hit rate is 4%

Post by braindead »

Wieviel Tabellen hast du denn? Ulimits den Betriebsystems schon gecheckt?
Top

fulltilt
Posts: 356
Joined: 2006-08-27 02:06

Re: tuning primer table_cache hit rate is 4%

Post by fulltilt »

braindead wrote:Wieviel Tabellen hast du denn? Ulimits den Betriebsystems schon gecheckt?


You have a total of 9222 tables

Ich habe jetzt von der Load her keine massiven Probleme, aber ich halte die Empfehlung von tuning primer etwas happig :?
Bin mir daher nicht sicher, ob meine jetzige Config O.K. ist oder nicht ...
Top

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: tuning primer table_cache hit rate is 4%

Post by isotopp »

fulltilt wrote:You have a total of 9222 tables


[mysqld]
open_files_limit = 32000
table_cache = 12000

Ich habe jetzt von der Load her keine massiven Probleme, aber ich halte die Empfehlung von tuning primer etwas happig :?


Wie kommst Du zu dieser Ansicht?
Top

fulltilt
Posts: 356
Joined: 2006-08-27 02:06

Re: tuning primer table_cache hit rate is 4%

Post by fulltilt »

Danke isotopp,

ich hatte mich an Empfehlungen orientiert bzw. auch an Tipps einiger "Experten" :roll:
und vom Ram her die 2048 MB ... nicht gerade grosszügig ausgestattet.
PHP5 /FCGI, MySQL5, wie gesagt "noch" keine Resourcenprobleme ...
Also Du würdest empfehlen den table cache auf 12000 zu setzen?

isotopp wrote:[mysqld]
open_files_limit = 32000
table_cache = 12000
Wie kommst Du zu dieser Ansicht?
Top

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: tuning primer table_cache hit rate is 4%

Post by isotopp »

fulltilt wrote:Also Du würdest empfehlen den table cache auf 12000 zu setzen?


In MySQL bis einschließlich 5.0 cached der table_cache

1. den Inhalt der .frm Datei
2. das Filehandle

Beide Dinge haben nichts miteinander zu tun, werden aber dennoch einheitlich und zusammen gecached - in 5.1 ist das getrennt worden und der table_cache existiert so nicht mehr.

Wenn der table_cache kleiner ist als die Anzahl der benutzten Tabellen im System muß MySQL unnötig Dateien öffnen und schließen und das kann je nach Dateisystem und Dateisystem-Konfiguration lange dauern. Daher sollte der table_cache groß genug sein um die Daten aller im System enthaltenen Tabellen zu cachen. In Deinem System ist das mit ein wenig Reserve also eine Größe von 12000.
Top

blogster
Posts: 9
Joined: 2008-05-07 21:39

Re: tuning primer table_cache hit rate is 4%

Post by blogster »

Hi,
kurze Frage dazu:
Ich betreibe einen phpbb Forenserver.
Derzeit sind ca. 1500 Foren * 40 Tabellen (tägliche werdens natürlich mehr) angemeldet.
Also knapp 60.000 Tabellen.
Der Server verfügt über nen AMd Dual Core 6000+ und 8 GB Ram.
Was würdest du da empfehlen ?
Table Cache auf 60.000 ? ^^
Top

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: tuning primer table_cache hit rate is 4%

Post by isotopp »

Blogster wrote:Was würdest du da empfehlen ?
Table Cache auf 60.000 ? ^^


Nein, soweit ich weiß macht Linux bei so ca. 32000 Filehandles zu. Ich frage mich, warum Du diese Form der Tabellenstruktur gewählt hast, statt da sinnvoller und normalisierter aufzuteilen?
Top

blogster
Posts: 9
Joined: 2008-05-07 21:39

Re: tuning primer table_cache hit rate is 4%

Post by blogster »

Hi,
danke für deine Antwort.

;eines erachtens ist das beim phpbb nicht anders möglich.
Wenn du normal ein phpbb installierst werden ja die Tabellen mit dem Prefix phpbb erstellt also phpbb_config, phpbb_users usw.
Bei dem Forenserver wird dieser Prefix natürlich durch den Forennamen ersetzt.
Die Tabellen sind ja fest in der Software verdratet?!

Oder habe ich dich nun völlig falsch verstanden, und du meinst mit sinnvoller und normalisierter aufteilen was ganz anderes ^^
Top

freddy36
RSAC
Posts: 277
Joined: 2008-03-20 17:31

Re: tuning primer table_cache hit rate is 4%

Post by freddy36 »

isotopp wrote:Nein, soweit ich weiß macht Linux bei so ca. 32000 Filehandles zu.

Nein, ein halbwegs aktuelles Linux kann noch deutlich mehr, das ganze wird inzwischen wohl irgendwie in Abhängigkeit der Hardware vom Kernel berechnet.
Auf dicken Serven kann der Wert Standardmäßig durchaus mal im 1 Millionen Bereich liegen.

Guck einfach mal nach bei dir:
cat /proc/sys/fs/file-max
Den Wert kannst du auch selber anpassen.
Top

User avatar
isotopp
RSAC
Posts: 482
Joined: 2003-08-21 10:21
Location: Berlin

Re: tuning primer table_cache hit rate is 4%

Post by isotopp »

Freddy36 wrote:Nein, ein halbwegs aktuelles Linux kann noch deutlich mehr, das ganze wird inzwischen wohl irgendwie in Abhängigkeit der Hardware vom Kernel berechnet. Auf dicken Serven kann der Wert Standardmäßig durchaus mal im 1 Millionen Bereich liegen.


Dann kann es sich je nach benutzungshäufigkeitr der einzelnen Foren tatsächlich lohnen, diese Werte noch höher zu drehen. Eine kleine Messung sollte da ja schnell Antworten liefern.

Ich halte das gewählte Schema dennoch für fragwürdig.
Top

User avatar
Joe User
Project Manager
Project Manager
Posts: 11519
Joined: 2003-02-27 01:00
Location: Hamburg

Re: tuning primer table_cache hit rate is 4%

Post by Joe User »

isotopp wrote:Ich halte das gewählte Schema dennoch für fragwürdig.

ACK, das Erweitern des Schema um eine Kunden-ID würde genügen und schon bräuchte er nur noch 1*40 Tabellen. Die Anpassung des phpBB2 hält sich ebenfalls in Grenzen...
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Top

fulltilt
Posts: 356
Joined: 2006-08-27 02:06

Re: tuning primer table_cache hit rate is 4%

Post by fulltilt »

Dank noch mal an isotopp :-D

habe diese Werte seit gestern übernommen - läuft jetzt alles viel runder und die Load ist auch runtergegangen.

Ist bei diesen Werten noch etwas zu ändern:
max-connections (momentan 40) sollte der überhaupt angebeben werden?

und bei Joins:
join_buffer_size >= 4 M
This is not advised


isotopp wrote:
fulltilt wrote:Also Du würdest empfehlen den table cache auf 12000 zu setzen?


In MySQL bis einschließlich 5.0 cached der table_cache

1. den Inhalt der .frm Datei
2. das Filehandle

Beide Dinge haben nichts miteinander zu tun, werden aber dennoch einheitlich und zusammen gecached - in 5.1 ist das getrennt worden und der table_cache existiert so nicht mehr.

Wenn der table_cache kleiner ist als die Anzahl der benutzten Tabellen im System muß MySQL unnötig Dateien öffnen und schließen und das kann je nach Dateisystem und Dateisystem-Konfiguration lange dauern. Daher sollte der table_cache groß genug sein um die Daten aller im System enthaltenen Tabellen zu cachen. In Deinem System ist das mit ein wenig Reserve also eine Größe von 12000.
Top