MySQL unter Volllast

frank1987

New Member
Hallo,

bei meinem dedizierten Server läuft MySQL fast immer mit über 95% Auslastung (laut Webmin). Besonders abends ist die Seite spürbar langsam.
tuning-primer.sh liefert mir folgende Ausgabe:
Code:
MySQL Version 5.0.51a-24+lenny5-log x86_64

Uptime = 7 days 14 hrs 18 min 27 sec
Avg. qps = 467
Total Questions = 306615841
Threads Connected = 5

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[/url]
Visit [url]http://www.mysql.com/products/enterprise/advisors.html[/url]
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 4 sec.
You have 4217 out of 306615960 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 [url]http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html[/url]

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

MAX CONNECTIONS
Current max_connections = 250
Current threads_connected = 5
Historic max_used_connections = 215
The number of used connections is 86% of the configured maximum.
You should raise max_connections

INNODB STATUS
Current InnoDB index space = 0 bytes
Current InnoDB data space = 0 bytes
Current InnoDB buffer pool free = 95 %
Current innodb_buffer_pool_size = 8 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 4.00 G
Configured Max Per-thread Buffers : 4.05 G
Configured Max Global Buffers : 524 M
Configured Max Memory Limit : 4.57 G
Physical Memory : 5.84 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 50 M
Current key_buffer_size = 512 M
Key cache miss rate is 1 : 2784
Key buffer free ratio = 80 %
Your key_buffer_size seems to be fine

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

JOINS
Current join_buffer_size = 132.00 K
You have had 22215 queries where a join could not use an index properly
You have had 333754 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 = 2308 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 = 1024 tables
You have a total of 330 tables
You have 406 open tables.
The table_cache value seems to be fine

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

TABLE LOCKING
Current Lock Wait ratio = 1 : 137
You may benefit from selective use of InnoDB.

Was könnte ich in der my.conf verbessern?

Es handelt sich um ein Debian Lenny System mit 6 GB RAM und Q8300 @ 2.50GHz CPU, falls das relevant ist

Vielen Dank
 
Last edited by a moderator:
Was macht der Server sonst noch? SATA oder SAS HDD's? Raid Level und Art (z.B. Hardware Raid 10 oder Software Raid 1)? Was wirft "top" aus, wenn die Maschine langsam wird?

Die gezeigten MySQL Infos dürften selbst diese CPU nicht ins Schwitzen bringen (wenn ich mich nicht gewaltig verschaut habe). Nur die 38% Temp Tables im Filesystem machen mich stutzig. Und da könnte, wenn es sich um SATA Platten handelt (möglicherweise noch als Software Raid) und der Server andere Dienste mit viel Schreib/Lese-Vorgängen bedient, der Knackpunkt liegen. Sehr oft sind langsame Dienste dieFolge von sehr hohen I/O Werten auf den Platten.

Bevor Du an das Tuning gehts solltest Du entsprechend sie Ursache finden.
 
Poste doch mal bitte den Output von:

Code:
show global status where Variable_name in (
    'Created_tmp_tables', 
    'Created_tmp_disk_tables',
    'Innodb_buffer_pool_pages_free', 
    'Innodb_buffer_pool_pages_total',
    'Key_blocks_used',
    'Key_blocks_unused',
    'Max_used_connections', 
    'Open_tables', 
    'Opened_tables', 
    'Qcache_free_blocks',
    'Qcache_free_memory',
    'Qcache_hits',
    'Qcache_inserts',
    'Qcache_lowmem_prunes',
    'Qcache_not_cached',
    'Qcache_queries_in_cache',
    'Qcache_total_blocks',
    'Threads_cached',
    'Threads_connected',
    'Threads_running',
    'Uptime'
);

show global variables where Variable_name in (
    'innodb_buffer_pool_size',
    'innodb_open_files',
    'key_buffer_size',
    'key_cache_block_size',
    'max_tmp_tables',
    'query_cache_limit',
    'query_cache_size',
    'read_buffer_size',
    'read_rnd_buffer_size',
    'sort_buffer_size',
    'table_cache',
    'thread_cache_size',
    'tmp_table_size'
);
 
