MySQL Performance Tuning mit Tuning-Primer.sh Script

Sicher hab ich das gelesen.

Aber wie ich schon in meinen andern Threads geschrieben hab lerne ich noch.

Learning by doing ist die beste Methode,allerdings braucht man ab und an Denkanstösse.

Mit Zitaten ist mir nicht wirklich geholfen.

Wo werden die Änderungen gemacht bzw. angelegt?

Man kann nicht alles wissen. :o
 
Hallo,

Die Änderungen machst du in der /etc/my.cnf. Und dannach nicht vergessen: MySQL neu starten damit die Änderungen übernommen werden. Und vielleicht solltest du dir von den Dateien die du änderst noch ein Backup anlegen.

Damit dieses Script genaue Werte liefert muss dein Server mindestens 48 Stunden am Stück an sein, das ist er aber noch nicht gewesen im Zeitpunkt als du das Script ausgeführt hast. Also: Erst was warten und dann nochmal ausführen, da werden sich ein paar Werte bestimmt noch ändern, so liefert der gerade nämlich unter Umständen noch falsche Werte.

MySQL tuning ist schön und gut. Allerdings da du noch Anfänger bist würde ich erstmal schauen dass dein Server "normal" läuft ehe du mit der optimierung anfängst. Du hast einen guten Server der sollte auch mit einer nicht ganz optimierten MySQL Datenbank super laufen :)
 
Shellghost said:
Aber wie ich schon in meinen andern Threads geschrieben hab lerne ich noch.
Click to expand...
Ich lese aber bei über 1000 aktiven Usern nicht jedesmal alle anderen Threads bevor ich antworte. :D

Mit Zitaten ist mir nicht wirklich geholfen.
Click to expand...
Ganz ehrlich: Bei Deinen Fragen kann ich Deine Antworten vollständig aus diesem 7-Seiten-langen-Thread zusammen Zitieren. Aber die Mühe mache ich mir nicht, die solltest Du Dir machen.
Ansonsten gibt das tuning-primery-script bereits recht klare Aussagen darüber, wie die Einstellungen in der my.cf lauten müssen. Wenn Du Dir mal unsicher bist, dann schau in der MySQL-Doku nach (=> RTFM).

huschi.
 
djrick said:
MySQL tuning ist schön und gut. Allerdings da du noch Anfänger bist würde ich erstmal schauen dass dein Server "normal" läuft ehe du mit der optimierung anfängst. Du hast einen guten Server der sollte auch mit einer nicht ganz optimierten MySQL Datenbank super laufen :)
Click to expand...

Das Problem welches ich hab liegt daran das ich ein Forum betreibe, ziemlich gross.

Software ist ein wbb236pl2.

Die Startseite hat Ladezeiten von bis zu 30 Sekunden,innerhalb der Foren und sogar im Portal hab schnelle Ladezeiten (3 Sekunden) wobei das Portal eigentlich langsamer sein sollte als die Startseite.

Diesen Fehler such ich zu beheben.
 
Dann nenne uns doch den Namen des Forums. Dann können wir uns ein besseres Bild davon machen. (Evtl. liefert auch nur ein Ad-Server seine Daten nicht schnell genug?)

huschi.
 
MOD: Bitte keine Fullquotes! Danke
Aber wenn du Werbung oder Extra Funktionen eingebaut hast, greifst du auf solche zu und wenn diese hacken, hackt auch dein Forum, da es nicht an die notwendigen Daten oder Infos kommt.

gruss Gero
 
Last edited by a moderator:
MOD: Bitte keine Fullquotes! Danke

Hab ich auch nicht.

Nur die index.php ist langsam,innerhalb der Foren und auch im Portal, welches grösser ist und normalerweise langsam sein sollte, ist der Speed normal.
 
Last edited by a moderator:
Hallo Forum,
nachdem ich jetzt schon eine ganze Weile mitlese wollte ich euch mal was Fragen:

