Freien Speicher anzeigen.

verwendetes Datenbanksystem: MS SQL 2005 SP2

Hallo an alle,

Ich habe eine SP, die die angehängte Exception wirft.
Führe ich die SP in VisualStudio mit gleichen Daten aus, habe ich keine Excpetion.

Der Code ist hier sehr simpel:

XmlDocument oDoc = new XmlDocument();
oDoc.LoadXml(inInfoPathXML.Value); <- Exception

Ich würde mir jetzt gerne vorher die Speicherverhältnisse in eine Datei schreiben lassen. Das Schreiben in eine Datei ist kein Thema, aber wie ich alle relevanten Speicher Daten erhalte weiß ich leider nicht, da ich nicht aus dem .NET Bereich komme.

Kann mir da jemand helfen?

Vielen Dank und viele Grüße

Marc

.NET Framework execution was aborted by escalation policy because of out of memory.
System.Threading.ThreadAbortException: Der Thread wurde abgebrochen.
System.Threading.ThreadAbortException:
at System.String.GetStringForStringBuilder(String value, Int32 startIndex, Int32 length, Int32 capacity)
at System.Text.StringBuilder.GetNewString(String currentString, Int32 requiredLength)
at System.Text.StringBuilder.Append(Char[] value, Int32 startIndex, Int32 charCount)
at System.IO.StringWriter.Write(Char[] buffer, Int32 index, Int32 count)
at System.Xml.XmlEncodedRawTextWriter.FlushBuffer()
at System.Xml.XmlEncodedRawTextWriter.WriteAttributeTextBlock(Char* pSrc, Char* pSrcEnd)
at System.Xml.XmlEncodedRawTextWriter.WriteString(String text)
at System.Xml.XmlEncodedRawTextWriter.WriteNamespaceDeclaration(String prefix, String namespaceName)
at System.Xml.XmlWellFormedWriter.WriteEndAttribute()
at System.Xml.XmlWriter.WriteAttributes(XmlReader reader, Boolean defattr)
at System.Xml.XmlWriter.WriteAttributes(XmlReader reader, Boolean defattr)
at System.Xml.XmlWriter.WriteNode(XmlReader reader, Boolean defattr)
at System.Data.SqlTypes.SqlXml.get_Value()
at StoredProcedures.updateXML(SqlXml& out, SqlXml in, Int32 num)

http://blogs.msdn.com/sqlclr/archive/2006/03/24/560154.aspx

SPs in CLR laufen im sog. MemToLeave-Speicherbereich. Der kann je nach Konfiguration gerade mal 256 MB umfassen. In dem Beitrag steht auch, wie man an die Informationen zum freien und gesamten Speicher kommt.

>

SPs in CLR laufen im sog. MemToLeave-Speicherbereich. Der kann je nach Konfiguration gerade mal 256 MB umfassen. In dem Beitrag steht auch, wie man an die Informationen zum freien und gesamten Speicher kommt.

Hi GarlandGreene,

den Beitrag hatte ich Bereits gelesen und ausprobiert. Hatte leider überhaupt keinen Effekt gezeigt.

Ich konnte in dem Artikel und den Links leider nicht die Information finden, wie ich ausgeben kann, wie viel CLR Speicher noch frei ist. Kannst du mir da helfen?

Viele Grüße

Marc

PS. Die Testmaschine ist 32Bit 4GB Ram. Bei der OOM Exception hat die Maschine noch 3GB Ram frei.

wie gesagt, die CLR läuft im MemToLeave-Speicherbereich. Der ist anscheinend mindestens 256 MB groß, die Maximalgröße wird aber durch den virtuellen Adressbereich (2 GB) und den darin bereits belegten SQL Buffer-Pool begrenzt. Wenn der Server also die vollen 2 GB nutzen darf und diese in seinem Buffer Pool größtenteils schon belegt hat, bleibt kaum noch was für den Rest.