Output lautet:
Code:
Created_tmp_disk_tables 	2872200
Created_tmp_tables 	4508702
Innodb_buffer_pool_pages_free 	490
Innodb_buffer_pool_pages_total 	512
Key_blocks_unused 	418245
Key_blocks_used 	36582
Max_used_connections 	215
Open_tables 	439
Opened_tables 	13536
Qcache_free_blocks 	33
Qcache_free_memory 	1726584
Qcache_hits 	87596583
Qcache_inserts 	143866278
Qcache_lowmem_prunes 	53098924
Qcache_not_cached 	3416442
Qcache_queries_in_cache 	133
Qcache_total_blocks 	316
Threads_cached 	13
Threads_connected 	7
Threads_running 	2
Uptime 	663195


innodb_buffer_pool_size 	8388608
innodb_open_files 	300
key_buffer_size 	536870912
key_cache_block_size 	1024
max_tmp_tables 	32
query_cache_limit 	1048576
query_cache_size 	2097152
read_buffer_size 	131072
read_rnd_buffer_size 	262144
sort_buffer_size 	16777208
table_cache 	1024
thread_cache_size 	16
tmp_table_size 	33554432

@Hostingparadies: Ausgabe von top:
Code:
top - 14:38:36 up 94 days, 10:31,  1 user,  load average: 1.70, 1.64, 1.65
Tasks: 164 total,   2 running, 162 sleeping,   0 stopped,   0 zombie
Cpu(s): 17.5%us, 11.5%sy,  0.2%ni, 67.7%id,  1.6%wa,  0.2%hi,  1.4%si,  0.0%st
Mem:   6130744k total,  5328980k used,   801764k free,   857540k buffers
Swap: 17960628k total,      780k used, 17959848k free,  1711128k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20678 mysql     20   0  968m 240m 6160 S  156  4.0  10608:15 mysqld
 1200 www-data  20   0  257m  36m  13m R   28  0.6   0:00.56 apache2
 1225 www-data  20   0  252m  30m  12m S   16  0.5   0:00.64 apache2
 1230 www-data  20   0  249m  25m  10m S    8  0.4   0:00.44 apache2
  509 www-data  20   0  247m  28m  14m S    4  0.5   0:01.06 apache2
 1205 www-data  20   0  239m  13m 7064 S    4  0.2   0:00.34 apache2
 1250 www-data  20   0  251m  30m  13m S    4  0.5   0:00.50 apache2
 1257 www-data  20   0  248m  23m 9732 S    4  0.4   0:00.28 apache2
