SQL Umlegen

[the_condor]

Hallo,

beschäftige mich gerade mit MYSQL und deren Leistung, habe da auch jetzt 2-3 Informationen bei google gelesen das man z.b die MYSQL Database einfach auf seine 2 Platte verlegen sollte um die Leistung b.z.w den Schreibvorgang zu Optimieren.

Ich würde einfach gerne wissen ob sowas Ratsam ist und ob einer von euch dieses Thema auch mal überlegt hat und wenn ja wieviel Performance man dadurch Gewinnen kann.

Bin für alle Ideen offen

mfg
the_condor

 

[Ricko]

Grundsätzlich gefragt:

Welche Prozesse beanspruchen die zweite Platte?
(Anders: Ist dort weniger 'los' als auf der ersten? )


Zusätzlich:

Ist die Datenbank denn wirklich so groß?

Wenn du extrem große Datenbanken hast kannst du die Option der Partitionierung benutzen.

Auszug aus: MySQL AB :: MySQL 5.1 Referenzhandbuch :: 17.2.5 Unterpartitionen

Teilpartitionen können bei extrem großen Tabellen helfen, die Daten und Indizes über viele Festplatten zu verteilen.

 

[the_condor]

Danke für deine Antwort

also im Moment sind die Einzelnen Datenbanken nur von 8MB - 180MB Groß , ist für mich normal kein Grund da was zu ändern.
Viel mehr müßte ich mich an die Slow Queries machen und an die Richtige einstellung div Werte in der my.cnf

mfg
the_condor

 

[Ricko]

Hmm. .

Also, ehrlich gesagt habe ich einige Jahre ein Forum betrieben welches (jetzt) über 220 MB nur an MySQL Daten hat.
Und das auf einem 'normalen' Webspace account, bei dem der Hoster wohl nie wirklich viel in Sachen optimierung gemacht hat.

gut, eventuell bringt es dir bei starker frequentierung der Datenbank etwas die 'größten' zu verschieben.

 

[daseddy]

Der Link zu MySQl ist glaube ich was irreführend, da es hierbei nicht direkt um die Verteilung der Datenbank auf verschiedene Festplatte geht, sondern um die horizontale bzw. vertikale Verteilung von sehr großen Tabellen/Datenbanken (Ich muss zugeben, ich habe die Seite nicht gelesen.) und ich glaube verteilte Datenbanken haben nicht direkt was mit der Fragestellung zu tun.

Zur Frage:
Durch den Einsatz eines Raid läßt sich der Durchsatz einer Datenbank schon steigern. Die verschiedenen Vorteile/Nachteile von Raid0/1/5/10 usw. will ich jetzt hier nicht erklären. Da ist Google dein Freund.
Es gibt übrigens viele Dinge die Datenbanken beschleunigen/verlangsamen können.

nur eine kleine Auswahl:
Wahl des Betriebssystems
Größe Arbeitsspeicher
Prozessorgeschwindigkeit / Anzahl
Datenbanklayout
Geschwindigkeit der Festplatten
Filesystem
sonstige Programme auf dem Server
und und und ....

Datenbankserver bei mir auf Arbeit(soweit ich es weiß):
Solaris 9, ein paar schnellen SCSI-Platten(Raid1 wegen der Ausfallsicherheit) + SAN-Anschluss, 4 CPU oder so und wenn ich mich nicht irre 24 oder 32GB Arbeitsspeicher.
Arbeitsspeicher geht halt über alles...

 

[the_condor]

@daseddy

du darfst das nicht mit einem Firmen Server vergleichen der Power haben muss.

Was Du da sagst bezüglich raid stimmt schon und von daher war ja auch der Thread aufgemacht, meine 2 Festplatte läuft da so rum ohne last. Würde ich nun für die MYSQL die Platte wechseln, wäre der Prozess der einzigste der auf die 2 Platte schreibt und das sollte minmal was bringen. Aber meine 7 Projekte sind jetzt nicht so das dieses in betracht kommen würde. Jedoch hängt es - ich hänge morgen mal Screen und Daten an.

mfg
the_condor

 

[Huschi]

Die Frage ist ja woran es eigentlich 'hängt'.
Denn komplizierte Joins wirst Du weniger mit einer idle-HD beschleunigen können.
Vielmehr hilft es die MySQL-Konfiguration auf mehr RAM (falls vorhanden) auszubauen und vor allem die richtigen Indizes zu setzten.

huschi.

 

[the_condor]

So also hier mal ein paar Daten:

AMD Athlon 64 X2 5600+
4 GB RAM
Sata 2 Festplatte
BS: Debian etch
mysql Ver 14.12 Distrib 5.0.51
PHP 5.2.5-0.dotdeb.2 with Suhosin-Patch 0.9.6.2

So ein Teil der Top Ausgabe:

