Cobalt serveert traag - Serversoftware en clouddiensten

dinsdag 9 april 2002 23:34

Acties:

Sliden is koel

Topicstarter

Beste mensen,

Sinds vandaag draait mijn website op mijn eigen server.

Wat gegevens:
* Cobalt RaQ4R
* 450mhz
* 512mb
* RAID 1

Wel grappig, mijn server hang RECHT tegenover de kast van Tweakers.net, hehe!!

Ofwel, de verbinding is DIK in orde...

En toch reageert de server traag.
Als je op een link klikt, dan "denkt" de browser(server??) eerst wat seconden na, en daarna wordt de data uitgepoept. Dat gaat dus WEL heel snel.

Weet iemand hoe dat komt?

De Cobalt is helemaal standaard, met alle updates tot nu toe...

Motor-Forum.nl

woensdag 10 april 2002 08:50

Acties:

Verwijderd

Heb je het al geprobeerd op verschillende werkstations? Het kan ook wel aan IE liggen. Is namelijk een heel erg dwars programma.

woensdag 10 april 2002 08:55

Acties:

Dutchman!

Op dinsdag 09 april 2002 23:34 schreef Duderuud het volgende:

Als je op een link klikt, dan "denkt" de browser(server??) eerst wat seconden na, en daarna wordt de data uitgepoept. Dat gaat dus WEL heel snel.

Klinkt als langzame DNS? (qua resloven) Gooi je domain/ip combo eens in je hosts file en kijk eens of dat -wel- zo snel gaat als je zou verwachten?

We spend our years as a tale that is told

woensdag 10 april 2002 08:58

Acties:

Bart B

En misschien dat je webserver voor logging ook een reverse DNS doet. Kan dat prestatieproblemen geven

woensdag 10 april 2002 09:47

Acties:

duderuud

Sliden is koel

Topicstarter

Langzame DNS zal het niet zijn, want die is nog niet eens omgezet.

Ik klopt dus het harde IP-adres in...

Kan het met caching te maken hebben??

Motor-Forum.nl

woensdag 10 april 2002 10:16

Acties:

mavink

Wat voor pagina's gaat het precies om? Is dit gewoon statische HTML? Of gaat het om een PHP script met wat moeilijke dingen er in?

Ik zou willen adviseren eerst eens een platte HTML file te testen, en dan direct naar het IP-adres van de server te gaan ipv een hostname. Dan heb je in ieder geval niet meer met DNS lookups op je eigen machine te maken.

woensdag 10 april 2002 15:47

Acties:

jelmervos

Simple user

Op woensdag 10 april 2002 10:16 schreef vink het volgende:
Wat voor pagina's gaat het precies om? Is dit gewoon statische HTML? Of gaat het om een PHP script met wat moeilijke dingen er in?

Ik zou willen adviseren eerst eens een platte HTML file te testen, en dan direct naar het IP-adres van de server te gaan ipv een hostname. Dan heb je in ieder geval niet meer met DNS lookups op je eigen machine te maken.

Het gaat bij Ruud's site om PHP pagina's weet ik.

Het is ActiveTopics (forum van Niels de Koning) wat er op zijn server draait.

"The shell stopped unexpectedly and Explorer.exe was restarted."

woensdag 10 april 2002 15:56

Acties:

duderuud

Sliden is koel

Topicstarter

Het blijkt dus dat de load heel hoog is.

Een aantal processen draait dubbel, soms wel 10-dubbel.

Een reboot heeft weinig zin, de load blijft toch rond de 3,00 hangen, en is dus veel te hoog.

Misschien mensen die hetzelfde probleem hadden? Dat een aantal processen "te vaak" draaien?

Motor-Forum.nl

woensdag 10 april 2002 15:58

Acties:

Zwelgje

Op woensdag 10 april 2002 15:56 schreef Duderuud het volgende:
Het blijkt dus dat de load heel hoog is.

Een aantal processen draait dubbel, soms wel 10-dubbel.

Een reboot heeft weinig zin, de load blijft toch rond de 3,00 hangen, en is dus veel te hoog.

Misschien mensen die hetzelfde probleem hadden? Dat een aantal processen "te vaak" draaien?

welke processen draaien dan te vaak?

A wise man's life is based around fuck you

woensdag 10 april 2002 16:04

Acties:

jelmervos

Simple user

Dit is een typisch software 'probleem' lijkt mij, dus misschien kan deze beter naar Non Windows OS forum? Denk dat daar ook wel aardig wat experts zitten.

* jelmervos weet weinig van niet Windows OS'ses.

"The shell stopped unexpectedly and Explorer.exe was restarted."

woensdag 10 april 2002 16:10

Acties:

Verwijderd

Op woensdag 10 april 2002 15:56 schreef Duderuud het volgende:
Het blijkt dus dat de load heel hoog is.

Een aantal processen draait dubbel, soms wel 10-dubbel.

Een reboot heeft weinig zin, de load blijft toch rond de 3,00 hangen, en is dus veel te hoog.

Misschien mensen die hetzelfde probleem hadden? Dat een aantal processen "te vaak" draaien?

Welke processen

Zoals oa het httpd process kan inderdaad wel een paar keer parallel draaien!
Zelf heb ik 'm op een minimum gezet van 4 servers en een max van 20 servers en een 'keep-alive' van ik geloof 10 of 15 seconde.
Dus op een druk moment kan ik in dat geval inderdaad 20 keer het httpd process zien.
Maar wat betreft andere processen..... Nee die zouden niet zo massaal aanwezig moeten zijn.
Welke processen verbruiken dan eigenlijk die load? (kijk eens met het commando 'top')

woensdag 10 april 2002 16:46

Acties:

mavink

Ik zou dan eens naar je scripts gaan kijken... Er zou een foutje in een van die PHP-scripts kunnen zitten waardoor die gewoon veel te veel processortijd gaan vreten.

woensdag 10 april 2002 19:30

Acties:

duderuud

Sliden is koel

Topicstarter

Vink, dat denk ik niet, want op andere servers heb ik nooit problemen gehad...

Hier een dump van de processen:

code:

USER     PID %CPU %MEM   VSZ  RSS TTY   STAT START   TIME COMMAND
root       1  0.0  0.0  1120  472 ?   S    13:18   0:04 init
root       2  0.0  0.0     0    0 ?   SW   13:18   0:00 [kflushd]
root       3  0.0  0.0     0    0 ?   SW   13:18   0:01 [kupdate]
root       4  0.0  0.0     0    0 ?   SW   13:18   0:00 [kpiod]
root       5  0.0  0.0     0    0 ?   SW   13:18   0:00 [kswapd]
root       6  0.0  0.0     0    0 ?   SW<  13:18   0:00 [mdrecoveryd]
root       7  0.0  0.0     0    0 ?   SW<  13:18   0:00 [raid1d]
root       8  0.0  0.0     0    0 ?   SW<  13:18   0:00 [raid1d]
root       9  0.0  0.0     0    0 ?   SW<  13:18   0:00 [raid1d]
root      10  0.0  0.0     0    0 ?   SW<  13:18   0:00 [raid1d]
root     368  0.0  0.1  1172  524 ?   S    13:20   0:00 syslogd -m 0
root     377  0.0  0.1  1472  792 ?   S    13:20   0:00 klogd
root     407  0.0  0.1  1328  616 ?   S    13:20   0:00 crond
root     419  0.0  0.0  1136  484 ?   S    13:20   0:00 inetd
root     424  0.0  0.1  2096  964 ?   S    13:20   0:00 sshd
root     435  0.0  1.0  7308 5640 ?   S    13:20   0:02 /usr/sbin/httpd.admsrv -f /etc/admserv/conf/httpd.co
root     457  0.0  1.2  7952 6276 ?   S    13:20   0:01 /usr/sbin/httpd.admsrv -f /etc/admserv/conf/httpd.co
root     458  0.0  1.3 11436 7220 ?   S    13:20   0:01 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
root     487  0.0  0.2  2596 1344 ?   S    13:20   0:00 sendmail: accepting connections
httpd   512  1.6  1.8 13456 9664 ?    S    13:20   5:54 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   513  1.5  1.8 13332 9544 ?    S    13:20   5:51 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   514  1.5  1.9 13624 9828 ?    S    13:20   5:37 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   515  1.5  1.8 13280 9488 ?    S    13:20   5:43 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   516  1.4  1.8 13316 9528 ?    S    13:20   5:28 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   521  1.6  1.8 13560 9768 ?    S    13:20   6:05 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
postgres   525  0.0  0.2  4656 1344 ?     SN   13:20   0:00 /usr/bin/postmaster
httpd   528  1.6  1.9 13760 9940 ?    S    13:20   6:04 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   529  1.5  1.8 13356 9564 ?    S    13:20   5:36 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   540  1.6  1.8 13400 9596 ?    S    13:20   6:02 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   541  1.5  1.8 13512 9720 ?    S    13:20   5:33 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   542  1.5  1.8 13520 9728 ?    S    13:20   5:37 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   543  1.5  1.8 13548 9744 ?    S    13:20   5:37 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
root     545  0.0  0.1  1672  824 ?   S    13:20   0:00 sh /usr/bin/safe_mysqld --datadir=/home/mysql --pid-
httpd   566  1.5  1.8 13496 9708 ?    S    13:20   5:48 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   567  1.6  1.8 13520 9716 ?    S    13:20   5:54 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   568  1.5  1.8 13212 9420 ?    S    13:20   5:35 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   570  1.6  1.8 13324 9532 ?    S    13:20   6:09 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   571  1.3  1.9 13828 10064 ?  S    13:20   5:04 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   572  1.7  1.8 13528 9736 ?    S    13:20   6:15 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   573  1.5  1.8 13484 9692 ?    S    13:20   5:42 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd   575  1.5  1.8 13416 9624 ?    S    13:20   5:43 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
mysql   579  0.0  3.0 18448 15928 ?  S    13:20   0:00 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   584  0.0  3.0 18448 15928 ?  S    13:20   0:00 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   585  0.0  3.0 18448 15928 ?  S    13:20   0:00 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   586  0.8  3.0 18448 15928 ?  S    13:20   3:14 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   596  0.9  3.0 18448 15928 ?  S    13:20   3:28 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
root     602  0.0  0.0   296  128 ?   S    13:20   0:00 /sbin/lcdsleep
mysql   638  0.9  3.0 18448 15928 ?  S    13:20   3:30 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
root     642  0.0  0.0  1136  460 ?   S    13:20   0:00 /sbin/getty ttyS0 115200
mysql   645  0.7  3.0 18448 15928 ?  S    13:20   2:53 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   646  0.9  3.0 18448 15928 ?  S    13:20   3:31 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   648  0.9  3.0 18448 15928 ?  S    13:20   3:28 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   650  1.0  3.0 18448 15928 ?  S    13:20   3:52 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   663  0.8  3.0 18448 15928 ?  S    13:21   3:10 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   665  0.9  3.0 18448 15928 ?  S    13:21   3:31 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   686  0.8  3.0 18448 15928 ?  S    13:21   3:15 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   687  0.8  3.0 18448 15928 ?  S    13:21   3:06 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   689  0.9  3.0 18448 15928 ?  S    13:21   3:20 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   710  1.0  3.0 18448 15928 ?  S    13:21   3:39 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   711  0.8  3.0 18448 15928 ?  S    13:22   3:14 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   712  0.9  3.0 18448 15928 ?  S    13:22   3:21 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   732  0.8  3.0 18448 15928 ?  S    13:22   3:15 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   752  0.9  3.0 18448 15928 ?  S    13:22   3:26 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   753  0.9  3.0 18448 15928 ?  S    13:22   3:33 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   754  0.9  3.0 18448 15928 ?  S    13:23   3:18 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql   777  0.9  3.0 18448 15928 ?  S    13:23   3:32 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
root    1063  0.0  1.2  7952 6284 ?   S    13:30   0:01 /usr/sbin/httpd.admsrv -f /etc/admserv/conf/httpd.co
root    3061  0.0  1.2  7952 6284 ?   S    14:14   0:01 /usr/sbin/httpd.admsrv -f /etc/admserv/conf/httpd.co
root    3067  0.0  1.2  7952 6280 ?   S    14:14   0:01 /usr/sbin/httpd.admsrv -f /etc/admserv/conf/httpd.co
root    3068  0.0  1.2  7956 6276 ?   S    14:14   0:01 /usr/sbin/httpd.admsrv -f /etc/admserv/conf/httpd.co
httpd     4975  1.6  1.8 13616 9824 ?     S    14:53   4:26 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
mysql     4976  0.8  3.0 18448 15928 ?   S    14:54   2:25 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
httpd    13501  1.6  1.8 13332 9536 ?     S    17:54   1:31 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
mysql    13540  1.0  3.0 18448 15928 ?   S    17:55   0:55 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
httpd    16872  1.6  1.7 12884 9228 ?     S    19:00   0:26 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
mysql    16892  0.8  3.0 18448 15928 ?   S    19:00   0:12 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
root     17173  0.0  0.3  2968 1604 ?     S    19:07   0:00 sshd
admin    17202  0.0  0.1  1692  924 pts/0    S    19:07   0:00 -bash
httpd    17515  1.3  1.7 12752 9088 ?     S    19:13   0:10 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
mysql    17537  0.8  3.0 18448 15928 ?   S    19:13   0:07 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
httpd    17622  1.4  1.7 12816 9156 ?     S    19:15   0:09 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
mysql    17626  1.2  3.0 18448 15928 ?   S    19:15   0:09 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
httpd    18309  1.0  1.6 12348 8612 ?     S    19:24   0:01 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd    18310  1.9  1.7 12580 8904 ?     S    19:24   0:02 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd    18311  1.9  1.7 12708 9040 ?     S    19:24   0:02 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd    18313  0.4  1.6 12352 8672 ?     S    19:25   0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
mysql    18334  2.5  3.0 18448 15928 ?   S    19:25   0:02 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql    18335  2.5  3.0 18448 15928 ?   S    19:25   0:02 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql    18355  1.5  3.0 18448 15928 ?   S    19:26   0:01 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
httpd    18371  1.1  1.6 12436 8668 ?     S    19:26   0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd    18380  2.4  1.6 12316 8596 ?     S    19:26   0:01 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd    18381  0.7  1.6 12364 8644 ?     S    19:26   0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd    18382  0.6  1.6 12356 8624 ?     S    19:26   0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd    18383  2.5  1.6 12284 8564 ?     S    19:26   0:01 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
httpd    18384  0.6  1.6 12356 8624 ?     S    19:26   0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
mysql    18387  0.0  3.0 18448 15928 ?   S    19:26   0:00 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql    18388  2.4  3.0 18448 15928 ?   S    19:26   0:01 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql    18389  2.3  3.0 18448 15928 ?   S    19:26   0:01 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql    18390  0.0  3.0 18448 15928 ?   S    19:26   0:00 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql    18417 15.7  3.0 18448 15928 ?   S    19:27   0:01 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -
mysql    18418  0.6  3.0 18448 15928 ?   S    19:27   0:00 /usr/sbin/mysqld --basedir=/ --datadir=/home/mysql -

Hebben jullie hier wat aan?

Motor-Forum.nl

woensdag 10 april 2002 21:08

Acties:

duderuud

Sliden is koel

Topicstarter

Met top:

code:

 9:08pm  up  7:50,  1 user,  load average: 2.49, 3.43, 4.05
91 processes: 88 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 62.7% user, 13.9% system,  0.0% nice, 23.3% idle
Mem:   517112K av,  409968K used,  107144K free,  244620K shrd,   54240K buff
Swap:  131448K av,   0K used,  131448K free         231064K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
  638 mysql 1   0 16044  15M  1476 S     0 25.4  3.1   4:18 mysqld