32306 www-data  20   0  251m  27m  10m S    4  0.5   0:00.82 apache2
13001 teamspea  20   0  252m  13m 5428 S    2  0.2 312:42.95 ts3server_linux
    1 root      20   0 10316  700  584 S    0  0.0   0:54.59 init
    2 root      15  -5     0    0    0 S    0  0.0   0:00.34 kthreadd
    3 root      RT  -5     0    0    0 S    0  0.0   0:10.18 migration/0
    4 root      15  -5     0    0    0 S    0  0.0   2:47.33 ksoftirqd/0
    5 root      RT  -5     0    0    0 S    0  0.0   4:17.02 watchdog/0
    6 root      RT  -5     0    0    0 S    0  0.0   0:08.76 migration/1
    7 root      15  -5     0    0    0 S    0  0.0   1:48.18 ksoftirqd/1
    8 root      RT  -5     0    0    0 S    0  0.0   0:12.92 watchdog/1
    9 root      RT  -5     0    0    0 S    0  0.0   0:03.74 migration/2
   10 root      15  -5     0    0    0 S    0  0.0   1:52.85 ksoftirqd/2
   11 root      RT  -5     0    0    0 S    0  0.0   0:11.30 watchdog/2
   12 root      RT  -5     0    0    0 S    0  0.0   0:04.04 migration/3
   13 root      15  -5     0    0    0 S    0  0.0   1:33.85 ksoftirqd/3
   14 root      RT  -5     0    0    0 S    0  0.0   0:10.86 watchdog/3
   15 root      15  -5     0    0    0 S    0  0.0  13:15.75 events/0
   16 root      15  -5     0    0    0 S    0  0.0  16:25.20 events/1
   17 root      15  -5     0    0    0 S    0  0.0   6:47.92 events/2
   18 root      15  -5     0    0    0 S    0  0.0  21:39.48 events/3
   19 root      15  -5     0    0    0 S    0  0.0   0:00.00 khelper
   56 root      15  -5     0    0    0 S    0  0.0   0:12.50 kblockd/0
   57 root      15  -5     0    0    0 S    0  0.0   0:10.38 kblockd/1
   58 root      15  -5     0    0    0 S    0  0.0   0:11.12 kblockd/2
   59 root      15  -5     0    0    0 S    0  0.0   0:09.30 kblockd/3
   61 root      15  -5     0    0    0 S    0  0.0   0:00.00 kacpid
   62 root      15  -5     0    0    0 S    0  0.0   0:00.00 kacpi_notify
  142 root      15  -5     0    0    0 S    0  0.0   0:00.00 ksuspend_usbd
  148 root      15  -5     0    0    0 S    0  0.0   0:00.00 khubd
  151 root      15  -5     0    0    0 S    0  0.0   0:00.00 kseriod
  208 root      15  -5     0    0    0 S    0  0.0   5:41.56 kswapd0
  209 root      15  -5     0    0    0 S    0  0.0   0:00.00 aio/0
  210 root      15  -5     0    0    0 S    0  0.0   0:00.00 aio/1
  211 root      15  -5     0    0    0 S    0  0.0   0:00.00 aio/2
  212 root      15  -5     0    0    0 S    0  0.0   0:00.00 aio/3
  631 root      20   0 40900 7612 1640 S    0  0.1   2:07.77 munin-node
ist eine SATA HDD, ohne RAID (habe zumindest nichts dergleichen installiert)

Gruß und danke
 
Last edited by a moderator:
Meine Empfehlung:

* Created_tmp_disk_tables 2872200, Created_tmp_tables 4508702

Über 50% der temporären Tabellen landen auf der Platte, was nicht
besonders berauschend ist. Du hast zwar tmp_table_size auf 32 MB
gesetzt, aber max_heap_table_size noch auf 16 MB stehen. Beide
Werte sollten identisch sein.

* Qcache_not_cached 3416442, Qcache_queries_in_cache 133, Qcache_free_memory 1726584
* query_cache_limit 1048576, query_cache_size 2097152

Das ist ein wenig mager. Die meisten Queries landen garnicht im
Cache. Ich würde query_cache_size viel höher einstellen. Für den
Anfang vielleicht auf 128M und query_cache_limit würde ich auf 2M
setzen.

Die restlichen Werte (innodb, threads, key buffer und table cache)
sehen eigentlich ganz ok aus.
 
top - 14:38:36 up 94 days, 10:31, 1 user, load average: 1.70, 1.64, 1.65
Tasks: 164 total, 2 running, 162 sleeping, 0 stopped, 0 zombie
Cpu(s): 17.5%us, 11.5%sy, 0.2%ni, 67.7%id, 1.6%wa, 0.2%hi, 1.4%si, 0.0%st
Mem: 6130744k total, 5328980k used, 801764k free, 857540k buffers
Swap: 17960628k total, 780k used, 17959848k free, 1711128k cached

Im Grund genommen dümpelt der Server vor sich hin. 67% idle und kein IOwait
und auch keine hohe Load. Wäre mal interessanter zu wissen wie die
Statistiken aussehen wenn der Server unter volldampf läuft und du die
langsamen Antwortzeiten bemerkst.
 
Ein paar andere Tipps:

