zich Mysql sleeping prozesse

MySQL, PostgreSQL, SQLite
rouven
Posts: 58
Joined: 2002-10-10 15:27

zich Mysql sleeping prozesse

Post by rouven » 2003-10-29 21:14

Habe seit ein paar stunden folgendes problem, das sau viele Mysql sleeping prozesse offen sind. Was kann man dagegen machen??
top:

279 processes: 271 sleeping, 8 running, 0 zombie, 0 stopped
CPU0 states: 72.0% user, 17.5% system, 0.0% nice, 9.5% idle
CPU1 states: 63.3% user, 15.4% system, 0.0% nice, 20.2% idle
Mem: 1033780K av, 638032K used, 395748K free, 0K shrd, 19496K buff
Swap: 787176K av, 0K used, 787176K free 296456K cached

kommt fast alles von mysql /httpd

rouven
Posts: 58
Joined: 2002-10-10 15:27

Re: zich Mysql sleeping prozesse

Post by rouven » 2003-10-29 21:19

es kommt natürlich immer die meldung "to many coneccts"..
cpu und ram sind komischerweise ok

User avatar
Joe User
Project Manager
Project Manager
Posts: 11137
Joined: 2003-02-27 01:00
Location: Hamburg

Re: zich Mysql sleeping prozesse

Post by Joe User » 2003-10-29 21:28

unsauber geschriebenes Script und/oder persistant connections in der php.ini erlaubt...

rouven
Posts: 58
Joined: 2002-10-10 15:27

Re: zich Mysql sleeping prozesse

Post by rouven » 2003-10-29 21:31

pconnect verwende ich definitiv nicht!!!
und in der php.ini ist es auch auf off!.. ich verzweifle

rouven
Posts: 58
Joined: 2002-10-10 15:27

Re: zich Mysql sleeping prozesse

Post by rouven » 2003-10-30 08:45

hier noch meine my.cnf:

Code: Select all


# The following options will be passed to all MySQL clients
[client]
#password       = your_password
port            = 3306
socket          = /var/lib/mysql/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-locking
set-variable    = key_buffer=16M
set-variable    = max_allowed_packet=1M
set-variable    = table_cache=64
set-variable    = sort_buffer=512K
set-variable    = net_buffer_length=8K
set-variable    = myisam_sort_buffer_size=8M

skip-innodb
skip-locking
#log-bin
server-id       = 1


# Point the following paths to different dedicated disks
#tmpdir         = /tmp/




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

[mysqldump]
quick
set-variable    = max_allowed_packet=16M

[mysql]
no-auto-rehash

[isamchk]
set-variable    = key_buffer=20M
set-variable    = sort_buffer=20M
set-variable    = read_buffer=2M
set-variable    = write_buffer=2M

[myisamchk]
set-variable    = key_buffer=20M
set-variable    = sort_buffer=20M
set-variable    = read_buffer=2M
set-variable    = write_buffer=2M

[mysqlhotcopy]
interactive-timeout

odysseus
Posts: 115
Joined: 2003-02-07 10:21

Re: zich Mysql sleeping prozesse

Post by odysseus » 2003-10-31 19:59

Vermutlich hast du auf einer oder mehreren Tabellen Deadlocks.
Besonders anfällig sind selbst gebastele Volltext-Indizes von Bulletin Boards, da hier immens viele Updates, und Inserts reinkommen.

Eine weiteres Killer-Kriterium sind - wieder bei Foren - die Tabelle, in der die Thread-Infos gespeichert werden. Da kommt es jede Sekunde und je nach Useranzahl zu zig Updates, damit die Anzahl der Thread-Views aktualisiert wird. Diese Funktion sollte man nach Möglichkeit komplett rauswerfen - wird doch eh nur von statistikgeilen Spinnern "gebraucht".


Ich hatte letzteres Problem auch mal - nach der Abschaltung hatte MySQL wieder "Ruhe".

Du solltest auch erwägen, auf MySQL 4 umzusteigen, um Vorteile aus dem Query Cache ziehen zu können.

alexander newald
Posts: 1117
Joined: 2002-09-27 00:54
Location: Hannover

Re: zich Mysql sleeping prozesse

Post by alexander newald » 2003-10-31 21:53

Wobei Querry Cache gerade bei Boards mit Statistikfunktion nichts bringt bzw eher das Gegenteil bewirkt

pennybridge
Posts: 64
Joined: 2002-10-24 21:37

Re: zich Mysql sleeping prozesse

Post by pennybridge » 2003-10-31 22:34

Compiler Advisory: Several users have reported random crashes and table corruptions when using MySQL binaries compiled with gcc 2.96 on the x86 Linux platform. We suggest that you use gcc 2.95 or gcc 2.91 to compile your own binaries. It should also be safe to use gcc 3.2.
sollte man mal überlegen, weil die von suse auch sehr mies compiliert sind
Alexander Newald wrote:Wobei Querry Cache gerade bei Boards mit Statistikfunktion nichts bringt bzw eher das Gegenteil bewirkt
SQL_NO_CACHE tells MySQL not to store the query result in the query cache. See section 6.9 MySQL Query Cache. In case of query with UNIONs and/or subqueries this option will take effect to be used in any SELECT of the query.

majortermi
Userprojekt
Userprojekt
Posts: 916
Joined: 2002-06-17 16:09

Re: zich Mysql sleeping prozesse

Post by majortermi » 2003-10-31 22:39

Alexander Newald wrote:Wobei Querry Cache gerade bei Boards mit Statistikfunktion nichts bringt bzw eher das Gegenteil bewirkt
Man kann den Query-Cache ja auch im "Cache nur was als entsprechend markiert ist" Modus benutzen und die SQL-Queries des Boards, die sich gut cachen lassen, entsprechend anpassen.
Erst nachlesen, dann nachdenken, dann nachfragen... :)
Warum man sich an diese Reihenfolge halten sollte...

captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten

Re: zich Mysql sleeping prozesse

Post by captaincrunch » 2003-10-31 22:40

sollte man mal überlegen, weil die von suse auch sehr mies compiliert sind
Die einzigste mir bekannte Distri, die jemals auf den gcc 2.96 gesetzt hat war RedHat. Ich wüsste daher nicht, was SuSE damit zu tun haben sollte ?!?
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

odysseus
Posts: 115
Joined: 2003-02-07 10:21

Re: zich Mysql sleeping prozesse

Post by odysseus » 2003-10-31 22:51

Alexander Newald wrote:Wobei Querry Cache gerade bei Boards mit Statistikfunktion nichts bringt bzw eher das Gegenteil bewirkt
Da muss ich widersprechen.
Die Anzahl der cachebaren Queries ist um so viel größer als die Anzahl an immer neu zu generierenden Statistikfunktionen, dass es sich sehr wohl lohnt, den Query Cache einzusetzen.
Rein theoretisch magst du recht haben, aber wenn man die positiven Aspekte berücksichtigt, sieht es in der PRaxis einfach anders aus.

Ein paar Zahlen als Beispiel:

Code: Select all

Dieser MySQL-Server läuft bereits 6 Tage, 13 Stunden, 6 Minuten und 55 Sekunden. Er wurde am 25. Oktober 2003 um 10:42 gestartet. 

insert   59.315   0,44 %
select   3.745.319   27,79 %
update   1.390.032   10,31 %

Qcache queries in cache   2865  
Qcache inserts   3742769  
Qcache hits   6695704  
Qcache lowmem prunes   84573  
Qcache not cached   2495

Für mich sind diese Zahlen recht eindeutig PRO query vache.

Oder habe ich deine Anmekrung falsch interpretiert? :(