uptime mit jelent?

Linux-haladó

Mondjuk hogy ez egy haladó kérdés - nem tudtam hova tegyem.

Szóval van egy antik gép - P1 200 MHz MMX.
uptime (mióta fut) 5.x 5.x 5.x
Szerintetek ez most piszokul túl van terhelve?

Egyébként van benne két hálókártya, és négy soros port, és amolyan média konverter - csomag koncentrátor - szerepet tölt be.
Első NIC (100 Base) 64KBit/sec max. sebességű kommunikációt fogad, rövid
UDP csomagok formájában (bérelt vonal).

3 soros port 9600 Baud -on fogad ugyancsak rövid csomagokat, az adás
elenyésző.

4. soros port 38000 Baud -on kezel egy ipari GSM modult és SMS
fogadásra, küldésre van használva.

Második NIC mindezeket "áttemeli" a belső hálóra, multicastban, és a belső hálóról is ezen a multicast csatornán át.
Mindez persze szigorúan logolva, rotálva. Ez most akkor sok neki?

  • 2863 megtekintés

( pinyo_villany | 2008. 04. 23., sze – 17:19 )


 5.x           5.x            5.x
1min       5min       15min-es terhelés

szóval ha minden 5.x, akkor egy stabil tartós terhelés alatt van, a hw-t elnézve ez ideális szvsz

debian gnu/linux @ linux-2.6.22.22-opt1 | patch
info

