Il riavvio del server in una pianificazione sarebbe una buona idea per le prestazioni?

Mi chiedo se riavviare un server in un programma sarebbe una buona idea per le prestazioni.

Supponiamo di voler riavviare il server alle 02:00 ogni 2 notti.

Il server qui è Windows Server 2008 R2. Principalmente, SQL Server e IIS 7.5 (quasi 15 app in esecuzione) sono in esecuzione su questo server. Il server ha 4 GB di memoria.

Anche se sarei d'accordo sul fatto che non c'è nulla di sbagliato nel riavviare la scatola, di per sé, in base al tuo commento che l'agente SQL Server si sta arrestando, consiglierei alcune analisi aggiuntive della causa principale. I servizi in genere non si fermano e i servizi di SQL Server Agent non hanno agito in questo modo nella mia esperienza, in genere.

Penso che faresti bene, oltre al riavvio, per esaminare i log degli eventi ed eseguire un log dei contatori delle prestazioni a lungo termine che puoi analizzare con Performance Analysis of Logs (PAL) per vedere se "vede" qualcosa di sbagliato. Dovresti provare, se non altro, a correlare gli eventi associati all'agente SQL che si interrompe con altri fattori.

Se stai cercando di riavviare il computer per migliorare le prestazioni, probabilmente significa che alla fine stai riscontrando problemi di gestione della memoria.

La memorizzazione nella cache è buona

Semmai, il riavvio dei server danneggerebbe le prestazioni (e ovviamente il tempo di attività) in un ambiente più ideale . Uno dei fondamenti delle prestazioni nell'informatica è sfruttare la memorizzazione nella cache (con dati disponibili in memoria veloce). Ogni volta che si riavvia, si scarica la cache. Questo vale sia per SQL Server che per IIS. Anche se potresti non avere l'ambiente ideale, ciò che segue dovrebbe aiutarti a scegliere un'opzione migliore rispetto al riavvio del server in base a una pianificazione.

Perdite di memoria IIS?

Ora hai detto che si tratta di IIS 7.5. Anche se lo trovo deprimente, così tante app Web in esecuzione su IIS 7.5 presentano perdite di memoria che l'impostazione predefinita in IIS consiste nel riavviare l'APP ogni X minuti e spegnerla se un pool di APP è inattivo. L'ideale è correggere le perdite di memoria, ma se non è possibile è possibile regolare queste impostazioni che includono limiti di memoria e timer. Puoi usare perfmon per capire quale processo di w3wp sta usando la memoria. È un po 'una seccatura ma puoi ricollegarlo al pool di app %systemroot%\system32\inetsrv\APPCMD list wps.

Memoria SQL

Tornando alla cache, SQL prenderà tutta la memoria che può. È possibile limitare questo nelle proprietà per il server SQL. Se non limiti la memoria e stai anche eseguendo IIS sulla scatola, questi possono iniziare a combattere per le prestazioni di uccisione della memoria. Questo eccellente articolo approfondisce questo aspetto : una guida di Sysadmin alla memoria di Microsoft SQL .

Equilibrio

Dal momento che hai entrambi IIS e SQL nella stessa scatola, dovrai bilanciare il loro utilizzo della memoria. In caso contrario, potresti ottenere memoria che probabilmente verrà riutilizzata scambiata su disco, il che è un posto terribile (ci dovrebbero essere contatori perfmon per l'attività di scambio). Utilizzando le impostazioni di riciclo IIS e i limiti di memoria SQL, si dovrebbe essere in grado di rendere stabile questo sistema. Per bilanciare ciò potresti aver bisogno di più memoria di 4 GB. Inoltre, se è un'opzione, consiglio vivamente di mettere il server SQL su una macchina dedicata: migliorerà le prestazioni e semplificherà notevolmente le cose.

Non sono un sostenitore del riavvio dei server in base a una pianificazione, soprattutto non come mezzo per risolvere alcuni problemi sottostanti. Se è necessario riavviare questo server per risolvere un problema di prestazioni, la soluzione migliore è quella di trovare la causa del problema e risolverlo. Il riavvio del server su una pianificazione regolare sta solo offuscando il problema sottostante.

Se hai perdite significative di memoria, sicuramente, perché no, altrimenti riavvia mensilmente con gli aggiornamenti.

Se si desidera davvero riavviare il server in base a una pianificazione (a causa delle perdite di memoria o degli aggiornamenti sopra menzionati o di qualsiasi altro motivo), perché non guardare una soluzione di cluster? Installa un altro server in parallelo, collegali a un bilanciamento del carico (anche uno semplice farebbe) e puoi riavviarli quanto vuoi senza perdere il tempo di attività del servizio o preoccuparti che il server non si avvierà affatto e sarai fuori.

Non è un'idea orrenda , ma se è solo un "voodoo", probabilmente non ti aiuterà molto.

Tuttavia, ci sono due motivi per non lasciare che questa sia la fine della tua indagine sul miglioramento delle tue prestazioni.

Uno è la futura scalabilità. Se le interruzioni sono il risultato di un carico, di un certo numero di query, di una query specifica che colpisce una cache, compilazione di query o bug di indicizzazione btree o altri problemi che si verificano attualmente su base giornaliera, probabilmente si verificheranno più frequentemente durante il caricamento aumenta nel tempo. Stroncalo sul nascere.

L'altro problema è che sospetto che dovrai interrompere le richieste in arrivo dai servizi dipendenti durante il riavvio. Hai appena creato una cadenza operativa. Ogni volta che è necessario eseguire alcune attività quotidiane, questa verrà legata al riavvio. Ad un certo punto, avrai questi enormi riavvii che durano sei ore (non sto esagerando qui, l'ho visto accadere in più di una società) e nessuno ricorderà perché tutto deve essere fermato e riavviato nel mezzo della notte.

