RootForum Community

Posted: **2011-06-24 16:02**

Hallo,

Ich bin durch zuviel lesen verunsichert worden und hätte von euch nun gerne eine Einschätzung zu den weiter unten genannten Punkten / Fragen.

Server:
Intel Xeon X3430 Processor
(2.40GHz, 4C, 8M Cache, 95W TDP, Turbo)
8GB Arbeitsspeicher 1333MHz
2x500GB SATA 7,2k 3,5Zoll Festplatte Hot Plug
1 PERC H200A RAID Controller - Raid 1

Domains / Anwendungen:

50 Domains
- Blogs & Infoseiten - mittlere Last
- 2 größere Foren - Die Foren machen wohl den großteil der Querys aus
- 2 Online Shops - einige Besucher aber wenig Last

Datenbanken Insgesamt: 70
Tabellen Insgesamt: 1960
Größte DB ist ca. 100 MB / Tendenz steigend

Online gleichzeitig ca. 180
Zu Lastzeiten auch mal 300

DB Abfragen kann ich nicht weiter optimieren, da ich mich nicht auskenne.

-----------------------

Nachdem ich die beiden gängingen Tuning Programme ausgeführt hatte, habe ich die folgenden Werte etwas erhöht. Hier die my.cnf

my.cnf
---
set-variable = key_buffer_size=256M
set-variable = max_allowed_packet=100M
set-variable = thread_stack=128K
set-variable = table_cache=2048
set-variable = sort_buffer_size=4M
set-variable = net_buffer_length=8K
set-variable = myisam_sort_buffer_size=128M
set-variable = max_connections=600
set-variable = wait_timeout=28800
set-variable = interactive_timeout=28800
set-variable = query_cache_size=512M
set-variable = query_cache_limit=32M
set-variable = read_buffer_size=4M
set-variable = tmp_table_size=1024M
set-variable = max_heap_table_size=1024M
set-variable = read_buffer_size=4M
set-variable = read_rnd_buffer_size=8M
set-variable = join_buffer_size=8M
set-variable = thread_cache_size=20
set-variable = thread_concurrency=8

----

1, tmp_table_size & max_heap_table_size

Frage: sollen diese werte jetzt gleich sein oder nicht? Ich habe keine Arbeitsspeicher / memory Tabellen sondern nur den typ myisam.

Ist der eingetragene Wert zu groß?

2, query_cache_size & query_cache_limit

Frage: Durch viel lesen und vergleichen ist mir aufgefallen, dass meine Werte für den "size" evtl. zu groß sind. Der Tunig primer + mysqltuner haben mir allerdings eine Erhöhung empfohlen. Nach unten schrauben oder so lassen?

3, Welche Werte müssen / sollten verändert werden? Vor allem im Bereich Thread, join und Buffer?

Danke für die Beantwortung der Fragen...vielleicht fällt ja auf den ersten Blick etwas auf?! Meine große Sorge liegt darin, dass ich evtl. einen Wert total falsch eingestellt habe und ich dadurch Probleme bekomme.

---

Hier die primer auswertung:

WORKER THREADS
Current thread_cache_size = 20
Current threads_cached = 18
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 600
Current threads_connected = 2
Historic max_used_connections = 27
The number of used connections is 4% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating
No InnoDB Support Enabled!

MEMORY USAGE
Max Memory Ever Allocated : 1.39 G
Configured Max Per-thread Buffers : 14.12 G
Configured Max Global Buffers : 778 M
Configured Max Memory Limit : 14.88 G
Physical Memory : 7.80 G

nMax memory limit exceeds 90% of physical memory

KEY BUFFER
Current MyISAM index space = 141 M
Current key_buffer_size = 256 M
Key cache miss rate is 1 : 3124
Key buffer free ratio = 77 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 512 M
Current query_cache_used = 234 M
Current query_cache_limit = 16 M
Current Query cache Memory fill ratio = 45.77 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 4 M
Current read_rnd_buffer_size = 7 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 8.00 M
You have had 11952 queries where a join could not use an index properly
join_buffer_size >= 4 M - This is not advised
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.