Na ezért kérdeztelek benneteket. az ilyen és hasonló nagyon határozott és bölcs cikkekkel vagyok bajban. Most akkor az 5-5-5 azt jelenti hogy 5x gyorsabb proci kellene? Vagy esetleg inkább az FSB kevés? - túl sokat kell várni az I/O műveletekre - esetleg vegyek vissza a logok szószátyárságából?
Egyébként az egyik (a 64 Kbit -es csatorna, mindenféle egyéb infóval kibővített ASCII log -ja, több száz megabájtot produkál!?). Egy idő után a logrotate nem bírja követni (vagy nem tudom mi történik) és pár nap alatt termel egy Gigabyte log fájlt, mire a 2,4 Gigás hdd betelik!
Ha újra indítom a verklit, akkor egy ideig (1-2 hét) megint jól megy, aztán megint megzavarodik :( Érdekes jelenség (számomra) hogy miután purge -löm a log fájlt (hogy helyet csináljak):
#> log.fájl
a mérete nem változik!!! - pedig leűrül, mert vioszont a "df -h" azt mondja hogy visszanyertem a területet. Zavaros - csak arra tudok tippelni, hogy kevés a szufla :(
Olyan jelzéseket is kapok, hogy nem elég a reakció idő (UDP csomagra nem érkezik nyugta).
Szóval jó lenne több bizonyságot kapni!

* Én egy indián vagyok. Minden indián hazudik.

ha egy épp megnyitott file-t törölsz, az n em törlődik azonnal az fs-ről, addig amíg be nem zárad azt a programot, ami nyitva tartja. ha biztosan törölni akarod, akkor elötte zárd be a programot ami megnyitotta és csak utána töröld a filet.

debian gnu/linux @ linux-2.6.22.22-opt1 | patch
info

A #>log.fájl "trükköt" nem én találtam fel, valamelyik "Linux bevetés közben" számtalan jó tippje között találtam - "semmivel" tölti a fájlt, pontosan ugyanaz az eredmény mint mondjuk a #cat /dev/null > log.fájl csak jóval kevesebbet kell gépelni - ügyes, tetszik, működik. :)
Amúgy nem tudom hogy reagál egy egyébként "nyitott" fájl de mivel ezt már néztem pl. egy másik konzolon $tail -f log.fájl és ha ezt a parancsot kiadod akkot kiírja hogy "File was truncated" vagy valami ilyesmi - vagyis igenis kinullázza! De ha kiadod az "#ls -lha " parancsot a fájl mérete változatlan(?). Ellenben a "df -h" mutatja hogy a terület felszabadult. Szóval érdekes.

Bocs de az iostat, dstat az mi?

* Én egy indián vagyok. Minden indián hazudik.

Most majdnem szetnevettem magamat. Kepzeld el, hogy eppen scp-zed az "eletem_muve.iso"-t. Nyilvan, egyetlen masolat.
A masik terminalban pedig kiadod a rm -f eletem_muve.iso parancsot.

10%-nal jon a termeszeti katasztrofa s visz mindent magaval :D.

Ezt nem azert talaltak ki, hanem azert mert multi-user rendszeren ennek igy kene mukodni, nem ugy mint Windows-on, a regen becsukott es meg mindig nem torolheto file/folder.

( turul16 v | 2008. 04. 23., sze – 21:57 )

O_NONBLOCK -ot haznlasz sosors portoknal ?

( tovis v | 2008. 04. 23., sze – 22:01 )

Ez így azért még mindíg nem válasz.
Az hogy 1,2,3 vagy akár 4 processz vár nem biztos hogy gond. egyrészt mennyit várakozik? A gép simán könnyedén kezelhető - windows -ban simán lehet iolyan processzt faragni ami "dupla Nelson" -ba fogja a gépet (csináltunk már ilyet) alig kezelhető a gép, minden belassul. Itt ezt nem tapasztalom csak ilyen "kis" furcsaságok: Szóval nem érzem magam okosabbnak. Mindenestre megnézem mit mond az iostat meg a dstat bár nem is tudom (egyenlőre) mik ezek.

* Én egy indián vagyok. Minden indián hazudik.

Baj lessz :(
Nem tudom hogy tegyem föl a sysstat csomagot - Debian asszem Woody!
Nincs CD, csak floppy, internet kapcsolat sincs! - talán az utóbbit átmenetileg, de úgy hamis. Talán, ha floppy -ra tudnám kitenni a csomagot esetleg USB -re, de a Woody, van valakinek ilyen csomagja? Postolja valahogy el - plíííz.

* Én egy indián vagyok. Minden indián hazudik.

Load (uptime)

Megmutatja, hogy hany futasra kesz vagy futo folyamat van a rendszerben, atlagosan az atott ido intervallumban.
http://en.wikipedia.org/wiki/System_load

Az i/o -ra varakozo folyamtok alvok (S), ezeket nem szamolja hozza.

Ha a programjaid ugy vannak megirva, hogy egy vegtelen ciklusban kerdezed le (TIOCOUTQ), vagy olvasod ki (read) O_NONBLOCK i/o-val (ami rogton visszater, ha nincs adat) akkor sokat lesz, running vagy futasra kesz.

Nem tudom mi az a "TIOCOUTQ".
A programjaim egy-egy select -ben keringenek - várnak a beeső csomagokra, az adott interface -en keresztül (soros és socket) illetve figyelik az stdin -t. Viszont a logolás - nagyon primitíven - szinkron irogatják az stdout és stderr fájlokat - nagyon szószátyár módon, minden be és kimenet illetve hibaüzenetek.
Ez a kütyü tulajdonképpen orrán-száján kommunikál - de ha asebességeket nézem, nem kellene nagyon megizzadnia. Arra gondolok még, hogy az összes interface nagyonsokat logol, lemezre esetleg, átmenetileg ezeket (vagy csak a legtermékenyebbiket - kiugróan sok - átirányitani a /dev/null csendes nihiljébe). Azonban amíg nem tudok valami megbízható módot annak a mérésére, hogy most akkor mi van addig nem látom sok értelmét a beavatkozásnak, hiszen nem tudok meggyőződni arról, hogy használt :(
Emiatt próbálok valami kézelfogható információt szerezni a gépben uralkodó állapotokról.

* Én egy indián vagyok. Minden indián hazudik.