Vector im RAM haltwn



  • Hallo,

    wir haben im Moment das Problem, dass unser SQL Server in bestimmten Situationen(Suchanfragen) extrem unperformant ist. Das ganze wurde mittlerweile von zwei angeblichen Spezialisten verschlimmbessert.
    Nun wollen wir mal einen anderen Weg einschlagen und gucken, was sonst noch so möglich ist.
    Folgende Situation:

    Ich lese mit meinem Windows Dienst(kein MFC oder so ein Kram...Alles reine API) eine Tabelle der Datenbank aus. Jeder Datensatz wird in eine Struktur gepackt und landet anschließend in einem Vector. Jetzt ist damit zu rechnen, nein..es wird so sein, dass weit über 300.000 Datensätze eingelesen werden. Damit wir nun einen Performancevorteil erzielen können, muss ich sicher gehen, dass meine, zur Laufzeit erstellten Variablen(in dem Fall der Vector mit allen Datensätzen), nicht auf die Festplatte ausgelagert werden.Das kann dann bis zu mehreren GB sein die ich einfach nicht schnell genug von der Festplatte lesen kann.
    Wir müssen uns keinen Sorgen um die Größe des RAM`s machen. Der ist SEHR üppig ausgestattet!!

    Werden Variablen generell im RAM gehalten oder mache ich mir zu viele Gedanken?
    Sollten sie doch ausgelagert werden, wie kann ich das verhindern?



  • secondsun schrieb:

    Sollten sie doch ausgelagert werden, wie kann ich das verhindern?

    Gar nicht. Andere Applikationen können immer dazwischen funken, sodass Windows Daten deiner Applikation auf Disk "paged". Eine Lösung bei mehreren GB Daten wäre sicherlich nur ein 64 Bit OS in Kombination mit massig RAM. Der virtuelle Speicher sollte keine Schwierigkeiten machen (64 Bit momentan 8192 GB).



  • Die Auslagerung kannst du verhindern indem zu unter Windows keine Auslagerung erlaubst. Dies kann aber zu einem Absturz führen, wenn der Ram voll ist. Es gibt zwei Wege, wie du variablen in einem Vector schreiben kannst. Entweder als Referenz oder als Pointer. Mit new reservierst du dir den Speicher auf dem HEAP und legst den Vector als Pointer ab. Ohne new wirst du wohl auf dem STACK arbeiten. Bei größeren Datenmengen ist new zu favorisieren. Das Problem mit dem STACK ist, dass dieser eine limitierte Größe hat.

    http://www.learncpp.com/cpp-tutorial/79-the-stack-and-the-heap/

    Ich kenne den Code nicht, aber es sieht einfach so aus, als steht zu wenig Ram zur Verfügung und die Daten werden vom System ausgelagert.

    Ausschalten der Auslagerungsdateien:

    Systemsteuerung -> System -> Erweitert -> Leistungseinstellungen -> Erweiter -> Virtueller Speicher // dort ausschalten


  • Mod

    Lass einfach die Finger vom Speichermanagement. Windows weiß am Betsen was ausgelagert werden soll.Es wird nur Speicher ausgelagert, der auch länger nicht verwendt wurde.
    Wenn Windows auf die Idee kommt Teile Deines Vektors auszulagern, dann hat es recht, weil andere Teile von Windows "wichtiger" Speicher bruachen.



  • Eine Frage: Existiert heutzutage die RAM-Disk überhaupt noch ?

    Man könnte sich nämlich hier einen High-End Rechner mit mehreren GByte (32 ?) RAM holen, 10 GByte für die RAM-Disk reservieren und die Datenbank für den Betrieb immer auf die RAM-Disk laden.


  • Mod

    Warum RAM-Disk wenn es SSD Platten gibt?



  • Denk doch mal nach, wieviel GB im RAM eines Zielrechners gespeichert werden können. Mit vielleicht 1 GB RAM für alles kannst du dort keine mehrere GB halten. Sei doch froh, wenn Windows bei Bedarf auf Festplatte auslagert. Früher hat man dafür sequentielle Magnetbänder einsetzen müssen. 🙄 Das gehört aber nicht mehr zur WinApi, sondern zum Programmdesign! 😃 Mannomann, in der ´Steinzeit` hatte man auch auf Grossrechnern oft nur eine handvoll kb RAM zur Verfügung oder man musste Sonderjobs in der Nacht fahren.



  • berniebutt schrieb:

    Denk doch mal nach, wieviel GB im RAM eines Zielrechners gespeichert werden können. Mit vielleicht 1 GB RAM für alles kannst du dort keine mehrere GB halten.

    secondsun schrieb:

    Wir müssen uns keinen Sorgen um die Größe des RAM`s machen. Der ist SEHR üppig ausgestattet!!

    Wer lesen kann...



  • @hustbaer: danke, das hatte ich glatt überlesen!

    Zurück zum Thema: wenn genügend RAM-Speicher vorhanden ist, kann man sich diesen mit malloc oder calloc greifen und diesen z.B. als Array einer Struktur verwenden. Das dürfte jederzeit effektiver sein als eine RAM-Disk oder SSD-Platte. Habe das gerade bei 1 GB RAM mit einem int-Array mit calloc ausprobiert. Alles, was nicht bereits anders belegt ist (> 0.7 GB), kann ich problemlos über Indizes schreiben und lesen. Das war mal so locker ein Array mit 180 Mio. 4-byte-Integers.

    Interessiert mich auch, wie das nun bei einem grösseren RAM mit mehr gewünschtem allokierbaren Speicher aussieht. Irgendwo gibt es immer irgenwelche Grenzen.



  • Ich verstehe nicht was da jetzt die grosse Frage sein soll, 32 Bit Systeme sind Scheisse, und auf 64 Bit Systemen nimmt er RAM so lange welches da ist und fängt dann an auf die Disk auszulagern.


  • Mod

    hustbaer schrieb:

    ...32 Bit Systeme sind Scheisse...

    Du übergtreibst... 😃

    Der Speicherhunger heutiger Programme wird IMHO meistens ausgelöst durch Entwickler, die nicht genügend Hirnschmalz mehr einsetzen wollen/können um effektiv Ressourcen schonend zu entwickeln.



  • So, da bin ich wieder....
    Also zum Thema "Finger weg vom Speichermanagement". Damit gebe ich micht nicht zufrieden. Denn in dem Fall wollen wir SICHER gehen. Ich kann mich nicht darauf verlassen, dass Windows "weiß" was ich nun auf die Schnelle brauche oder nicht. Das soll in dem Fall einfach mein Problem sein!!!
    Ich stelle mir nämlich folgende Situation vor:
    Es werden Nachts keine Suchanfragen an den Server gestellt. Aber morgens, wenn der erste kunde dann mal anfängt zu arbeiten, wird auf einmal eine Suchanfrage verschickt und schon haben wir das Problem. Es muss wieder von der Festplatte gelesen werden. Und wenn das so ist, dann können wir auch direkt beim SQL Server bleiben.
    Ja, wie schon gesagt. RAM ist AUSREICHEND da!! Und 64Bit ist sowieso klar...Mit 32Bit hantieren wir schon gar nicht mehr rum.
    Nach ersten Tests habe ich auch gesehen, dass der Vector im RAM gehalten wird. Allerdings muss ich das ganze noch einem Langzeittest unterziehen. Sprich, ich guck nach 2Tagen ohne eine Anfrage mal was passiert. Sobald ich mehr weiß, werd ich mal berichten.



  • secondsun schrieb:

    So, da bin ich wieder....
    Also zum Thema "Finger weg vom Speichermanagement". Damit gebe ich micht nicht zufrieden. Denn in dem Fall wollen wir SICHER gehen. Ich kann mich nicht darauf verlassen, dass Windows "weiß" was ich nun auf die Schnelle brauche oder nicht. Das soll in dem Fall einfach mein Problem sein!!!

    Dann lasse keine anderen Anwendungen auf dem Server laufen. Anderen egoistisch die Ressourcen zu klauen ist Quatsch.

    secondsun schrieb:

    Ich stelle mir nämlich folgende Situation vor:
    Es werden Nachts keine Suchanfragen an den Server gestellt. Aber morgens, wenn der erste kunde dann mal anfängt zu arbeiten, wird auf einmal eine Suchanfrage verschickt und schon haben wir das Problem.

    Wo soll da ein Problem liegen? Windows lagert den Speicher aus, weil er knapp wird und nicht weil er lange ungenutzt ist.

    secondsun schrieb:

    Es muss wieder von der Festplatte gelesen werden. Und wenn das so ist, dann können wir auch direkt beim SQL Server bleiben.

    Warum eigentlich auch nicht? Das was ihr da vorhabt ist im Prinzip nichts anderes, als ein Datenbank. Nur mit dem Unterschied, dass sich andere schon etwas mehr Gedanken um die Optimierung gemacht haben.

    secondsun schrieb:

    Nach ersten Tests habe ich auch gesehen, dass der Vector im RAM gehalten wird.

    Wie stellt man das fest? Hast du die Festplattenaktivität analysiert? Die kann auch andere Ursachen haben. Oder gibt dir Windows wirklich Auskunft über den physikalischen Speicherbereich?

    secondsun schrieb:

    Allerdings muss ich das ganze noch einem Langzeittest unterziehen. Sprich, ich guck nach 2Tagen ohne eine Anfrage mal was passiert. Sobald ich mehr weiß, werd ich mal berichten.

    Wie schon erwähnt, wird der Speicher nicht frei geschaufelt, weil Windows gerade langweilig ist. Das es auch keinen Sinn machen würde, hast du ja selber festgestellt.

    Gruß



  • Ich hoffe nur, dass ihr das Programm ned offiziell vertreibt, bzw. den Kunden dann nen ordentlichen Beipackzettel an Beschraenkungen was das System dann alles ned mehr kann, mitgebt.

    Du kannst schon "einigermassen effizient" ein system am auslagern hindern.
    Windows wird kaum teile des vectors seperat auszulagern. Sondern wird ne Menge an Speicherseiten fuer dein Prog reservieren. Wenn der RAM dann knapp wird, wird es sich einfach totswappen. Das ist dann halt deine physikalische grenze ....
    Das das Programm alles andere als kooperativ ist, sollte schon klar sein.

    Warum muessen die Daten denn unbedingt aus dem Speicher kommen ...
    Ich denk mal mit ner ordentlichen platte, und MMIO is man mit Sicherheit schneller, effezienter und sicherer als wie mit nem SpeicherMonster in ner Swap Situation. Heutige Platten schaffen sequentiell lesen > 100MiB/s. Du bist sicher dass du die Daten so schnell verarbeiten keonntest ?

    Ciao ...


  • Mod

    Ich kann mich den Argumenten meiner von Nick Unbekannt und RHBaum nur anschließen.

    Wenn Du wirklich genug Speicher hast wird, Windows nicht auslagern!
    Und wenn ausgelagert werden muss, eben dass was am meisten Sinn macht.

    Funktionen in Programmen, wie Du sie vorhast sind dann die Art von Programmen, die jeden Admin Nerven kosten, weil niemand letzten Endes weiß warum sich die gesamte Performance auf einem Rechner mies verhält...
    Meinst Du ein Admin liest das readme/Anleitung Deines Programmes und weiß was er sich da einkauft?

    Würde ich von solch einer Funktion wissen, die den Speicher meines Servers so benutzt: Es wäre ein 100% Entscheidungskriterium gegen den Kauf dieser Software.

    Zudem: Sollte Dein Server virtualisiert werden (Hyper-V etc.) wirst Du nicht mal mit allen Tricks der Welt das Auslagern verhindern, wenn es das unterliegende OS für sinnreich erachtet. Und da Virtualisierung extrem im Vormarsch ist würde ich gerade von den Eingriffen in das Speichermanagent extrem abraten.



  • Martin Richter schrieb:

    Würde ich von solch einer Funktion wissen, die den Speicher meines Servers so benutzt: Es wäre ein 100% Entscheidungskriterium gegen den Kauf dieser Software.

    👍 Ich würde auch kein Auto mit einem riesigen Tank kaufen, nur damit ich seltener tanken muss. So wie ich im Auto noch einen Kofferraum brauche, braucht das System jederzeit freien RAM oder die Kiste wird lahm und der Admin weiss nicht warum!

    Aber er kann das auf seiner eigenen Kiste machen wie er will, meinetwegen auch im RAM - nur weitergeben oder verkaufen sollte er eine solche Lösung bitte nicht!



  • RHBaum schrieb:

    Warum muessen die Daten denn unbedingt aus dem Speicher kommen ...
    Ich denk mal mit ner ordentlichen platte, und MMIO is man mit Sicherheit schneller, effezienter und sicherer als wie mit nem SpeicherMonster in ner Swap Situation.

    Ob MMIO oder ein entsprechend grosser Speicherblock ohne File dahinter sollte egal sein was die Performance angeht, zumindest sobald das System mal warmgelaufen ist.

    Heutige Platten schaffen sequentiell lesen > 100MiB/s. Du bist sicher dass du die Daten so schnell verarbeiten keonntest ?

    Was dir bei Random Access aber nix bringt.
    Der OP schreibt was vonwegen Suchanfragen. Da wird wohl nix mit sequenziell Lesen sein, ausser er macht für jede Suche nen Table-Scan.

    @OP: wenn du unbedingt willst, kannst du VirtualLock verwenden. Wobei du den Speicher dann nicht mit new() sondern mit VirtualAlloc(Ex) anfordern solltest.


  • Mod

    hustbaer schrieb:

    Ich verstehe nicht was da jetzt die grosse Frage sein soll, 32 Bit Systeme sind Scheisse, und auf 64 Bit Systemen nimmt er RAM so lange welches da ist und fängt dann an auf die Disk auszulagern.

    Und was ist damit anders als bei 32bit Systemen, außer das aus technischen Gründen weniger RAM verfügbar ist?



  • Ob MMIO oder ein entsprechend grosser Speicherblock ohne File dahinter sollte egal sein was die Performance angeht

    Naja "ohne File" muesste er nen "(virtuelles) Filesystem" bauen ... oder gibts da schon was fertiges ?
    MMIO deshalb, weil da mehr einfluss auf die ablage (auch wenns in fileform ist) als wie mit normalen lese schreibzugriffen. Aber wenns was besseres gibt, warum ned ...

    Der OP schreibt was vonwegen Suchanfragen. Da wird wohl nix mit sequenziell Lesen sein, ausser er macht für jede Suche nen Table-Scan.

    Naja, ganz ohne hash's und baeume würde er sicher nicht auskommen. Aber allemale um laengen schneller als wie ne performante DB, Zugriff ueber TCP/IP und den ganzen Datenaustausch wenns geht noch schön in TextTokens geformt (SQL).

    Mit zwischenspeichern binaer auf der Platte ohne grossartige sonderloesungen ... und implementation paar gescheiter hash algos und baeumen zum indizierten suchen, wird er allein wohl schon mal um faktor 4 bis 5 schneller sein als wie ne traditionelle RDBM Struktur.

    Ciao ...



  • hustbaer schrieb:

    @OP: wenn du unbedingt willst, kannst du VirtualLock verwenden. Wobei du den Speicher dann nicht mit new() sondern mit VirtualAlloc(Ex) anfordern solltest.

    http://blogs.msdn.com/b/oldnewthing/archive/2007/11/06/5924058.aspx

    When you lock memory with VirtualLock it locks the memory into your process's working set. It doesn't mean that the memory will never be paged out.

    Man kann einfach Windows nicht daran hindern, dass Windows Speicher auslagert.



  • @Martin Richter:

    lassen wir doch hustbaer auf seiner Meinung 32/64-bit herumreiten wie er will. Er kannte keine 8/16-bit-Systeme, mit denen PCs einmal angefangen hatten. IBM-Grossrechner hatten einst auch nur 32-bit. Irgendwann morgen haben wir 128-bit oder mehr. Und dann kommt wieder jemand, der uns erklärt ´das ist .....´

    Es geht in diesem Thema um die zweckmässige Realisierung, wie man eine Server programmiert. Ich habe aus meiner Sicht alles dazu gesagt, mehr fällt mir nicht ein.

    daddeldu! :p


Anmelden zum Antworten