magas system in es cs ertekek

[Kosa Attila]

Hello!
# uptime
08:54:56 up 41 days, 17:11, 2 users, load average: 1.00, 1.00, 1.00

Az erdekes a stabil 1-es load. A gep gyakorlatilag nem csinal
semmit, egy HA-ban a melegtartalek. A top szerint (0.3-re allitva
a frissitesi idot lathato) a system 0 es 3.3% kozott ugral
(mikozben az idle 100 es 96.7% kozott), de neha felugrik 6.7%-ra
(durvan 3 masodpercenkent). A vmstat meg erdekesebb:

# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 188424 193516 329780 0 0 0 5 1 8 0 2 98 0
0 0 0 188424 193516 329780 0 0 0 0 2193 210 0 2 98 0
0 0 0 188424 193516 329780 0 0 0 0 2216 216 0 1 99 0
0 0 0 188424 193516 329780 0 0 0 0 2211 212 0 3 97 0
0 0 0 188424 193516 329780 0 0 0 0 2216 213 0 1 99 0

A system in es cs ertekek 10-20-szor akkorak, mint a HA terheles
alatt levo gepen. Hogyan lehetne megtalalni, hogy mi okozza a
problemat?

# hpacucli controller slot=0 physicaldrive all show


Smart Array 5i in Slot 0

array A
physicaldrive 2:0 (port 2:id 0 , Parallel SCSI, 36.4 GB, OK)
physicaldrive 2:1 (port 2:id 1 , Parallel SCSI, 36.4 GB, OK)

A kernel 2.4.32. A HA ket gepe teljesen egyforma hardveresen, a
szoftververziok es a kernel is ugyanaz rajtuk. A masik gepen
viszont nem eri el a load az 1-et sosem (pedig az van uzemben). A
logokban nincs semmi, ami barmilyen problemara utalna. Nincs
megosztott diszk a HA 2 gepe kozott.

[KORN Andras]

Post by Kosa Attila
Hello!
# uptime
08:54:56 up 41 days, 17:11, 2 users, load average: 1.00, 1.00, 1.00
Az erdekes a stabil 1-es load. A gep gyakorlatilag nem csinal
semmit, egy HA-ban a melegtartalek. A top szerint (0.3-re allitva
a frissitesi idot lathato) a system 0 es 3.3% kozott ugral
(mikozben az idle 100 es 96.7% kozott), de neha felugrik 6.7%-ra

Van olyan processzed, ami nem S allapotu (hanem mondjuk D)?

Guy

[Kosa Attila]

Post by KORN Andras

Post by Kosa Attila
Az erdekes a stabil 1-es load. A gep gyakorlatilag nem csinal
semmit, egy HA-ban a melegtartalek. A top szerint (0.3-re allitva
a frissitesi idot lathato) a system 0 es 3.3% kozott ugral
(mikozben az idle 100 es 96.7% kozott), de neha felugrik 6.7%-ra

Van olyan processzed, ami nem S allapotu (hanem mondjuk D)?

S, SN, Ss, SLs, SL, Ss+, R+ - csak ilyen allapotu processzek vannak.

[Pallai Roland]

Post by Kosa Attila
Az erdekes a stabil 1-es load. A gep gyakorlatilag nem csinal
semmit, egy HA-ban a melegtartalek. A top szerint (0.3-re allitva
a frissitesi idot lathato) a system 0 es 3.3% kozott ugral
(mikozben az idle 100 es 96.7% kozott), de neha felugrik 6.7%-ra

ez a konstans 1.00 -as load D processz nelkul es ~95% -os allando
idlevel kisse bizarr. a kernel maga is ugy meri a load -ot hogy 5
(LOAD_FREQ) masodpercenkent vegigmegy a processzlistan es osszeszamolja
a D es R allapotu processzeket, tehat akar userspace -bol is ugyanugy
merheto lenne, nincs benne varazslat. azonban egy 5mp -nkent aktivalt
processz okozhat ilyen anomaliat, ha mindig akkor lep R statuszba mikor
a kernel epp futja a load-mero koret. a load csak becsles, nem ekzakt
meroszam

Post by Kosa Attila
# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 188424 193516 329780 0 0 0 5 1 8 0 2 98 0
0 0 0 188424 193516 329780 0 0 0 0 2193 210 0 2 98 0
0 0 0 188424 193516 329780 0 0 0 0 2216 216 0 1 99 0
0 0 0 188424 193516 329780 0 0 0 0 2211 212 0 3 97 0
0 0 0 188424 193516 329780 0 0 0 0 2216 213 0 1 99 0
A system in es cs ertekek 10-20-szor akkorak, mint a HA terheles
alatt levo gepen. Hogyan lehetne megtalalni, hogy mi okozza a
problemat?

mivel page IO nincs, szerintem a halozati kartya generalja a forgalmat,
a /proc/interrupts -ban ennek utana tudsz nezni, ha tenyleg az, akkor
tcpdump. ez magyarazhatja a magasabb cs -t is


--
dap

[Kosa Attila]

Post by Pallai Roland

Post by Kosa Attila
Az erdekes a stabil 1-es load. A gep gyakorlatilag nem csinal
semmit, egy HA-ban a melegtartalek. A top szerint (0.3-re allitva
a frissitesi idot lathato) a system 0 es 3.3% kozott ugral
(mikozben az idle 100 es 96.7% kozott), de neha felugrik 6.7%-ra

