PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Load Average



DBGTMaster
05.10.08, 13:20
Hallo Leute,

ich betreibe eine HTTP Anwendung mit PHP, Postgresql, Lighttpd,...

Gestern waren zwar ziemlich viele Leute online, hatte aber auch mit einem Load Average von ~5.2 zu kämpfen.

Würde zwar nun meine Anwendung etwas optimieren, wüsste aber nicht, wie ich das genau anstellen sollte.

Gibt es irgendwelche Befehle:

1.) Welcher Prozess welchen Load Average verursacht?
2.) Worauf dieser Prozess zugreift (Datei,...), welcher diesen Load Average verurscht?

danke & mfg

derRichard
05.10.08, 14:25
hi!

die loadaverage hat nicht wirklich viel mit prozessen zu tun.
hast mal mit "top" nachgesehen welcher prozess viel cpu-zeit verbraucht?

//richard

DBGTMaster
05.10.08, 15:06
Hallo,

CPU Last war bei etwa 60% (php-cgi hatte die meinste CPU gebraucht).

Seit wann hast Load Average nichts mit CPU zu tun? Ich dachte, das wäre, wie lange die Prozesse schlafen würde bzw. umgekehrt...

derRichard
05.10.08, 15:11
hi!

ich wollte eigentlich sagen, dass eine hohe load nicht unbedingt was mit prozessen zu tun haben muss.
load kann auch vom kernel stammen...

du verwendest php als cgi?
das kann ja gar nicht schnell gehen.
hast du es mal mit fastcgi versucht? das sollte etwas schneller sein.

hth,
//richard

DBGTMaster
05.10.08, 15:25
Sorry, meinte natürlich fastcgi :).

Warum kann hohes Load vom "Kernel" stammen?

derRichard
05.10.08, 15:28
hi!

ja glaubst, dass routing, arbeit der treiber, etc... keine last macht? :-)

//richard

DBGTMaster
05.10.08, 17:00
hi!

ja glaubst, dass routing, arbeit der treiber, etc... keine last macht? :-)

//richard

OK, da könntest du auch wieder Recht haben :). Aber wie finde ich nun heraus, was für das hohe Load Average verantwortlich ist :o ?

MiGo
05.10.08, 18:46
Aber wie finde ich nun heraus, was für das hohe Load Average verantwortlich ist ?
Indem du mal die Ausgabe von "top" postest, wenn mal wieder Last ist?
(mit "top -n 1> Datei " kann man den Kram auch in eine Datei ausgeben)

DBGTMaster
05.10.08, 20:47
Derzeit zwar keine hohe Last, aber eine kleine :).


