none
Speichernutzung Analysis Services 2005/2008 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    ich habe Probleme bei der Nutzung des Analysis Servers 2005/8.

    Auf einem Rechner mit 8 GB RAM kommt es nach Wiederherstellung einiger Datenbanken zu Fehlern durch wu wenig freien Arbeitsspeicher. Der AS Prozess nutzt bis zur physikalischen Arbeitsspeichergrenze die 8GB aus( durch "normale" BElegung und Reservierung) , greift jedoch scheinbar nicht auf die Auslagerungsdatei zu.

    Es sind zwar einige Datenbänke, ca. 75 (die meisten eher klein, nur einige sind größer ca. 400 MB), doch denke ich dass das der Rechner eigentlich verkraften sollte. Ein Rechner mit 16 GB scheiterte schon an weniger wiederhergestellten Datenbänken.

    Tests mit verschiedenen MemoryMin/MaxLimits brachten keine Besserung.

    Wie kann ich die Auslagrungsdatei besser nutzen bzw. den RaM besser ausnutzen?

    Gruß

    MSit

    Mittwoch, 14. September 2011 14:30
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo MSit,

    ehrliche klare Antwort: Mehr Speicher.

    Ich verstehe nicht, daß man bei diesen Peanutsbeträgen für Speicher noch überlegt, wie man Speicher in die Auslagerungsdatei verlagern soll ;(
    Bei 75 Datenbanken geht allein schon für die Allokierung der Verwaltung im RAM Einiges verloren:

    http://msdn.microsoft.com/de-de/library/aa337559.aspx

    Ich persönlich halte 8 GB RAM für einen dedizierten SQL Server mit AS für eindeutig unterdimensioniert!
    Ausgerechnet dann noch AS mit auf den Server zu packen halte ich für leichtsinnig; warum dann nicht auch noch gleich RS und SSIS ;)

    Letztendlich heißt das IMO Sparen am falschen Ende.

    Unsere angewendete Faustregel bei einem Kunden: 4 GB / Core

    Uwe Ricken

    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    • Als Antwort vorgeschlagen Horizon_Net Dienstag, 20. September 2011 18:03
    Freitag, 16. September 2011 04:11
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Herr Ricken,

    Danke für die Einschätzung, da fehlen mir die Erfahrungswerte.

    Der SQL Server ist zwar parallel zum AS installiert, läuft aber ohne DB.

    Wir migrieren die Cubes von einem 2000er AS auf 2005/2008. Der 2000er AS kann mit fast ebenso soviel DBs noch eheblich "speichersparender" umgehen. Gibts da so einen gravierenden Unterschied in den AS Versionen?

    Vielleicht noch ein Nachhaken:

    Gibt es eine Faustregel zum Bezug Größe des RAMs zu Größe der archivierten DBs auf HD (bei uns ca. 7,5 GB)? Oder ist eher die Anzahl der Dimensionen pro CUbe oder die ANzahl der Cubes für den Speicherhunger entscheidend?

    Viele Grüße

    M. Sitran

    Montag, 19. September 2011 14:14
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo M. Sitran,

    im einem gebe ich Uwe uneingeschränkt Recht: SSAS (wie SQL Server) ist eine speicher-intensive Server Applikation und je mehr Hauptspeicher zur Verfügung steht, um so besser. Wenn genügend Hauptspeicher zur Verfügung steht, kann vieles im Cache gehalten werden und teurer IO Zugriff wird so nicht nötig.

    Das heisst aber nicht zwingend, das es nicht auch mit weniger geht.
    Ich habe einen Server mit 32Bit OS, 4 GB Ram und 2x2 Cores. Auf dem Server laufen SQL Server + SSAS + SSIS und das mit den Versionen 2005 und 2008; also 2 benannte Instanzen. Die SQL Server hosten die Dataware Houses für die Cubes, das sind 12 DWH und entsprechend 12 SSAS DBs mit je einem Cube. Die Größen variieren zwischen 100 MB und 5 GB.

    Auch das läuft und zwar halbwegs gut. OK, die Response Zeiten von den beiden großen Cubes sind nicht in den erstrebenswerten Sekundenbereichen, aber sie liefern ein Ergebnis.

    Zu Fehlern wegen vermeintlich zu wenig Speicher habe ich bisher nie erhalten, allerdings habe ich auch nie eine SSAS Datenbank zurück gesichert; wenn, dann deploy & verarbeite ich eine Cube einfach neu.

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Freitag, 23. September 2011 17:24
    |