OPEN FILES LIMIT
Current open_files_limit = 4706 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 2048 tables
You have a total of 1945 tables
You have 1750 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 1023 M
Current tmp_table_size = 1.00 G
Of 67237 temp tables, 35% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
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.

TABLE SCANS
Current read_buffer_size = 3 M
Current table scan ratio = 475 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 654
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'

---

so wie ich diese Auswertung jetzt verstehe, muss ich mit OPEN FILES LIMIT viel höher, muss mit join_buffer_size unter 4 und muss mit tmp_table_size und heap weiter hoch?

danke

Posted: **2011-06-24 21:30**

Moin labu,

zunächst ist "set-variable" ein lästiges Überbleibsel aus Zeiten von MySQL3 und seit Jahren deprecated, was soviel heisst wie, dass man "set-variable" nicht mehr verwenden soll.

Bevor es weitergeht, legst Du bitte als root erstmal ein vollständiges Backup Deiner Datenbanken an:

Code: Select all

mysqldump --flush-logs --master-data --lock-all-tables --delete-master-logs --all-databases -uroot -p > /root/mysqldump.sql

labu wrote: set-variable = thread_stack=128K
set-variable = net_buffer_length=8K
set-variable = wait_timeout=28800
set-variable = interactive_timeout=28800

An den diversen Timeouts, der Net-Buffer-Length und dem Thread-Stack sollte man nicht ohne zwingenden Grund drehen, also bitte raus damit.

labu wrote: set-variable = tmp_table_size=1024M
set-variable = max_heap_table_size=1024M

tmp_table_size und max_heap_table_size sollten möglichst die gleiche Grösse haben. Die Grösse selbst sollte dabei nur so gross sein, dass bei Operationen welche temporäre Tabellen benötigen, alle Daten in eine einzelne temporäre Tabelle passen. Bei den heute üblichen Webapplikationen (etwas anderes nutzt Du ja nicht) reichen hier meist 64MB völlig aus.

labu wrote: set-variable = query_cache_size=512M
set-variable = query_cache_limit=32M

Das query_cache_limit kannst Du auf 4MB senken und für die query_cache_size reichen laut der tuning-primer-Ausgabe 320MB.

labu wrote: set-variable = sort_buffer_size=4M
set-variable = myisam_sort_buffer_size=128M
set-variable = read_buffer_size=4M
set-variable = read_rnd_buffer_size=8M
set-variable = join_buffer_size=8M

join_buffer_size, read_buffer_size und sort_buffer_size sind mit jeweils 2MB und read_rnd_buffer_size mit 8MB mehr als grosszügig dimensioniert. myisam_sort_buffer_size sollte mit 64MB ebenfalls mehr als ausreichend gross sein.

labu wrote: set-variable = key_buffer_size=256M
set-variable = max_allowed_packet=100M
set-variable = table_cache=2048

max_allowed_packet kannst Du ebenfalls senken, 32MB sollten reichen. Die key_buffer_size sollte immer etwas grösser sein, als der aktuelle "MyISAM Index Space" Wert aus tuning-primer, passt also. table_cache (ab MySQL 5.1 auch table_definition_cache) sollte grösser als die Anzahl der vorhandenen Tabellen sein, passt also auch (noch).

labu wrote: set-variable = thread_cache_size=20
set-variable = thread_concurrency=8

Du hast eine CPU mit 4 Cores und Hyperthreading, was letztendlich 8 Cores nahe kommt. thread_concurrency sollte immer der Anzahl der Cores entsprechen, passt. thread_cache_size setze ich immer doppelt so hoch wie thread_concurrency damit auch bei Lastspitzen möglichst alle (wartenden) Threads im Thread-Cache landen können.

labu wrote: set-variable = max_connections=600

So, dann bleibt noch die kritischte Option, die max_connections. Diese sollten immer so gering wie möglich gehalten werden, da jede geöffnete Connection zusätzlichen RAM benötigt. Ich empfehle Dir hier nicht über den Default von 100 zu gehen, da Dir im ungünstigsten Fall der komplette RAM (plus Swap) ausgeht und der Kernel dann beginnt wahllos Prozesse zu beenden (OOM-Killer).