top - 20:43:38 up 117 days, 36 min, 1 user, load average: 0.57, 0.47, 0.51
Tasks: 106 total, 2 running, 103 sleeping, 0 stopped, 1 zombie
Cpu(s): 13.0%us, 4.1%sy, 0.0%ni, 81.8%id, 0.7%wa, 0.1%hi, 0.4%si, 0.0%st
Mem: 6083396k total, 3608708k used, 2474688k free, 282460k buffers
Swap: 2104504k total, 24k used, 2104480k free, 2819196k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19272 ftpuser 16 0 93044 19m 12m R 27 0.3 0:04.92 php5-cgi
19279 ftpuser 16 0 91672 12m 7632 S 19 0.2 0:00.89 php5-cgi
19273 postgres 15 0 198m 30m 27m S 6 0.5 0:01.37 postmaster
19288 postgres 16 0 196m 7800 5820 S 4 0.1 0:00.02 postmaster
1 root 15 0 6120 628 520 S 0 0.0 0:23.12 init
2 root RT 0 0 0 0 S 0 0.0 0:01.14 migration/0
3 root 34 19 0 0 0 S 0 0.0 0:00.10 ksoftirqd/0
4 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/0
5 root RT 0 0 0 0 S 0 0.0 0:01.81 migration/1
6 root 34 19 0 0 0 S 0 0.0 0:00.15 ksoftirqd/1
7 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/1
8 root 10 -5 0 0 0 S 0 0.0 0:00.41 events/0
9 root 10 -5 0 0 0 S 0 0.0 0:00.34 events/1
10 root 10 -5 0 0 0 S 0 0.0 0:00.00 khelper
11 root 10 -5 0 0 0 S 0 0.0 0:00.01 kthread
16 root 10 -5 0 0 0 S 0 0.0 2:39.86 kblockd/0
17 root 10 -5 0 0 0 S 0 0.0 1:00.37 kblockd/1
18 root 10 -5 0 0 0 S 0 0.0 0:00.00 kacpid
122 root 10 -5 0 0 0 S 0 0.0 0:00.00 khubd
124 root 10 -5 0 0 0 S 0 0.0 0:00.00 kseriod
178 root 10 -5 0 0 0 S 0 0.0 1:48.63 kswapd0
179 root 15 -5 0 0 0 S 0 0.0 0:00.00 aio/0
180 root 15 -5 0 0 0 S 0 0.0 0:00.00 aio/1
426 root 19 -5 0 0 0 S 0 0.0 0:00.00 xfslogd/0
427 root 10 -5 0 0 0 S 0 0.0 0:00.00 xfslogd/1
428 root 20 -5 0 0 0 S 0 0.0 0:00.00 xfsdatad/0
429 root 10 -5 0 0 0 S 0 0.0 0:00.00 xfsdatad/1
467 root 20 -5 0 0 0 S 0 0.0 0:00.00 ata/0
468 root 20 -5 0 0 0 S 0 0.0 0:00.00 ata/1
469 root 20 -5 0 0 0 S 0 0.0 0:00.00 ata_aux
499 root 10 -5 0 0 0 S 0 0.0 0:00.01 scsi_eh_0
500 root 10 -5 0 0 0 S 0 0.0 0:00.01 scsi_eh_1
501 root 10 -5 0 0 0 S 0 0.0 0:00.00 scsi_eh_2
502 root 10 -5 0 0 0 S 0 0.0 0:00.00 scsi_eh_3
1207 root 14 -5 0 0 0 S 0 0.0 0:00.00 kmirrord
1259 root 10 -5 0 0 0 S 0 0.0 27:58.72 kjournald
1445 root 16 -4 10592 700 324 S 0 0.0 0:00.08 udevd
1785 root 15 -5 0 0 0 S 0 0.0 0:00.00 kpsmoused
2444 root 15 0 3728 664 508 S 0 0.0 1:31.88 syslogd
2450 root 15 0 2660 396 308 S 0 0.0 0:00.00 klogd
2700 root 18 0 2656 592 484 S 0 0.0 0:00.00 acpid
2709 root 10 -5 0 0 0 S 0 0.0 0:00.46 kondemand/0
2710 root 12 -5 0 0 0 S 0 0.0 0:00.00 kondemand/1
2726 root 15 0 22400 14m 636 S 0 0.2 255:06.92 memcached
2817 root 15 0 25836 1256 800 S 0 0.0 1:28.57 sshd
2892 ntp 15 0 14076 1456 1052 S 0 0.0 0:09.26 ntpd
2906 root 15 0 11496 940 716 S 0 0.0 0:11.89 cron
2942 root 18 0 2656 540 452 S 0 0.0 0:00.05 getty
2943 root 19 0 2652 536 452 S 0 0.0 0:00.00 getty
2944 root 20 0 2652 536 452 S 0 0.0 0:00.00 getty
2945 root 21 0 2656 540 452 S 0 0.0 0:00.01 getty
2946 root 16 0 2656 540 452 S 0 0.0 0:00.01 getty
2947 root 16 0 2656 540 452 S 0 0.0 0:00.02 getty
3132 root 15 0 23556 15m 636 S 0 0.3 7:49.06 memcached2
3156 root 15 0 24564 16m 636 S 0 0.3 0:15.40 memcached3