top - 21:31:49 up 8 days, 13:26,  1 user,  load average: 0.44, 0.48, 0.51
Tasks: 111 total,   1 running, 110 sleeping,   0 stopped,   0 zombie
Cpu(s): 42.5%us,  6.3%sy,  0.0%ni, 51.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4021144k total,  3551720k used,   469424k free,   107684k buffers
Swap:  2104504k total,       36k used,  2104468k free,   392972k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
13735 lady    15   0 66800 8960 4208 S   43  0.2  23:55.43 php5-cgi
13737 cond    16   0 66652 8852 4248 S   29  0.2   3:37.22 php5-cgi
17823 mysql     15   0  234m 127m 5816 S   20  3.3 102:57.95 mysqld
13732 lady    15   0 66800 8940 4188 S    6  0.2  23:47.54 php5-cgi
13668 www-data  19   0  287m 7116 2044 S    1  0.2   0:19.41 apache2

Ausgabe des tuning Script:

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

WORKER THREADS
Current thread_cache_size = 12
Current threads_cached = 9
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 50
Current threads_connected = 1
Historic max_used_connections = 10
The number of used connections is 20% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 87 M
Configured Max Per-thread Buffers : 224 M
Configured Max Global Buffers : 43 M
Configured Max Memory Limit : 267 M
Physical Memory : 3.83 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 43 M
Current key_buffer_size = 30 M
Key cache miss rate is 1 : 4015
Key buffer fill ratio = 63.00 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 3 M
Current query_cache_used = 16 K
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = .54 %
Current query_cache_min_res_unit = 1 M
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current record/read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 2.00 M
You have had 27343 queries where a join could not use an index properly
You have had 2340 joins without keys that check for key usage after each row
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 = 6062 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 = 3001 tables
You have a total of 673 tables
You have 1307 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 42 M
Current tmp_table_size = 40 M
Of 67304 temp tables, 3% were created on disk
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 57 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 18624
Your table locking seems to be fine

Einstellung in meiner my.cnf

 # * Fine Tuning
#
join_buffer_size = 2M
key_buffer              = 30M
max_allowed_packet      = 32M
thread_stack            = 128K
thread_cache_size       = 12
#thread_cache_size       = 8
max_connections        = 50
table_cache            = 3001
max_heap_table_size    = 42M
tmp_table_size         = 40M
thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit=1M
query_cache_size=3M
query_cache_type=1
query_cache_min_res_unit=1M

Apache Einstellung

<IfModule mpm_worker_module>
    StartServers          2
    MaxClients          100
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>
KeepAliveTimeout 2

So und nun ein paar Grafiken der Woche im Anhang.

So bin dann für alle Tipps und vorschläge Dankbar

mfg
the_condor

 

[Huschi]

Hier steht doch alles:

You have had 27343 queries where a join could not use an index properly
You have had 2340 joins without keys that check for key usage after each row
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.

huschi.

 

[the_condor]

da hast Du Recht Huschi , aber ich kann ja nicht die Script Optimieren - weiß nicht wo ich Ansetzen soll.

Auszug aus der mysql-slow.log

# Time: 080125  7:52:49
# User@Host: lady[lady] @ localhost []
# Query_time: 0  Lock_time: 0  Rows_sent: 10  Rows_examined: 10405
SELECT t.*, b.title, b.hotthread_reply, b.hotthread_view, tv.lastvisit, bv.lastvisit AS blastvisit
        FROM bb1_threads t
         LEFT JOIN bb1_boards b
          ON (b.boardid = t.boardid)
         LEFT JOIN bb1_threadvisit tv
          ON ((tv.threadid = t.threadid) AND (tv.userid = 101))
         LEFT JOIN bb1_boardvisit bv
          ON ((bv.boardid = t.boardid) AND (bv.userid = 101))
        WHERE (t.visible <> 0)
        AND (b.boardid IN (1,2,3,4,6,8,9,11,12,14,15,16,17,19,20,21,27,28,29,30,31,32,33,38,39,40,41,43,48,49,50,51,53,54,55$
        AND NOT (b.boardid IN (-1)))
        AND (t.closed < 3)
        ORDER BY t.lastposttime DESC LIMIT 10;
# User@Host: lady[lady] @ localhost []
# Query_time: 0  Lock_time: 0  Rows_sent: 12  Rows_examined: 24
SELECT styleid,stylename FROM bb1_styles ORDER BY styleid ASC;
# User@Host: lady[lady] @ localhost []
# Query_time: 0  Lock_time: 0  Rows_sent: 1  Rows_examined: 176
SELECT COUNT(userid) as users FROM bb1_users WHERE styleid = '0';

Gut ich soll wenn ich das so nicht Optimieren kann den join_buffer_size höher setzen um mehr durchsatz zu bekommen.

mfg
the_condor

 

[Huschi]

Ich kann es noch mal zusammen stutzen:

You have had 27343 queries where a join could not use an index properly
You have had 2340 joins without keys that check for key usage after each row
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.

Du mußt nicht zwangsweise an den Scripten etwas ändern. Die Tabellen-Struktur reicht bereits.

huschi.