Ich hoffe, das beantwortet ein paar Deiner Fragen, zusätzlich empfehle ich die offizielle MySQL-Dokumentation, dort wird vieles deutlich ausführlicher erläutert.

Damit Du einen neuen Startpunkt hast, folgt noch eine my.cnf wie ich sie vorläufig für Dein System verwenden würde. Die Pfade musst Du allerdings selbstständig an Dein System anpassen:

Code: Select all

[client]
port                            = 3306

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

[mysqld]
user                            = mysql
port                            = 3306
bind-address                    = 127.0.0.1
basedir                         = /usr/local
datadir                         = /var/db/mysql
tmpdir                          = /var/tmp
slave-load-tmpdir               = /var/tmp
log-bin                         = /var/db/mysql/mysql-bin
relay-log                       = /var/db/mysql/relay.log
relay-log-index                 = /var/db/mysql/relay.index
relay-log-info-file             = /var/db/mysql/relay.info
master-info-file                = /var/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                        = 50
sync_binlog                     = 1
binlog_cache_size               = 1M
max_binlog_size                 = 100M
binlog-format                   = MIXED
expire_logs_days                = 7
slow-query-log                  = 1
slow-query-log-file             = /var/db/mysql/slow-query.log
slave_compressed_protocol       = 1
#lower_case_table_names          = 1
safe-user-create                = 1
delay-key-write                 = ALL
myisam-recover                  = FORCE,BACKUP
key_buffer_size                 = 256M
join_buffer_size                = 2M
sort_buffer_size                = 2M
read_buffer_size                = 2M
read_rnd_buffer_size            = 8M
myisam_sort_buffer_size         = 64M
max_allowed_packet              = 32M
max_heap_table_size             = 64M
tmp_table_size                  = 64M
table_cache                     = 2048
table_definition_cache          = 2048
query_cache_type                = 1
query_cache_size                = 320M
query_cache_limit               = 4M
thread_concurrency              = 8
thread_cache_size               = 16
max_connections                 = 100
ft_max_word_len                 = 20
ft_min_word_len                 = 3
long_query_time                 = 3
local-infile                    = 0
log-warnings                    = 2
log-slave-updates
log-queries-not-using-indexes
skip-external-locking
#innodb_thread_concurrency       = 8
#innodb_buffer_pool_size         = 2G
#innodb_additional_mem_pool_size = 128M
#innodb_data_home_dir            = /var/db/mysql
#innodb_log_group_home_dir       = /var/db/mysql
#innodb_data_file_path           = ibdata1:2000M;ibdata2:10M:autoextend
#innodb_flush_method             = O_DIRECT
#innodb_log_file_size            = 128M
#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_lock_wait_timeout        = 120
#innodb_file_per_table           = 1

[mysqldump]
max_allowed_packet              = 32M
quote_names
quick

[isamchk]
key_buffer_size                 = 256M

[myisamchk]
key_buffer_size                 = 256M

Da Du offenbar keine Replikation und kein InnoDB nutzt, habe ich dessen Optionen jetzt nicht berücksichtigt.

Nach 48 Stunden postest Du bitte nochmal die Ausgaben von tuning-primer.sh und mysqltuner.pl zum weiteren Feintuning.

Gruss,
Joe User

Posted: **2011-06-25 10:58**

Hallo Joe User,

zuerst möchte ich mich mal bei dir bedanken, dass Du Dir die Zeit genommen hast, mir bei der Optimierung zu helfen. Du hast in die Antwort Zeit investiert und das freut mich.

Mein Server bestreitet zum Großteil meinen Lebensunterhalt, deswegen schlafe ich schlecht, wenn dort nicht alles optimal ist!

Ich werde bzw. habe nun heute die Werte von Dir gesetzt und werde dann nach 48 Stunden die beiden Auswertungen posten. Bei den Thread Stacks habe ich es so gelassen, da diese Einstellungen von meinem Host schon vorher so waren..warum auch immer?