17515 httpd     11   0  9516 9516  6992 R    0 20.2  1.8   2:11 httpd
  572 httpd 1   0  9720 9720  6996 S     0 15.3  1.8   7:38 httpd
16872 httpd 0   0  9720 9720  6996 S     0  2.9  1.8   1:46 httpd
23590 admin 6   0   892  892   676 R     0  2.9  0.1   0:00 top
17537 mysql 0   0 16044  15M  1476 S     0  0.9  3.1   1:05 mysqld
22529 httpd 1   0  9340 9340  6992 S     0  0.7  1.8   0:16 httpd
  540 httpd 0   0  9528 9528  6996 S     0  0.1  1.8   7:28 httpd
16892 mysql 0   0 16044  15M  1476 S     0  0.1  3.1   0:52 mysqld
    1 root   0   0   472  472   400 S    0  0.0  0.0   0:04 init
    2 root   0   0     0    0     0 SW  0  0.0  0.0   0:00 kflushd
    3 root   0   0     0    0     0 SW  0  0.0  0.0   0:01 kupdate
    4 root   0   0     0    0     0 SW  0  0.0  0.0   0:00 kpiod
    5 root   0   0     0    0     0 SW  0  0.0  0.0   0:00 kswapd
    6 root     -20 -20     0    0     0 SW<     0  0.0  0.0   0:00 mdrecoveryd
    7 root     -20 -20     0    0     0 SW<     0  0.0  0.0   0:00 raid1d
    8 root     -20 -20     0    0     0 SW<     0  0.0  0.0   0:00 raid1d

Motor-Forum.nl

woensdag 10 april 2002 21:24

Acties:

JMW761

jah, d'r is iets niet goed met je mysqld

en httpd mag wel een paar duizend keer draaien van mij !
dat betekend tenminste dat men je pagina's bekijkt..daar heb je zo'n server voor...

maar een paar duizend is te zwaar voor jou cobalt hoor..dan moet je met iets zwaarders komen.

Succes:)

woensdag 10 april 2002 21:34

Acties:

Verwijderd

Op woensdag 10 april 2002 21:08 schreef Duderuud het volgende:
Met top:

code:

 9:08pm  up  7:50,  1 user,  load average: 2.49, 3.43, 4.05
91 processes: 88 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 62.7% user, 13.9% system,  0.0% nice, 23.3% idle
Mem:   517112K av,  409968K used,  107144K free,  244620K shrd,   54240K buff
Swap:  131448K av,   0K used,  131448K free         231064K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
  638 mysql 1   0 16044  15M  1476 S     0 25.4  3.1   4:18 mysqld
17515 httpd     11   0  9516 9516  6992 R    0 20.2  1.8   2:11 httpd
  572 httpd 1   0  9720 9720  6996 S     0 15.3  1.8   7:38 httpd
16872 httpd 0   0  9720 9720  6996 S     0  2.9  1.8   1:46 httpd
23590 admin 6   0   892  892   676 R     0  2.9  0.1   0:00 top
17537 mysql 0   0 16044  15M  1476 S     0  0.9  3.1   1:05 mysqld

Ik vindt dat vooral die twee httpd processen monsteractig veel cpu-tijd verstoken....
En in combinatie met mysql

lijkt het toch ergens in die hoek te zitten....

En even snel geteld kom ik op 37 mysqld processen....
Nu ben ik verder geen mysql expert maar is 37 deamons niet een beetje veel van het goede

Verder zie ik dat er redelijk wat httpd en mysql processen rondom dezelfde tijd gestart zijn / worden. (kijk maar eens naar het blok van 19:24 - 19:27)
Ik denk dat er een paar mogelijkheden zijn:
1) je site wordt mega-druk bezocht (kijk eens in je /var/log/http/access_log en error_log)
2) toch iets niet goed in de php scripting
3) iets fout in de mysql(d) config waardoor ie telkens afsterft en opnieuw wil starten (maar het feit dat er rond 13:21 - 13:23 een zwik mysqld's zijn gestart en nog steeds leven zou dit ook weer niet kunnen; maar toch ff nakijken)
4) iemand is van buitenaf je database aan het plunderen / misbruiken

woensdag 10 april 2002 23:19

Acties:

duderuud

Sliden is koel

Topicstarter

Bedankt voor de info, hier heb ik denk ik wel wat aan...

Als er nog meer mensen een geweldig idee hebben...

Motor-Forum.nl

woensdag 10 april 2002 23:22

Acties:

Bigs

Op dinsdag 09 april 2002 23:34 schreef Duderuud het volgende:
Wel grappig, mijn server hang RECHT tegenover de kast van Tweakers.net, hehe!!

Hey, buurman

(ik hang er net schuin tegenover)

woensdag 10 april 2002 23:26

Acties:

Verwijderd

Hehe.. ik zal je cobalt 'n schouderklopje geven vrijdag ruud

ik ben dan wel geen buurman maar hang 'r wel in de buurt

woensdag 10 april 2002 23:27

Acties:

duderuud

Sliden is koel

Topicstarter

Zou best kunnen, heb geen idee!

Toevallig veel verstand van Cobalts?

Motor-Forum.nl

donderdag 11 april 2002 10:04

Acties:

jelmervos

Simple user

Heeft Jeroen nog iets kunnen ontdekken Ruud?

"The shell stopped unexpectedly and Explorer.exe was restarted."

donderdag 11 april 2002 11:04

Acties:

Hans

Op woensdag 10 april 2002 21:34 schreef oudakker het volgende:
Ik vindt dat vooral die twee httpd processen monsteractig veel cpu-tijd verstoken....

top is een momentopname, die cpu usage van die httpd processen zou dus heel normaal kunnen zijn. Verder is er niks mis met een load average van rond de 2 a 3, dan begint een server het net naar zn zin te krijgen.

Op woensdag 10 april 2002 21:34 schreef oudakker het volgende:
En even snel geteld kom ik op 37 mysqld processen....
Nu ben ik verder geen mysql expert maar is 37 deamons niet een beetje veel van het goede

Ooit van threads gehoord? Iedere connectie naar MySQL spawned een nieuwe thread (is wel afhankelijk van een aantal factoren zoals persistent connections en verschillende usernames etc.). Persistent database connections blijven in leven zolang ze actief zijn en zo niet, totdat de timeout period is verstreken. 36 mysqld processen is dus niets spannends.

donderdag 11 april 2002 12:10

Acties:

jelmervos

Simple user

Wat zou dit probleem dan volgens jou dan kunnen zijn, Hans?

"The shell stopped unexpectedly and Explorer.exe was restarted."

donderdag 11 april 2002 13:16

Acties:

Verwijderd

In eerste instantie zou ik denken aan reverse dns'ing. Staan er in je apache access log alleen IP nummers of ook hostnames? En als er hostnames in staan, welke DNS'en raadpleegt je cobalt dan? Misschien dat er meerdere DNS'en staan en dat de eerste steeds in een timeout schiet ofzo?

en... klopt het wel dat mysqld het zo druk heeft?

Doe eens:
mysql
en dan
show status;

donderdag 11 april 2002 13:38

Acties:

Verwijderd

Op donderdag 11 april 2002 11:04 schreef Hans het volgende:

[..]

top is een momentopname, die cpu usage van die httpd processen zou dus heel normaal kunnen zijn. Verder is er niks mis met een load average van rond de 2 a 3, dan begint een server het net naar zn zin te krijgen.
[..]

Als je twee of drie cpu's hebt JA, maar niet met 1 cpu.
De absolute 'idle-use' van een cpu is 1.0
Zodra je daar boven komt te zitten kan je cpu een bottle-neck te worden.

Ooit van threads gehoord? Iedere connectie naar MySQL spawned een nieuwe thread (is wel afhankelijk van een aantal factoren zoals persistent connections en verschillende usernames etc.). Persistent database connections blijven in leven zolang ze actief zijn en zo niet, totdat de timeout period is verstreken. 36 mysqld processen is dus niets spannends.