Wie kann es sein das mir Tuning Primer anteigt das " 1666 out of 22442 " SQL's über 10 Sekunden brauchen? Ich schraub schon länger an der Konfig aber bekomme Sie nicht runter. Auch glaube ich nciht das es an den SQL's liegt. Ich hab die mal mitloggen lassen und es sind welche drunter die ca. 1500 Zeilen MAX zurückgeben, aber das kann doch nicht 10 Sec dauern, oder?
Ich habe vielmehr das Gefühl das irgendwas an den MySql Variablen nicht stimmt. Auf dem Server laufen nur ein paar Typo3 Projekte. Der RAM Verbrauch liegt bei ca. 2 GB.
D.h. ich hätte also noch massig frei um die SQL's schneller zu machen.

Währe cool wenn sich das mal einer von euch ansieht. Aber genug gequatscht, hier die Daten:

Code: 
Server:
AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
4GB RAM

Code: 
mysqld is alive

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

MySQL Version 5.0.32-Debian_7etch8-log x86_64

Uptime = 0 days 0 hrs 57 min 6 sec
Avg. qps = 6
Total Questions = 22357
Threads Connected = 34

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/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 = 10 sec.
You have 1666 out of 22378 that take longer than 10 sec. to complete
Your long_query_time may be too high, I typically set this under 5 sec.

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/5.0/en/point-in-time-recovery.html

WORKER THREADS

elton:~# ./tuning-primer.sh
mysqld is alive

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

MySQL Version 5.0.32-Debian_7etch8-log x86_64

Uptime = 0 days 0 hrs 57 min 9 sec
Avg. qps = 6
Total Questions = 22421
Threads Connected = 34

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/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 = 10 sec.
You have 1666 out of 22442 that take longer than 10 sec. to complete
Your long_query_time may be too high, I typically set this under 5 sec.

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/5.0/en/point-in-time-recovery.html

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

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

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

KEY BUFFER
Current MyISAM index space = 4 M
Current key_buffer_size = 1 G
Key cache miss rate is 1 : 70
Key buffer fill ratio = 0 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 1.00 G
Current query_cache_used = 12 M
Current query_cache_limit = 48 M
Current Query cache Memory fill ratio = 1.23 %
Current query_cache_min_res_unit = 4 K
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 read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 2.00 M
You have had 28 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 = 4206 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 557 tables
You have 565 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 128 M
Current tmp_table_size = 128 M
Of 3399 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 = 218 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 0 : 22627
Your table locking seems to be fine

Code: 
skip-external-locking
bind-address            = 127.0.0.1
key_buffer              = 1024M
max_allowed_packet      = 16M
thread_stack            = 128K
thread_cache_size       = 16
table_cache            = 2048
open_files              = 2000
tmp_table_size          =128M
max_heap_table_size     =128M
join_buffer_size        = 2M
query_cache_limit       = 48M
query_cache_size        = 1024M
log_slow_queries        = /var/log/mysql/mysql-slow.log
long_query_time = 10
log-queries-not-using-indexes
skip-bdb
[mysqldump]
quick
quote-names
max_allowed_packet      = 16M
[mysql]
[isamchk]
key_buffer              = 16M


Vielen Dank schonmal,
dexcs
 
dexcs said:
Wie kann es sein das mir Tuning Primer anteigt das " 1666 out of 22442 " SQL's über 10 Sekunden brauchen?
Click to expand...
Blöde Antwort: Weil es diese Daten aus der MySQL-Statistik rausholt.
Antwort zu der interpretierten Frage:
Weil Du 1666 Queries hattest, die länger als 10 Sekunden brauchten.
Dies muss im Einzelfall gar nicht mal der spezielle geloggte SQL-Query gewesen sein. Es kann auch einfach sein, dass ein anderer Query eine Datenbank solange gelockt hatte. Z.B. so:
- Ein Query "A" über 3 Tabellen braucht tatsächlich 15 Sekunden.
- Ein Query "B" über eine von A genutzte Tabelle braucht nur 0,1 Sekunden.
- Während A arbeitet, kann B i.d.R. dennoch ausgeführt werden.
Aber folgender Fall:
- Während A wird ein Update/Insert/Delete "U" auf eine von A genutzte Tabelle durchgeführt.
- U muss warten bis A fertig ist.
- Wenn nun B ebenfalls gestartet wird, kann es nicht gleichzeitig ausgeführt werden, da MySQL weiß, dass vorher U abgearbeitet werden muss, damit B ein aktuell korrektes Ergebnis liefert.
- Und schon sind 2 Queries gelockt und brauchen ebenfalls deutlich länger als normal und fallen damit ebenfalls in diese Statistik rein.

