FreeBSD 6.4(mostmar 7.1) performance problémák

FreeBSD-all

Üdv mindenkinek!

Napok óta bosszant egy igen-igen kellemetlen dolog, mégpedig az hogy a fennt említett php képtelen arra hogy normálisan fusson az általam telepített gépen.
A gép maga egy HP DL380-g3, a következő procikkal:
CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3047.06-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf29 Stepping = 9
Logical CPUs per core: 2

SMP kernelben, felismeri szépen a 2 CPU-t, apache a statikus dolgok kiszolgálásánál hasít, aztán jött a nagy pofáraesés a php által generált dolgoknál. Elsőre az apache-ra gyanakodtam, de konzolbol futtatva az oldalt szintén igen csúnya volt a lefutási ideje (Egy gyengébb linuxos gépen, 400ms környékén futott le, itt 1.4 - 2sec). Következő a telepített sql szerver volt a gyanú középpontjában (ugyanis ez egy másik gépen, gigabit nic, patch kábellel összekötve), de a for ciklusba rakott sql lekérdezés a nagy forgalom gyártáson kívül semmivel nem juttatott előre(hip-hop lefutott), a referencia géphez képest dupla olyan gyors is volt. Maradt a PHP, modulok kicsupaszítása, gcc flagekkel való játszadozás, hátha valamit segít, de látványos eredményt nem értem el. Van valakinek valamilyen ötlete/javaslata, hogy legalább milyen irányba induljak el?

  • 1505 megtekintés

( Mcsivaat | 2009. 01. 20., k – 09:03 )

Feltűnt még egy érdekes dolog ezzel kapcsolatban, szedtem új php-t, ám már a tar.gz szétmarcangolása is írdatlan lassú. Leteszteltem egy másik, szintén 6.4-es FreeBSD-n ugyanezt a műveletet:
----
2500+ Athlon, mindenféle sallang nélkül, pata diskel:
# time tar xvzf php-5.1.4.tar.gz
0.980u 1.260s 0:14.48 15.4% 61+416k 210+20413io 4pf+0w
----
Dual xeon gép, már már lassan teljesen kibelezve:
# time tar xvzf php-5.1.4.tar.gz
0.668u 1.234s 1:58.47 1.5% 65+443k 0+19205io 0pf+0w

A vicc kedvéért ugyanez a művelet /dev/null -ba
# time tar xvzf php-5.1.4.tar.gz -O > /dev/null
0.412u 0.096s 0:03.62 13.8% 60+357k 0+0io 0pf+0w
Szemet gyönyörködtető különbség, lássuk ugyanezt a folyamatot fileba írva:
# time tar xvzf php-5.1.4.tar.gz -O > ./asdasd
0.494u 0.224s 0:06.21 11.4% 64+384k 0+324io 0pf+0w

Mind a tesztgépen, mind az említett szerveren ufs van (hogy miért, arról nem ejtenék szót).
Senkinél semmi ötlet?:\

( andrej_ v | 2009. 01. 20., k – 09:24 )

Ez nem egy hájperszredinges vas véletlenül? Azon ne eröltesd az SMP kernelt, mert a HT-re nem úgy kell ütemezni, mint két magra vagy két külön cpu-ra. Ez az UFS mikori UFS? A Softupdates be van kapcsolva? (Ha télleg két cpu van benne, akkor a biosban disable HT.)

biosban nem talaltam HT-re utalo nyomokat, igaz a szerverek jottek hozzam, voltak nalam kb fel orat mig ragyogyitottam a BSD-t, aztan mar ment is a hostingba, idohiany miatt. Rendesen korbe-korbe jartam a googlen, az esetek 90%-ban mindenki smp kernelt hasznalt, viszont ilyen teljesitmeny beli visszaesesre nem panaszkodott senki. Elmeletileg jonak kene lennie mindennek, es megsem.

Igen az elmélet az ilyen, nagyon könnyű belátni és leírni hogy elméletben mindenjó. :) A prolianteken van LOM és ha ügyes voltál akkor van hozzá madzagod és licenszed és remote újra tudod indítani úgy hogy tudsz fullosan kotorászni a biosban. A CPU settingsnél kell lennie elvileg. A BSD egyébként most összesen hány cpu-t lát?

mind a kettőt látja. a biost már szerintem sajnos nem fogom elérni egykönnyen (hosszú hosszú utazás kéne hozzá), de még azért így is csúnya dolognak tartom, hogy a lassan 6 éves barton, 20x veri oda sebességben. Valami ötlet arra hogy hogyan tudnám bevallásra bírni a gépet, hogy hova szökik a fennmaradó teljesítmény?
---szerk----
De nem feltetlen a proci korul keresnem a hibat, mert erdekes modon a tar lassu normalisan hasznalva, viszont /dev/null -ba, fileba iranyitva porog.

