Newsgroup: it.comp.os.dibattiti
Titolo: quanto resiste windows senza reboot?

 in The New York Times.
Ma 'sto baco del win95 non era stato fissato? Non credo che per gestire un
aereoporto abbiano messo in produzione il 95.....

> prevent a data overload, a union official told the LA Times.
Boh, forse usano un'applicazione scritta in Deplhi e che usa Oracle come DB.
O forse MySQL. Senza una straccio di informazione aggiuntiva potrei pure
pernsare che usano
Windows 2000 + VMWare su cui gira una Fedora Core 2.

 aereoporto abbiano messo in produzione il 95.....
Parlano di "Windows servers brought in over the past three years", il 
che fa supporre Windows 2000.
Quanto all'overload che richiede(rebbe) uno shutdown ogni 30 giorni, ci 
puoi scommettere le gioie che è un problema del software che ci gira sopra.


Ipotesi... che sia il software di gestione che magari utilizza gettickcount, 
che dopo 49.7 giorni si resetta?
Devono proprio temporizzarsi sui millisecondi? :)
Saluti. 

 Ma 'sto baco del win95 non era stato fissato?
http://support.microsoft.com/default.aspx?scid=kb;en-us;823273
:
'A supported hotfix is now available from Microsoft, but it is only 
intended to correct the problem that is described in this article. Only 
apply it to systems that are experiencing this specific problem. This 
hotfix may receive additional testing. Therefore, if you are not 
severely affected by this problem, we recommend that you wait for the 
next Windows 2000 service pack that contains this hotfix.'
In pratica: 'speriamo di averlo aggiustato ma forse abbiamo rotto 
dell'altro, chi puo` dirlo'.
-- 
Vincenzo

 
http://support.microsoft.com/default.aspx?scid=kb;en-us;823273
:
Quello si riferisce ad un problema dello stesso genere, ma presente
su W2K, e anche su NT4 se con le patch 305399 e/o 297534:
The Rpcss.exe process consumes 60 percent of CPU time and
performance is affected.
Questo è quello del 95 e del 98 (patchato):
Computer Hangs After 49.7 Days
http://support.microsoft.com/support/kb/articles/q216/6/41.asp
Questo è di NT4 e 3.51, patchato, solo per NT4, dall'SP4:
SNMP SysUpTime Counter Resets After 49.7 Days
http://support.microsoft.com/default.aspx?scid=kb;EN-US;169847
Altri problemi dello stesso genere o correlati:
Print Spooler Stops Scheduling Print Jobs
http://support.microsoft.com/default.aspx?scid=kb;en-us;318152
 (W2K)
A large segment of time is lost when you use GetTickCount in a
custom program
http://support.microsoft.com/default.aspx?scid=kb;en-us;831408
 (NT4)
Ping -T stops responding after running for more than 49.7 days
http://support.microsoft.com/default.aspx?scid=kb;en-us;225024
 (NT4)
Windows 2000 Terminal Services Time-Out Setting Limits
http://support.microsoft.com/default.aspx?scid=kb;en-us;222995
 (W2K)
X-Duration Values Are Larger Than Expected in Windows Media
Server Log
http://support.microsoft.com/default.aspx?scid=kb;en-us;281659
 (media server)
Lo stesso problema, AFAIK, c'è in tutti i programmi che usano
l'API GetTickCounts, che lavora su una DWORD, e sempre AFAIK,
è uguale in tutti i S.O. della MS, compreso per esempio CE.
Bye, G.

 aereoporto abbiano messo in produzione il 95.....
La mia esperienza diretta su server 2000 me li fa riavviare causa 
manutenzione (ovvero smontaggio fisico e pulizia) ogni sei mesi. Per 
questo tempo girano tutti senza problemi, probabilmente "reggerebbero" 
anche d più.
-- 
Saluti
SuperLips

 su W2K, e anche su NT4
