MySQL Serveroptimierung + Ignorierte Updates

[borbarad]

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:
[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

[borbarad]

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.)

-- 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:
MySQL AB :: MySQL 5.0 Reference Manual :: 5.1.3 System Variables
Visit MySQL AB :: MySQL Enterprise Advisors
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 MySQL AB :: MySQL 5.0 Reference Manual :: 5.6.3 Point-in-Time Recovery

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

openSUSE-103-64-LAMP:/usr/bin #