Datenbank überlastet :-(

[admin]

root oder managed

[admin]

49 ,99 oder 149 €

[homer_j]

Rootserver L, d.h. 49 € (hab' ich oben irgendwo schon geschrieben, aber egal )

[homer_j]

vielleicht hilft ja das hier weiter:

mysql> SHOW STATUS;
ERROR 2006: MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 18800
Current database: *** NONE ***

+--------------------------+----------+
| Variable_name | Value |
+--------------------------+----------+
| Aborted_clients | 1402 |
| Aborted_connects | 557 |
| Bytes_received | 24048837 |
| Bytes_sent | 20508002 |
| Connections | 18895 |
| Created_tmp_disk_tables | 0 |
| Created_tmp_tables | 52584 |
| Created_tmp_files | 0 |
| Delayed_insert_threads | 0 |
| Delayed_writes | 0 |
| Delayed_errors | 0 |
| Flush_commands | 1 |
| Handler_delete | 0 |
| Handler_read_first | 55 |
| Handler_read_key | 78483 |
| Handler_read_next | 0 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 8832 |
| Handler_read_rnd_next | 10223465 |
| Handler_update | 51227 |
| Handler_write | 11028 |
| Key_blocks_used | 2 |
| Key_read_requests | 78483 |
| Key_reads | 2 |
| Key_write_requests | 0 |
| Key_writes | 0 |
| Max_used_connections | 200 |
| Not_flushed_key_blocks | 0 |
| Not_flushed_delayed_rows | 0 |
| Open_tables | 264 |
| Open_files | 274 |
| Open_streams | 0 |
| Opened_tables | 276 |
| Questions | 218889 |
| Select_full_join | 0 |
| Select_full_range_join | 0 |
| Select_range | 0 |
| Select_range_check | 0 |
| Select_scan | 70817 |
| Slave_running | OFF |
| Slave_open_temp_tables | 0 |
| Slow_launch_threads | 969 |
| Slow_queries | 41 |
| Sort_merge_passes | 0 |
| Sort_range | 0 |
| Sort_rows | 8832 |
| Sort_scan | 52608 |
| Table_locks_immediate | 158496 |
| Table_locks_waited | 7660 |
| Threads_cached | 0 |
| Threads_created | 18894 |
| Threads_connected | 182 |
| Threads_running | 83 |
| Uptime | 10890 |
+--------------------------+----------+
54 rows in set (5 min 31.33 sec)

[hand]

Gefällt mir wie Du an die Sache ran gehst. Super.

Es tut mir leid, aber ich muß das Fragen. Die Änderungen die Du durchgeführt hast haben schon gezogen oder? (mysqld --help)

Schauen wir uns mal die Tabellen an, wie die definiert sind (bezüglich Indizes udgl.)

>describe table1;
>describe table2;
>....

Probier mal die timeouts noch zu verringern:

set-variable=wait_timeout=900 
# wait_timeout alter Wert: 28800 = 8 Stunden

set-variable=interactive_timeout=900 
# interactive_timeout alter Wert: 28800 = 8 Stunden

Dann kann noch sein, daß die Abfragen in den Skripten selbst umständlich programmiert sind. Irgendwie muß der Knoten doch zu lösen gehen.

Zum Zeitpunkt wo mySQL so ziemlich dicht ist, wie sieht es da mit anderen Requests, die mit mySQL nix zu tun haben aus. Sind die dann soweit performant, oder auch grindig?

Gibt es vielleicht irgendwelche Hinweise in irgendeinem Logfile?

Läuft vielleicht irgendein Batch(Cron)job der die Maschine regelmäßig dicht macht? Denk mal nach. Mir geht es primär darum ausschließen zu können, daß andere Einflüsse das DB Verhalten beeinflussen oder sogar provozieren. Nicht daß wir uns mit einem Folgefehlverhalten beschäftigen, und am Ende die Erkenntnis kommt, daß die große Backupsicherung läuft oder so was.

[homer_j]

ja, die ich hab' extra nachgeschaut, ob die änderungen funktioniert haben. da ich nicht weiß, wie man das in mysql macht, hab ich sowieso gleich den ganzen server neu gebootet *g

timeouts sind noch mal runter.

mysql> describe tabelle1;
+---------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------------------+------+-----+---------+-------+
| vorname | varchar(15) | YES | | NULL | |
| name | varchar(15) | YES | | NULL | |
| login | varchar(15) | | PRI | | |
| passwort | varchar(15) | YES | | NULL | |
| homepage | varchar(80) | YES | | NULL | |
| banner | varchar(100) | YES | | NULL | |
| startbonus | mediumint(9) | YES | | NULL | |
| einblendung | int(11) | YES | | NULL | |
| ausblendung | int(11) | YES | | NULL | |
| hitsein | mediumint(9) | YES | | NULL | |
| hitsaus | mediumint(9) | YES | | NULL | |
| email | varchar(40) | YES | | NULL | |
| freischaltung | tinyint(4) | YES | | NULL | |
| art | mediumint(9) | YES | | NULL | |
| ratio | tinyint(4) | YES | | NULL | |
| bemerkung | varchar(200) | YES | | NULL | |
| url | varchar(80) | YES | | NULL | |
| bonus | mediumint(9) | YES | | NULL | |
| rubrik | varchar(7) | YES | | NULL | |
| top10view | int(11) | YES | | NULL | |
| top10hits | mediumint(9) | YES | | NULL | |
| clickbonus | mediumint(9) | | | 0 | |
| t0 | tinyint(4) | | | 0 | |
| t1 | tinyint(3) unsigned | | | 0 | |
| t2 | tinyint(3) unsigned | | | 0 | |
| t3 | tinyint(3) unsigned | | | 0 | |
| t4 | tinyint(4) | | | 0 | |
| t5 | tinyint(4) | | | 0 | |
| t6 | tinyint(4) | | | 0 | |
| t7 | tinyint(4) | | | 0 | |
| t8 | tinyint(4) | | | 0 | |
| t9 | tinyint(4) | | | 0 | |
| t10 | tinyint(4) | | | 0 | |
| t11 | tinyint(4) | | | 0 | |
| banner2 | varchar(100) | YES | | NULL | |
| banner3 | varchar(100) | YES | | NULL | |
| oneclick | tinyint(4) | | | 0 | |
| datum | mediumint(9) | | | 0 | |
| status | char(2) | | | | |
| v01 | mediumint(9) | | | 0 | |
| h01 | smallint(6) | | | 0 | |
| v02 | mediumint(9) | | | 0 | |
| h02 | smallint(6) | | | 0 | |
| v03 | mediumint(9) | | | 0 | |
| h03 | smallint(6) | | | 0 | |
| v04 | mediumint(9) | | | 0 | |
| h04 | smallint(6) | | | 0 | |
| v05 | mediumint(9) | | | 0 | |
| h05 | smallint(6) | | | 0 | |
| v06 | mediumint(9) | | | 0 | |
| h06 | smallint(6) | | | 0 | |
| v07 | mediumint(9) | | | 0 | |
| h07 | smallint(6) | | | 0 | |
| v08 | mediumint(9) | | | 0 | |
| h08 | smallint(6) | | | 0 | |
| v09 | mediumint(9) | | | 0 | |
| h09 | smallint(6) | | | 0 | |
| v10 | mediumint(9) | | | 0 | |
| h10 | smallint(6) | | | 0 | |
| v11 | mediumint(9) | | | 0 | |
| h11 | smallint(6) | | | 0 | |
| v12 | mediumint(9) | | | 0 | |
| h12 | smallint(6) | | | 0 | |
| v13 | mediumint(9) | | | 0 | |
| h13 | smallint(6) | | | 0 | |
| v14 | mediumint(9) | | | 0 | |
| h14 | smallint(6) | | | 0 | |
| v15 | mediumint(9) | | | 0 | |
| h15 | smallint(6) | | | 0 | |
| v16 | mediumint(9) | | | 0 | |
| h16 | smallint(6) | | | 0 | |
| v17 | mediumint(9) | | | 0 | |
| h17 | smallint(6) | | | 0 | |
| v18 | mediumint(9) | | | 0 | |
| h18 | smallint(6) | | | 0 | |
| v19 | mediumint(9) | | | 0 | |
| h19 | smallint(6) | | | 0 | |
| v20 | mediumint(9) | | | 0 | |
| h20 | smallint(6) | | | 0 | |
| v21 | mediumint(9) | | | 0 | |
| h21 | smallint(6) | | | 0 | |
| v22 | mediumint(9) | | | 0 | |
| h22 | smallint(6) | | | 0 | |
| v23 | mediumint(9) | | | 0 | |
| h23 | smallint(6) | | | 0 | |
| v24 | mediumint(9) | | | 0 | |
| h24 | smallint(6) | | | 0 | |
| v25 | mediumint(9) | | | 0 | |
| h25 | smallint(6) | | | 0 | |
| v26 | mediumint(9) | | | 0 | |
| h26 | smallint(6) | | | 0 | |
| v27 | mediumint(9) | | | 0 | |
| h27 | smallint(6) | | | 0 | |
| v28 | mediumint(9) | | | 0 | |
| h28 | smallint(6) | | | 0 | |
| v29 | mediumint(9) | | | 0 | |
| h29 | smallint(6) | | | 0 | |
| v30 | mediumint(9) | | | 0 | |
| h30 | smallint(6) | | | 0 | |
| v31 | mediumint(9) | | | 0 | |
| h31 | smallint(6) | | | 0 | |
| notiz | varchar(250) | YES | | NULL | |
+---------------+---------------------+------+-----+---------+-------+
102 rows in set (0.01 sec)

...
LOL, Beitrag zu lang... unten gehts weiter

[homer_j]

mysql> describe tabelle2;
+-------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id | smallint(6) | YES | | NULL | |
| login | char(15) | YES | | NULL | |
| ip | char(15) | YES | | NULL | |
| click | tinyint(4) | YES | | NULL | |
+-------+-------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

mysql> describe tabelle3;
+------------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------------------+------+-----+---------+----------------+
| id | int(11) | | PRI | NULL | auto_increment |
| breite | smallint(6) | YES | | NULL | |
| hoehe | smallint(6) | YES | | NULL | |
| status | tinyint(4) | YES | | NULL | |
| url | char(80) | YES | | NULL | |
| banner | char(100) | YES | | NULL | |
| view | int(11) | YES | | NULL | |
| hit | mediumint(9) | YES | | NULL | |
| bannertext | char(140) | YES | | NULL | |
| namecode | char(30) | YES | | NULL | |
| bbreite | tinyint(3) unsigned | | | 0 | |
| ratio | tinyint(4) | | | 0 | |
| sbonus | mediumint(9) | | | 0 | |
| wbonus | mediumint(9) | | | 0 | |
| cbonus | smallint(6) | | | 0 | |
| zurl | char(100) | YES | | NULL | |
| at | tinyint(4) | | | 0 | |
| wbonus2 | mediumint(9) | | | 0 | |
| wbonus3 | mediumint(9) | | | 0 | |
| wbonus4 | mediumint(9) | | | 0 | |
+------------+---------------------+------+-----+---------+----------------+
20 rows in set (0.00 sec)

mysql> describe tabelle4;
+--------+----------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+----------+------+-----+---------+-------+
| anzahl | char(7) | YES | | NULL | |
| preis | char(6) | YES | | NULL | |
| thema | char(20) | YES | | NULL | |
| preis2 | char(6) | YES | | NULL | |
+--------+----------+------+-----+---------+-------+
4 rows in set (0.00 sec)

mysql> describe tabelle5;
+-------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| name | varchar(60) | YES | | NULL | |
| art | tinyint(4) | YES | | NULL | |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

mysql> describe tabelle6;
+----------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+-------+
| id | tinyint(4) | YES | | NULL | |
| mailtext | text | YES | | NULL | |
| bezug | varchar(60) | YES | | NULL | |
+----------+-------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

Inwieweit die Abfragen umständlich programmiert sind, wage ich jetzt mal nicht zu beurteilen. Aber so ganz einfach ist das Script auf jeden Fall nicht... gibt u.a. diverse Statistiken, IP-Log. Wenn Du willst, kann ich es dir ja mal schicken.

Wenn die mysql-DB dicht ist, dann ist nicht nur die DB langsam, sondern der ganze Server. Oder was meinst Du mit "Sind die dann soweit performant, oder auch grindig?"??

Also in den mir bekannten Logfiles konnte ich nix finden...
Nur ab und zu bekomme ich Mails an /var/mail/root. Die sehen dann ca. so aus:

From root@p15097545.pureserver.info Sat Aug 17 14:32:57 2002
Return-Path: <root@p15097545.pureserver.info>
Received: (from root@localhost)
by p15097545.pureserver.info (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id g7HCIZV20737
for root; Sat, 17 Aug 2002 14:18:35 +0200
Date: Sat, 17 Aug 2002 14:18:35 +0200
Message-Id: <200208171218.g7HCIZV20737@p15097545.pureserver.info>
From: root@p15097545.pureserver.info (Cron Daemon)
To: root@p15097545.pureserver.info
Subject: Cron <root@p15097545> /root/confixx/confixx_counterscript.pl
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>

DBI->connect(confixx:localhost) failed: Too many connections at confixx_counterscript.pl line 36
#2005: Konnte Datenbank nicht öffnen: Too many connections at confixx_counterscript.pl line 36.

Stellt sich die Frage, ob dieses confixx_counterscript.pl die DB zu sehr belastet, oder ob die DB wegen etwas anderem belastet ist und confixx_counterscript.pl deswegen nicht zugreifen kann.
Aber ich kann mir eigentlich nicht vorstellen, dass das vorinstallierte Confixx solche Fehler hat.

Damit wären wir auch schon bei den Crons: ich konnt nur diesen hier finden, der oben bereits genanntes Script startet:

-*/10 * * * * root /root/confixx/confixx_counterscript.pl

Vielleicht sollte ich den doch mal entfernen, oder? Täusche ich mich, oder wird das teil alle 6 Sekunden ausgeführt??? Das wär schon extrem oft.
Das ist der einzige Cronjob, den ich finden konnte. Ich hab' zwar selbst auch noch einen festgelegt, aber der läuft nur ein mal in der Woche. An dem kanns aber nicht liegen, weil der Server vorher scho nicht ging.

Recht viele weitere Belastungsquellen gibt es auf dem Server eigentlich nicht. Ich habe ihn erst seit ca. 40 Tagen und bis jetzt sind nur zwei Scripte darauf installiert. Besagtes php / mysql -script (banner-exchange), dass für die db-belastung verantwortlich ist und noch ein anderes banner-exchange-script (cgi). über diese laufen nur ein paar tausend views / tag und beim top-befehlt taucht es eigentlich gar nicht mehr in der liste auf, d.h. ich glaub nicht, dass die belastung von dort kommt.

mal ne andere frage: wie lange dauert eigentlich ein mysql-db-zugriff? (lesen + schreiben) bzw. wieviele zugriffe / sekunde sind machbar? weil wenn ich richtig rechne, dann können es bei mir in spitzenzeiten durchschnittlich schon mal 2,5 - 3 zugriffe / sekunde sein.

so, ich hoffe, ich hab' jetzt nix vergessen....

[hand]

Der Hinweis [i]#2005: Konnte Datenbank nicht öffnen: Too many connections at confixx_counterscript.pl line 36[I] ist schon mal nicht schlecht. Vielleicht sollte man mal die max_connections etwas raufdrehen.

set-variable = max_connections=300

Aber wie gesagt, wenn man das tut, muß man immer das System beobachten, manchmal bewirkt man ganz das Gegenteil.
Durch das raufschrauben der Connections wird klarerweise mehr Memory beansprucht.

Du hast recht
-*/10 * * * * root /root/confixx/confixx_counterscript.pl
ruft alle 6 Sekunden das Skript auf. (Übrigens irgendjemand muß den cron ja gebaut haben, der muß ja wissen warum - oder?)

Ist ja ansich kein Problem, 6 Sekunden sind ja Lichtjahre.
Ob man es abdrehen kann, oder das Interval erhöhen kann/soll kann ich Dir so nicht sagen, da ich nicht weiß was es tut und wie wichtig es wofür ist. Inwieferne das Skript das System belastet, wenn überhaupt, ist auch noch unklar.

Ruf das Skript einmal manuell auf, dauert's lange? braucht es viel Ressourcen (CPU, RAM)? Sonst kannst ja mal auf -*/4 stellen, diese CGI-Applikation wird ohnehin relativ "selten" verwendet, oder?

Schau mal in den Source von confixx_counterscript.pl vielleicht steht da kommentiert was es für eine Aufgabe hat und warum es permament exekutiert werden muß.

Bei den Tabellen haben nur Tabelle1 (login) und Tabelle3 (id) einen Key definiert. Das ist keine Wertung, wird wohl in Ordnung sein so.

So - jetzt CGI. CGI ist ein Performancefresser, wenn sich allerdings kaum was über diese Schnittstelle abspielt dann kanns da wohl nicht daran liegen.

Fakt ist, die CPU (1200 MHz Celeron) ist mit der Zeit komplett überlastet 98%. Ein offener MySQL Connect belastet ja eigentlich nicht die CPU.

3890 mysql 3.3%
3891 mysql 3.2%
3893 mysql 3.1%
3707 mysql 0.9%
3867 mysql 0.9%
3705 mysql 0.8%
3794 mysql 0.8%
...

Die Summe der vielen wenigen CPU-Anteile macht es aus. 175 Prozesse x 0,5% sind ja schon an die 90%

Also was ist an einem Bannerexchange so CPU-Intensiv?

Von wo hast denn die Skripte? Wo liegen denn die Banner? Am selben Host? Könnt es sein, dass mysql_close($link); überflüssigerweise zu spät gemacht wird, zum Beispiel am Ende eines Skriptes und nicht bereits nach der letzten mySQL Interaktion, was sich bei großem Traffic dann eben auswirkt - is ja möglich, dass dazwischen noch Banner zusammengebastelt werden, was mit der DB nix mehr zu tun hat und DB-Connections blockiert, auch wenn es nur für wenige msec ist?

[hand]

http://dblab.cs.ucr.edu/mysql/Performance.htm
http://www1.jpartner.com/docs/mysql/...rformance.html

[goth]

Ich würde mal gar nicht soviel an den Datenbank Parametern rumbasteln ... sondern mir erstmal anschauen was die offenen Prozesse soweit vorhanden überhaupt machen ...

Parameter Tuning bei 'em Puretec Exclusive Server mit 256 MB Ram ist witzlos ... da sollten die Standard Einstellungen durchaus ausreichen ... wenn du da dem Server oder den Threads zuviel Ram zuordnest kommst Du ganz schnell ins Swapping ... war bei Dir aber noch nicht der Fall zu sein scheint ...

Die Thread-Laufzeiten liegen bei Dir bei Maximal 2 Sekunden ... was je nach Script aber nicht unbedingt viel sein muß ... ich habe in Deiner Prozessliste jetzt keine auffällig lange Laufzeit erkennen können ... also schau dir mit SHOW PROCESSLIST mal an was die Prozesse gerade machen und überleg' Dir dann ob Du bei den Queries was optimieren kannst.

PS.: mysql_pconnect() kann für jeden MySQL-Server tötlich sein ... !

[admin]

@goth

wie hoch würdest du memory_limit auf einem Serve rmit 512 MB Ram setzten?

[goth]

@Berni: Hmmnnn ... das ist schwer zu sagen ... ich habe die Erfahrung gemacht das der wichtigste Parameter 'key_buffer_size' ist (Das Entwicklerteam empfielt bei >= 256MB einen Wert von 64MB) ... bei der Suche nach dem Richtigen Wert ist das Verhältniss zwischen 'Key_read_requests' und 'Key_reads' wichtig, dieses sollte so weit wie möglich unter 1% liegen. Über 1% ist böse ... ich tariere meine Server meistens so aus das diese unter 0,5% liegen (3GB Gesamtspeicher ... 512MB Keybuffer ... 0,4%).

Wenn viele ORDER BY's oder GROUP BY's laufen kannst Du den Wert für 'sort_buffer' höher setzen ... ich habe Ihn auf 64MB stehen ... der subjektive Effekt ist allerdings nicht sehr groß).

Die meisten anderen Parameter haben meiner Meinung nach eher eine philosophische Bedeutung.

Das Hauptproblem bei MySQL liegt allerdings im Table-Locking der MyISAM Tabellen ... (ich experimentiere gerade mit INNO-Tabellen ... habe dort allerdings bisher noch keine richtig optimalen Werte) ... und da hilft meines erachtens primär Prozessor-Leistung ... damit sich die Locks so schnell wie möglich auflösen ... .

[homer_j]

Original geschrieben von hand
Der Hinweis [i]#2005: Konnte Datenbank nicht öffnen: Too many connections at confixx_counterscript.pl line 36[I] ist schon mal nicht schlecht. Vielleicht sollte man mal die max_connections etwas raufdrehen.

set-variable = max_connections=300

Aber wie gesagt, wenn man das tut, muß man immer das System beobachten, manchmal bewirkt man ganz das Gegenteil.
Durch das raufschrauben der Connections wird klarerweise mehr Memory beansprucht.

Du hast recht
-*/10 * * * * root /root/confixx/confixx_counterscript.pl
ruft alle 6 Sekunden das Skript auf. (Übrigens irgendjemand muß den cron ja gebaut haben, der muß ja wissen warum - oder?)

Ist ja ansich kein Problem, 6 Sekunden sind ja Lichtjahre.
Ob man es abdrehen kann, oder das Interval erhöhen kann/soll kann ich Dir so nicht sagen, da ich nicht weiß was es tut und wie wichtig es wofür ist. Inwieferne das Skript das System belastet, wenn überhaupt, ist auch noch unklar.

Ruf das Skript einmal manuell auf, dauert's lange? braucht es viel Ressourcen (CPU, RAM)? Sonst kannst ja mal auf -*/4 stellen, diese CGI-Applikation wird ohnehin relativ "selten" verwendet, oder?

Schau mal in den Source von confixx_counterscript.pl vielleicht steht da kommentiert was es für eine Aufgabe hat und warum es permament exekutiert werden muß.

connections hab ich hochgesetzt. mal schaun, wie es wirkt...

über das confixx_counterscript.pl habe ich mich mal erkundigt. das hat die Aufgabe, wenn man einstellungen in Confixx macht, neue Accounts anlegt ect., daß diese dann auch wirksam werden. und da extrem viele server confixx verwenden, kann ich mir nicht vorstellen, dass dieses script schuld ist.
der aufruf dauert auch nicht sehr lange... aber ich hab's jetzt trotzdm mal so eingestellt, dass es nur noch alle 15 sekunden läuft.

Original geschrieben von hand
Bei den Tabellen haben nur Tabelle1 (login) und Tabelle3 (id) einen Key definiert. Das ist keine Wertung, wird wohl in Ordnung sein so.

So - jetzt CGI. CGI ist ein Performancefresser, wenn sich allerdings kaum was über diese Schnittstelle abspielt dann kanns da wohl nicht daran liegen.

Fakt ist, die CPU (1200 MHz Celeron) ist mit der Zeit komplett überlastet 98%. Ein offener MySQL Connect belastet ja eigentlich nicht die CPU.

3890 mysql 3.3%
3891 mysql 3.2%
3893 mysql 3.1%
3707 mysql 0.9%
3867 mysql 0.9%
3705 mysql 0.8%
3794 mysql 0.8%
...

Die Summe der vielen wenigen CPU-Anteile macht es aus. 175 Prozesse x 0,5% sind ja schon an die 90%

Also was ist an einem Bannerexchange so CPU-Intensiv?

Von wo hast denn die Skripte? Wo liegen denn die Banner? Am selben Host? Könnt es sein, dass mysql_close($link); überflüssigerweise zu spät gemacht wird, zum Beispiel am Ende eines Skriptes und nicht bereits nach der letzten mySQL Interaktion, was sich bei großem Traffic dann eben auswirkt - is ja möglich, dass dazwischen noch Banner zusammengebastelt werden, was mit der DB nix mehr zu tun hat und DB-Connections blockiert, auch wenn es nur für wenige msec ist?

ich werd die cgi-script mal zum test für einen tag löschen. vielleicht bringt es ja doch was...

Das Script ist von http://www.webmaster-experte.de.
Die Banner liegen alle auf anderen Servern (ausser meine eigenen Banner), weswegen der Traffic meistens auch unter 100 MB / Tag ist.
Das Adview-Script (welches ja zu 99% aufgerufen wird), besteht eigentlich nur das DB-Zugriffen, wenn ich das richtig sehe... wenn du willst, kann ich es dir ja mal per Mail schicken.

[hand]

Im Support-Forum von webmaster-experte.de hab ich einen Thread zum Thema gefunden:
MySQL Server Konfiguration optimieren beim Multi 2 Script
Wir empfehlen beim Einsatz des Multi 2 Exchange Server Scriptes einen virtuellen oder dedizierten Server. Manche Provider bieten dedizierte Server bereits ab 49,- Euro an!

Folgende Einstellungen sollten im MySQL Server verändert werden, falls Sie den MySQL Server so einstellen wollen, das die Free Exchange mit noch optimalerer Performance laufen.

Loggen Sie sich per Telnet auf dem Linux Server ein. Bearbeiten Sie die Datei:

/etc/my.cnf

Folgende Variablen sollten bei einem mit 256 MB ausgestatteteten Servers mindestens folgende Werte enthalten.

#The MySQL server
[mysqld]
set-variable = key_buffer=16M
set-variable = table_cache=800

Folgende Einträge sollten ergänzt werden:

set-variable = max_connections=400
set-variable = max_user_connections=200

http://support.webmaster-experte.de/...hp?threadid=78

[goth]

Original geschrieben von hand
Im Support-Forum von webmaster-experte.de hab ich einen Thread zum Thema gefunden:
...

#The MySQL server
[mysqld]
set-variable = key_buffer=16M
set-variable = table_cache=800

Folgende Einträge sollten ergänzt werden:

set-variable = max_connections=400
set-variable = max_user_connections=200
[/i]
http://support.webmaster-experte.de/...hp?threadid=78

Mit 16M bleiben die allerdings weit hinter den Empfehlungen des Entwicklerteams zurück ... allerdings sollte man das intensiv ausprobieren und testen.
table_cache von 800 bringt nicht viel ... und hat zusätzlich die erhöhte Gefahr von Datenverlußten ...
max_connections und max_user_connections haben lediglich was mit der Seitenabruf-Frequenz zu tun ... auch da ist letztlich testen angesagt.