Arbeitsspeicher für den Datenbankserver

[Dekan]

Hallo,

wie groß soll der Speicher für eine Datenbank sein.

Zur Datenbank:

- ca. 70 GB (Integer, Real, Varchar, Float, Text - keine Images o.ä)

- Anzahl Tabellen - ca. 100 (von ziemlich kleinen ~100Kb bis ziemlich großen ~ 500MB oder sogar 1GB)

- es wird zur Analysen(1) und für Web(2) benutzt (dafür sind 2 Fujitsu TX300S da mit je 4GB Speicher)

- geschrieben wird dort kaum, nur wenn neue Tabelle hinzugefügt wird und nicht über Webinterface. Dafür sind extra Rechner da.

Ich habe das Gefühl, dass manchmal der Speicher nicht reicht, wenn auf die großen Tabellen gleichzeitig mehr als 3 Abfragen kommen (die sind manchmal kompliziert).

Wie kann ich am besten die Größe des Speichers bestimmen

[Thanks-and-Goodbye]

Das hängt von mehr Faktoren ab als vom eigentlichen Arbeitsspeicher.

Welches OS? Welches DBMS?

Unter einem 32bittigen Windows kann ein Prozess üblicherweise eh nur 2 GB nutzen. Mach dich bitte mit den Grenzen des Betriebssystems vertraut.

[Dekan]

vielen Dank für deine Antwort,

OS für Web - Windows Server 2008 64 Bit, DBMS - SQL Server 2008 R2, Analyse Windows Server 2003 64 Bit (wird jedoch im nächsten Jahr umgestellt)

Und die Grenzen sind mir auch bekannt (in diesem Fall ist der Speicher jedoch durch Hardware begrenzt - 192 GB). - Sorry ich habe es wahrscheinlich unglücklich formuliert. Meine Frage war aber wie viel Speicher wäre dann Optimal? Ob es was bringt wenn ich statt 4 GB dort 16 GB einbaue und wie ich überhaupt den benötigten Süeicher berechnen kann.

[lordy]

Das einzige, was besser ist, als mehr Speicher, ist noch mehr Speicher.

[carstenj]

Hi,

natürlich ist vieles durch Hardware zu erschlagen, nur ist das gar nicht immer notwendig. Es gibt zahlreiche Tuningmaßnahmen, die die Performance so enorm verbessern können, wie es kein Speicherausbau zu leisten vermag.

Das erfordert allerdings Kenntnisse des Datenbanksystems. Ich würde erstmal eine Analyse der Datenbank vornehmen, und schauen, wo es wirklich harkt.

[dr.dimitri]

Es wär auch nicht das erste mal, dass nach einer solchen "blinden" Hardwareaufrüstung die Performance noch schelchter wurde, da man auf den eigentlichen Flaschenhals jetzt noch mehr einprügeln kann.

Dim

[Dekan]

Die Indizes sind schon soweit wie möglich gesetzt(was ja 95% der Tuningmaßnahmen ausmacht) und das hat die Perfomance an manchen Stellen um Faktor 100(!) verbessert, die Tabellen wurden auch den Abfragen angepasst. Also fast alles was zu machen gewesen wäre, wurde gemacht!!!

Es geht mehr darum wie man den notwendigen ARBEITSSPEICHER berechnet. Gibt es ein Tool daß die Schwachstellen zeigen kann in SQL Server 2008?

[Thanks-and-Goodbye]

Da sich das ganze immer mehr von der eigentlichen Hardwarefrage entfernt: verschoben in die Datenbankabteilung.

[carstenj]

Hi,

da du ja bereits das Wort Arbeitsspeicher rot und groß geschrieben hast, gehe mich mal davon aus, dass weitere Tipps, die evtl. die Performance verbessern könnten nicht erwünscht sind?

Denn Indizes sind ein wichtiger Teil, nur gibt es noch andere Faktoren, die u.U. genauso entscheidend sein können.

[Dekan]

Hi,