Die Kunst des MySQL-Tunings innerhalb der Scripte ist u.a. genau diese A-Queries zu finden und zu optimieren.

Warning: Server has not been running for at least 48hrs.
Click to expand...
Sprich: Die Daten sind unbrauchbar!

huschi.
 
hallo,

kann man bei meinem Server noch irgendwas optimieren? weil der hohe RAM-Verbrauch macht mir Sorgen...

my.cnf

Code: 
[client]
character_sets_dir              = /usr/share/mysql/charsets
default_character_set           = utf8
port                            = 3306
socket                          = /var/run/mysqld/mysqld.sock

[mysql]
character_sets_dir              = /usr/share/mysql/charsets
default_character_set           = utf8
prompt                          = \u@\h [\d]>\_
no_auto_rehash

[mysqladmin]
character_sets_dir              = /usr/share/mysql/charsets
default_character_set           = utf8

[mysqlcheck]
character_sets_dir              = /usr/share/mysql/charsets
default_character_set           = utf8

[mysqldump]
character_sets_dir              = /usr/share/mysql/charsets
default_character_set           = utf8
max_allowed_packet              = 32M
quote_names
quick

[mysqlimport]
character_sets_dir              = /usr/share/mysql/charsets
default_character_set           = utf8

[mysqlshow]
character_sets_dir              = /usr/share/mysql/charsets
default_character_set           = utf8

[isamchk]
character_sets_dir              = /usr/share/mysql/charsets
key_buffer_size                 = 256M

[myisamchk]
character_sets_dir              = /usr/share/mysql/charsets
key_buffer_size                 = 256M

[myisampack]
character_sets_dir              = /usr/share/mysql/charsets

[mysqld_safe]
err_log                         = /var/log/mysql/mysql.err

[mysqld]
character_sets_dir              = /usr/share/mysql/charsets
character_set_server            = utf8
default_character_set           = utf8
user                            = mysql
port                            = 3306
bind_address                    = 127.0.0.1
socket                          = /var/run/mysqld/mysqld.sock
pid_file                        = /var/run/mysqld/mysqld.pid
log_error                       = /var/log/mysql/mysqld.err
log_slow_queries                = /var/log/mysql/slow-queries.log
basedir                         = /usr
datadir                         = /var/lib/mysql
tmpdir                          = /var/tmp
#slave_load_tmpdir              = /var/tmp
language                        = /usr/share/mysql/english
#log_bin                        = /var/lib/mysql/mysql-bin
#max_binlog_size                = 100M
#expire_logs_days               = 3
#relay-log                      = /var/lib/mysql/relay.log
#relay-log-index                = /var/lib/mysql/relay.index
#relay-log-info-file            = /var/lib/mysql/relay.info
#master-info-file               = /var/lib/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                    = 0
#binlog_cache_size              = 1M
#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
record_buffer                   = 2M
join_buffer_size                = 3M
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                     = 9000
open_files_limit                = 27000
query_cache_type                = 1
query_cache_size                = 256M
query_cache_limit               = 16M
thread_concurrency              = 16
thread_cache_size               = 16
max_connections                 = 40
ft_max_word_len                 = 20
ft_min_word_len                 = 3
long_query_time                 = 4
local_infile                    = 1
log_warnings                    = 2
log_queries_not_using_indexes
#log_slave_updates
log_long_format
skip_locking
skip_name_resolve
skip_external_locking
#skip_show_database
#skip_innodb
innodb_thread_concurrency       = 8
innodb_buffer_pool_size         = 512M
innodb_additional_mem_pool_size = 16M
innodb_data_home_dir            = /var/lib/mysql
innodb_log_arch_dir             = /var/lib/mysql
innodb_log_group_home_dir       = /var/lib/mysql
innodb_data_file_path           = ibdata1:10M:autoextend
innodb_flush_method             = O_DIRECT
innodb_log_file_size            = 5M #100M
innodb_log_buffer_size          = 8M
innodb_log_files_in_group       = 2
innodb_flush_log_at_trx_commit  = 1 #2
innodb_max_dirty_pages_pct      = 90
innodb_lock_wait_timeout        = 50 #120
innodb_file_per_table