Threads, JA zeker wel van gehoord, maar een systeem dat zo'n hoge load heeft moet dan wel iets aan het doen zijn, en daar ging de hele vraag van Ruud over.
WAT is ie aan het doen?
En zoals ik zelf al zei:

Nu ben ik verder geen mysql expert [...]

en kan er wat dat betreft ook geen inhoudelijk (technisch) oordeel over geven. (wel m'n bedenkingen!)

Maar (voordat je direct begint te schieten

) niet alle load is afhankelijk van de cpu, je hebt uiteraard memory, swap activiteit (wat in dit geval NIET van toepassing is!), en I/O's.
Met name disk I/O's kunnen voor een hoge load zorgen.
Ik zag dat er voor de cpu nog wel de nodige idle-time (23,3%) had en daar waarschijnlijk de bottle-neck dus niet zit.
Maar dan zou ik de load eens over een periode moeten zien en niet 1 shot van 3 seconde om daar iets meer over te kunnen zeggen.

1) je site wordt mega-druk bezocht [...]

Als dit het geval is, zou ik zeggen; opgelost, dan weet je in iedergeval WAAR het vandaan komt.
Maar dat is, zoals ik de vraag van Ruud begrijp, nu niet het geval!
Dus waar zit het 'probleem' wel? zou mijn volgende vraag zijn!

donderdag 11 april 2002 14:00

Acties:

mavink

Een ding is in ieder geval duidelijk: die machine is *veel* tijd kwijt met apache en mysql-processen. Ik zeg niet dat het altijd zo is, maar als je niet al te veel hits krijgt wijst dit er op dat er een behoorlijk inefficiente query in een van je PHP-scripts zit.

Hij is namelijk zowel met PHP (die apache processen) als met mysql behoorlijk wat tijd kwijt. En het zou best kunnen dat de harddisk ook een bottleneck is; als je joins aan het doen bent op een paar grote tabellen kan het zo zijn dat mysql tijdelijke tabellen aan het aanmaken is. Dan staat de processor de 25% van de tijd dat hij niets doet gewoon op de harddisk te wachten. Met vmstat kan je daar wel achter komen.

Maar om het even wat eenvoudiger te maken: mysql heeft een heel mooi commando om te laten zien wat hij aan het doen is. Met mysqladmin processlist kan je precies zien wat voor queries hij aan het doen is. Dat zou je wat meer informatie moeten geven over bottlenecks.

donderdag 11 april 2002 14:15

Acties:

JMW761

Wat ik me net bedenk!!

de managment pages van die cobalt, ja die op poort 81, vreten proc en mem !

en worden waarschijnlijk ook vanuit mysql geladen..is dat het niet gewoon? tenminste..daar hadden wij ooit problemen mee...

succes

donderdag 11 april 2002 15:13

Acties:

Hans

Op donderdag 11 april 2002 14:15 schreef JMW het volgende:
de managment pages van die cobalt, ja die op poort 81, vreten proc en mem !

en worden waarschijnlijk ook vanuit mysql geladen..is dat het niet gewoon?

Nope die komen uit postgresql op een Cobalt RaQ4.

Enne, oudakker, niet huilen hoor, ik schiet op niemand, ik reageer puur op je verhaal. En een load boven de 1 op een single cpu box is idd gezellig druk, maar niet echt iets om je druk om te maken. Ik heb wel gekkere dingen gezien, en in die omstandigheden bleef Apache gewoon doorstampen.
Het is idd waar dat processen in zo'n geval staan te wachten op hun beurt, maar dat kan bij een load average van 2 a 3 nooit zo lang duren als de vertragingen die ik op duderuud zn forum merk.

Ik zou es gaan kijken naar stale locks op tabellen, zware queries en dat soort zaken. Misschien is dat ActiveTopics toch niet zo'n heel puik gecode forum

Anders idd zoals anderen al zeggen eens in Apache config kijken of HostNameLookups uit staat en dat soort zaken.

donderdag 11 april 2002 15:46

Acties:

duderuud

Sliden is koel

Topicstarter

Wow, bedankt mensen! Hier heb ik wat aan!

offtopic:
Eindelijk weer het GoT van vroeger!