da du ja bereits das Wort Arbeitsspeicher rot und groß geschrieben hast, gehe mich mal davon aus, dass weitere Tipps, die evtl. die Performance verbessern könnten nicht erwünscht sind?

Denn Indizes sind ein wichtiger Teil, nur gibt es noch andere Faktoren, die u.U. genauso entscheidend sein können.

Doch , ich nehme gerne alle Tipps an. Es ist bloß so dass ich mit meinem Vorgesetzten, der kein Informatiker ist, seit langer Zeit einen "Streit" habe. Und er ist der Meinung, dass der Zukauf vom Speicher keine Vorteile bei solch "kleiner" Datenbank bringt. Er hat mit der DB fast gar nichts zu tun. Ich und meine Kollegen führen verschiedene Analysen aus und wir merken, wenn gleichzeitig drei oder mehr langen Abfragen machen, wird es langsamer, obwohl die einzelne Abfrage ziemlich schnell ist ~0.01-0.3 Sekunden je nach Abfrage. Für drei gleichzeitige Abfragen würde es 1-1.5 Sekunden pro Abfrage dauern, deswegen waren wir der Meinung, dass es an dem Arbeitsspeicher liegt. Es wäre natürlich super, wenn du mir andere Tipps geben könnte.

[dr.dimitri]

Es ist bloß so dass ich mit meinem Vorgesetzten, der kein Informatiker ist, seit langer Zeit einen "Streit" habe. Und er ist der Meinung, dass der Zukauf vom Speicher keine Vorteile bei solch "kleiner" Datenbank bringt.

Solange ihr keine messbaren Belege dafür liefert, glaube ich das als Informatiker und alter Tuning Spezi auch nicht.

Für drei gleichzeitige Abfragen würde es 1-1.5 Sekunden pro Abfrage dauern, deswegen waren wir der Meinung, dass es an dem Arbeitsspeicher liegt.

Eine seltsame Logik. Habt ihr das mal verifiziert? Muss der Server Speicher auslagern? Mit wie viel Speicher ist denn der SQL Server denn überhaupt konfiguriert? Gehen wir mal von 2,5GB aus, dann müssten die 3 Abfragen pro Sekunde ca. 1,5GB belegen, damit ihnen in 1,5 Sekunden der Speicher ausgeht. Liefert euer Plattensystem diese Datenmengen? Wisst ihr welche Datentransferrate ihr habt maximal habt und wie viel davon benutzt wird?

Wenn eine Abfrage schnell und drei parallele Abfragen langsam sind, würde ich eher mal auf einen CPU Engpass tippen, denn bei den Zeiten dürfte man Full Tablescans auf riesige Tabelle ausschließen (sofern ihr nicht eine alte Notebookplatte in dem Server stecken habt, die schon bei einem kleinen Indexzugriff in die Knie geht).

Alternativ könnte es natürlich auch sein, dass sich die Abfragen gegenseitig blockieren. MSSQL bietet ja, soweit ich weiß, auch das "Feature", dass ein lesender Prozess einen anderen lesenden blockiert. In diesem Fall würden weder Memory, noch CPU noch Plattenaufrüstung sondern nur Applicationstuning helfen.

Dim

[Dekan]

Eine seltsame Logik. Habt ihr das mal verifiziert? Muss der Server Speicher auslagern?

Wie könnte ich das testen? Da sind keine "Statisticstools" installiert (mein Chef wollte sie nicht haben). Gibt es andere Möglichkeiten?

Mit wie viel Speicher ist denn der SQL Server denn überhaupt konfiguriert?

Der hat 4 GB Arbeitsspeicher.

Liefert euer Plattensystem diese Datenmengen? Wisst ihr welche Datentransferrate ihr maximal habt und wie viel davon benutzt wird?

Nein das wissen wir leider nicht. Wir haben RAID-5 - 3 Maxtor Festplatten(10.000 rpm)

Wenn eine Abfrage schnell und drei parallele Abfragen langsam sind, würde ich eher mal auf einen CPU Engpass tippen, denn bei den Zeiten dürfte man Full Tablescans auf riesige Tabelle ausschließen (sofern ihr nicht eine alte Notebookplatte in dem Server stecken habt, die schon bei einem kleinen Indexzugriff in die Knie geht).