Vorab nochmal ein paar Fragen. Danke für eine Beantwortung.

Backup ist gemacht - mache ich täglich 4 mal automatisch mit Crontab + mysqldumper

1. Verständnisfrage:

Angenommen ich würde die Werte wie ich Sie jetzt gesetzt habe lassen. Wäre dann der Server langsamer und die Performance schlechter? Ich habe das noch nicht so ganz verstanden. Mir ist klar, dass höher Werte nicht immer bedeutet, dass er auch z. B. mehr auslagern kann aber ich dachte, wenn ich 8 MB habe und dann z. B. Buffer und Cache nur auf 64 MB habe, dass dies zu wenig ist und ich hier locker 3 mal soviel einstellen könnte. Muss der Server bei kleineren Caches und Buffer nicht jedesmal neu Cachen obwohl er vorher die gleiche Query schon im Cache hatte?

Wie ist das tatsälich?

2. max connections

Wenn durch eine Werbeaktion oder ähnliches auf dem Server mehr als 100 Connections wären, würden Besucher ja die Meldung bekommen, dass die max connections erreicht wurden und die Seite würde sich nicht öffnen. Ich bin vor 4 Jahren von einem Hosting Paket wo die Connectins auf 100 waren auf einen eigenen Server umgestiegen, da sporadisch die Meldung kam, dass die max connections erreicht wurden. Mir wäre lieber, die Seite würde sich aufbauen, wenn auch langsam, anstatt einen kritischen Wert zu haben, der evtl. mal erreicht wird.

3. tmp_table_size und max_heap_table_size

Ich habe wie gesagt auch 2 Foren (gut frequentiert) und 2 Online Shops laufen. Beide Foren haben eine DB um die 100 MB. Der eine Fremdshop hat 150 MB habe ich gerade gesehen. Ist deswegen 64 nicht zu wenig? Ich dachte, alle DBs vom Server sollte hier rein passen...
Wenn er sagt: Of 67237 temp tables, 35% were created on disk, dann wäre doch der Wert von 64 zu niedrig, weil er ja bisher schon 35% auf die Platte schreiben musste. was ja nicht sein soll oder? Ich weiss, dass ich hier Halbwissen habe...ich wills nur verstehen und freue mich auf deine Erklärung.

4. Join Buffer Size

Ich habe 2 Verzeichnisse auf dem Server laufen. Dort laufen fast nur Suchanfragen. Deswegen ist der Wert Handler_read_rnd_next immer recht hoch. Müsste hier zum Ausgleich die join buffer size nicht höher sein oder hab ich das komplett falsch verstanden?

Bzw. die Frage ist anders. Wenn ich sehr viele Anfragen habe, die keine indizes haben, wie kann ich dann für den Server positiv entgegen wirken?

Danke vielmals
gruß
Labu

Posted: **2011-06-27 09:59**

Für 1-4 überlasse ich mal Joe das Feld.

Was die Indizes angeht: Du wirst ja ungefähr wissen, welche Querys du so nutzt, ansonsten mal alle Skripte nach Querys durchforsten und schauen, welche Spalten so in den WHERE-Klauseln vorkommen.
Dann in einer sehr ruhigen Minute (sprich, wenig Zugriffe) via MySQL-Konsole Indizes auf alle Spalten legen, die nötig sind.
Das dauert dann, je nach Zeilenzahl, einmal ziemlich lange und bringt die Kiste ziemlich ins Schwitzen, aber ist in der Form eine einmalige Aktion und der Effekt ist groß.
Gerade wegen der möglichen Dauer würde ich so eine Aktion auch nicht via phpMyAdmin o.Ä. erledigen, weil da bei einem Skript-Timeout auch völlig unvorhergesehene Dinge passieren können.

Posted: **2011-06-27 14:05**

Hallo,

ok, danke für die Info.

Hier nun die beiden Auswertungen. Bitte teilt mir mit, ob und was ich von den Tipps nun umsetzen soll.

mysqltuner:

Code: Select all

