MySQL Serveroptimierung + Ignorierte Updates

B

borbarad

New Member
Es gibt 2 Punkte:
1.) Müssen auf Dauer sehr viele User bei einem Onlinespiel das ich geschrieben haben darauf zugreifen können und dafür die MySQL Einstellungen optimiert werden.
Da es ein Freewaregame ist sind jedoch die Mittel mehr als begrenzt,
da der Server bereits teuer ist und die MySQL Schulung knapp 1600 Eur kosten soll,
was als Schüler ein wenig heftig ist.

2.) Mache ich Updates nacheinander in viele Tabellen hintereinander,
Wird mir bei mysql_affected_rows() zwar eine 1 angezeigt,
das er eine Veränderung gemacht hat bei der dritten Änderung,
wenn diese alleine Läuft klappt es auch,
aber bei den 4 Updates hintereinander verschluckt er diese immer.

Daher einmal die Bitte ob jemand so lieb ist die my.cnf zu optimieren und
ob jemand ne idee hat für die verschluckten updates.

Ich habe ein dedicated Server mit folgenden Daten:
- AMD Athlon 64 X2 6000+ Dual Core
- 6 GB DDR2 RAM
- 2 x 750 GB SATA II

- openSuSE 10.3

Mem: 6094232k total, 3025988k used, 3068244k free
Swap: 2104504k total, 0k used, 2104504k free

Aktuell sind 20 User angemeldet.
Es werden vorraussichtlich insgesamt 25.000 angemeldete User werden,
die aber NICHT gleichzeitig aktiv sind.

Meine my.cnf sieht wie folgt aus:
Code: 
[mysqld]
port		= 3306
socket		= /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 16M
max_allowed_packet = 1M
table_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M

bind-address = 127.0.0.1

server-id	= 1

[safe_mysqld]
err-log=/var/lib/mysql/mysqld.log

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

Vielen Dank für die Hilfe
 
Last edited by a moderator:
Zu 1) Welche Programmiersprache? Welche Technik?

Zu 2) Hier mußt Du schon etwas Beispiel-Code liefern.

Zu 3) Suche nach dem tuning-primer-script.
Poste hier die Ausgabe bzw. setzt die gemachten Vorschläge entsprechend um.

huschi.
 
1.) In PHP ist es geschrieben.

2.) Naja es sind nur normale Updates und an denen an sich kann es nicht liegen,
daher hatte ich diese auch nicht gepostet oder wieso sagst Du das?

3.)
Code: 
        -- MYSQL PERFORMANCE TUNING PRIMER --
             - By: Matthew Montgomery -

MySQL Version 5.0.45 x86_64