ez a konstans 1.00 -as load D processz nelkul es ~95% -os allando
idlevel kisse bizarr. a kernel maga is ugy meri a load -ot hogy 5

Ez zavar engem is...

Post by Pallai Roland
processz okozhat ilyen anomaliat, ha mindig akkor lep R statuszba mikor
a kernel epp futja a load-mero koret. a load csak becsles, nem ekzakt
meroszam

Viszont ugy tunik, mintha a szokasosnal lassabban reagalna a
billentyuzetre is, mint a "parja". Nem veszes, de lassabb.

Post by Pallai Roland

Post by Kosa Attila
# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 188424 193516 329780 0 0 0 5 1 8 0 2 98 0
0 0 0 188424 193516 329780 0 0 0 0 2193 210 0 2 98 0
0 0 0 188424 193516 329780 0 0 0 0 2216 216 0 1 99 0
0 0 0 188424 193516 329780 0 0 0 0 2211 212 0 3 97 0
0 0 0 188424 193516 329780 0 0 0 0 2216 213 0 1 99 0
A system in es cs ertekek 10-20-szor akkorak, mint a HA terheles
alatt levo gepen. Hogyan lehetne megtalalni, hogy mi okozza a
problemat?

mivel page IO nincs, szerintem a halozati kartya generalja a forgalmat,
a /proc/interrupts -ban ennek utana tudsz nezni, ha tenyleg az, akkor
tcpdump. ez magyarazhatja a magasabb cs -t is

Koszi az otletet!

Every 1.0s: cat /proc/interrupts Thu Dec 14 13:54:16 2006

CPU0
0: 362223762 XT-PIC timer
1: 377 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 2657612002 XT-PIC serial
5: 11727287 XT-PIC eth0
8: 4 XT-PIC rtc
10: 309304551 XT-PIC eth1, eth3, eth5
11: 1860425 XT-PIC cciss0
15: 301817145 XT-PIC eth2, eth4
NMI: 0
ERR: 6048634

Every 1.0s: cat /proc/interrupts Thu Dec 14 13:55:16 2006

CPU0
0: 362229822 XT-PIC timer
1: 377 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 2657728238 XT-PIC serial
5: 11727338 XT-PIC eth0
8: 4 XT-PIC rtc
10: 309309704 XT-PIC eth1, eth3, eth5
11: 1860588 XT-PIC cciss0
15: 301822184 XT-PIC eth2, eth4
NMI: 0
ERR: 6048676

A tcpdump azt mutatja, hogy mindossze a ket gepet osszekoto
kartyan van forgalom (a heartbeat forgalmaz).

A masik gepen ugyanez igy nez ki:

Every 1.0s: cat /proc/interrupts Thu Dec 14 14:02:15 2006

CPU0
0: 362322279 XT-PIC timer
1: 689 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 1 XT-PIC serial
5: 105716219 XT-PIC eth0
8: 4 XT-PIC rtc
10: 355102445 XT-PIC eth1, eth3, eth5
11: 10447872 XT-PIC cciss0
15: 397458134 XT-PIC eth2, eth4
NMI: 0
ERR: 28313170

Every 1.0s: cat /proc/interrupts Thu Dec 14 14:03:15 2006

CPU0
0: 362328346 XT-PIC timer
1: 689 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 1 XT-PIC serial
5: 105723310 XT-PIC eth0
8: 4 XT-PIC rtc
10: 355107613 XT-PIC eth1, eth3, eth5
11: 10448236 XT-PIC cciss0
15: 397466805 XT-PIC eth2, eth4
NMI: 0
ERR: 28314816

Ez alapjan ugy tunik, mintha a soros portnak lenne valami baja
(azt is hasznalja a heartbeat). Jott is uzenet a logba a HA aktiv
tagjatol, hogy nem tudja irni a ttyS0-t. De a masik gepen nincs
errol semmi a logban...

[Kosa Attila]

Post by Kosa Attila
Ez alapjan ugy tunik, mintha a soros portnak lenne valami baja
(azt is hasznalja a heartbeat). Jott is uzenet a logba a HA aktiv
tagjatol, hogy nem tudja irni a ttyS0-t. De a masik gepen nincs
errol semmi a logban...

Egyelore kivettem a heartbeat-bol a soros portot, azonnal
elkezdett csokkenni a load... Koszi az interrupts otletet!

[Nagy Gabor Peter]

Post by Kosa Attila
Ez alapjan ugy tunik, mintha a soros portnak lenne valami baja
(azt is hasznalja a heartbeat). Jott is uzenet a logba a HA aktiv
tagjatol, hogy nem tudja irni a ttyS0-t. De a masik gepen nincs
errol semmi a logban...

Nekem egyszer az tortent, hogy egy gep baromi lassu volt, es kiderult,
hogy a soros portra (konzolra) firkalt a gep, es a soros port sebessege
(9600 volt) nem volt eleg gyors, igy gyakorlatilag a kernel folyton
varakozott.

Mondjuk arra nem emlekszem, hogy hogy alakult a load, meg a
prociterheles, mert jopar eve volt.

Csak gondoltam, hatha neked is az van, hogy tul sokat forgalmazna a
soroson, de az tul lassura van allitva.

G