über die Systemtabelle sys.dm_os_memory_clerks kannst du die Speicherbelegung bekommen. Beispiel:

select type, sum(single_pages_kb + multi_pages_kb + virtual_memory_committed_kb) as kbges  from sys.dm_os_memory_clerks group by type

listet alle Speichertypen im SQL-Server mit ihrer aktuellen Speichernutzung auf. Alternativ kannst du auch den Befehl "dbcc memorystatus" dazu benutzen.

Details zu den gezeigten Werten findest du hier. Wenn ich das ganze richtig verstanden habe, ist die Differenz zwischen VM Reserved und dem, was der SQL Buffer Pool "schluckt" das, was deine CLR zur Verfügung hat.

*forum tret*

interessant, das Forum hat den Post zwar angenommen, die Threadübersicht aber nicht aktualisiert.

Der Tipp mit dem DBCC MEMORYSTATUS hat mir sehr geholfen. Vielen Dank dafür.

Somit konnte ich verfolgen ob die Einstellungen überhaupt greifen.
Scheinbar tun diese es leider nicht.

Ich habe dem Starten des Dienstes die -g Option angehängt:
"C:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe" -sMSSQLSERVER -g1024
Diese scheint nicht zu greifen. Ich habe den Server Selbst auch im Speicher begrenzt. Testweise MAX Server Memory auf 600MB, 1GB , 2GB. Auch jedes mal einen Reboot der ganzen Maschine habe ich durchgeführt.

In allen Fällen lieferte mir der MEMROYSTATUS unter MEMORYCLERK_SQLCLR, VM Reserved ~160MB. Im letzten Versuch hatte ich noch 3,2GB Hauptspeicher frei, als die OOM Exception auftrat. So langsam überkommt mich das Gefühl das CLR unter SQL zu nutzen ein sehr schlechter Ansatz ist.

Hast eine Idee die mir aus der Misere hilft 😉

Viele Grüße

Marc

hast du mal versucht, die SP nach Änderung des verfügbaren Speichers für den Server und Neustart des Servers (der Rechner muss nicht neu gestartet werden) aufzurufen?

Also ich habe die SP immer nach neustart der Maschine incl Änderung der MAX MEMORY Werte ausgeführt.
Gibt es einen Unterschied zu "nur den SQL durchstarten" den ich übersehe?

Viele Grüße

Marc

nö, eigentlich nicht.

Wie groß ist denn das XML-Dokument, das du da laden willst? Xml erzeugt ja bei der Validierung eine ziemliche Arbeitslast, das kann temporär ziemlichen Speicherhunger bedeuten. Denn das System muss die komplette XML-Struktur in den Speicher laden und anschliessend validieren.

Das XML ist nicht groß. 1,3MB mit welchem ich die Exception bekomme. Lokal habe ich aber schon 60MB XMLs problemlos verarbeitet bekommen.

Ich würde ja auch einsehen, falls der Server an die 2GB Task Grenze kommen würde, oder das System an 4GB, dass das XML zu groß sei. Aber der dümpelt bei 800MB bis 1,4GB rum.

wie gesagt, die Speicherverwaltung vom SQL-Server scheint da ihre Tücken zu haben. 32 Bit-Prozesse haben die Begrenzung auf 2 GB, die CLR läuft ebenfalls in diesem Prozess, damit muss sich alles zusammen die 2 GB teilen. Und anscheinend gibts da ein Problem mit dem virtuellen Adressbereich, unabhängig von der tatsächlichen Speicherauslastung. Mit dem SQL Server für 64 Bit-Systeme ist das übrigens kein Problem mehr, da hat der Prozess dann 8 TB virtuellen Adressraum zur Verfügung.

Hi All,

ich wollte nur berichten, dass ich mit dem SQL Server auf x64 gegangen bin, und seid dem keine Probleme mehr in Hinsicht OutOfMemory habe.

Viele Grüße