Wir haben nur eine CPU XEON E5600(welche genau weiß ich nicht mehr) und die hat 4 Kerne mit Hyperthreading(also 8 logische) - das sollte reichen - oder? Kann DBMS mehrere CPU-Kerne (logische) für eine Abfrage benutzen? Auf Mainboard ist noch ein Socket frei.

Alternativ könnte es natürlich auch sein, dass sich die Abfragen gegenseitig blockieren. MSSQL bietet ja, soweit ich weiß, auch das "Feature", dass ein lesender Prozess einen anderen lesenden blockiert. In diesem Fall würden weder Memory, noch CPU noch Plattenaufrüstung sondern nur Applicationstuning helfen.

Das muss ich dann checken. Vielen Dank

Bearbeitet 8. Dezember 2010 von Dekan

[dr.dimitri]

Da sind keine "Statisticstools" installiert (mein Chef wollte sie nicht haben). Gibt es andere Möglichkeiten?

Windows selbst hat doch auch Tools von Haus aus dabei. Evtl. kann Dir da jemand aus dem Windowsforum helfen.

Der hat 4 GB Arbeitsspeicher.

Nicht der Rechner, sondern der DB Server. Den kann man ja mit 10MB starten oder 3GB - je nach Konfiguration.

Kann DBMS mehrere CPU-Kerne (logische) für eine Abfrage benutzen?

Kommt auf die Abfrage und die Datenbank an. Bei 2 Sekunden Laufzeit ist das aber nicht relevant. Wie sieht denn die CPU Auslastung aus?

Dim

[Dekan]

Nicht der Rechner, sondern der DB Server. Den kann man ja mit 10MB starten oder 3GB - je nach Konfiguration.

Der Server(die Software) ist mit vollem Speicher konfigueiert(da ist ein Hacken gesetzt) - kann das das Problem sein?

Kommt auf die Abfrage und die Datenbank an. Bei 2 Sekunden Laufzeit ist das aber nicht relevant. Wie sieht denn die CPU Auslastung aus?

Und jetzt glaube ich zu wissen woran es liegt. Vor zwei Monaten haben wir die Speicherauslastung gemessen. Das war jedoch auf dem alten DBServer, bei einer komplizierten Abfrage hat die Speichernutzung fast gar nicht geändert (maximal +/-30 MB), während beide CPU-Kerne mit 70% liefen.

SQLStatement besteht aus 3 UNION und es wird in einer VIEW(Sicht) gesucht, die aus 18 UNION ALL besteht(die Tabellen da haben ca.20 Spalten und von 100 bis 2.000.000 Zeilen, je nach Tabelle - VARCHAR, Integer, Real, Float). Und wenn es in der größten Tabelle gesucht wird, dann dauern die drei Abfragen ziemlich lang.

hier ist der php Code:

//query to get the result of a test analysis:

function queryTestAnalyis($values, $upstream, $downstream, $Restriction) {

    //don't change order of the attributes

    $return = "SELECT A_name, B_name, position, strand, ISNULL(C_position, A_position) AS A_position,

                          convert(varchar(50), score) as score, wert2, A_strand, lnp

                   FROM VIEW_all_bla_bla_blup

                   WHERE $upstream <= ISNULL(C_position, A_position) AND ISNULL(C_position, A_position) <= $downstream";

    $ARestriction = getARestrictionForTestAnalysis($values, "A_name");

    if ($ARestriction != "") {

        $return .= " AND ($ARestriction)";

    }

    if ($BRestriction != "") {

        $return .= " AND ($BRestriction)";

    }


    $return .= " UNION SELECT prev_A_name, B_name, position, strand, prev_A_position,

                          convert(varchar(50), score) as score, wert2, prev_A_strand, lnp

                   FROM  VIEW_all_bla_bla_blup

                   WHERE $upstream <= prev_A_position AND prev_A_position <= $downstream";

    $ARestriction = getARestrictionForTestAnalysis($values,  "prev_A_name");

    if ($ARestriction != "") {

        $return .= " AND ($ARestriction)";

    }

    if ($BRestriction != "") {

        $return .= " AND ($BRestriction)";

    }


    $return .= " UNION SELECT next_A_name, B_name, position, strand, next_A_position,

                          convert(varchar(50), score) as score, wert2, next_A_strand, lnp

                   FROM  VIEW_all_bla_bla_blup

                   WHERE $upstream <= next_A_position AND next_A_position <= $downstream";

    $ARestriction = getARestrictionForTestAnalysis($values,  "next_A_name");

    if ($ARestriction != "") {

        $return .= " AND ($ARestriction)";

    }

    if ($BRestriction != "") {

        $return .= " AND ($BRestriction)";

    }


    $return .= " ORDER BY A_name, B_name ASC";

    return $return;


}