/usr/bin/tuning-primer.sh: line 388: bc: command not found
/usr/bin/tuning-primer.sh: line 389: bc: command not found
/usr/bin/tuning-primer.sh: line 390: bc: command not found
/usr/bin/tuning-primer.sh: line 391: bc: command not found
/usr/bin/tuning-primer.sh: line 392: bc: command not found
/usr/bin/tuning-primer.sh: line 393: bc: command not found
Uptime =  days  hrs  min  sec
Avg. qps = 0
Total Questions = 1637789
Threads Connected = 1

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:
[url=http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html]MySQL AB :: MySQL 5.0 Reference Manual :: 5.1.3 System Variables[/url]
Visit [url=http://www.mysql.com/products/enterprise/advisors.html]MySQL AB :: MySQL Enterprise Advisors[/url]
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10 sec.
You have 0 out of 1637810 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 [url=http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html]MySQL AB :: MySQL 5.0 Reference Manual :: 5.6.3 Point-in-Time Recovery[/url]

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

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 1
Historic max_used_connections = 6
The number of used connections is 6% 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

MEMORY USAGE
/usr/bin/tuning-primer.sh: line 1204: bc: command not found
/usr/bin/tuning-primer.sh: line 1205: bc: command not found
/usr/bin/tuning-primer.sh: line 1229: bc: command not found
/usr/bin/tuning-primer.sh: line 1232: bc: command not found
/usr/bin/tuning-primer.sh: line 1233: bc: command not found
/usr/bin/tuning-primer.sh: line 1235: bc: command not found
/usr/bin/tuning-primer.sh: line 1237: [: -gt: unary operator expected
/usr/bin/tuning-primer.sh: line 350: [: max_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 356: [: max_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 362: [: max_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 369: export: `0=max_memoryHR': not a valid identifier
Max Memory Ever Allocated :  bytes
/usr/bin/tuning-primer.sh: line 350: [: per_thread_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 356: [: per_thread_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 362: [: per_thread_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 369: export: `0=per_thread_buffersHR': not a valid identifier
Configured Max Per-thread Buffers :  bytes
/usr/bin/tuning-primer.sh: line 350: [: global_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 356: [: global_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 362: [: global_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 369: export: `0=global_buffersHR': not a valid identifier
Configured Max Global Buffers :  bytes
/usr/bin/tuning-primer.sh: line 350: [: total_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 356: [: total_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 362: [: total_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 369: export: `0=total_memoryHR': not a valid identifier
Configured Max Memory Limit :  bytes
/usr/bin/tuning-primer.sh: line 331: bc: command not found
Physical Memory :  G
Max memory limit seem to be within acceptable norms

KEY BUFFER
/usr/bin/tuning-primer.sh: line 331: bc: command not found
/usr/bin/tuning-primer.sh: line 646: bc: command not found
/usr/bin/tuning-primer.sh: line 647: bc: command not found
/usr/bin/tuning-primer.sh: line 331: bc: command not found
Current MyISAM index space =  K
/usr/bin/tuning-primer.sh: line 331: bc: command not found
Current key_buffer_size =  M
Key cache miss rate is 1 : 706
Key buffer fill ratio =  %
/usr/bin/tuning-primer.sh: line 684: [: -ge: unary operator expected
/usr/bin/tuning-primer.sh: line 688: [: -le: unary operator expected
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is supported but not enabled
Perhaps you should set the query_cache_size

SORT OPERATIONS
/usr/bin/tuning-primer.sh: line 331: bc: command not found
Current sort_buffer_size =  K
/usr/bin/tuning-primer.sh: line 331: bc: command not found
Current read_rnd_buffer_size =  K
Sort buffer seems to be fine

JOINS
/usr/bin/tuning-primer.sh: line 331: bc: command not found
Current join_buffer_size =  K
You have had 1040 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 = 1024 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 = 64 tables
You have a total of 98 tables
You have 64 open tables.
Current table_cache hit rate is 0%, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
/usr/bin/tuning-primer.sh: line 331: bc: command not found
Current max_heap_table_size =  M
/usr/bin/tuning-primer.sh: line 331: bc: command not found
Current tmp_table_size =  M
Of 7117 temp tables, 61% 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
/usr/bin/tuning-primer.sh: line 331: bc: command not found
Current read_buffer_size =  K
Current table scan ratio = 764 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 231498
Your table locking seems to be fine
 
Last edited by a moderator:
borbarad said:
Naja es sind nur normale Updates und an denen an sich kann es nicht liegen,
Click to expand...
Das habe ich wirklich nicht zu Spaß geschrieben.
Denn wie soll man Dir mir Einstellungen helfen, wenn Du evtl. einen (kleinen) Fehler im Code hast?
Aber wir können diesen Punkt gerne überspringen...

/usr/bin/tuning-primer.sh: line 388: bc: command not found
Click to expand...
Installier Dir das Paket "bc".

Your long_query_time may be too high, I typically set this under 5 sec.
Click to expand...
Und wie ich schon sagte: Einfach den Empfehlungen folgen...
"bc" ist aber erstmal wichtiger.

huschi.
 
Apache, server-tuning.conf
Code: 
<IfModule prefork.c>
StartServers       1
MinSpareServers    5
MaxSpareServers    10
ServerLimit       400
[COLOR="Red"]MaxClients        400[/COLOR]
MaxRequestsPerChild  8000
</IfModule>

my.cnf
Code: 
[mysqld]

key_buffer = 32M
net_buffer_length = 8K

sort_buffer_size = 256K
myisam_sort_buffer_size = 256K
read_buffer_size = 128K
read_rnd_buffer_size = 256K
join_buffer_size = 1M

query_cache_size = 2M
thread_cache = 32
table_cache = 1024
max_allowed_packet = 256K

[COLOR="Red"][COLOR="Red"]max_connections = 400[/COLOR][/COLOR]
low_priority_updates = 1
long_query_time = 2

Apache benötigt für 400 gleichzeitige Verbindungen (httpd Prozesse) ~ 4800 MB RAM. Vorausgesetzt die CPU + Netzwerkkarte machen die 400 Verbindungen überhaupt mit.

Von den 6000 MB RAM bleiben dann noch 1200 MB RAM übrig. 1000 MB stellen wir MySQL zur Verfügung.

Die Buffers + Caches müssen so gewählt werden, daß bei max_connections = 400 der Configured Max Memory Limit: 1GB nicht übersteigt.

Tuning-Primer Script
Code: 
MEMORY USAGE
Max Memory Ever Allocated :  M
Configured Max Per-thread Buffers :  M
Configured Max Global Buffers :  M
[COLOR="Blue"]Configured Max Memory Limit : 1GB[/COLOR]
Total System Memory :  G

Tuning-Primer Script macht Verbesserungsvorschläge auf die man eingehen kann wenn ausreichend RAM vorhanden ist. Thread_cache könnte man z.B. mal mit 64 testen.
 
Last edited by a moderator:
News

Huschi said:
MOD: Full-Quote entfernt!
Click to expand...
Also zu dem ersten Punkt:
$anzahl=mysql_affected_rows();
ergibt den WERT 1 also macht er was bei diesem Befehl:

UPDATE rohstoffe SET res1=res1-'8000', res2=res2-'4000', res3=res3-'0' WHERE userid='1' AND planetenid='22'
Doch nur scheinbar, weil die Werte bleiben gleich.

Wenn ich das jedoch bei Webmin z.B. manuell reinhacke kommt
No data returned und er legt die werte wie er sollte zurück/um.

2.) Habe das BC Tool installiert und /usr/bin/tuning-primer.sh ein zweites mal ausgeführt,
nun kommt folgendes raus:

MOD: CODE-Tag gesetzt
Code: 
        -- MYSQL PERFORMANCE TUNING PRIMER --
             - By: Matthew Montgomery -

MySQL Version 5.0.45 x86_64

Uptime = 24 days 15 hrs 43 min 3 sec
Avg. qps = 0
Total Questions = 1731220
Threads Connected = 1

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:
[url=http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html]MySQL :: MySQL 5.0 Reference Manual :: 5.1.3 System Variables[/url]
Visit [url=http://www.mysql.com/products/enterprise/advisors.html]MySQL :: MySQL Enterprise Advisors[/url]
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10 sec.
You have 0 out of 1731241 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 [url=http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html]MySQL :: MySQL 5.0 Reference Manual :: 6.3 Point-in-Time Recovery[/url]

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

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 1
Historic max_used_connections = 6
The number of used connections is 6% 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

MEMORY USAGE
Max Memory Ever Allocated : 35 M
Configured Max Per-thread Buffers : 161 M
Configured Max Global Buffers : 26 M
Configured Max Memory Limit : 187 M
Physical Memory : 5.81 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 588 K
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 514
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 supported but not enabled
Perhaps you should set the query_cache_size

SORT OPERATIONS
Current sort_buffer_size = 512 K
Current read_rnd_buffer_size = 508 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 1154 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 = 1024 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 = 64 tables
You have a total of 98 tables
You have 64 open tables.
Current table_cache hit rate is 0%, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 9932 temp tables, 53% 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 = 252 K
Current table scan ratio = 764 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 244160
Your table locking seems to be fine
 
Last edited by a moderator:
borbarad said:
UPDATE rohstoffe SET res1=res1-'8000', res2=res2-'4000', res3=res3-'0' WHERE userid='1' AND planetenid='22'
Click to expand...
Wenn resX ein Zahlenfeld ist, brauchst Du die Zahlen nicht in Hochkommata setzten. (Könnten bei der Subtraktion evtl. sogar hinderlich sein...)
Aber Du könntest danach ja einfach mal die MySQL-Fehler-Nummer/-String auslesen.

/usr/bin/tuning-primer.sh ein zweites mal ausgeführt
Click to expand...
Und was erkennst Du daraus?
Oder anders gefragt: Was verstehst Du davon nicht?

huschi.
 
Huschi said:
Wenn resX ein Zahlenfeld ist, brauchst Du die Zahlen nicht in Hochkommata setzten. (Könnten bei der Subtraktion evtl. sogar hinderlich sein...)
Aber Du könntest danach ja einfach mal die MySQL-Fehler-Nummer/-String auslesen.
Click to expand...

Ja das ist ein Zahlenfeld,
also meinst Du sollte ich testweise die Zahlen mal ohne ' schreiben?

Wobei wieso klappt es dann unter webmin mysql execution?

Das ist das was ich nicht verstehe zumal er ja auch sagt das die ROW 1 ist also er eine zeile verändert haben mag.

Wie lese ich den fehler nummer string aus weil
mysql_error();
bringt nichts zurück weil ja eine zeile angeblich verändert wurde.
 
Hey,

Ich würde dir empfehlen, PHP als fast-CGI zu kompilieren und die ganze Sache mit Lighttpd zu betreiben. Das sollte das ganze etwas entschärfen. RAM sollte primär MySQL zur Verfügung stehen, MySQL kann den RAM besser gebrauchen.

Ben
 
You must log in or register to reply here.
Back
Top