[mysql] gebruikt maar 1 lang process

[Verwijderd]

Als ik kijk naar de processlijst, zie ik dat mysql maar 1 instance/process gebruikt dat continu blijft lopen in tegenstelling tot bij.v apache die gewoon meerdere heeft.

op m'n oude server gebruikte mysql ook gewoon meerdere, maar waarom nu niet?

code:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7215 mysql     11  -5  195m  94m 4700 S 99.9  4.7  10:03.40 mysqld
 9445 www-data  15   0 76104 6144 3004 S  2.0  0.3   0:00.09 apache
 1502 www-data  16   0 79692 9500 2892 S  1.7  0.5   0:00.30 apache
20230 www-data  15   0 79272 9392 3084 S  1.7  0.5   0:00.48 apache
25867 www-data  16   0 79444 9432 2952 R  1.3  0.5   0:00.54 apache
 5884 www-data  15   0 80820 9.9m 3312 S  1.3  0.5   0:00.45 apache
10181 www-data  15   0 79456 9128 2688 S  1.3  0.4   0:00.04 apache
  993 www-data  16   0 80988 9.8m 3200 S  1.0  0.5   0:00.85 apache
31528 www-data  16   0 79552 9776 3188 S  1.0  0.5   0:00.52 apache
 6674 www-data  15   0 83520  13m 2948 D  1.0  0.7   0:00.82 apache
18464 www-data  16   0 79584 9512 2892 S  1.0  0.5   0:01.77 apache
28000 www-data  15   0 81020  10m 3284 S  1.0  0.5   0:00.54 apache
  505 www-data  15   0 79392 9248 2864 S  1.0  0.4   0:00.11 apache
30758 www-data  16   0 79544 9432 2856 S  1.0  0.5   0:00.55 apache
22350 www-data  15   0 79576 9068 2624 S  1.0  0.4   0:00.03 apache

Ik draai mysql 4.1.11

dit is mijn my.cnf

code:

socket          = /var/run/mysqld/mysqld.sock
nice            = -5
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid

port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
language        = /usr/share/mysql/english
skip-external-locking

old_passwords   = 1

key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 128K
max_connection          = 256
table_cache             = 512

query_cache_limit       = 1048576
query_cache_size        = 16777216
query_cache_type        = 1

log-bin                 = /var/log/mysql/mysql-bin.log

max_binlog_size         = 104857600

skip-bdb

[mysqdump]
quick
quote-names
max_allowed_packet      = 16M

[isamchk]
key_buffer              = 16M

ik heb al vanalles geprobeerd, en gezocht... maar kom er niet uit.

help!!

[Shadowman]

Apache forked zijn processen, mysql niet. Ik vermoed dat mysql multi-threading gebruikt en dat zie je niet terug in de processlist (was afaik eerder (met de oudere kernels) nog wel zo dat je dat terugzag in de proceslist, maar niet meer).

Met 'ps -eLf' zie je wel de threads overigens

[BtM909]

Waarom ben je trouwens niet verder gegaan in je ander topic

[rml][ mysql] gebruikt maar 1 lang process[/rml]

[_Thanatos_]

Wat apache doet, lijkt me juist veel inefficienter, omdat 20 processen veel meer overhead heeft dan 1 proces met 20 threads. En bovendien is het communiceren tussen die processen intern ook erg omslachtig (en dus trager).

MySQL is dus juist goed bezig

[Sallin]

Zitten er verschil in de performance van de twee servers wat hier aan te wijten is? Krijg je andere problemen/verschillen? Draai je verschillende databases op de servers? Of is alles identiek?

Als alles functioneert dan is er toch verder niet echt een probleem

[ Voor 1% gewijzigd door Sallin op 27-04-2006 10:58 . Reden: typo ]

[igmar]

_Thanatos_ schreef op donderdag 27 april 2006 @ 10:52:
Wat apache doet, lijkt me juist veel inefficienter, omdat 20 processen veel meer overhead heeft dan 1 proces met 20 threads.

Want ? Ik ben daar absoluut niet van overtuigd.

En bovendien is het communiceren tussen die processen intern ook erg omslachtig (en dus trager).

Dat valt ook wel mee. Apache processen communiceren eigenlijk niet onderling, op het scoreboard bestand na.

[_Thanatos_]

Want ? Ik ben daar absoluut niet van overtuigd.

Een process heeft meer nodig om op te starten en af te sluiten. Een proces heeft veel meer I/O mogelijkheden die bijgehouden worden, heeft aparte rechten, heeft alles eigenlijk apart. Een thread is veel slanker. Als je progrmmeur bent, dan raak je daar wel van overtuigt. Daar valt eigenlijk weinig aan te verklaren, het is gewoon common sense, in mijn optiek.

Toegegeven, in linux hebben processen minder overhead dan processen in windows, maar nog steeds veel meer dan threads in linux. Maar dat is de issue ook niet.

Dat valt ook wel mee. Apache processen communiceren eigenlijk niet onderling, op het scoreboard bestand na.

Misschien niet onderling (dat zei ik ook niet), maar wel met het apache-proces. Als dat niet hoeft, moet ieder proces alle variabelen en config-meuk van apache kennen, en dat lijkt me wel erg veel overhead. Communicatie moet er dus echt wel plaatsvinden. Al was het maar met de rendering engine, of voor applicatie-variabelen (of hoe die ook heten in apache).

[ Voor 9% gewijzigd door _Thanatos_ op 28-04-2006 12:53 ]

[igmar]

_Thanatos_ schreef op vrijdag 28 april 2006 @ 12:53:
Een process heeft meer nodig om op te starten en af te sluiten.

Een proces is bij elk modern OS niet veel meer werk als een thread.

Een proces heeft veel meer I/O mogelijkheden die bijgehouden worden, heeft aparte rechten, heeft alles eigenlijk apart.

Da's in dit voorbeeld geen issue. Threads moet je synchroniseren, dat dat is vrij kostbaar.

Een thread is veel slanker. Als je progrmmeur bent, dan raak je daar wel van overtuigt. Daar valt eigenlijk weinig aan te verklaren, het is gewoon common sense, in mijn optiek.

Sja. Ik ben programmeur, en ik ben daar dus niet van overtuigd. Het enige grote voordeel is de shared memory space. Op oa linux is een thread niet veel slanker als een proces.

Toegegeven, in linux hebben processen minder overhead dan processen in windows, maar nog steeds veel meer dan threads in linux. Maar dat is de issue ook niet.

Daar heb ik dus een andere mening over.

Misschien niet onderling (dat zei ik ook niet), maar wel met het apache-proces. Als dat niet hoeft, moet ieder proces alle variabelen en config-meuk van apache kennen, en dat lijkt me wel erg veel overhead. Communicatie moet er dus echt wel plaatsvinden. Al was het maar met de rendering engine, of voor applicatie-variabelen (of hoe die ook heten in apache).

Configs worden eerst geladen, daarna pas de workerchilds. Alle processen kennen dus inderdaad de volledige config, en aangezien zowat elk OS COW gebruikt is dat dus 1 page voor alle processen.

De enige onderlinge communicatie is het scoreboard en de accept mutex.