[/PHP]

Was uns noch aufgefallen ist: Die Funktion

[PHP]getARestrictionForTestAnalysis($values, "A_name");

macht aus Values ein String mit OR-Verknüpfung - val1 OR val2 OR val3 usw. Solange die # von ORs <=64 - dauert die Suche maximal 10 Sekunden, ab 65 sofort 67 Sekunden, bei 100 ca. 92 Sekunden, bei 128 sinkt wieder auf 44, 197 - schon 18 Sek. Woran könnte es liegen? - deswegen dachten wir auch, dass es an dem Arbeitsspeicher liegt.

[Thanks-and-Goodbye]

Aus deinen rudimentären Beschreibungen lese ich heraus, dass das System komplett auf einem Raid 5 läuft.

Das ist für eine SQL Maschine ziemlich mies konfiguriert. Das kann u. U. schon ein Flaschenhals sein. 4 GB für Server 2008 ist nicht viel, wenn das System selber swappen muss und auf dem gleichen Festplattenverbund noch Datenbankaktivitäten laufen: Prost Mahlzeit.

Geschickter wäre es gewesen, für die Datenbanken ein separates Raidsystem als Raid 10 zu konfigurieren, wenn man dann noch richtig Leistung rauskitzeln will / muss für die Transaktionslogs ein weiteres Raid 10.

Der Server(die Software) ist mit vollem Speicher konfigueiert(da ist ein Hacken gesetzt)

Wenn eine Hacke im Server steckt hat man was falsch gemacht.

[Corto -sX-]

erstmal beileid und Mitgefühl von mir an den nächsten armen FI der eine Datenbank auf den Buckel geschnallt bekommt, einen sql grundkurs machen darf und dann im Betrieb "DBA" gerufen wird.

Das soll dir jetzt nicht den Mut nehmen, sondern ansporn sein. Anfangs sah ich auch kein Land,(frag mal dr.dimitri ) aber jeden Tag wird man besser wenn man es will.

Ich würde dir empfehlen einfach mal ein paar Tage oder ne Woche den Perfmon von windows laufen zu lassen.

Kein Vergleich zu richtigen Statistiken die ein Tuningspezi aus dem Hut zaubert, aber mehr als Ausreichend um Dinge auszuschließen.

Dann schaust du dir mal die Statistiken an, in bezug auf:

CPU-Auslastung

Ram-Auslastung

und ganz wichtig:

DISK-I/O

Sollte bei diesen drei Werten der Windowsserver mehr "dümpeln" als "schwitzen" wäre jede Aufrüstung rausgeworfenes Geld.

@Dimitri:

mein RAC Problem wurde gelöst (bzw ist es nun diagnostiziert und wird behoben)

Bearbeitet 9. Dezember 2010 von Corto |sX|

[Goos]

Der Server(die Software) ist mit vollem Speicher konfigueiert(da ist ein Hacken gesetzt) - kann das das Problem sein?

Ich wüsste nicht wo es da einen Haken geben sollte. Es müssen ein Minimal- und ein Maximalwert gesetzt werden.

Ich geh den bisherigen Beschreibungen nach auch nicht davon aus, dass es am Hauptspeicher liegt, aber wer weiss