Schalte mal slow queries ein, so auf 3 Sekunden und schau dir die
Statements an, ob überall auch fein Indizes verwendet werden.

Darüber hinaus auch mal in die Prozessliste schauen "show processlist"
und nach "locked" ausschau halten. Bei MyISAM wird jedesmal die
gesamte Tabelle gelockt und wenn ein Index auf einer großen Tabelle
fehlt, auf der öfters mal ein Update gefahren wird, dann hängen auch
die lesenden Zugriffe. Ich kann in dem Szenario InnoDB wärmstens
empfehlen!
 
Meine Vorredner waren schneller, ich kann mich dem Gesagten nur anschliessen. Der Auszug von "top" ist nur interessant wenn Du das Performanceproblem feststellst.

Hilfreich könnte auch eine 24 Stunden Überwachung mit "sar" sein.
 
Meine Vorredner waren schneller, ich kann mich dem Gesagten nur anschliessen. Der Auszug von "top" ist nur interessant wenn Du das Performanceproblem feststellst.

Hilfreich könnte auch eine 24 Stunden Überwachung mit "sar" sein.

Mit Erlaubnis würde ich dem gerne noch etwas hinzufügen :-)

@frank1987: sar sollte in der Crontab noch etwas verfeinert werden und
zwar von den Standard 10 Minuten auf 3 oder sogar 2 Minuten gesetzt werden.

/etc/cron.d/sysstat müsste es sein. Dort dann */2 eintragen für die Minuten.
Keine Sorge, da werden keine Unmengen an Daten generiert, maximal so
100MB, die auch noch rotiert werden.

Warum die Umstellung? Wenn sar die Statistiken alle 10 Minuten sammelt,
dann verlieren die Statistiken leider an Aussagekraft, weil sar die
Durchschnittswerte seit dem letzten Aufruf berechnet. Wenn also 1 Minute
lang die CPU auf 100% lief und dann die nächsten 9 Minuten gegen 0,
dann würde man am Ende nur eine CPU Auslastung von 10% sehen.
Mit dem Sammeln der Daten alle 2 Minuten kann man das etwas entzerren.
 
Last edited by a moderator:
Hier wird gerade zu viel auf den Temp-Tables rum gelaufen und zu wenig auf den eigentlichen Schwachstellen.

Historic max_used_connections = 215
Dieser Wert ist sehr auffällig und bedenklich. Denn er sagt aus, das 215 Connections gleichzeitig Queries abgefeuert haben.
Wir können wahrscheinlich davon ausgehen, dass mind. 200 Connections von (PHP-)Scripten initiiert worden sind.
Und spätestens ab hier muss man die Apache-Konfiguration und die PHP-Einbindung (mod_php, FastCGI) erfragen um mal ein paar echte Schritte weiter zu kommen.
Ich tippe darauf, das zu viele Apache-Childs zugelassen sind. Und mal ganz ehrlich: Wie soll ein Quadcore über 200 PHP-Scripte gleichzeitig bedienen ohne dabei in die Knie zu gehen?
Manchmal ist weniger gleich mehr und ein "Nacheinander" schneller als "Parallel".

Current query_cache_size = 2 M
Current query_cache_used = 545 K
Diese Werte lassen auf zwei Szenarios schließen:
Entweder Massenwebhosting oder hoch frequentierte Webapplication mit schlechter Datenbank-Struktur. (Z.B. os|xt:Commerce, Wordpress)
Da aber nur 330 Tabellen vorhanden sind, tippe ich auf Letzteres.

Of 4477271 temp tables, 38% were created on disk
Ein Wort noch dazu: Dies ist nicht zwangsweise bedenklich. Denn "disk" bedeutet nicht zwangsweise wirklich Festplatte. Sie landen meistens im Festplatten-Cache (also ebenfalls im Ram) und werden - falls überhaupt - erst auf Platte geschrieben, wenn das System "idle" meldet.

