php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > SQL / Datenbanken
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


SQL / Datenbanken Probleme mit SQL? Hier könnt ihr eure Fragen zu SQL (MySQL, PostgreSQL, MS-SQL und andere ANSI-SQL Server) los werden.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #16 (permalink)  
Alt 23-08-2002, 19:19
Benutzerbild von Berni Berni
  OWNER
Links : Onlinestatus : Berni ist offline
Registriert seit: Jan 2001
Ort: Frankfurt / Egelsbach
Beiträge: 6.311
Blog-Einträge: 6
Berni befindet sich auf einem aufstrebenden Ast
Standard

root oder managed
__________________

php-Entwicklung | ebiz-consult.de
PHP-Webhosting für PHP Entwickler | ebiz-webhosting.de
die PHP Marktplatz-Software | ebiz-trader.de
Mit Zitat antworten
freelancermap.de - IT Projektvermittlung für Selbständige und Freiberufler
  #17 (permalink)  
Alt 23-08-2002, 19:20
Benutzerbild von Berni Berni
  OWNER
Links : Onlinestatus : Berni ist offline
Registriert seit: Jan 2001
Ort: Frankfurt / Egelsbach
Beiträge: 6.311
Blog-Einträge: 6
Berni befindet sich auf einem aufstrebenden Ast
Standard

49 ,99 oder 149 €
__________________

php-Entwicklung | ebiz-consult.de
PHP-Webhosting für PHP Entwickler | ebiz-webhosting.de
die PHP Marktplatz-Software | ebiz-trader.de
Mit Zitat antworten
  #18 (permalink)  
Alt 23-08-2002, 19:49
homer_j
 Newbie
Links : Onlinestatus : homer_j ist offline
Registriert seit: Aug 2002
Beiträge: 17
homer_j ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Rootserver L, d.h. 49 € (hab' ich oben irgendwo schon geschrieben, aber egal )
Mit Zitat antworten
  #19 (permalink)  
Alt 23-08-2002, 19:52
homer_j
 Newbie
Links : Onlinestatus : homer_j ist offline
Registriert seit: Aug 2002
Beiträge: 17
homer_j ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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)
Mit Zitat antworten
  #20 (permalink)  
Alt 23-08-2002, 22:00
hand
 PHP Expert
Links : Onlinestatus : hand ist offline
Registriert seit: Dec 2001
Ort: Kärnten
Beiträge: 3.138
hand ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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:
Code:
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.
Mit Zitat antworten
  #21 (permalink)  
Alt 24-08-2002, 01:38
homer_j
 Newbie
Links : Onlinestatus : homer_j ist offline
Registriert seit: Aug 2002
Beiträge: 17
homer_j ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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
Mit Zitat antworten
  #22 (permalink)  
Alt 24-08-2002, 01:38
homer_j
 Newbie
Links : Onlinestatus : homer_j ist offline
Registriert seit: Aug 2002
Beiträge: 17
homer_j ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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....
Mit Zitat antworten
  #23 (permalink)  
Alt 24-08-2002, 11:29
hand
 PHP Expert
Links : Onlinestatus : hand ist offline
Registriert seit: Dec 2001
Ort: Kärnten
Beiträge: 3.138
hand ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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.
Code:
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?
Mit Zitat antworten
  #24 (permalink)  
Alt 24-08-2002, 11:40
hand
 PHP Expert
Links : Onlinestatus : hand ist offline
Registriert seit: Dec 2001
Ort: Kärnten
Beiträge: 3.138
hand ist zur Zeit noch ein unbeschriebenes Blatt
Standard

http://dblab.cs.ucr.edu/mysql/Performance.htm
http://www1.jpartner.com/docs/mysql/...rformance.html
Mit Zitat antworten
  #25 (permalink)  
Alt 24-08-2002, 12:40
goth
  Moderator
Links : Onlinestatus : goth ist offline
Registriert seit: Mar 2002
Ort: Erde
Beiträge: 7.277
goth ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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 ... !
__________________
carpe noctem

Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht!
Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung!
Mit Zitat antworten
  #26 (permalink)  
Alt 24-08-2002, 13:17
Benutzerbild von Berni Berni
  OWNER
Links : Onlinestatus : Berni ist offline
Registriert seit: Jan 2001
Ort: Frankfurt / Egelsbach
Beiträge: 6.311
Blog-Einträge: 6
Berni befindet sich auf einem aufstrebenden Ast
Standard

@goth

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

php-Entwicklung | ebiz-consult.de
PHP-Webhosting für PHP Entwickler | ebiz-webhosting.de
die PHP Marktplatz-Software | ebiz-trader.de
Mit Zitat antworten
  #27 (permalink)  
Alt 24-08-2002, 14:06
goth
  Moderator
Links : Onlinestatus : goth ist offline
Registriert seit: Mar 2002
Ort: Erde
Beiträge: 7.277
goth ist zur Zeit noch ein unbeschriebenes Blatt
Standard

@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 ... .
__________________
carpe noctem

Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht!
Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung!
Mit Zitat antworten
  #28 (permalink)  
Alt 24-08-2002, 15:06
homer_j
 Newbie
Links : Onlinestatus : homer_j ist offline
Registriert seit: Aug 2002
Beiträge: 17
homer_j ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
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.
Code:
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.

Zitat:
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.
Mit Zitat antworten
  #29 (permalink)  
Alt 25-08-2002, 12:46
hand
 PHP Expert
Links : Onlinestatus : hand ist offline
Registriert seit: Dec 2001
Ort: Kärnten
Beiträge: 3.138
hand ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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
Mit Zitat antworten
  #30 (permalink)  
Alt 25-08-2002, 13:00
goth
  Moderator
Links : Onlinestatus : goth ist offline
Registriert seit: Mar 2002
Ort: Erde
Beiträge: 7.277
goth ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
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.
__________________
carpe noctem

Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht!
Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung!
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

PHP Marktplatz-Software
PHP Marktplatz-SoftwareEs hat sich viel getan! Die neue Version 7.5.9 unserer PHP Marktplatz-Software ebiz-trader steht ab sofort zur Verfügung.

28.10.2019 | Berni

Die RIGID-FLEX-Technologie
Die RIGID-FLEX-TechnologieDie sogenannte "Flexible Elektronik" , oftmals auch als "Flexible Schaltungen" bezeichnet, ist eine zeitgemäße Technologie zum Montieren von elektronischen Schaltungen.

06.12.2018 | Berni


 

Aktuelle PHP Scripte

SMT

Server Monitoring & Management Tool Das SMT wurde von einem Administrator für Administratoren entwickelt, es vereinfacht den Alltag in der klassischen Administration und Verwaltung. Mit dem SMT kannst Du alle Deine Server & Dienste verwalten und überwach

04.09.2020 palle_1977 | Kategorie: PHP
numaeks Web-Farbmixer

Die RGB-Farben lassen sich hier auf unterschiedliche Weise mischen. Zur Einstellung werden auch die Dreh- und Schieberegler mit Canvas verwendet. Gespeichert werden die Farben in einem Cookie.

04.09.2020 numaek | Kategorie: JAVASCRIPT/ Tools
phplinX-Erotikportal 4 ansehen phplinX-Erotikportal 4

Erweiterbares Portal speziell für Erotik mit den Modulen Webkatalog, Bannermanagement und Kleinanzeigenmarkt. Sämtliche Module können über einen einzigen Adminbereich verwaltet werden.

18.06.2020 Cosinus14 | Kategorie: PHP/ Anzeigenmarkt
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 12:52 Uhr.