Newsgroup: it.comp.os.win.win2000
Titolo: "Byte del Pool non di paging"

 Essendo ancora alle prese con un assillante problema con l'evento 2019
(Impossibile allocare memoria non di paging. Il pool non di paging è vuoto),
che mi inchioda sistematicamente un W2kProSP4 ogni 3-4 giorni, chiedo questo
chiarimento:
Ho attivato il performance monitor, e sto osservando che in due giorni il
contatore "Byte del Pool non di Paging" è praticamente raddoppiato, passando
da 29MB a 56MB.
Interpretando l'errore che dice che il "Pool non di paging è vuoto", ritengo
che questo aumento di dimensioni rappresenti un aspetto positivo.
Tuttavia non sono riuscito a trovare un documento che descriva il
significato di ciascun oggetto di prestazioni, per capire se devo aspettarmi
un nuovo crash o se gli interventi eseguiti (primo fra tutti l'aggiornamento
di un driver Ati Radeon 9200 che sembrava aver dei problemi) mi hanno messo
sulla strada giusta.
Siccome ogni volta che tocco qualcosa devo poi aspettare 4 giorni per sapere
l'esito, questa indagine sta assumendo tempi biblici...
Saluti
Alberto
--
E non so se avrò gli amici a farmi il coro,
o se avrò soltanto volti sconosciuti,
canterò le mie canzoni a tutti loro
e alla fine della strada
potrò dire che i miei giorni li ho vissuti...

 positivo.
[CUT]
No, al contrario. Non è la memoria che è vuota, ma il "Pool"
Guarda questo esempio
Windows 2000 Non-Paged Pool Is Exhausted by Afd.sys
http://support.microsoft.com/?id=296265
In pratica il "Pool di Memoria" (pool=gruppo) non ha aree di memoria
disponibili da allocare ai processi che ne richiedono, e  (il pool è vuoto)
Using Performance Monitor to Identify a Pool Leak
http://support.microsoft.com/?id=130926
Il fatto che tu veda quindi un progressivo aumento di byte nel non-paged
pool da parte di un determinato processo, sostanzialmente significa che quel
processo non sta funzionando correttamente e non libera memoria una volta
terminata l'opeazione.
Ciao!
-- 
_______________________________
        Microsoft® Technical Advice
         news://
news.microsoft.com
http://support.microsoft.com/newsgroups

 libera memoria una volta terminata l'opeazione.
Ho quantomeno sezionato il problema.
Ho spento tutto, tranne Sql-Server (Sql2000, SP3a, Developer Edition).
Questo Sql-Server esegue un DTS (una cosa banale, qualche decina di righe
importate da file di testo in una tabella di un db), ogni minuto.
Se spengo Sql-Server, l'oggetto "Byte del pool non di paging" non aumenta.
Se attivo Sql-Server e il relativo Sql-Agent, il contatore inizia ad
aumentare.
Mi chiedo cosa si possa modificare in Sql-Server per evitare questo leak.


 leak.
Non saprei dirti esattamente. Potrebbe anche solo essere SQL che non
rilascia memoria in tempo utile... Hai provato ad attendere un po?
Nel frattempo cmq ti posso consigliare di installare l'ultima service pack
di SQL se non hai ancora provveduto
http://www.microsoft.com/sql/downloads/2000/sp3.asp
A Breve poi dovrebbe essere anche disponibile la 4, ma nel frattempo puoi
cercare di vedere se il tuo problema fosse legato ad un Bug noto di cui già
esiste la correzione
A list of the bugs that are fixed in SQL Server 2000 Service Pack 4 Beta
http://support.microsoft.com/?id=888799
Poi potresti provare a chiedere sul NG dedicato
[microsoft.public.it.sql]


 rilascia memoria in tempo utile... Hai provato ad attendere un po?
Sarà un mese che le provo tutte...
Ma oggi credo di avere scoperto una cosa interessantissima.
Spegnendo Sql-Server, come dall'articolo che mi hai postato, si liberano
threads e byte del pool non di paging. Quindi, è lui il servizio che ha il
leak.
Ma solo, ed esclusivamente, se è avviato anche un altro servizio, il Promise
Raid Agent, ossia l'agente che invia i messaggini per e-mail se il Raid
segnala un problema. Se quest'ultimo servizio è spento, il leak sembra non
manifestarsi.
Adesso vedo se la Promise dovesse avere distribuito un Agent più recente o
se ha una fix, altrimenti disattiva quest'ultimo servizio (dei due,
Sql-Server mi serve assolutamente, l'agente del Raid no).


 (dei due, Sql-Server mi serve assolutamente, l'agente del Raid no).
Se ti stai riferendo al MsgAgt.exe, è un problema più o meno noto e ti
confermo, anche per esperienza personale, che la causa del memory leak è
lui.
http://groups-beta.google.com/groups?q=MsgAgt.exe+memory
Non so se la Promise abbia rilasciato un Agent aggiornato però. Fammi sapere
quindi.


 sapere quindi.
Non ho trovato niente al riguardo.
Promise afferma di non fare supporto per i prodotti on-board di altri
costruttori, e su Asus.Com non ho trovato niente al riguardo.
Per il momento, tengo il servizio disabilitato.
Saluti
Alberto
--
E non so se avrň gli amici a farmi il coro,
o se avrň soltanto volti sconosciuti,
canterň le mie canzoni a tutti loro
e alla fine della strada
potrň dire che i miei giorni li ho vissuti...