Weitere Werte die mir ins Auge fallen:
Current key_buffer_size = 512 M
Aktuell zu hoch.
Current read_rnd_buffer_size = 256 K
Current join_buffer_size = 132.00 K
Current read_buffer_size = 128 K
Alle Werte zu klein. Die kannst Du locker auf 1M erhöhen. Der Speicher wird nur angefordert, wenn er auch gebraucht wird. Es ist aber schlecht, wenn mal mehr Speicher gebraucht wird als maximal vorgegeben ist.
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Wie bereits gesagt wurde, machen diese Werte keinen Sinn. Tausch sie einfach um um.

huschi.
 
Hallo Huschi,

Dieser Wert ist sehr auffällig und bedenklich. Denn er sagt aus, das 215 Connections gleichzeitig Queries abgefeuert haben.
Wir können wahrscheinlich davon ausgehen, dass mind. 200 Connections von (PHP-)Scripten initiiert worden sind.
Und spätestens ab hier muss man die Apache-Konfiguration und die PHP-Einbindung (mod_php, FastCGI) erfragen um mal ein paar echte Schritte weiter zu kommen.
Ich tippe darauf, das zu viele Apache-Childs zugelassen sind. Und mal ganz ehrlich: Wie soll ein Quadcore über 200 PHP-Scripte gleichzeitig bedienen ohne dabei in die Knie zu gehen?
Manchmal ist weniger gleich mehr und ein "Nacheinander" schneller als "Parallel".

Ich weiß zwar nicht wo deine Erfahrungswerte liegen, aber ich habe
schon weitaus mehr Requests/s auf einem Quadcore gesehen mit ca.
MaxClients 1000 und jeder Menge MySQL-Connections.

Diese Werte lassen auf zwei Szenarios schließen:
Entweder Massenwebhosting oder hoch frequentierte Webapplication mit schlechter Datenbank-Struktur. (Z.B. os|xt:Commerce, Wordpress)
Da aber nur 330 Tabellen vorhanden sind, tippe ich auf Letzteres.

Das ist eine ziemlich unqualifizierte Antwort. Bitte teile mir den Link
mit, über den du deine Glaskugel gekauft hast :-)

Ein Wort noch dazu: Dies ist nicht zwangsweise bedenklich. Denn "disk" bedeutet nicht zwangsweise wirklich Festplatte. Sie landen meistens im Festplatten-Cache (also ebenfalls im Ram) und werden - falls überhaupt - erst auf Platte geschrieben, wenn das System "idle" meldet.

Das wäre mir neu. Wenn dem so ist, dann teile mir doch bitte einmal
die Stelle mit, an der das Verhalten dokumentiert ist. Ich werde es dir
danken.

Weitere Werte die mir ins Auge fallen:

Aktuell zu hoch.

Das macht nichts, weil der Bereich nur verwendet wird, wenn er
tatsächlich gebraucht wird.

Wie bereits gesagt wurde, machen diese Werte keinen Sinn. Tausch sie einfach um um.

Aus mysqlperformanceblog.com

In fact setting tmp_table_size is not enough as MySQL also looks at max_heap_table_size variable and uses lower value as a limit to for in memory temporary table after which it will be converted to MyISAM.

Also sollten die Werte identisch sein.
 
Hallo Huschi,

Current read_rnd_buffer_size = 256 K
Current join_buffer_size = 132.00 K
Current read_buffer_size = 128 K

Alle Werte zu klein. Die kannst Du locker auf 1M erhöhen. Der Speicher wird nur angefordert, wenn er auch gebraucht wird. Es ist aber schlecht, wenn mal mehr Speicher gebraucht wird als maximal vorgegeben ist.

read_buffer_size muss nicht unbedingt zu klein sein. Ich hatte mal diverse
Benchmarks mit unterschiedlichen Sets gefahren und kam auf fast immer
dem gleichen Ergebnis -> 128k scheint optimal zu sein.

Auch ganz nett:

http://www.mysqlperformanceblog.com/2007/09/17/mysql-what-read_buffer_size-value-is-optimal/