La mia raccomandazione sarebbe quella di monitorare il processo SQL e riavviare secondo necessità. Come accennato da un precedente poster, SQL non ha la perdita di memoria che la gente pensa di sì (e lo dico come persona che faceva parte del team MSSQL a metà degli anni '90). Si desidera che il server di database da utilizzare quasi il 100% memoria e CPU. Qualsiasi cosa in meno sta sprecando risorse.

Se il codice è scritto male e le perdite di memoria, il riavvio potrebbe essere l'unico modo per restituire la memoria allocata al pool. Se hai processi associati alla memoria, questo aggiornamento del pool su uno stato pulito può sicuramente migliorare le prestazioni .... per un po '. Ma questo è davvero un brutto modo di gestire i problemi di prestazioni, la causa reale dovrebbe essere inchiodata e risolta.

Altrimenti, lasciarlo funzionare fino a quando non è necessaria una finestra di manutenzione per applicare patch / applicazioni / ripristinare i dati. Questo potrebbe essere un buon momento per suggerire a un tecnico delle prestazioni di dare un'occhiata ai server in questione per capire esattamente perché / quali problemi lo convincono.

Pur non essendo una risposta completa di per sé , ma è un'opzione praticabile aggiungere un po 'più di RAM al server? 4 GB è un po 'basso per un computer IIS / SQL Server. A seconda che si tratti di un'unità server realmente dedicata o di un desktop messo in servizio, potresti ottenere 8 GB o più a un costo abbastanza basso. Certo, se si tratta di un server potrebbe costare un po 'di più rispetto alla RAM desktop standard ma ti darebbe un po' più di tempo tra i riavvii forzati.

Detto questo, vedi se riesci a limitare SQL Server all'utilizzo di un massimo dell'80% della RAM, oppure controlla i log per capire esattamente cosa non va e / o perché il servizio si sta arrestando.

Non correlato al problema SQL che potresti avere a che fare se disponi di server Windows e stai seguendo qualsiasi tipo di routine di patch, riavvierai i server su base regolare senza dover riavviare "solo perché". Quando ho lavorato per "BIG MULTINATIONAL", ci è stato richiesto di patchare mensilmente e come tale tutti i nostri server sono stati riavviati su base mensile almeno una volta.

Lo sto facendo su 3 server, 1 è nostro e 2 clienti. L'ho impostato per vari motivi: un server 2008R1 ha molti aggiornamenti in sospeso per l'installazione, ma non posso installarli in batch, quindi lo installo uno per uno ogni giorno; un altro server 2012R2 - per la risoluzione dei problemi di avvio e alcuni problemi di prestazioni ecc. Non penso che sia una cattiva pratica pianificare un riavvio periodico, dall'altro duro Può aiutare a tenere traccia di vari problemi hardware e software, in particolare quelli che sono coinvolti nell'avvio automatico .

Conosco una grande azienda che non solo riavvia i loro server Windows di notte, ma alcuni di essi vengono anche reinstallati ogni 24 ore. Per loro, è necessario a causa di porri di memoria nel software e problemi di sicurezza.

Sembra che alcune aziende si riavviino ogni 24 ore, anche se mi sembra strano come amministratore di Linux. Per chiarire: non consiglierei mai di farlo a causa di un problema di memoria: rintracciare il problema e risolverlo.

Se l'utilizzo della memoria rimane fisso al 75% per mesi, probabilmente non è necessario riavviare - è del tutto normale per un'applicazione server utilizzare tutta la memoria disponibile - aumenta le prestazioni molto perché è necessario un numero minore di I / O su disco se si utilizza la RAM per memorizzare nella cache i tuoi dati.