PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Optimale MySQL Einstellungen?



deja2001
01.02.2005, 11:22
Ich habe bei schlund einen Ready-to-run-Server Plus, der immer in die Knie geht sobald die Besucherzahl über 600 steigt. :mad:
Ich hatte den Provider den Vorschlag von Eva von vBulletin.com zugemailt ob die den Server Einstellungen änder kann.

Ich habe folgende E-Mail bekommen wo die bereit sind zu ändern.
Das ist für ein Ready-to-Run-Server (ServerPlus) bei schlund.

Ich wäre dankbar für die optimale Enstell vorschläge.


Gruß
macuser

ben_kulschewski
13.03.2005, 10:40
naja, man müsste als erstes mal wissen, welche hardware (platten, ram, cpu + L2 cache) sich in dem rtr-server verstecken, danach werden die mysql-konfigurationen eingestellt. Weiterhin ist wichtig, was für eine Anwendung drauf läuft, bzw welche Art von Abfrage die Maschine macht:
1.) liest die Kiste Daten aus text-dateien in die DB
2.) stellen viele User dieselben DB-Anfragen oder werden bei jeden User neue Queries abgesendet ?
3.) Sind die Abfragen einfach gehalten (select * from xxx) oder verzweigen sich die Abfrage mit vielen Joins ??
4.) Was für Tabellentypen werden genutzt? MYisam, HEAP, InnoDB ...

am besten mal den link zu der Anwendung ...

mfg

Debianer
14.03.2005, 08:48
Salve!
@ ben_kulschewski
Die Ausstattung findest du hier:
http://www1.schlund.de/index.php?&page=server_imvergleich ;)
( ServerPlus )

Stephan

ben_kulschewski
16.03.2005, 09:38
ALSO ....

[mysqld]
set-variable = max_allowed_packet=10M
(Max Größe eines Datenpaketes, ich glaube, 1M reicht pro clientanfrage, oder :rolleyes: )
set-variable = max_connections=310
(na, das sollte man bei 600 conn auch auf 600 setzten, NIE ÜBER 1000 !)
set-variable = max_user_connections=300
(ist doch dasselbe :confused: )
set-variable = wait_timeout=60
(Zeit, ab wann der Client die DB-server abfragen selber abbricht, nix machen)
set-variable = flush_time=300
(Zitat: Gibt bei einer Zahl größer Null das Intervall in sec an, in dem die Tabellen geschlossen und wieder geöffnet werden. NUR AUF WIN 9x/ME MIT WENIG SPEICHER ERFORDERLICH!!!) --> flush komplett abstellen, wenns nicht geht, auf 50-100 setzen !!!
set-variable = long_query_time=3
(diese variable sagt aus, ab wann eine QUERY als langsam eingestuft wird UND MITGELOGGT wird (irgendwo als long_query_XXX.log). LOGGEN kostet Zeit, ca. 1-3% Rechenleitung kommen pro Abfrage dazu! Wenns nicht benötigt wird: abstellen oder auf 20 sec setzen !)

default_week_format=3 ... log format
query_cache_type = 1 -> Query-caching ist aktiviert
query_cache_size = 16M
( AAAAA !!!!!!! Bei 2 GB speicher sind 16 MB für Q-Cache aktiv :eek: -->
Bitte 1 Null dranhängen !!! Nein, im Ernst. Wenn der Server als DB-server vorgesehen ist, dann darf man Ihm gerne einen Teil Ram als Q-Cache geben. Habe auf Maschine mit 512mb ram ca. 30 MB als QCache. Also in dem Fall sind 100 MB durchals vertretbar. der Qcache cacht(blödes wort) alte Abfragen und gibt die Ergebnisse bei bedarf wieder aus. Wenn also jemand in einem Shop-system nach "IBM" in der Kategorie "Festplatte" sucht, dann ist die Abfrage beim 2. Mal um ein vielfaches schneller ...
innodb_data_home_dir =
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_file_size=20M
innodb_additional_mem_pool_size=10M
innodb_buffer_pool_size=64M
innodb_lock_wait_timeout=60
-------- is nur wichtig, wenn, wenn man auch INNODB nutzt
key_buffer=32M
größe des Puffers für Indices: kommt drauf an, ob und welche tabellen man indiziert hat: habe ich eine Tabelle mit 1.000.000 Datensätzen und den Index auf dem Feld "Kundennummer, welches 8 stellig ist, ergibt sich eine einfache Rechnung:
1.000.000 * ([8byte(KNR) ] + [4-8byte(Datensatz-Zeiger)]) = 16.000.000 byte = 16 MB, aber dann habe ich nur einen Index einer Tabelle gepuffert. Fast alle Tabellen habe einen Primary-key (Nr) , der schon 2 stellig ist. Also kann man sich das selber rechnen. Der Puffer ist auf der Platte, nicht im Ram, deshalb verzögern sich die Lesezugriffe, aber durch die Indexierung ist die Abfrage ja schneller. Balanceakt eben.
table-cache=256
DEFINITION: "Anzahl der maximal offenen tabellen für ALLE Threats", also darf die DB maximal 256 Tabellen gleichzeitig abfragen, in dem Fall empfehle ich hochsetzten auf 512 ...

Ich habe selber mit solchen einstellungen mehrere systeme um ein vielfaches optimieren können. Viel spass

sorry, hatte viel zu tun, deshalb erst jetzt die antwort.

hoffe, konnte etwas helfen, aber die Anwendung würde mich mal interessieren :rolleyes: ...