Ik ga vanavond verder met het bekijken van onder andere de reverse lookups, en ik hou verder de stats in de gaten (ook met die "nieuwe" commando's)

Ik hou jullie allen op de hoogte!

O ja: de load fluctueerd heel erg. Soms is de processor 80% idle, dan ineens weer 0% idle...
httpd en mysql processen veroorzaken dit...

Motor-Forum.nl

donderdag 11 april 2002 15:53

Acties:

duderuud

Sliden is koel

Topicstarter

Hostnamelookups staat inderdaad uit...eens proberen 'm te enablen??

Motor-Forum.nl

donderdag 11 april 2002 15:55

Acties:

mavink

Nee het ging er juist om dat die uit moest... Maar daar ligt het waarschijnlijk niet aan. Ik vermoed een hele nare query in een van je PHP-scripts, kijk eerst maar eens bij je mysql processlist.

donderdag 11 april 2002 16:44

Acties:

duderuud

Sliden is koel

Topicstarter

Dat zal tot vanavond moeten wachten, want ik heb hier geen SSH-mogelijkheden...je hoort het van me!

Motor-Forum.nl

donderdag 11 april 2002 18:48

Acties:

Femme

Hardwareconnaisseur

Official Jony Ive fan

Even een hele simpele vraag: de MySQL server heeft een nogal hoge CPU load. Zijn de tabellen wel goed geïndexeerd?

MySQL gebruikt maar 16MB geheugen en is kennelijk niet optimaal geconfigureerd. Als er veel indexes in de database hangen is het zeker nuttig om de key buffer te vergroten.

Check je my.cnf settings.

Als voorbeeldje de my.cnf settings van Artemis die is geoptimaliseerd voor een 2GB dedicated MySQL server met MyISAM en InnoDB tables:

code:

set-variable    = max_connections=200
set-variable    = sort_buffer=4M
set-variable    = wait_timeout=30
set-variable    = table_cache=1500
set-variable    = key_buffer=384M
set-variable    = max_allowed_packet=1M
set-variable    = long_query_time=5
set-variable    = query_buffer_size=64000
set-variable    = max_connect_errors=9999999999
set-variable    = connect_timeout=30
set-variable    = thread_concurrency=8
set-variable    = myisam_sort_buffer_size=64M
set-variable    = thread_cache=12
set-variable    = record_rnd_buffer=1M
set-variable    = record_buffer=1M
set-variable    = join_buffer_size=1M

(server heeft ook nog zo'n 800MB buffer voor InnoDB)

Type 'show status' in de mysql client om de status van je mysql server te checken. De huidige settings kun je achterhalen met 'show variables'.

Optimale key_buffer size: maak key_buffer erg groot en check key_blocks_used in show status als de server een tijd heeft gedraaid. Als key_blocks_used niet of nauwelijks meer groeit heb je het optimale getal voor de key_buffer grootte. Als hulpmiddel kun je ook de keycache hitrate berekenen mbv ((Key_read_requests-Key_reads)/Key_read_requests)*100). Zoals je in de stats op http://www.tweakers.net/etc.dsp?Action=Stats ziet is het goed mogelijk om een keycache hitrate van bijna 100 procent te bereiken.

max_connections: hangt er van of je persistent connections gebruikt. Ik vind persistent connections niet bijzonder nuttig. Je kunt ook de thread_cache verhogen zodat MySQL altijd een paar idle threads open laat staan die nieuwe connecties kunnen aannemen. Het voordeel is dat er minder geheugen wordt geconsumeerd (key_buffer wordt geshared maar elke thread gebruikt sort_buffer, record_buffer, join_buffer en query_buffer). Tweede voordeel is dat je max connections laag kunt houden en veiliger bent in situaties waarbij een ultratrage queries de server plat kan leggen (30x ultrazware query is minder rampzalig dan 200x ultrazware query). Stem het aantal max connecties af op Max_used_connections in 'show status'.

sort_buffer en sort_record_buffer worden gebruikt om te sorteren als er geen index gebruikt kan worden. Groter dan 1MB is niet erg zinvol tenzij er erg grote result sets gesorteerd moeten worden.

table_cache: groter maken als de verhouding tussen het aantal 'opens' en 'open tables' erg hoog is (type 'status' in de mysql client).

query_buffer: groter maken als er veel lange queries (zoals bij het inserten van blobs) worden gedraaid.

thread_concurrency: twee tot vier keer het aantal CPU's.

Zet slow query logging aan met 'log-slow-queries' in my.cnf en check in de log (meestal hostname-slow.log) welke queries niet optimaal lopen. long_query_time in my.cnf bepaald na hoeveel seconden een query als traag wordt gezien.

Table locking: met table_locks_wait/(table_locks_im+table_locks_wait) kun je het percentage trage table locks berekenen. Bij een hoog percentage heb je last van veel table locking. Check of er erg trage inserts/updates zijn die bepaalde tables langdurig locken en overweeg het gebruik van InnoDB tables.

donderdag 11 april 2002 19:37

Acties:

duderuud

Sliden is koel

Topicstarter

Haha! Femme, erg bedankt...ik ga eerst 2 uur jouw oplossingen ontcijferen!

Ben niet zo'n kenner hoor, maar je houdt me zo weer een avond van de straat.

Ik ga het allemaal opzoeken, nakijken en eventueel aanpassen. Thx voor de info!

O ja, nog wat info:

code:

mysql> show status;
+--------------------------+------------+
| Variable_name     | Value |
+--------------------------+------------+
| Aborted_clients       | 0     |
| Aborted_connects     | 3      |
| Bytes_received         | 34487219   |
| Bytes_sent           | 604233261  |
| Connections         | 38591   |
| Created_tmp_disk_tables  | 0      |
| Created_tmp_tables     | 177    |
| Created_tmp_files   | 0       |
| Delayed_insert_threads   | 0      |
| Delayed_writes         | 0        |
| Delayed_errors         | 0        |
| Flush_commands         | 1        |
| Handler_delete         | 33814    |
| Handler_read_first     | 662    |
| Handler_read_key     | 1552597    |
| Handler_read_next   | 3966787    |
| Handler_read_prev   | 0       |
| Handler_read_rnd     | 4646189    |
| Handler_read_rnd_next    | 1328654035 |
| Handler_update         | 7861  |
| Handler_write     | 155600     |
| Key_blocks_used       | 7793   |
| Key_read_requests   | 4737549    |
| Key_reads         | 53870 |
| Key_write_requests     | 302869     |
| Key_writes           | 230365     |
| Max_used_connections     | 34    |
| Not_flushed_key_blocks   | 0      |
| Not_flushed_delayed_rows | 0      |
| Open_tables         | 64     |
| Open_files           | 81    |
| Open_streams       | 0        |
| Opened_tables     | 1945   |
| Questions         | 329527     |
| Select_full_join     | 36    |
| Select_full_range_join   | 0      |
| Select_range       | 64      |
| Select_range_check     | 0        |
| Select_scan         | 43761   |
| Slave_running     | OFF     |
| Slave_open_temp_tables   | 0      |
| Slow_launch_threads   | 451     |
| Slow_queries       | 28      |
| Sort_merge_passes   | 0       |
| Sort_range           | 9078    |
| Sort_rows         | 4651320    |
| Sort_scan         | 18143 |
| Table_locks_immediate    | 335934     |
| Table_locks_waited     | 28916    |
| Threads_cached         | 0        |
| Threads_created       | 38590 |
| Threads_connected   | 3       |
| Threads_running       | 2     |
| Uptime             | 35623    |
+--------------------------+------------+
54 rows in set (0.00 sec)

Motor-Forum.nl

donderdag 11 april 2002 20:02

Acties:

Femme

Hardwareconnaisseur

Official Jony Ive fan

Kun je ook 'show variables' posten?

Keycache hitrate: 98,86%
Slow table locks: 7,92%.

De keycache kan nog wat effeciënter door de key_buffer te vergroten (nu 8MB?). Probeer 'm eens op 64MB te zetten en dan kijken tot hoe ver Key_blocks_used na een dag is gegroeid.

Het percentage slow table locks vind ik extreem hoog. Kijk eens regelmatig in de processlist ('show processlist') of daar veel inserts/updates en wachtende selects hangen (en check je slow query log).

donderdag 11 april 2002 20:20

Acties:

duderuud

Sliden is koel

Topicstarter

Sorry voor de vern**kte layout:<blockquote>code:<hr>| connect_timeout | 5
| datadir | /home/mysql/
| delay_key_write | ON
| delayed_insert_limit | 100
| delayed_insert_timeout | 300
| delayed_queue_size | 1000
| flush | OFF
| flush_time | 0
| have_bdb | NO
| have_gemini | NO
| have_innodb | NO
| have_isam | YES
| have_raid | NO
| have_ssl | NO
| init_file |
| interactive_timeout | 28800
| join_buffer_size | 131072
| key_buffer_size | 8388600
| language | /usr/share/mysql/english/
| large_files_support | ON
| locked_in_memory | OFF
| log | OFF
| log_update | OFF
| log_bin | OFF
| log_slave_updates | OFF
| long_query_time | 10
| low_priority_updates | OFF
| lower_case_table_names | 0
| max_allowed_packet | 1048576
| max_binlog_cache_size | 4294967295
| max_binlog_size | 1073741824
| max_connections | 100
| max_connect_errors | 10 &nbs

Motor-Forum.nl

donderdag 11 april 2002 20:35

Acties:

Femme

Hardwareconnaisseur

Official Jony Ive fan

Ik zou om te beginnen de key_buffer vergroten in my.cnf (meestal /etc/my.cnf) net zolang tot je de ideale grootte hebt gevonden. Met 512MB moet dat niet zo'n probleem zijn.

table_cache mag ook wel omhoog maar ik kan niet vinden wat de huidige setting is. Probeer eens een waarde van 400 en kijk dan eens of de verhouding Open_tables / Opened_tables er beter op wordt.

Het grootste probleem is waarschijnlijk toch table locking. Als je de queries kunt aanpassen zou ik eens kijken of het mogelijk is om 'insert delayed' en 'update low_priority' te gebruiken. Als er queries zijn waarbij het niet belangrijk is dat ze direct wordt uitgevoerd (maar enkele seconden mogen wachten) kan insert delayed en update low_priority behoorlijk schelen omdat hij dan wacht met inserten/updaten tot er niet uit de tabel gelezen wordt. Om update low_priority mogelijk te maken moet je 'low-priority-updates' als regel aan my.cnf toevoegen.

donderdag 11 april 2002 20:35

Acties:

duderuud

Sliden is koel

Topicstarter

Femme, ik heb nu de (blijkbaar) standaard file my-large.cnf die in de map /usr/share/mysql staat, aangepast naar my.cnf, en in de map /home/mysql geplaatst.

Ik neem aan dat dat de data-map van mysql is (tis een cobalt he!) Staat in de bovenstaande dump, vandaar...

Zo eens proberen?

Inhoud my.cnf:

# The MySQL server
[mysqld]
port= 3306
socket= /var/lib/mysql/mysql.sock
skip-locking
set-variable= key_buffer=256M
set-variable= max_allowed_packet=1M
set-variable= table_cache=256
set-variable= sort_buffer=1M
set-variable= record_buffer=1M
set-variable= myisam_sort_buffer_size=64M
set-variable= thread_cache=8
# Try number of CPU's*2 for thread_concurrency
set-variable= thread_concurrency=8
log-bin
server-id= 1

# Uncomment the following if you are using BDB tables
#set-variable= bdb_cache_size=64M
#set-variable= bdb_max_lock=100000

# Uncomment the following if you are using Innobase tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:25M;ibdata2:37M;ibdata3:100M;ibdata4:300M
#set-variable = innodb_mirrored_log_groups=1
#set-variable = innodb_log_files_in_group=3
#set-variable = innodb_log_file_size=5M
#set-variable = innodb_log_buffer_size=8M
#innodb_flush_log_at_trx_commit=1
#innodb_log_archive=0
#set-variable = innodb_buffer_pool_size=16M
#set-variable = innodb_additional_mem_pool_size=2M
#set-variable = innodb_file_io_threads=4
#set-variable = innodb_lock_wait_timeout=50

# Point the following paths to different dedicated disks
#tmpdir= /tmp/
#log-update = /path-to-dedicated-directory/hostname

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

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

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

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

[mysqlhotcopy]
interactive-timeout

Motor-Forum.nl

donderdag 11 april 2002 21:04

Acties:

duderuud

Sliden is koel

Topicstarter

HA! Ik heb de my.cnf in /etc geplaatst, zie hier de dump van show variables:<blockquote>code:<hr>| connect_timeout | 5 |
| datadir | /home/mysql/ |
| delay_key_write | ON |
| delayed_insert_limit | 100 |
| delayed_insert_timeout | 300 |
| delayed_queue_size | 1000 |
| flush | OFF |
| flush_time | 0 |
| have_bdb | NO |
| have_gemini | NO |
| have_innodb | NO |
| have_isam | YES |
| have_raid | NO |
| have_ssl | NO |
| init_file | |
| interactive_timeout | 28800 |
| join_buffer_size | 131072 |
| key_buffer_size | 268431360 |
| language | /usr/share/mysql/english/ |
| large_files_support | ON |
| locked_in_memory | OFF |
| log | OFF |
| log_update | OFF |
| log_bin | ON |
| log_slave_updates | OFF |
| long_query_time | 10 |
| low_priority_updates | OFF |
| lower_case_table_names | 0 |
| max_allowed_packet | 1047552 |
| max_binlog_cache_size | 4294967295 &nbs

Motor-Forum.nl

donderdag 11 april 2002 21:10

Acties:

duderuud

Sliden is koel

Topicstarter

Status nu:

code:

mysql> status
--------------
mysql  Ver 11.15 Distrib 3.23.37, for pc-linux-gnu (i686)

Connection id:      27
Current database:
Current user:        admin@localhost
Current pager:      stdout
Using outfile:      ''
Server version:    3.23.37-log
Protocol version:    10
Connection:      Localhost via UNIX socket
Client characterset:    latin1
Server characterset:    latin1
UNIX socket:        /var/lib/mysql/mysql.sock
Uptime:          10 min 29 sec

Threads: 5  Questions: 4526  Slow queries: 0  Opens: 39  Flush tables: 1  Open tables: 33 Queries per second avg: 7.196

Motor-Forum.nl

donderdag 11 april 2002 21:26

Acties:

Femme

Hardwareconnaisseur

Official Jony Ive fan

sort_buffer en record_buffer zou ik terug draaien naar 128K of 256K en thread_concurrency naar 4. Verder nu even Key_blocks_used in de gaten houden en daar je key_buffer op afstemmen. Waarschijnlijk is 16 tot 32MB al voldoende.

Maar kijk vooral of er trage queries zijn en of daar iets aan verbeterd kan worden, want dat lijkt me het grootste probleem.

donderdag 11 april 2002 21:37

Acties:

duderuud

Sliden is koel

Topicstarter

Sort_ en record_buffer naar 256 gezet...
thread_concurrency naar 4 gezet...

Laatste puntje wat je noemt moet ik door iemand anders laten doen, want ik wet niet hoe dat moet.

Lijkt er op dat het nu al helpt, gaat stukkie sneller.

Ik ga de serverload in de gaten houden...

Mag ik je HEEL hartelijk bedanken? Vast wel...

HARTELIJK BEDANKT!

Ik zal hier wel posten als er nog iets opmerkelijks is...

Motor-Forum.nl

donderdag 11 april 2002 23:51

Acties:

Vm1heA

laat dit nou weer een mooi moment zijn op GoT , een samenwerkingsverband waar ik van zeg , SUPER Afbeeldingslocatie: http://www.motor-forum.nl/forum/images/smilies/worshippy.gif

Afbeeldingslocatie: http://www.motor-forum.nl/forum/images/smilies/worshippy.gif

( om in de MF stijl te blijven )

en dat GoT ook weer kwaliteit krijgt ( wat ik al her en der zie )

donderdag 11 april 2002 23:56

Acties:

Martin?81

Honda CBR600RR 2004

Hmmm... Ik hoop dat het gaat lukken...

vrijdag 12 april 2002 08:43

Acties:

witchdoc

Op donderdag 11 april 2002 23:51 schreef Niels Saarloos het volgende:
en dat GoT ook weer kwaliteit krijgt ( wat ik al her en der zie )

NT en ANS is nog nooit slecht geweest hoor!

vrijdag 12 april 2002 08:55

Acties:

duderuud

Sliden is koel

Topicstarter

jongens, ga nou niet offtopic!

Motor-Forum.nl

vrijdag 12 april 2002 09:11

Acties:

jelmervos

Simple user

Op vrijdag 12 april 2002 08:43 schreef poohbeer het volgende:

[..]

NT en ANS is nog nooit slecht geweest hoor!

Mag ik je wijzen op dit topic poohbeer?

[topic=463093/1/100]

Is het nu merkbaar beter Ruud?

"The shell stopped unexpectedly and Explorer.exe was restarted."

vrijdag 12 april 2002 09:13

Acties:

witchdoc

Op vrijdag 12 april 2002 09:11 schreef jelmervos het volgende:

[..]

Mag ik je wijzen op dit topic poohbeer?

[topic=463093/1/100]

Is het nu merkbaar beter Ruud?

Laatste opmerking voor ruud boos wordt: dat ging over de topics, niet de sfeer. Is ook snel ingegrepen en er wordt dus al tijden goed gemod hier. Zeker rekening houden met dat 'advanced' voor iedereen wat anders betekend.

vrijdag 12 april 2002 10:05

Acties:

Verwijderd

Leuk om dit te volgen.

Het is inderdaad een stuk sneller geworden!

Afbeeldingslocatie: http://80.247.197.209/forum/images/smilies/worshippy.gif

Femme & Duderuud

vrijdag 12 april 2002 23:59

Acties:

Hans

thread_concurrency op 4 is misschien nog wat enthousiast voor een single CPU server. Tevens zou ik log-bin uitzetten, is nergens voor nodig (je hebt toch geen replication draaien).

zaterdag 13 april 2002 19:14

Acties:

twixx

Ik denk toch dat het niet zozeer in de optimalisatie van MySQLd zit als wel in de scripting. Httpd processen die zoveel load voor een langere periode van tijd veroorzaken; das vreemd. Mede gezien je dataverkeer en geschat aantal bezoekers denk ik dat je load niet boven de .2 zou moeten zijn.
Overigens hebben deze load averages niets met de hoeveelheid CPU gebruik te maken.
Hoe snel wordt een standaard html page geserveerd? En hoe snel een pagina met wat default PHP? (like php_info();)

9x Canadian Solar + Enphase IQ7+ 3,4 kWp ZZW 20º
4x Yingli + Enphase IQ7 1 kWp ZZW 25º
4x Yingli + Enphase IQ7 1 kWp ZZW 90º

maandag 15 april 2002 01:41

Acties:

reddog33hummer

Dat schept mogelijkheden

wat ik wel vreemd vindt is dat je de postmaster van postgresql hebt draien. Je gebruikt immers mysql. Waarom loopt die postgres daar ?

Backup not found (R)etry (A)bort (P)anic<br\>AMD 3400+ 64, 2 GB DDR, 1,5 TB Raid5

maandag 15 april 2002 01:53

Acties:

Verwijderd

Op maandag 15 april 2002 01:41 schreef reddog33hummer het volgende:
wat ik wel vreemd vindt is dat je de postmaster van postgresql hebt draien. Je gebruikt immers mysql. Waarom loopt die postgres daar ?

er werd eerder verteld dat de admin packages van een RAQ4 op Postgresql draaien

maandag 15 april 2002 09:12

Acties:

jelmervos

Simple user

Het is momenteel nog traag op Ruud's forum...

"The shell stopped unexpectedly and Explorer.exe was restarted."

maandag 15 april 2002 11:18

Acties:

duderuud

Sliden is koel

Topicstarter

Op zaterdag 13 april 2002 19:14 schreef twixx het volgende:
Ik denk toch dat het niet zozeer in de optimalisatie van MySQLd zit als wel in de scripting. Httpd processen die zoveel load voor een langere periode van tijd veroorzaken; das vreemd. Mede gezien je dataverkeer en geschat aantal bezoekers denk ik dat je load niet boven de .2 zou moeten zijn.
Overigens hebben deze load averages niets met de hoeveelheid CPU gebruik te maken.
Hoe snel wordt een standaard html page geserveerd? En hoe snel een pagina met wat default PHP? (like php_info();)

Standaard html wordt heel snel geserveerd....phpinfo ook...

Motor-Forum.nl

maandag 15 april 2002 14:09

Acties:

Hans

Op maandag 15 april 2002 11:18 schreef Duderuud het volgende:
Standaard html wordt heel snel geserveerd....phpinfo ook...

Conclusie: ActiveTopics rammelt aan alle kanten. Excuses voor mijn botte conclusie maar daar komt het dan wel min of meer op terecht. Of er moet echt iets heel fout zitten in je mysql config, maar dat lijkt wel ok op het moment.

maandag 15 april 2002 14:21

Acties:

Verwijderd

Kan je ons misschien de status van de slow query's in mysql geven?

Die kan je onderanderen vinden via phpmyadmin als je het via de commandline niet kan. Verder geef ook de executie tijd van threads als je wilt.

maandag 15 april 2002 18:48

Acties:

twixx

Op maandag 15 april 2002 14:09 schreef Hans het volgende:

[..]

Conclusie: ActiveTopics rammelt aan alle kanten. Excuses voor mijn botte conclusie maar daar komt het dan wel min of meer op terecht. Of er moet echt iets heel fout zitten in je mysql config, maar dat lijkt wel ok op het moment.

Of het AT is weet ik niet, maar blijkbaar wel het geen wat je opvraagd. Ik zou eerst maar eens naar je source kijken voordat je je SQL server gaat herbakken, optimizen enz

9x Canadian Solar + Enphase IQ7+ 3,4 kWp ZZW 20º
4x Yingli + Enphase IQ7 1 kWp ZZW 25º
4x Yingli + Enphase IQ7 1 kWp ZZW 90º

maandag 15 april 2002 19:49

Acties:

Hans

Op maandag 15 april 2002 18:48 schreef twixx het volgende:

Of het AT is weet ik niet [...]

Meer draait er niet op die bak, dus dat moet haast wel

maandag 15 april 2002 21:12

Acties:

duderuud

Sliden is koel

Topicstarter

ik ga binnenkort de nieuwste versie installeren, als die uitkomt. Kan zijn dat ik zelf de source teveel verklooit heb.

Maar goed, AT heeft altijd goed gedraait op andere servers...dus kan in principe ook niet aan de software liggen...

Motor-Forum.nl

maandag 15 april 2002 23:32

Acties:

Hans

Dat ligt er maar net aan op wat voor server het hiervoor draaide. En of er misschien sprake was van een dedicated (aparte) database server, etc. etc.

woensdag 17 april 2002 21:52

Acties:

Verwijderd

Hmm, kijk eens even of in je apacheconfig toevallig 'HostnameLookups' aanstaat? dat kan nogal wat verschrikkelijke wachttijden geven.

Dit moet hetwezen:
HostnameLookups Off

donderdag 18 april 2002 10:05

Acties:

aKeY

Hee, mooi dat ik dit topic hier lees.

Ik draai zelf ook ActiveTopics van niels op een Cobalt server (alleen dan met een aantal zelf toegevoegde optie's in het forum)

Om de haverklap merk ik dat als je een topic opend, dit soms vrij lang kan duren.. (ook bij kleine topics)

Losse html file's (incl. plaatjes etc..) worden snel geladen, dus aan de verbinding kan het niet liggen..

Het nadeel dat ik dus heb, is dat "mijn goedje" virtueel wordt gehost.. dus ik kan niet bij de config bestanden van apache en mysql.

Als ik het aan mijn provider zou vragen om veranderingen aan te brengen, geld dit dus voor alle website's die op die server draaien; en of dit nu de bedoeling is?

Pas begonnen met het forum (1 maand nu) en nu al ruim boven de 50.000 pageviews..

Zelf ben ik geen php-goeroe (just a starter.. ;-) ) maar ik heb een php mannetje in "dienst"..

Wat ik van de code begrijp is dat het goedje nogal vrij complex in elkaar steekt.
Ik kan weleens vragen of hij MySql actie's eens goed wil bekijken en een conclusie kan trekken of het ook op een snellere manier kan..

1 nadeel, ik zie hem zaterdag pas weer, dus als het zover is zoek ik dit topic wel op, met hopelijk een antwoord.

Een dag is een dag...

donderdag 18 april 2002 12:15

Acties:

Hans

Dit begint langzaam op een ActiveTopics helpdesk topic te lijken. Misschien moesten jullie es met die Niels gaan babbelen over de performance van z'n forum.

donderdag 18 april 2002 12:40

Acties:

aKeY

Op donderdag 18 april 2002 12:15 schreef Hans het volgende:
Dit begint langzaam op een ActiveTopics helpdesk topic te lijken. Misschien moesten jullie es met die Niels gaan babbelen over de performance van z'n forum.

Idd, heb je gelijk in, alleen het probleem van het supportforum op activetopics.nl is:

Er kijkt nooit iemand op!

Ga je op forum.nielsonline.com vragen posten, krijg je geen fatsoenlijk antwoord..

In de trend van: Ow jij bent de enige met dat probleem, bij anderen werkt het wel dus zoek maar uit..

Als ik had geweten dat de ondersteuning van AT zo minimaal was, had ik waarschijnlijk voor een ander betaald forum gekozen. Na veel en lang zoeken naar een geschikt forum heb ik uiteindelijk voor AT gekozen en betaald.

De site loopt momenteel goed kwa gebruikers, dus om nu zomaar over te stappen op een ander forum is geen optie.

Dat wordt dus tweaken!

Een dag is een dag...

vrijdag 19 april 2002 16:22

Acties:

Twilight

Op donderdag 18 april 2002 12:40 schreef aKeY het volgende:

[..]

Idd, heb je gelijk in, alleen het probleem van het supportforum op activetopics.nl is:

Er kijkt nooit iemand op!

Misschien omdat zn server down is

Wat een

www.nanon.nl

zondag 21 april 2002 20:32

Acties:

duderuud

Sliden is koel

Topicstarter

Best makkelijk hoor, AT afzeiken...maar zie het verschil:

* AT --> eenmalig €57, open source
* Parse --> VEEL geld per maand (ik weet niet of ik het hier mag posten, maar het is veel poen per maand in ieder geval!!)

Nuff said....

O ja, AT is het beste forum wat ik tot nog toe ben tegengekomen (Yabb, UBB, phpBB, UbbThreads, vBulletin, allemaal niet top)

Conclusie: Je mag niet zeiken over AT, want het werkt ERG goed, en je kan en mag alles zelf aanpassen, en dat voor maar het eenmalige bedrag van €57 !!

Motor-Forum.nl

maandag 22 april 2002 00:38

Acties:

Hans

Chill chill, mijn postings hier zijn puur persoonlijk en niet professioneel, dus niet vanuit mn werk. Ik probeer dus ook absoluut niet ons forumproduct te pluggen zoals jij dat nu ziet.

Het is maar net wat jij wilt betalen voor dat extra beetje support, iets wat AT duidelijk zo goed als niet blijkt te hebben. En dat maakt het dus een beetje moeilijk in jouw geval. Wat ik je trouwens ook even moet melden is dat de prijs die je aangeboden is voor ons forum waarschijnlijk inclusief hosting was (dus dat wij ASP voor jouw forum zijn).

Het mag je nu dan € 57 gekost hebben, maar je zit wel met een forum dat kakkend traag draait op de server die je net aangeschaft hebt, en support laat niks van zich horen. Dat moet toch zuur zijn. Als het echt zo "ERG goed" zou zijn als jij doet voorkomen, had het op die Cobalt toch iets sneller moeten draaien dan het nu doet.

maandag 22 april 2002 12:02

Acties:

duderuud

Sliden is koel

Topicstarter

[gevoel, als mens zijnde]

Een asp-forum, door jullie gehost is wel het LAATSTE wat ik wil!
Koop je voor VEEL geld een forum, mag je het zelf niet eens aanpassen! Ik wil toch ECHT wel zelf alles kunnen aanpassen als ik dat wil...op mijn EIGEN server (of eigen accountje op webserver).

En even tussendoor....het forum draait de laatste tijd wel aardig goed, gemiddelde load is nu 1,5 ongeveer.
Alle tweaks en aanpassingen hadden dus wel degelijk zin (thx Femme en anderen!).

als je goed leest vanaf het begin, zie je dat ik die cobalt had gekocht, zo goed als ik het kon klaargemaakt en geplaatst.
Ik heb 0 verstand van Linux, en al helemaal niet van apache en het tweaken van een webserver, dus het is ook niet zo verwonderlijk dat de site in het begin traag was...die Cobalt was nog helemaal standaard.

Kijk, als Parse nou voor mij een 30-dagen trial heeft (en NIET in asp!), dan wil ik best kijken of het zoveel sneller is...

Maar vooralsnog heeft AT nog steeds mijn voorkeur.

Motor-Forum.nl

maandag 22 april 2002 12:24

Acties:

Femme

Hardwareconnaisseur

Official Jony Ive fan

Met 'ASP' bedoelt Hans in dit geval 'Application Service Provider', dus dat Parse jouw applicatie gaat hosten ipv op je eigen Cobalt.

maandag 22 april 2002 13:34

Acties:

witchdoc

[quote]Op maandag 22 april 2002 12:02 schreef Duderuud het volgende:
En even tussendoor....het forum draait de laatste tijd wel aardig goed, gemiddelde load is nu 1,5 ongeveer.
quote]

