[debian/apache/mysql] 1000 hits/sec teveel voor 2 servers

Pagina: 1
Acties:

  • asusk7m550
  • Registratie: Oktober 2000
  • Laatst online: 28-01 10:10

asusk7m550

Athlon 550@500

Topicstarter
Voor een website heb ik op twee servers debian sarge geinstalleerd. De ene server is de database (mysql) en de andere server is de webserver (apache). Beide servers zijn via een 100mb lijntje verbonden met het internet. Intern zijn de servers verbonden met een 1gb netwerk kabel (1 op 1).

Nu wil ik natuurlijk testen hoe snel deze combinatie is. En ik heb hiervoor een aantal testpagina's gemaakt:
PHP:
1
<? echo "bla"; ?>

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<? $link = mysql_connect("intern_ip_sql_server", "user", "password")
        or die("Kan geen verbinding maken");
mysql_select_db("db_naam")
        or die("Kan geen database selecteren");

$query = "SELECT * FROM `test` WHERE `field2` = 0 limit 1;";
$result = mysql_query($query)
        or die("Fout bij uitvoeren query1");

echo "bla";

mysql_free_result($result);

mysql_close($link); ?>

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<? $link = mysql_connect("intern_ip_sql_server", "user", "password")
        or die("Kan geen verbinding maken");
mysql_select_db("db_naam")
        or die("Kan geen database selecteren");

$query = "SELECT * FROM `test` WHERE `field2` = 0 limit 1;";
$result = mysql_query($query)
        or die("Fout bij uitvoeren query1");

$row = mysql_fetch_row($result);

echo "row[1]: $row[1]";

mysql_free_result($result);

mysql_close($link); ?>

Ik heb deze pagina's getest vanaf de sql server (buitenlangs).
Ik test de server met: ab2 -n100000 -c1000 http://externe_ip_www/index1.php

Als ik de eerste pagina opvraag krijg ik het volgende bij top:
top - 16:35:53 up  2:37,  2 users,  load average: 8.21, 7.14, 7.61
Tasks: 132 total,  21 running,  79 sleeping,   0 stopped,  32 zombie
 Cpu0 : 41.7% us, 21.3% sy,  0.0% ni, 17.7% id,  0.0% wa,  4.0% hi, 15.3% si
 Cpu1 : 45.7% us, 25.7% sy,  0.0% ni, 19.7% id,  1.0% wa,  1.3% hi,  6.7% si
Mem:   3344480k total,   185836k used,  3158644k free,    12036k buffers
Swap:   996008k total,        0k used,   996008k free,    85724k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3328 root      25   0 65772  10m 6208 R  3.7  0.3   0:08.74 apache2
12726 www-data  15   0     0    0    0 Z  1.7  0.0   0:00.05 apache2 <defunct>
12707 www-data  15   0     0    0    0 Z  1.3  0.0   0:00.04 apache2 <defunct>
12709 www-data  15   0     0    0    0 Z  1.3  0.0   0:00.04 apache2 <defunct>
12710 www-data  15   0     0    0    0 Z  1.3  0.0   0:00.04 apache2 <defunct>
12711 www-data  15   0     0    0    0 Z  1.3  0.0   0:00.04 apache2 <defunct>

Zoals je kunt zien staat er 15.3% en 6.7% bij si (dit zijn softirq).

Volgens mij is het niet normaal dat er bij een normale pagina al zo'n percentage bij de softirq staat. Als ik de tweede pagina opvraag (connectie naar de database) krijg ik het volgende:
top - 16:40:50 up  2:42,  2 users,  load average: 10.72, 5.26, 6.46
Tasks: 154 total,  50 running,  74 sleeping,   0 stopped,  30 zombie
 Cpu0 : 49.3% us, 18.3% sy,  0.0% ni,  0.0% id,  0.0% wa,  7.7% hi, 24.7% si
 Cpu1 : 57.1% us, 24.9% sy,  0.0% ni,  0.0% id,  0.0% wa,  4.7% hi, 13.3% si