Code:
read_buffer_size    Time (sec)
8200                45.2
16K                 44.8
32K                 45.6
64K                 43.4
128K                43.0
256K                51.9
512K                60.8
2M                  65.2
8M                  66.8
32M                 67.2

Natürlich muss dieses Ergebnis nicht für alle Umgebungen zutreffen.

Viele Grüße
Jonny


Edit: jede Menge, mea culpa
 
Last edited by a moderator:
@str76
Ich weiß ja nicht, warum Du mich direkt so anfeindest. Aber ich schiebe es einfach mal auf eine grundsätzlich Einstellungssache und nehme es nicht persönlich.

Folgendes:
Du weißt nicht wo meine Erfahrungswerte liegen, ich kenne auch nicht Deine.
Das macht aber nichts, da dadurch eine Bemerkung die sich nicht mit Deinen Werten decken nicht zwangsweise "unqualifiziert" sind.
Insbesondere nicht, wenn sie als Vermutung (im Sinne von Hypothese) abgegeben worden sind. ("...ich tippe darauf...")

Zu Deinem dritten Kommentar:
Google nach Linux-HD-Cache. Eine "Temp-Table on Disk" wird als normale Datei angelegt und dem entsprechend vom System gecached.

Und bei tmp_table_size+max_heap_table_size ist Dir in Deiner Quelle der Singular von "table" entgangen. Es besteht aber die Möglichkeit mehrere Temp-Tables zu erstellen. Und davon werden so viele im Speicher angelegt, bis max_heap_table_size erreicht ist.
Daher gilt "Kleinergleich" (statt "identisch"):
tmp_table_size <= max_heap_table_size

@bloonix
Dein Link ist schön zu lesen. Aber man sollte - gerade in der IT-Branche - immer am Puls der Zeit stehen. Daher wiederhole diesen Test von 2007 mit aktueller Hardware und vergleiche dabei auch 32bit zu 64bit Systemen.

huschi.
 
@Huschi: Spätestens, wenn die Tables Rows von Typ TEXT oder BLOB enthalten, werden diese grundsätzlich auf Platte geschrieben, egal wie gross max_heap_table_size ist. Und da solche Tabellen relativ oft recht gross werden, ist tmp_table_size am Besten immer gleich max_heap_table_size.

Unabhängig davon fehlen einigen Tabellen passende Indexe, wodurch etliche Temp-Tables und Slow-Queries erst erzwungen werden. Bevor diese Indexe nicht gesetzt sind, macht das Doktorn an der my.cnf keinen wirklichen Sinn...
 
Hallo Huschi,

@bloonix
Dein Link ist schön zu lesen. Aber man sollte - gerade in der IT-Branche - immer am Puls der Zeit stehen. Daher wiederhole diesen Test von 2007 mit aktueller Hardware und vergleiche dabei auch 32bit zu 64bit Systemen.

der Artikel ist von 2007 und ich habe den Test vor ca. einem Jahr
wiederholt, mit knapp 30 Millionen Zeilen und bin auf das gleiche
Resultat gekommen. Nur manchmal waren 256k optimaler.

Ich hatte aber auch schon Kundensysteme bei denen 512k ein
besseres Resultat erzielten.

Da wir leider Franks Datenbank nicht profilen können, schweben natürlich
alle Aussagen ein wenig in den Wolken. Das ist leider immer der große
Nachteil in Foren -> wir haben keine genaue Sicht auf die Systeme.

Viele Grüße und einen schönen Abend noch,
Jonny
 
Hi huschi,

@str76
Ich weiß ja nicht, warum Du mich direkt so anfeindest. Aber ich schiebe es einfach mal auf eine grundsätzlich Einstellungssache und nehme es nicht persönlich.

entschuldige bitte, ich bin von natur aus ein wenig sarkastisch,
das ist aber nicht böse gemeint. :-)

Bei dem einen oder anderen Satz musste ich halt ein wenig
schmunzeln.

Bis dann.
 
Back
Top