1.5 voor 1 forum op 1 server.. lijkt mij eerlijk gezegd nog wat veel hoor ruud.
Noujah, het draait alweer zonder dat je er echt een halve minuut op moet wachten dus ik ben tevreden.

Eeneuh.. Hans, parse en AT zijn gewoon andere fora met verschillende doelgroepen.
Jij haalt je broodwinning uit PARSE en laat klanten dan ook zwaar betalen. Hierdoor kan je ze natuurlijk ook serieuze service bieden. Blijft natuurlijk duur een onbetaalbaar voor sites zoals motor-forum.

AT is een goedkoop alternatief dat tenminste haalbaar is voor een amateurforumpje als motor-forum. De server betalen is een eenmalige kost en het forum ook. Blijf je enkel nog met 1U zitten die je moet betalen.
Ok, het draait iets minder goed, maar het draait dan toch en er wordt nog enigzins naar de klant geluisterd.
Dat zou zonder AT niet zijn geweest. (al zijn er natuurlijk nog genoeg van dergelijke alternatieven)

maandag 22 april 2002 13:55

Acties:

Hans

Op maandag 22 april 2002 12:24 schreef Femme het volgende:
Met 'ASP' bedoelt Hans in dit geval 'Application Service Provider', dus dat Parse jouw applicatie gaat hosten ipv op je eigen Cobalt.