A HT az IO műveleteknek tud adni egy kisebb pofont. Egyébként az a netburst-os xeon nem volt egy sebességbajnok. A xeonok a melléjük pakolt platformmal hasítottak, de az opteronok megjelenése nem kis pofont adott nekik. :)

Mindkét proci: Melyik kettőt? Mert ha a HT be van kapcsolva akkor is két cpu-t lát, de ha mindkét fizikai benne van és a ht is be van kapcsolva akkor négyet kell látnia. A proliantekhez van hpasmd nevű cucc és elvileg ha guglizol a "hpasm freebsd" -re akkor meg is találhatod.

A diszkek körül minden rendben van? Mert pl. ha szinkronban sikerült mountolni a filerendszert vagy az egyik diszk egy raid1-ben meghalt az is okozhat hasonlót.

sikerült életet lehelnem ebbe a hpasm cuccba
show server:
ystem : ProLiant DL380 G3
Serial No. : 803TMV3R3W
ROM version : P29 09/15/2004
iLo present : Yes

Processor: 0
Name : Intel Xeon
Stepping : 9
Speed : 3066 MHz
Bus : 533 MHz
Socket : 2
Level2 Cache : 512 KBytes
Status : Ok
Proc 2 ugyanaz
hpasmcli> show ht
Processor hyper-threading is currently disabled.
Akkor bekapcsolom a ht-t valahogy a rendszeren keresztül, SMP-t hagyjam bennt, vagy álljak vissza generic kernelre a biztonság kedvéért?

Egy nem-HP, de a g3-ashoz hasonló korú vason 2x2,4GHz-es procival FreeBSD 6.3-al: 

time tar -zxf php-5.2.8.tar.gz 
0.798u 0.813s 0:14.28 11.2%	62+389k 570+190io 2pf+0w

Egy X2100-on, még az első széria, Dual Core (2,2GHz asszemhogy) opteronnal: 

time tar -zxf php-5.2.8.tar.gz
0.449u 0.535s 0:03.68 26.3%	79+448k 10+257io 0pf+0w

Az első vasban egy 2db 10kRPM-es raptor vinyón, amik sima gmirrorban vannak, futott a cucc. A másodiknál pedig szintén WD vinyók vannak, RE2-es 320GB-os verziók konkrétan és szintén gmirror. Az első gépben még van egy 3ware hwraid-es cucc is (RAID5), de annak az eredményét inkább nem írom ide, mert elég pocsék (szerintem a BBC modul hiánya miatt) és szal 2 perc felett volt kicsivel. :P

Ha csak nincs szénné terhelve a vasad, akkor mindenképp a diszkek körül nézelődnék, pl. hogy a SCSI tényleg syncelt-e 160MB-on vagy valamiért 40-en zakatol az egyik vinyó. Ha a RAID level RAID5, akkor simán lehet hogy a diszk irás lassúságot a BBC hiánya miatti write cache hiány okozza, mert ilyenkor full szinkronban működik.

hpacucli még nem megy, mert még Undefined symbol-al elszál, de reszelem.
Viszont másolás gyors, grep file outba gyors, devnull-ba is gyors
domus# diskinfo -t /dev/da0s1
Seek times:
Full stroke: 250 iter in 1.135873 sec = 4.543 msec
Half stroke: 250 iter in 1.090216 sec = 4.361 msec
Quarter stroke: 500 iter in 2.994673 sec = 5.989 msec
Short forward: 400 iter in 1.230212 sec = 3.076 msec
Short backward: 400 iter in 1.592944 sec = 3.982 msec
Seq outer: 2048 iter in 0.356638 sec = 0.174 msec
Seq inner: 2048 iter in 0.354043 sec = 0.173 msec
Transfer rates:
outside: 102400 kbytes in 1.567910 sec = 65310 kbytes/sec
middle: 102400 kbytes in 1.831442 sec = 55912 kbytes/sec
inside: 102400 kbytes in 3.978799 sec = 25736 kbytes/sec

Ez szintén meggyőző szerintem, egyszerűen nem értem hol lehet a hiba
Ja, az össz terhelést én csinálom, nem fut rajta jelenleg semmi

( zsirmo v | 2009. 01. 20., k – 12:40 )

Nem akarok hulyeseget mondani, de nekem ugy remlik, hogy ha HT-s a proci ha nem, a HT-t nem hasznalja a FreeBSD csak a 7-es verziotol!

( Mcsivaat | 2009. 01. 21., sze – 13:24 )

Felajánlásra kerül egy rekesz sör annak aki hozzájárul hogy menjenek ezek a vackok;]