Uptime rekord?

Olvasva az angol és a magyar wikipédiát, teljesen más értékek vannak az Uptime rekordnál.
A Magyar-nál ez olvasható: "Az eddigi legnagyobb rekord 11 év, 303 nap, 20 óra és 57 perc, melyet egy olyan számítógép tart, melyen OpenVMS volt."
Az angol wiki cikknél pedig ez van: "In 2005, Novell reported a server with a 6 year uptime."

6 vagy 11 év.. Az azért nem mindegy. Van "egy kis" különbség a kettő közt.

Szóval most melyik a jó? Egyik se? Kíváncsi lennék rá, hogy mi a valós rekord.. Egyébként lehet valahol ilyen statisztikákat nézni, hogy ilyen-olyan gépekkel, illetve a különböző op rendszerekkel mennyi az uptime rekord?

( kisbetu v | 2010. 10. 02., szo – 17:40 )

A viki médiát hozzánk hasonló pancserek irkálják.
Pontos adatokat abban keresni ... khm ... dőreség.

( KoGa v | 2010. 10. 02., szo – 18:19 )

Mikor is fordul at a szamlalo Linuxon? Valami masfel evnel? :)


#741630 +(1061)- [X]

<matt____> hey guys is there a way to patch an older redhat server??
<matt____> Linux devcvs 2.2.16-22 #1 Tue Aug 22 16:49:06 EDT 2000 i686 unknown
<Evolution> holy hell
<Evolution> 2.2.16?
<Evolution> just out of curiosity, what's the uptime on that antique?
<matt____> devnu11:18am  up 2287 days,  2:52, 25 users,  load average: 1.76, 1.26, 0.70
<Zathrus> gods

--
Don't be an Ubuntard!

2.6-osnal mar nem fordul at, 2.4-esnel picivel tobb, mint 497 nap utan.

Van is egy Woody-s gepem, amelyiknel tapasztaltam is... orankent logoltam az uptime-t egy file-ba, igy nezett ki: 

 07:33:19 up 497 days, 41 min,  1 user,  load average: 0.00, 0.00, 0.00
 08:33:19 up 497 days,  1:41,  1 user,  load average: 0.00, 0.00, 0.00
 09:33:19 up 13 min,  2 users,  load average: 0.13, 0.04, 0.01
 10:33:20 up  1:13,  1 user,  load average: 0.00, 0.00, 0.00

:-)

( egeresz | 2010. 10. 02., szo – 18:23 )

oprendszer uptime != cluster uptime != szolgaltatas uptime

a VMS-nel gyakran beszelnek a cluster uptime-rol (kulon is szamitja a rendszer) es letezik is "rolling reboot" amikor is a clustert alkoto (minimum 3) gepet egymas utan rebootolod, hogy a cluster maga ne alljon le.

Ha egy oprendszer folyamatosan megy evek ota, de az alkalmazas potyog hetente, akkor (a ceg szempontjabol relevans) uptime csak heti. Viszont, ha az alkalmazas elvart valaszidejebe belefer egy oprendszer reboot (gyorsan bootolo beepitett celhardvernel ez lehetseges) akkor az alkalmazas uptime meghaladhatja az oprendszer uptimet.

Egyes mainframe gepeknel lehetseges hardvert cserelni, es oprendszert upgradelni az alkalmazas leallitasa nelkul.

Azthiszem, a nevezetes 11 eves VMS uptime az "cluster uptime"
Egyebkent minden tapasztaltabb rendszergazda tudja, hogy az elerheto oprendszer uptime erosen fugg a terhelestol. Nalunk, amikor a ludens.elte.hu (vms) nagyon massziv terheles alatt volt, akkor a 100 nap mar rendkivuli volt. Mig egy teszt/devel gep (ugyanaz az oprendszer) siman elketyegett ket elektromos karbantartas kozott (3 ev).

na ez az, jól beszélsz. szerintem az a 11 év amúgy már több (2006 óta fut) de az, hogy azon az uptime weboldalon mi van, nem a teljes kép..

én egy 6 évesről tudok, történetesen VMS cluster, és egy frontend MQ van rajta. volt egy négy éves as400 egy cégnél, nagyon örültek neki, hogy megy, pedig nagyon nem volt jó, hogy nem nyúltak hozzá..

én inkább sun-nal foglalkozom és sokszor hallom, hogy dicsérik cégeknél "ott azokat a régi lila gépeket", amikhez évek óta nem nyúlt senki, már a jelszót se tudják rá, de megy. ránézek és már tudom is, hogy semmi nem hiányzik oda jobban, mint egy komplett reinstall...