Juist! De term ASP wordt hier een beetje verkeerd begrepen. Ik bedoel hiermee dus inderdaad Application Service Provider en niet die VB-meuk van MS.

En alle mogelijke customizations zijn bespreekbaar, en tevens verschillende licentievormen (ASP-constructie, compiled source met templates, volledige sourcecode etc.). Maar ik ga hier verder geen verkooppraatjes verkondigen voordat er weer een horde boze mensen op me duikt.

Oh en wat ik nog even wil toevoegen: Ik wil hier ook helemaal geen vergelijking trekken tussen het forumproduct van mijn werk en AT of wat voor forum dan ook. Ik begrijp best dat jij voor die 57 euro waar voor je geld hebt, voor het doel waar je het voor gebruikt. Neemt niet weg dat ik als persoon niet een beetje mag dollen met AT.

dinsdag 23 april 2002 19:00

Acties:

duderuud

Sliden is koel

Topicstarter

Okee!

Inderdaad, de 2 produkten hebben een totaal verschillende achtergrond...en ik weet dat je met ASP bedoelde dat het op jullie servers draaide...

Maar goed...mail me maar als je denkt dat het heel wat beter kan dan AT, want ik sta voor kwaliteit natuurlijk!

Motor-Forum.nl

woensdag 24 april 2002 23:02