Si`, volevo dire che era plausibile che avessero un server Windows 2000.
-- 
Vincenzo

 Windows 2000 + VMWare su cui gira una Fedora Core 2.
però stranamente quel 49.7 giorni è esattamente lo stesso numero del
baco di win95 quando la variabile a 32 bit che gli teneva l'uptime andava
in overflow....
Per quanto si possa parlar male di utenti e sviluppatori M$, non oso
nemmeno pensare che nel software della torre di controllo questi usino
win95....
Però è strano....

 su W2K, e anche su NT4 se con le patch 305399 e/o 297534:
queste sono le cose che mettono paura di volare...

 anche d più.
Infatti. Prima delle ferie stavo spegnendo un 2000 server (oracle) da un 
cliente e ho osservato la durata della connessione della scheda di rete 
(nemmeno l'uptime, la connessione potrebbe essere meno perchè basta 
interromperla un attimo per resettare il count). Era più di un'anno. Non 
è stata resettata per problemi, non c'era nessun memory leak e le CPU 
erano normalmente occupate dai servizi di oracle.
Lo stesso cliente aveva un terminal server (sempre 2000) con cui faceva 
lavorare uno stabilimento remoto con 15 utenti, la maggior parte con un 
solo programma ma alcuni con un desktop remoto completo. Anche quello 
(che IMHO è più a rischio, sull'altro bene o male girano solo i processi 
di Oracle) era su da sei mesi abbondanti.
IMHO quando si parla di non far girare applicazioni mission critical su 
windows, mi concentrerei più su come sono scritte queste applicazioni e 
sui problemi di affidabilità che *loro* hanno, piuttosto che il sistema 
su cui girano. Si fa presto a dire che "windows ha bisogno di essere 
riavviato ogni 30 giorni" quando è proprio il programma critico che si 
impappina in quel periodo.

 in overflow....
Si, ma stranamente c'è una notevole casistica di server 2000 che sta su 
per semestri senza nessuno overflow. Mentre si può scrivere anche per 
unix un programma che (ad esempio) per una certa logica nel memorizzare 
una timetable dopo 49.7 giorni deve essere riavviato.
Poi ovviamente uno concluda quello che vuole.

 impappina in quel periodo.
Non me ne parlare neanche, il programma che ci gira sopra (un robo che 
parla con le seriali e scrive in un db SQL) viene riavviato 
"preventivamente" tutte le settimane.
-- 
Saluti
SuperLips

 win95....
Infatti... (brrrrrrrrrr).
Bye, G.

 "preventivamente" tutte le settimane.
Ti va bene...da me quei pazzi dei sistemisti certi server li spengono la
sera quanto escono e li riaccendono al mattino quando arrivano...
Raffaele

 impappina in quel periodo.
La questione è il "come reagisce il sistema" in caso di crash di una
applicazione. L'applicativo che usi è bacato è impappina windows? Certo,
c'è una falla nel software, ma bisogna anche chiedersi se il sistema
operativo potrebbe o meno gestire il crash in maniera diversa, evitando
magari di andare in crash lui stesso. Bisogna poi anche vedere se quel
software ha avuto la possibilità di fare qualcosa che invece l'OS avrebbe
dovuto impedire.
Definire un OS adatto ad impieghi "mission critical", significa
assicurarsi che lui stesso non vada in crash per i cazzi propri, ma anche
verificare che resista al crash degli applicativi che fa girare, o a
fallimenti hardware, totali o parziali, o ad intrusioni esterne.
Tra parentesi, l'ultima volta che ho guardato l'unico OS Microsoft
certificato mission critical era WinNT 4.0, mentre l'unico linux era Suse
8.0 (mi pare...) su server IBM i900.
Raffaele

 applicazione. 
Nel caso specifico, tanto per tagliare la testa al toro, non si parlava 
di crash. I 49.7 giorni non è un periodo casuale, è esattamente il 
numero di millisecondi che può essere contenuto in una DWORD. Esiste 
l'API GetTickCount che resituisce il tempo trascorso dall'avvio del 
sistema in una DWORD, è una funzione che viene regolarmente utilizzata 
per misurazioni relative di tempo. Inutile quindi ricordare che la 
funzione misura in un ciclo di 49.7 giorni e per evitare casini 
misurando periodi a cavallo della fine del ciclo naturalmente non basta 
fare una differenza fra due chiamate bensì occorre fare una operazione 
appena più complessa. E' altresì ovvio che *deve* esserci certezza che 
il periodo misurato è inferiore ai 49.7 giorni altrimenti questo metodo 
non può essere utilizzato.
In questo caso windows non c'entra nulla, il sistema non ha nessun 
problema e in prossimità dei fatidici 49.7 giorni di uptime gli unici 
crash sarebbero quelli degli aerei.
IMHO sono pronto a scommettere che la procedura di riavviare i server 
ogni 30 giorni è semplicemente per evitare di arrivare a questo limite, 
probabilmente l'avranno codificata come procedura di sicurezza.

 sera quanto escono e li riaccendono al mattino quando arrivano...
Risparmio energetico?
Però io non ce l'avevo coi sistemisti (brave persone), bensì con i 
programmatori....
-- 
Saluti
SuperLips

probabilmente l'avranno codificata come procedura di sicurezza.
Sono disposto a crederci solo se l'applicazione e' scritta in Visual Basic ;-P
Alessandro.

 una timetable dopo 49.7 giorni deve essere riavviato.
me ne citi uno o mi codi un esempio?

 me ne citi uno o mi codi un esempio?
Guarda cosa succede ai due poveri aerei che atterreranno dopo 36 minuti.
#include <time.h>
#include <stdio.h>
int main(void) {
	clock_t tstart, elapsed;
	int aereo;
	aereo = 0;
	do {
		aereo++;
		tstart = clock()/CLOCKS_PER_SEC;
		while( (elapsed = clock()/CLOCKS_PER_SEC) - tstart < 120);
		printf("[%d]: Sono passati 2 minuti dall'ultimo atterraggio:\n", elapsed);
		printf("L'aereo %d puo' atterrare!\n", aereo);
	} while(1);
	return 0;
}

 Guarda cosa succede ai due poveri aerei che atterreranno dopo 36 minuti.
brrr!!! ok, hai ragione... ma credo che con una gettimeofday le cose
funzionerebbero meglio.... :-)

 Poi ovviamente uno concluda quello che vuole.
Mah, una conclusione potrebbe essere che la cialtronaggine
e` selettiva del SO... :-)
bye,
-- 
   Piergiorgio Sartor

 sera quanto escono e li riaccendono al mattino quando arrivano...
Ah, beh, si vede che lo possono fare. Potendolo fare, perchè non 
risparmiare più di metà dell'energia elettrica consumata dai server?
Il problema sorge se una mattina ai sistemisti viene un cacone 
collettivo e non hanno previsto questa evenienza... ;-)

 funzionerebbero meglio.... :-)
Guardacaso è esattamente ciò che raccomanda Microsoft sull'uso di 
GetTickCount. Che coincidenza... :-)

 raffaele castagno wrote:


Il problema è che su quei server ci stavano i nostri ambienti di test e
sviluppo, e ogni volta che al mattino accendevano i server la cache delle
pagine jsp veniva resettata, e tutto doveva essere ricompialto, con
evidenti rallentamenti.
E poi l'uptime andava a farsi benedire...
Raffaele
-- 
Raffaele Castagno
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it