[mysqlhotcopy]
interactive_timeout

apache.conf

Code: 
Timeout 30

KeepAlive On

MaxKeepAliveRequests 150

KeepAliveTimeout 2

<IfModule prefork.c>
StartServers           5
MinSpareServers        5
MaxSpareServers       10
ServerLimit           40
MaxClients            40
MaxRequestsPerChild 8000
</IfModule>

MYSQL Tuning Primer

Code: 
SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 4 sec.
You have 69596 out of 3444493 that take longer than 4 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/5.0/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 16
Current threads_cached = 14
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

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

MEMORY USAGE
Max Memory Ever Allocated : 1 G
Configured Max Per-thread Buffers : 607 M
Configured Max Global Buffers : 1 G
Configured Max Memory Limit : 1 G
Physical Memory : 3.94 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 406 M
Current key_buffer_size = 256 M
Key cache miss rate is 1 : 267
Key buffer fill ratio = 15.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 256 M
Current query_cache_used = 162 M
Current query_cache_limit = 16 M
Current Query cache Memory fill ratio = 63.64 %
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 = 2 M
Current read_rnd_buffer_size = 7 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 3.00 M
You have had 77 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 = 27000 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 = 9000 tables
You have a total of 8280 tables
You have 8377 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 64 M
Current tmp_table_size = 64 M
Of 33011 temp tables, 21% were created on disk
Created disk tmp tables ratio seems fine

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

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

Code: 
top - 10:41:32 up 27 days, 14:35,  1 user,  load average: 0.07, 0.05, 0.04
Tasks:  80 total,   1 running,  78 sleeping,   0 stopped,   1 zombie
Cpu(s):  5.3%us,  0.6%sy,  0.0%ni, 93.5%id,  0.6%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4141100k total,  3881712k used,   259388k free,   531408k buffers
Swap:  2104472k total,       48k used,  2104424k free,  2593760k cached

ich hoffe, ihr könnt mir da weiterhelfen :)
 
Welcher hohe RAM-Verbrauch?
Der von MySQL?
Oder der Allgemeine?
Oder dass nicht geswappt wird?

Du lieferst zwar viele Info's aber die Frage ist nicht präzise. ;)

huschi.

PS: Bitte Punkt 3.2 unserer Nutzungsbedingungen beachten. Danke!
 
OK. Das werde ich in Zukunft beachten.

Mir geht es nur darum, dass er momentan schon knapp 3,8GB RAM benutzt und nur noch 0,3GB frei ist. Und da habe ich die Befürchtung, dass er dann anfängt zu swappen bzw. das er dann Probleme macht wegen zu wenig RAM. Daher wollte ich fragen, ob man den Verbrauch nicht verringern könnte (z.B. durch bessere optimierte Einstellungen).

Infos zum System:

Code: 
# Intel Core 2 Duo 2x 2,6 GHz
# Arbeitsspeicher 4 GB DDR2 RAM
# Traffic 5.000 GB inklusive
# Festplatte SATA 2x 320 GB
# FTP-Backup 100 GB Speicherplatz
 
Dann erkundige Dich mal nach der Speicherverteilung von Linux. Ein paar Hinweise findest Du in meinem Artikel: Prozesse und Speicher überwachen - huschi.net
Bei "free" wird etwas über die Speicherbelegung referiert.
Nach den Zahlen von oben wird von Deinem Speicher lediglich ~800 MB als Programmspeicher genutzt. Den Rest teilen sich die Buffers und der Festplatten-Cache.

huschi.
 
Code: 
 total       used       free     shared    buffers     cached
Mem:       4141100    3883420     257680          0     531576    2598436
-/+ buffers/cache:     753408    3387692
Swap:      2104472         48    2104424

ok, habe das mal so durchgeführt. Sind meine Einstellungen soweit eigentlich optimiert oder gibt es da noch Verbesserungsmöglichkeiten/-bedarf?
 
Kommt drauf an, was Du optimieren haben willst bzw. ob Du mit der Performance Deines Servers unzufrieden bist.