Acties:

witchdoc

Vergeet niet de BETAALBAAR bij die kwaliteit te plakken he ruud.
Een ferari is ook kwaliteit.. betaalbaar daarentegen is weer wat anders.

vrijdag 26 april 2002 15:28

Acties:

Vm1heA

Ferrari is uiterlijk vertoon
veel duur onderhoud nodig

vrijdag 3 mei 2002 08:57

Acties:

aKeY

Even omhoog gekickd, misschien interessant:

Ik gebruik momenteel ook ActiveTopic van niels op een cobalt server.

Momenteel ben ik met een groep mensen het forum van tuinhark (yapbb) aan het testen, en volledig aan het aanpassen na eigen wensen..

Op dit moment kan ik bijna 100% zeker zeggen dat de traagheid grotendeels in je code zit..
Als extratje kun je natuurlijk idd je server fijn tunen wat je geloof ik momenteel al gedaan hebt..

Een dag is een dag...

zaterdag 4 mei 2002 02:37

Acties:

Steyn

te laat ..

m'n slack 8.0 draait ondertussen ook al (zat naast je tijdens die install:))

maandag 6 mei 2002 10:06

Acties:

reclamedoos

Op vrijdag 03 mei 2002 08:57 schreef aKeY het volgende:
Op dit moment kan ik bijna 100% zeker zeggen dat de traagheid grotendeels in je code zit..

Kan je dat ook onderbouwen? Ik ben zeer benieuwd wat je dan als aanwijsbare reden kan aandragen

maandag 6 mei 2002 11:58

Acties:

aKeY

Op maandag 06 mei 2002 10:06 schreef reclamedoos het volgende:

Kan je dat ook onderbouwen? Ik ben zeer benieuwd wat je dan als aanwijsbare reden kan aandragen

Als je naar de code kijkt, is het goed strak geprogrammeerd. (mijn compimenten overigens, want ik doe het niet na..)

Toch als je gaat zoeken, zit het zo strak geprogrammeerd dat dat je bij een actie op het forum (vooral SQL handelingen) het goedje eerst moet zoeken hoe of wat, voordat daadwerkelijk het resultaat getoond word.
Dit kost na mijn mening teveel tijd..

Het forum waar ik nu gebruik van maak, doet in principe hetzelfde maar is "losser" (=lees minder strak) geprogrammeerd zodat het minder tijd kost om een resultaat te krijgen..

Ik zei al eerder, dat natuurlijk het fijn-tunen van een webserver+sql ook al veel scheel, maar alle beetjes helpen natuurlijk.

Een dag is een dag...

Pagina: 1

Reageer