Du kannst mit folgendem Statement mal die üblichen Verdächtigen unter den Waitstatistiken abprüfen:

SELECT wait_type

,waiting_tasks_count

,wait_time_ms

,max_wait_time_ms

FROM sys.dm_os_wait_stats

WHERE wait_type LIKE 'Resource%'

OR wait_type LIKE 'CMEMTHREAD%'

OR wait_type LIKE 'Latch%'

OR wait_type LIKE 'PAGE%'

OR wait_type LIKE 'DBTABLE%'

OR wait_type IN 

('LOGBUFFER'

,'DISKIO_SUSPEND'

,'REQUEST_DISPENSER_PAUSE'

,'REPLICA_WRITES'

,'FCB_REPLICA_READ'

,'FCB_REPLICA_WRITE'

,'DBMIRROR_SEND'

,'ASYNC_NETWORK_IO'

,'ASYNC_IO_COMPLETION'

,'WRITEBUFFER'

,'IMPPROV_IOWAIT'

,'IO_COMPLETION'

,'SOAP_READ'

,'SOAP_WRITE')

ORDER BY wait_time_ms DESC

Weiterhin würde ich dir empfehlen, die Waitstatistiken für Locks anzuschaun.

SELECT wait_type

,waiting_tasks_count

,wait_time_ms

,max_wait_time_ms

FROM sys.dm_os_wait_stats

WHERE wait_type LIKE 'LCK%'

Falls der Server allerdings schon sehr lange läuft, solltest du die Waitstats auch mal zurücksetzen. Sie werden nämlich durch Sonderaufgaben wie z.B. Indexrebuilds gerne mal verfälscht.

Goos

[.NETter]

Hallo,

das ist alles nicht falsch was hier so geschrieben wird.

Hier gibt es aber grundlegende Fragen zur Installation des SQL Servers und zur Erstellung der jeweiligen Datenbank.

Was eine SQL Server Datenbank in die Knie zwingen kann ist ein falsch konfiguriertes ISOLATION LEVEL (einfach mal googeln). Oder aber auch ganz einfache "nicht optimale" Einstellungen in der DB.

Sind die Datendateien und Logdateien auf seperaten Laufwerken?

Wird für die Datenbankobjekte die FILEGROUP PRIMARY verwendet? Wenn ja sollten die Standardeinstellungen zum Erstellen von DB-Objekten auf eine seperate FILEGROUP konfiguriert werden. In der PRIMARY tobt der SQL Server selbst herum. Die Systemdatenbank tempdb sollte auf jeden Fall physikalisch an einem anderen Ort liegen.

Große Tabellen können über mehrere Laufwerke partitioniert werden u.v.m....

Benutze mal den SQL Server Profiler und im SQL Server 2008 auch gerne mal den Optimierungsratgeber. Ebenso kannst Du Leistungsdaten aufzeichnen und mit dem Windows Resourcenmonitor automatisiert abgleichen lassen und Dir die Auslastung (z.B. RAM) exakt im Vergleich mit einem Trace der DB anzeigen lassen.

Wieviele Verbindungen sind denn permanent geöffnet? Vielleicht ein Anwendungsfehler von Progs die darauf zugreifen und offene Verbindungen zurück lassen?

Wie Du siehst gibt es hier unendlich viele Möglichkeiten.

Viele Grüße,

Thomas

[DocInfra]

Solange aus der DB mehr gelesen als geschrieben wird, ist ein RAID 5 okay. Aber: Drei Spindeln, selbst mit 10k, und dann für System, DB und Logs ist echt mies. Chunksize ist wohl eher nicht das Problem, die IOs des SQL sind mit ziemlicher Sicherheit kleiner, als die Chunksize des Controllers, außer ihr habt daran rumgefummelt. Partition Alignment habt ihr auch nicht gemacht, oder?

Denk bitte daran, dass gerade DB Performance auch sehr viel mit IO Performance zu tun hat. Du kannst an RAM und Tabelle/ Indizies soviel rumoptimieren wie du willst, wenn von unten nix kommt.