huschi.
 
Hallo Community,
da ich mal wieder faul sein wollte und hier immer wieder super Tips bekommen hab, dachte ich mir das "tuning-primer"Script ist doch bestimmt was für Dich :)

Naja falsch gedacht ich bekomms nichtmal zum laufen:
Code: 
root@happy-server:/usr/bin# ./tuning-primer.sh
[: 1423: Linux: unexpected operator
-e \e[0m-e 
-e \e[0m-e e[1;31mc
-e - INITIAL LOGIN ATTEMPT FAILED -

-e \e[0m-e \e[0m-e Testing Stored for passwords:-e \e[0m-e e[1;31mc
-e  None Found

-e \e[0m-e e[1;31mc
-e - RETRY LOGIN ATTEMPT FAILED -

-e \e[0m-e \e[0m-e Could not auto detect login info!

-e \e[0mDo you have your login handy ? [y/N] : y
User: xxxxx
Password: xxxxx
-e \e[0m-e 
-e \e[0mWould you like me to create a ~/.my.cnf file for you? [y/N] : y
-e e[1;31mc
-e 
~/.my.cnf already exists!

-e \e[0mReplace ? [y/N] : y
-e e[1;31mc
-e - FINAL LOGIN ATTEMPT FAILED -

-e \e[0m-e e[1;31mc
-e Unable to log into socket: /var/run/mysqld/mysqld.sock
-e \e[0mroot@happy-server:/usr/bin#

Mach ich da was falsch?
Mein System ist Ubuntu 9.04 x64 Desktop (AMD x2 3800, 4Gig Ram), MySQL-Server-Version 5.0.75-0ubuntu10, MySQL-Client-Version: 5.0.75, Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4 with Suhosin-Patch

Gruß Micha
 
Deine Frage ist relativ leicht beantwortet:
Du hast falsche Login-Daten angegeben.

PS: Im Putty mit der Maus markieren und dann einfach hier "Einfügen". Ist deutlich leichter zu lesen. ;)

huschi.
 
MOD: Full-Quote entfernt!
Hallo hushi,

hmm jetzt bin ich verwirrt :confused: falsche Login-Daten?
Gut dann frag ich mal dumm welche Login-Daten sollten da denn rein, die vom MySQL-Admin (wäre bei mir root den hab ich benuntzt) oder vom System User (in meinem Fall identisch auch das PW)?

Gruß Micha74

PS: Das ist aus meinem Putty Kopiert, sah mir auch etwas komisch aus hab mir aber nichts dabei gedacht
 
Last edited by a moderator:
Hallo huschi,

ich hab lange gerübelt viel gegoogelt (irgendwann bin ich dabei dann auch auf deine HP gestossen) unds hab mir mal mysqltuner.pl besorgt.

Code: 
root@happy-server:/usr/bin# wget http://mysqltuner.com/mysqltuner.pl
--2009-04-04 10:42:47--  http://mysqltuner.com/mysqltuner.pl
Resolving mysqltuner.com... 209.20.89.226
Connecting to mysqltuner.com|209.20.89.226|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 38688 (38K) [text/plain]
Saving to: `mysqltuner.pl'

100%[======================================>] 38.688      87,0K/s   in 0,4s    

2009-04-04 10:42:47 (87,0 KB/s) - `mysqltuner.pl' saved [38688/38688]

root@happy-server:/usr/bin# chmod +x mysqltuner.pl
root@happy-server:/usr/bin# ./mysqltuner.pl

 >>  MySQLTuner 1.0.0 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password: 
[!!] Attempted to use login credentials, but they were invalid.
root@happy-server:/usr/bin#

Was soll ich nun sagen ich bin verwirrt "root" ist mit dem PW definiv mein MySQL-Admin, er hat alle Rechte.
Ich weiss nicht ob es bei GNOME-Desktop-Systemen irgendwelche Besonderheiten zu beachten gibt. Normal geister ich ja nur auf Servern in den Konsolen rum, allerdings hat mir ein Freund letztens mal sein GNOME-GUI-System gezeigt naja da wollt ich das dann auch mal ausprobieren (ich kannte GUI nur von Suse4 oder was das damals war)

Gruß Micha
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top