Aber wenn ich so drüber nachdenke, glaube ich auch langsam, dass der Kernel dafür verantwortlich ist.

Die PHP Seiten wurden in etwa ~25ms. aufgebaut, wobei ich ein Load Average von 5.2 hatte.
TCP HTTP Anfragen gleichzeitig waren es geschätze ~150 Stück. Antwortzeiten waren aber trotzdem etwas länger, etwa 2-3 Sekunden teilweiße. Möglich, dass der Kernel die TCP Anfragen nicht mehr verwalten hat können und daher etwas länger mit den Antworten gebraucht hat?

Wenn ja, was könnte ich dagegen tun?

marce
06.10.08, 10:40
ich fürchte eher, Du hast ein Problem in der Webanwendung - ein CGI, das 27% CPU braucht - keine gute Idee.

DBGTMaster
06.10.08, 10:57
ich fürchte eher, Du hast ein Problem in der Webanwendung - ein CGI, das 27% CPU braucht - keine gute Idee.

Bei aber ~150 Zugriffe gleichzeitig wundert es mich wiederrum nicht :)

DBGTMaster
06.10.08, 11:12
Hab nun mal in der lighttpd Doku herumgestöbert :).

http://trac.lighttpd.net/trac/wiki/Docs%3APerformanceFastCGI#how-many-php-processes-do-i-need

Eventuell hilft das, werd ich mal probieren :)

marce
06.10.08, 11:46
Bei aber ~150 Zugriffe gleichzeitig wundert es mich wiederrum nicht :)
ich dachte, nun ist keine hohe Last - also wohl keine 150 parallelen Zugriffe. Und trotzdem 27%.

DBGTMaster
06.10.08, 13:57
ich dachte, nun ist keine hohe Last - also wohl keine 150 parallelen Zugriffe. Und trotzdem 27%.

Achso, ja ist korrekt. Die Anwendung werd ich sowieso noch in Zukunft optimieren müssen. In diesem moment waren aber wohl auch etwa 30 Zugriffe pro Sekunde.

Habe im lighttpd nun die server-stats aktiviert, liefert mir soetwas:


fastcgi.active-requests: 5
fastcgi.backend.localhost.0.connected: 2291
fastcgi.backend.localhost.0.died: 0
fastcgi.backend.localhost.0.disabled: 0
fastcgi.backend.localhost.0.load: 1
fastcgi.backend.localhost.0.overloaded: 0
fastcgi.backend.localhost.1.connected: 5789
fastcgi.backend.localhost.1.died: 0
fastcgi.backend.localhost.1.disabled: 0
fastcgi.backend.localhost.1.load: 1
fastcgi.backend.localhost.1.overloaded: 0
fastcgi.backend.localhost.2.connected: 16495
fastcgi.backend.localhost.2.died: 0
fastcgi.backend.localhost.2.disabled: 0
fastcgi.backend.localhost.2.load: 1
fastcgi.backend.localhost.2.overloaded: 0
fastcgi.backend.localhost.3.connected: 49779
fastcgi.backend.localhost.3.died: 0
fastcgi.backend.localhost.3.disabled: 0
fastcgi.backend.localhost.3.load: 2
fastcgi.backend.localhost.3.overloaded: 0
fastcgi.backend.localhost.load: 6
fastcgi.requests: 74354

Nun eine Verständnisfrage:
In diesem Moment sind ja 5 Requests und 4 php-cgi Prozesse. CGI Prozess #3 hat ja in diesen Moment 2 Anfragen. Werden diese Parallel oder nacheinander abgearbeitet?

Hätte ich beispielsweiße im Durchschnitt 6 Requests gleichzeitig, macht es Sinn, Anzahl der cgi Prozesse auf 6 zu erhöhen?

mfg