és ahogy mondod, ha egy PLC feladata az, hogy pl. ki-be kapcsolja a megfelelő szivattyúkat a megfelelő input paraméterek alapján, és ezt már 15 éve elvégzi, tökmind1, hányszor nem volt áram a területen, akkor annak a cuccnak az uptime-ja 15 év.

manapság commodity hardverre felteszel valami alaprendszert, és elrakod jó mélyre, nagy valószínűséggel évekig futni fog, ha csak OS uptime-ot akarsz. az alkalmazás más kérdés, de nem is elvárás az extrém uptime mint mutató, szerintem mindenhol csak egy bizonyos réteget kell ennyire nagy rendelkezésre állással futtatni (pl banki/üzleti alkalmazásban valamilyen mq interfész), mögötte a folyamatokat úgyis folyamatosan fejlesztik, ahhoz kell egy megfelelő és kiszámítható alapot adni.

"Nalunk, amikor a ludens.elte.hu (vms) nagyon massziv terheles alatt volt, akkor a 100 nap mar rendkivuli volt.": te indítottad újra vagy felborult magától?

nekem saját géppel 850 nap volt a rekord, pedig volt rajta terhelés. most van olyan gépem, ami 80-90Mbps-sel routol meg natol és 316 nap az uptime.

nem mbps függő, ha egy rendszert használnak, fejlesztenek rajta, telnek a logok, fogy a hely, belemegy a sok szemét, alkalmazásokat kell telepíteni és frissíteni, hibákat megoldani, IPC paramétereken állítani, új LUN-t kiajánlani, hamar rebootra kényszerülsz vagy érdemes megtenni, nyilván teszel is olyankor róla, hogy legközelebb jobb legyen.

ezekhez reboot?

volt már a kezemben fejlesztői szerver, akkor volt reboot, amikor előre közölték, hogy tartós áramszünet lesz.

egyébként meg ha szerencsésen választottál hardvert és kernel verziót, akkor valóban nem mbps függő, ha meg belenyúltál valami leakes kacatba, akkor sajnos az.

akkor beszéljük meg, hogy legközelebb segítesz ipc sysctl paramétert állítani menet közben linuxon, én meg megmondom tutira, mi nem lesz leak-es 90mbps-nél, és mindketten időt spóroltunk. ;)

"új LUN behúzás fos linuxon éles rendszer alatt: best practices" c. doksit is keresem már egy ideje

vannak bizonyos alkalmazások - elsősorban kereskedelmi termékek, adatbázisok-, amik rohadtul meg tudnak pusztulni IPC/shared memoryt illetően.

itt most elsősorban teszt/fejlesztői rendszerekről beszélek, élesben nem szoktak olyan nagy váratlan dolgok zajlani. de ezer olyan van, amit szívesebben tesz az ember tervezett leállással egybekötve. a "nem fos" linuxon hogy teszel be egy új targetről egy új LUN, de úgy, hogy nem romolhat el, elromlásnak számít az is, ha "csak" elmegy az I/O 2 percre, mert ha összedől tőle az adatbázis, akkor a végeredmény egy jóval hosszabb és fájdalmasabb recovery, mint ami eredetileg lett volna. ez tényleg érdekel, nem kötekedésként, hanem épp keresem erre a jó megoldást.

borult.

tcp/ip alapu borulas/fagyas 70% valami egyeb fatal bugcheck (beleertve a hw hibat is) 20%, felrenyultam 10%

most van egy webszerver, ami cpu/mem/ip forgalom tekinteteben minden eddigieket meghalad, megis atomstabil. Azt hiszem, a ludensen a rendkivul sokretu szolgaltatashalmaz az okozo.

vaxon, ahol meg kevesebb volt az eroforras, 50 nap is szepnek latszott. Mondjuk ott gyakran volt iranyitott reboot, hogy ne boruljon ;-)

( nanto | 2010. 10. 02., szo – 18:44 )

http://bash.org/?741630 ez egy tiszta OS uptime linuxrol

------------
A Windows 95 hibajabol tanulva inkabb Windows XP-nek nevezték el, hogy ne legyen ciki, hogy a legtöbb dologra 2008-ban még mindig a "Windows 2001" a leghasználhatóbb

( hajduarpad | 2010. 10. 02., szo – 23:36 )

Van egy kis gateway-ünk, ami jelenleg cirka 8,6 éve fut :) készülünk a 10 éves évfordulójára és reméljük senki sem rántja ki alóla a tápot/diszket. Igaz azon kívül, hogy átjáró semmi mást nem csinál max a java eszi meg az erősforrásait néha-néha :)

( kukukk v | 2010. 10. 07., cs – 11:01 )

Lehet hulye kerdes, de ha 2005-ben 6 eves uptime-ja volt, nem lehet, hogy az mostanra (2010-re) 11 evre nott? :}

Sic Transit Gloria Mundi