Mem:   3344480k total,   221744k used,  3122736k free,    12868k buffers
Swap:   996008k total,        0k used,   996008k free,    96072k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3254 mysql     16   0  132m  17m 3204 S  0.0  0.5   0:00.36 mysqld
13610 www-data  16   0 70840  11m 6592 R  3.3  0.4   0:00.10 apache2
13609 www-data  16   0 65776  10m 6516 R  2.3  0.3   0:00.08 apache2
13521 www-data  16   0 65772  10m 6516 R  2.3  0.3   0:00.07 apache2
13522 www-data  16   0 65772  10m 6516 R  2.6  0.3   0:00.08 apache2
13523 www-data  16   0 65772  10m 6516 R  2.3  0.3   0:00.07 apache2

top - 16:43:17 up  2:45,  2 users,  load average: 20.98, 12.32, 8.98
Tasks: 128 total,  23 running,  80 sleeping,   0 stopped,  25 zombie
 Cpu0 :  4.2% us,  1.5% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi, 94.3% si
 Cpu1 :  3.9% us,  1.5% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi, 94.5% si
Mem:   3344480k total,   219920k used,  3124560k free,    13608k buffers
Swap:   996008k total,        0k used,   996008k free,   104432k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
14376 www-data  16   0 70848  11m 6596 R  7.2  0.4   0:01.51 apache2
14306 www-data  16   0 65772  10m 6520 R  0.7  0.3   0:00.79 apache2
14335 www-data  15   0 65772  10m 6520 S  5.4  0.3   0:01.03 apache2
14363 www-data  15   0 65772  10m 6520 S  0.5  0.3   0:01.10 apache2
14374 www-data  16   0 65772  10m 6520 R  1.7  0.3   0:01.31 apache2
14380 www-data  15   0 65772  10m 6520 S  6.7  0.3   0:01.19 apache2

Zoals je hier ziet staan wordt er bijna een kwart van de cpu gebruikt voor softirq's. Bij de laatste listing zelfs bijna 100%. Ik heb helemaal geen cpu power over voor de andere dingen. Dit wordt namelijk allemaal opgebruikt. Ik krijg van ab2 (apache bench) door dat er van de 100.000 aanvragen 13.940 fout zijn gegaan (bijna 14%).

Ik heb geprobeerd of ik er achter kan komen waar het probleem ligt, en hieronder vind je een denk ik relevante output van procinfo:
Linux 2.6.12-1-amd64-k8-smp (buildd@athlon) (gcc 4.0.2 ) #1 SMP Wed Sep 28 02:57:49 CEST 2005 2CPU []

Memory:      Total        Used        Free      Shared     Buffers
Mem:       3344480      242564     3101916           0       15028
Swap:       996008           0      996008

Bootup: Mon Dec 19 13:58:10 2005    Load average: 23.58 14.96 10.59 28/147 15447

user  :       0:11:29.94   3.3%  page in :        0
nice  :       0:00:00.00   0.0%  page out:        0
system:       0:05:01.67   1.4%  swap in :        0
idle  :       5:04:41.59  88.7%  swap out:        0
uptime:       2:51:43.04         context :  5029758

irq  0:  10302138 timer                 irq  9:         0 acpi
irq  1:       265 i8042                 irq 10:         0 libata, ohci_hcd:usb
irq  2:         0 cascade [4]           irq 11:     83242 libata
irq  3:         7 serial                irq 12:   6847056 eth0, eth1
irq  4:         7 serial                irq 15:        11 ide1
irq  7:  17234719

Ik heb al de apic aangezet in grub, maar dit heeft ook niet geholpen. Hieronder tot slot nog mijn apache en mysql config files.
Timeout 120
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15
ServerLimit             2048
StartServers              20
MinSpareServers           32
MaxSpareServers           64
MaxClients              1024
MaxRequestsPerChild      100
ServerTokens Prod
ServerSignature Off
UseCanonicalName Off
HostnameLookups Off