[--] Data in  tables: 0B (Tables: 9)
[--] Data in MyISAM tables: 528M (Tables: 1936)

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 2d 3h 8m 11s (59M q [320.908 qps], 558K conn, TX: 1B, RX: 2B)
[--] Reads / Writes: 93% / 7%
[--] Total buffers: 906.0M global + 16.1M per thread (200 max threads)
[OK] Maximum possible memory usage: 4.0G (51% of installed RAM)
[OK] Slow queries: 0% (323/59M)
[OK] Highest usage of available connections: 24% (48/200)
[OK] Key buffer size / total MyISAM indexes: 256.0M/136.3M
[OK] Key buffer hit rate: 100.0% (7B cached / 1M reads)
[OK] Query cache efficiency: 64.3% (36M cached / 56M selects)
[!!] Query cache prunes per day: 45633
[OK] Sorts requiring temporary tables: 0% (38 temp sorts / 10M sorts)
[!!] Joins performed without indexes: 120902
[!!] Temporary tables created on disk: 35% (413K on disk / 1M total)
[OK] Thread cache hit rate: 99% (268 created / 558K connections)
[!!] Table cache hit rate: 10% (1K open / 17K opened)
[OK] Open file limit used: 81% (3K/4K)
[OK] Table locks acquired immediately: 99% (26M immediate / 26M locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Add skip-bdb to MySQL configuration to disable BDB
    Run OPTIMIZE TABLE to defragment tables for better performance
    Increasing the query_cache size over 128M may reduce performance
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_size (> 512M) [see warning above]
    join_buffer_size (> 2.0M, or always use indexes with joins)
    tmp_table_size (> 128M)
    max_heap_table_size (> 127M)
    table_cache (> 2048)

sql primer:

Code: Select all

-- MYSQL PERFORMANCE TUNING PRIMER --
             - By: Matthew Montgomery -

MySQL Version 4.1.22-max-log i686

Uptime = 2 days 3 hrs 13 min 30 sec
Avg. qps = 320
Total Questions = 59188202
Threads Connected = 2

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/4.1/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 2 sec.
You have 323 out of 59188299 that take longer than 2 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/4.1/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 20
Current threads_cached = 18
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 200
Current threads_connected = 2
Historic max_used_connections = 48
The number of used connections is 24% of the configured maximum.
Your max_connections variable seems to be fine.

No InnoDB Support Enabled!

MEMORY USAGE
Max Memory Ever Allocated : 1.51 G
Configured Max Per-thread Buffers : 3.14 G
Configured Max Global Buffers : 778 M
Configured Max Memory Limit : 3.90 G
Physical Memory : 7.80 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 136 M
Current key_buffer_size = 256 M
Key cache miss rate is 1 : 3895
Key buffer free ratio = 76 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 512 M
Current query_cache_used = 254 M
Current query_cache_limit = 32 M
Current Query cache Memory fill ratio = 49.80 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 4 M
Current read_rnd_buffer_size = 7 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 2.00 M
You have had 121249 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 4306 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 = 2048 tables
You have a total of 1945 tables
You have 2048 open tables.
Current table_cache hit rate is 11%
, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 127 M
Current tmp_table_size = 128 M
Of 765297 temp tables, 35% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
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.

TABLE SCANS
Current read_buffer_size = 1 M
Current table scan ratio = 136 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 447
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'

danke

Posted: **2011-06-27 16:36**

Nach den auskommentierten InnoDB-Optionen bitte noch ein "skip-bdb" einfügen.
table_cache und table_definition_cache auf 4096 setzen.
open_files_limit kannst Du auf 12000 setzen.

Den Rest bekommst Du langfristig nur durch das Anlegen der fehlenden Indexes und das Optimieren der Queries in den Griff.

Posted: **2011-06-27 16:45**

Ist skip-bdb nicht obsolet?

Edith meint: Vergiss es, ich sollte lesen lernen - ist ja MySQL 4.1, nicht 5.x...

Posted: **2011-06-27 17:29**

Huch, 4.1 sehe ich auch jetzt erst, danke fürs Aufpassen.

MySQL 4.1 wird nicht mehr supportet, daher empfehle ich dringend ein Upgrade auf MySQL 5.5 (mindestens jedoch 5.1). Woher stammt denn überhaupt diese Uraltversion? Ist Deine Distribution etwa genauso veraltet und damit ein ernstes Sicherheitsproblem?

Posted: **2011-06-27 17:54**

Hallo,

eigentlich ist das ein Managed Server und ich hab mich bisher nicht darum gekümmert sondern nur um die Webseiten.

Ist ein Upgrade auf die 5er Version ohne große Ausfälle und Probleme möglich?

Die Linux Version ist:

Linux version 2.6.32-bpo.5-amd64 (Debian 2.6.32-30~bpo50+1)

ist das ok?

Also skip-bdb setzen oder nicht setzen?

Wenn ich die beiden erhöhe bringt nichts?

query_cache_size (> 512M) [see warning above]
join_buffer_size (> 2.0M, or always use indexes with joins)

und

Current max_heap_table_size = 127 M
Current tmp_table_size = 128 M
Of 765297 temp tables, 35% were created on disk

wenn ich auf 265 M gehe, komm ich dann nicht auf 70%?

danke

Posted: **2011-06-27 18:31**

Ja, skip-bdb bitte setzen.

Da es ein Managed-Server ist, wirst Du vermutlich auf die vom Anbieter ausgewälten Softwareversionen festgenagelt sein. Frage mal bei Deinem Anbieter an, ob er mitlerweile nicht aktuellere Systeme anbietet und Dir bei einem eventuellen Wechsel unter die Arme greift.

Bei einem Upgrade von MySQL 4.1 auf 5.1/5.5 kann es bei älteren und/oder schlecht programmierten Anwendungen zu Problemen kommen, das sollte allerdings bei aktuellen Anwendungen nicht der Fall sein. Dennoch solltest Du Dich vorher über mögliche Fallstricke bei den Herstellern Deiner Anwendungen darüber informieren. Desweiteren ist bei solchen Upgrades ein vollständiges Backup Pflicht.

Was im Einzelnen beim reinen MySQL-Upgrade zu beachten ist, steht hier:
http://dev.mysql.com/doc/refman/5.0/en/upgrading.html
http://dev.mysql.com/doc/refman/5.1/en/upgrading.html
http://dev.mysql.com/doc/refman/5.5/en/upgrading.html

Ob Deine Datenbankinhalte ein Upgrade unverändert mitmachen, musst Du ebenfalls beim jeweiligen Anwendungshersteller in Erfahrung bringen.

PS: Auch wenn es etwas Arbeit bedeutet, würde ich das Upgrade schon allein aus sicherheitstechnischen Gründen nicht auf die lange Bank schieben.

Posted: **2011-06-27 18:44**

labu wrote:Wenn ich die beiden erhöhe bringt nichts?

query_cache_size (> 512M) [see warning above]
join_buffer_size (> 2.0M, or always use indexes with joins)

Nein, das Erhöhen dieser Werte bringt maximal kurzfristig etwas, langfristig ist das aber der absolut falsche Weg.

labu wrote:Current max_heap_table_size = 127 M
Current tmp_table_size = 128 M
Of 765297 temp tables, 35% were created on disk

wenn ich auf 265 M gehe, komm ich dann nicht auf 70%?

Werte über 128MB sind nur recht selten sinnvoll, da temporäre Tabellen in der Regel deutlich kleiner sind und so nur unnötig Ressourcen verschwendet würden.

Die tmp-tables-on-disk entstehen bei Dir mit recht hoher Sicherheit durch Tabellen die Spalten vom Typ TEXT oder BLOB enthalten und diese werden grundsätzlich on-disk generiert. Abhilfe schafft hier nur das Überarbeiten der Anwendungen, so dass deutlich weniger TEXT beziehungsweise BLOB Spalten genutzt werden.

Posted: **2011-06-27 18:47**

Hallo,

ok, danke. Werde bei meinem Host gleich anfragen.

Kannst du noch was zu meinen beiden Fragen sagen? Ich weiss, du hast ja oben schon geschrieben, dass ich das evtl. nur mit den Indexes und Queries in den Griff bekomme. Trotzdem danke für eine Antwort..vielleicht hast es auch übersehen?! wäre lieb

Wenn ich die beiden erhöhe bringt nichts?

query_cache_size (> 512M) [see warning above]
join_buffer_size (> 2.0M, or always use indexes with joins)

und

Current max_heap_table_size = 127 M
Current tmp_table_size = 128 M
Of 765297 temp tables, 35% were created on disk

wenn ich auf 265 M gehe, komm ich dann nicht auf 70%?

toll wäre auch noch zu wissen, wie du auf folgende Werte gekommen bist. so hätte ich was gelernt..danke, dann haben wirs auch

table_cache und table_definition_cache auf 4096 setzen.
open_files_limit kannst Du auf 12000 setzen.

Posted: **2011-06-27 19:39**

Du hast rund 2000 Tabellen (Tendenz steigend) und die möchten nach Möglichkeit gecached werden, daher table_cache=4096
open_files_limit sollte circa dreimal so gross sein wie der table_cache, da Du offenbar nur MyISAM nutzt. Würdest Du nur InnoDB nutzen, könnte open_files_limit etwas kleiner sein, da InnoDB weniger Files benötigt als MyISAM.

Die meisten Werte sind bewärte Erfahrungswerte für durchschnittliche Webserver, oder leiten sich direkt aus der MySQL-Dokumentation ab. Manche Werte entstammen auch den Empfehlungen von (ehemaligen) MySQL-AB Mitarbeitern, also quasi direkt vom Hersteller.

Posted: **2011-06-27 21:57**

Joe User wrote:
labu wrote:Wenn ich die beiden erhöhe bringt nichts?

query_cache_size (> 512M) [see warning above]
join_buffer_size (> 2.0M, or always use indexes with joins)
Nein, das Erhöhen dieser Werte bringt maximal kurzfristig etwas, langfristig ist das aber der absolut falsche Weg.

Meinst du mit "absolut der falsche Weg" weil dadurch das Problem der "nicht optimalen Querys" nicht behoben wird oder weil sich nach einer Weile auch dieser Cache ganz einfach füllt und man dann am nächsten Limit ist?

Es ist einfach so, dass ich die Querys nicht optimieren kann. Es sind ja eine Vielzahl von Domains und viele Tabellen. Mir fehlt leider leider die Zeit und kenne niemand der mir hilft.

Ich weiss also, dass es der falsche Weg ist. Würdest Du aber vor dem Hintergrund, dass ich die Querys nicht optimieren kann, auch empfehlen, diese Werte nicht höher zu setzen?

Damit meine ich, wäre es auch richtig, die beiden Werte zu lassen, wenn ich die Querys nicht optimiere oder sollte ich dann z. B. die Werte so setzen oder höher?

query_cache_size 1024 MB
join_buffer_size 4 MB

Danke Joe

Grüße
labu

Posted: **2011-06-27 22:19**

Ja, den "falschen Weg" hast Du richtig verstanden.

Nur auf eigene Gefahr, ich rate ausdrücklich davon ab:
Den query_cache bitte nicht grösser 512MB setzen, das bringt wirklich nix.
Den join_buffer_size auf maximal 8MB, darüber kann es zu Problemen kommen.

Am Besten ist es, Du findest den/die Übeltäter mit den fehlenden Indexes und zwingst den entsprechenden Kunden zum Optimieren oder Wechsel seiner Anwendung, da er die Stabilität Deines Systems nachhaltig stört. Notfalls musst Du auf diesen Kunden zum Wohle der anderen Kunden verzichten.

Den Übeltäter findest Du mit Hilfe des Slow-Query-Log und der Option log-queries-not-using-indexes, näheres dazu in der MySQL-Dokumentation.

RootForum Community

Optimierung der my.cnf - Bitte Einschätzung

Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung

Re: Optimierung der my.cnf - Bitte Einschätzung