4. Vector im RAM haltwn

Vector im RAM haltwn

  • Mod

    Warum RAM-Disk wenn es SSD Platten gibt?

    0
  • B

    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.

    0

  • 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...

    0
  • B

    @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.

    0

  • 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.

    0
  • 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.

    0
  • ?

    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.

    0
  • N

    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ß

    0
  • R

    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 ...

    0
  • 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.

    0
  • B

    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!

    0

  • 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.

    0
  • 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?

    0
  • R

    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 ...

    0
  • ?

    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.

    0
  • B

    @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

    0

  • Martin Richter schrieb:

    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?

    Nichts ist technisch anders, nur dass es Kacke^4 ist wenn man auf einem 32 Bit System mehr als 2~3GB Daten im Speicher halten muss. Ja, AWE und blablubb, aber das mag doch keiner wirklich machen wenn es nicht sein muss.

    Ich hatte das nicht allgemein gemeint, sondern auf diesen Thread bezogen, wo der OP schon mehr oder weniger deutlich geschrieben hat, dass er wohl mehr als nur 2-3 GB Daten im RAM halten möchte. Und da sind 32 Bit Systeme nunmal Mist, auch wenn sie ausreichend RAM zur Verfügung hätten.

    0

  • _Luckie schrieb:

    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.

    Lies mal den letzten Absatz des von dir verlinkten Artikels 🙄

    0

  • berniebutt schrieb:

    @Martin Richter:

    lassen wir doch hustbaer auf seiner Meinung 32/64-bit herumreiten wie er will.

    Gehts noch?

    Er kannte keine 8/16-bit-Systeme, mit denen PCs einmal angefangen hatten.

    Wenn du das sagst muss es wohl stimmen...

    0
Anmelden zum Antworten