[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0
[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
language        = /usr/share/mysql/english
skip-external-locking
bind-address            = 10.0.0.105
key_buffer              = 128M
max_allowed_packet      = 16M
thread_stack            = 128K
table_cache             = 512M
sort_buffer             = 15M
record_buffer           = 1M
query_cache_limit       = 1048576
query_cache_size        = 16777216
query_cache_type        = 1
wait_timeout            = 120
max_user_connections    = 4096
max_connections         = 4096
max_connect_errors      = 10000
log-slow-queries        = /var/log/mysql/mysql-slow.log
log-bin                 = /var/log/mysql/mysql-bin.log
max_binlog_size         = 104857600
skip-bdb
[mysqldump]
quick
quote-names
max_allowed_packet      = 16M
[mysql]
[isamchk]
key_buffer              = 16M


Ik ben met dit probleem nou zo'n week bezig geweest, en ik heb vanalles geprobeerd. Te veel om op te noemen, maar tot nu toe hebben weinig dingen geholpen.
Zijn er mensen die hun licht kunnen laten schijnen op mijn probleem?

It takes only a minute to get a crush on someone, an hour to like someone, and a day to love someone, but it takes a lifetime to forget someone.


  • rvm
  • Registratie: November 2000
  • Niet online

rvm

Kun je uit /proc/interrupts herleiden welke IRQ de boosdoener is (wat zit op IRQ7?).

In een newsgroup posting (zoek op /proc/sys/debug/0) vond ik onderstaande methode om te achterhalen wie de softIRQ's veroorzaakt, alleen heb ik geen /proc/sys/debug/0 op m'n debian systeem kunnen vinden:

code:
1
2
3
dmesg -c
echo 1 > /proc/sys/debug/0 ; sleep 1; echo 0 > /proc/sys/debug/0
dmesg -s 1000000 > /tmp/foo


Vervolgens zou in /tmp/foo de relevante info moeten staan.

Overigens zie ik zelf rond de 10% softIRQ's als ik ab2 met 100 concurrent requests (statische HTML pagina) loslaat op m'n eigen testservertje (apache 1.3, Debian Etch)

[ Voor 6% gewijzigd door rvm op 20-12-2005 11:02 ]


  • daft_dutch
  • Registratie: December 2003
  • Laatst online: 02-12-2025

daft_dutch

>.< >.< >.< >.<

volgens mij is apache2 het probleem
kijken naar het grote aantal zombies.
zombies zijn processen niet meer doen wat ze moeten doen.

in PS worden deze uitgedruk met de text "<defunct>"

herstart apache en kijk dan of het beter gaat
(natuurlijk is dit geen oplossing)


moet je echt apache2 hebben omdat apache1.3 veel stabiler is.

[ Voor 32% gewijzigd door daft_dutch op 20-12-2005 03:55 ]

>.< >.< >.< >.<


  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
Als je geen apache nodig hebt kan je ook eens kijken naar lighttpd, erg snel en stabiel.

  • Arnout
  • Registratie: December 2000
  • Laatst online: 05-02 22:41
Debian en performance trekken me allebei wel, daarom heb ik even wat research gedaan.

Het lijkt me dat dit gerelateerd is aan het vele netwerkverkeer.

1 page request levert een aantal netwerkacties op.
Connectie openen, query doorgeven, resultaat, en afsluiten.

si = software interrupts. Kijk eens naar je netwerkkaart en de module die je gebruikt. Wat voor netwerkkaart is het eigenlijk?
Het lijkt me dat de machine erg druk bezig is om netwerkverkeer af te handelen.

Ik krijg bij dit soort setups eigenlijk direct de neiging om een recente, custom kernel te bouwen.

[ Voor 8% gewijzigd door Arnout op 20-12-2005 14:29 ]