Bei einem abweichenden Code, der durch eine etwa 10 MB große UID-Tabelle und eine zweite Tabelle durchgeht, und bei den Ergebnissen des Leistungsmonitors ist mir aufgefallen, dass die Seitenfehler beim Klicken auf "Ausführen" stetig ansteigen. Es wird etwa 5000 / s hoch sein und der Systemcache sinkt ständig. Interessanterweise scheint dies auch der allmählichen Verlangsamung der Schleife zu entsprechen.
Ich bin kein Entwickler und kann Ihnen beim ersten Teil Ihrer Frage leider nicht helfen, aber als Ingenieur kann ich etwas Licht in die Hardware / Betriebssystem-Beziehung bringen.
Bitte haben Sie Verständnis dafür, dass es keine einfache Möglichkeit gibt, dies zu erklären, ohne zuerst tief in die grundlegenden Unterschiede (und Ähnlichkeiten) eines Betriebssystems und der Plattform-Hardware zu tauchen. Aber hier geht es:
Außerdem hilft es Ihnen zu wissen, dass die gesamte Plattform auf ihrer einfachsten Stufe aus einer langen Treppe mit Cache-Ebenen besteht, entweder physischer Cache für die CPU (L1, L2, L3, L4, RAM, Festplatte usw.) oder virtueller Cache Ebenen für Prozesse und OS Memory Mangler. (Privates Arbeitsset bearbeiten, Arbeitsset, Standby usw.).
Page-Fehler gibt es in zwei Ausführungen: weich und hart. Ein Soft- Page-Fehler tritt auf, wenn ein Prozess eine Seite anfordert, die sich nicht innerhalb seines Arbeitssatzes befindet, auch der für den Prozess verfügbare Adressbereich . Die Seite befindet sich normalerweise im RAM als Teil der "Standby" -Liste im Task-Manager (zwischengespeicherte Dateien).
Die Beschreibung Standby ist irreführend, da in Wirklichkeit alle von der CPU abgebildeten Seiten Teil des Systemarbeitssatzes sind. Sogar zwischengespeicherte Dateien.
Eine CPU kennt den Speicherort einer angeforderten Seite im primären (RAM) oder sekundären (HDD) Speicher - RAM oder der HDD (AKA-Cache-Level - sehen Sie?). Es kümmert sich um nichts anderes.
Die CPU bewegt die Seite nicht, sie bewegt den Zeiger.
Zusammengefasst: Ein Soft Fault ist ein Paging in den Prozessadressraum und aus diesem heraus - z. B. Working Set auf Standby und wieder zurück. Es ist jedoch kein wirklich großes Problem.
Ein Hard- Page-Fehler tritt auf, wenn sich die angeforderte Seite nicht im RAM, sondern in der Seiten-Datei der Festplatte befindet. Harte Seitenfehler treten nicht auf, wenn die Seitendatei (offensichtlich) deaktiviert ist.
Bei Softfehlern, wenn freier Speicher verfügbar ist, kann die Größe des Arbeitssatzes (Registrierung und Gruppenrichtlinienobjekt-Editor) und / oder RAM erhöht werden.
Ich habe einen interessanten und hochgewählten Beitrag gelesen, den ich jetzt nicht finden kann (aber ich denke, er wurde hier veröffentlicht), in Bezug auf die Seitendatei, in der der Benutzer darauf hingewiesen hat, dass in Windows niemals wirklich "freier" RAM vorhanden ist. Es wird ständig präventiv gefüllt, die Dinge werden ausgelagert und dann ausgegeben, wenn etwas anderes Platz benötigt.
Nicht wahr.
Für eine optimale Leistung sollte immer mindestens etwas freier Arbeitsspeicher vorhanden sein, damit die Seiten direkt vom Laufwerk eingelesen werden können. Andernfalls müssen Standby-Seiten zuerst verworfen und Seitentabellen aktualisiert werden. Das braucht Zeit.
Wenn es kein Free gibt, benötigt die Maschine mehr RAM.
Es scheint einige extrem gemischte Meinungen darüber zu geben, ob die Auslagerungsdatei aktiviert werden soll oder nicht.
Ich habe sowohl die Aktivierung als auch die Deaktivierung versucht und sehe das gleiche Muster bei auftretenden Seitenfehlern.
Die Seitendatei war für Intel IA-32e / Intel-64-Prozessoren mit 32-Bit-Adress-Pins erforderlich, um unter Windows x86 mit PAE oder Windows 64 RAM auszuführen.
Die Seitendatei war die einzige Möglichkeit, mit der diese CPUs Adressen von mehr als 4 GB erreichen konnten, was das Betriebssystem voll und ganz erreichen konnte.
Entgegen dem weit verbreiteten Mythos, PAE in dem O steht für Seite Address Extension NICHT Physical Address Extension. Mit der Seitenadresserweiterung können Adressen mit mehr als 4 GB vom Betriebssystem erreicht werden, vorausgesetzt, die CPU verfügt über interne 36-Bit-Register.
Wenn die Seitenadresserweiterung auf CPUs mit 32-Bit-Registern aktiviert ist, ist die Hölle los. 32/32 CPUs (32 externe Pins / 32 interne Register) können Adressen von bis zu 4 GB erreichen.
Edit: Ich habe weitere zufällige, aber relevante Punkte hinzugefügt, um das Gesamtbild klarer zu machen ... hoffentlich habe ich es nicht übertrieben.
E ** Hinweis: Früher habe ich IA-64 fälschlicherweise als x86-64 benannt. Ich sollte Intel-64 gelesen haben .
IA-64 ist x64.
** 32/36 (IA32e / Intel 64) Der AKA x86-64 kann Segmente mit mehr als 4 GB und 2x 4 GB ansprechen. Ein 4-GB-Segment ist RAM, das andere Segment ist die Auslagerungsdatei. Primär- und Sekundärspeicher. RAM ---> CPU: Externe Adresspins, CPU ------> HDD: Interne Datenregister.
Die 36-Bit-Seitenadresserweiterung reduziert den Prozessadressraum auf IA32e / Intel64 auf 3,5 GB, 512 MB sind für das CPU-Seitentabellenverzeichnis reserviert und die zusätzlichen 4 Bit für den Segmentverzeichniszeiger
Haben Sie sich jemals gefragt, warum mit x87 kompilierte Spiele nie mehr als 3,6 GB zu verwenden scheinen? Der Grund dafür ist, dass der Intel-Compiler Hochzeiger abschneidet. Die anderen ~ 512 MB sind als reserviert markiert. Auf 64-Bit-Hardware ist der Prozess für rund 500 MB VADs permanent als freier Speicherplatz gekennzeichnet.
Intel IA-32e / Intel-64 ist ansonsten als x86-64 bekannt. x86-64: Eine CPU mit 32 Pins zum RAM, die über interne Register und eine Auslagerungsdatei auf der Festplatte für Seiten 4 GB fähig ist.
Keines der oben genannten Probleme wirkt sich übrigens auf das RAM aus. Eine CPU mit 32 Pins kann nicht mit Speichermodulen mit einer Dichte von mehr als 4 GB kommunizieren. Dies ist eine Hardwarebeschränkung.
Es wäre, als würde man versuchen, einen Freund über ein Festnetz ohne Telefon anzurufen - nur ein Telefon. : P
Physical Address Extension ist eine Intel-CPU-Architektur-Nomenklatur, die sich auf die CPU-Adress-Pins im RAM bezieht. Das oben Gesagte ist in den Intel-Dokumenten eindeutig angegeben.
Die Seitendatei wurde auf CPUs mit 36-Bit-Adress-Pins noch nie benötigt. (AMD64 / IA64)
BTW, verwandte Artikel wie Wikipedia, Technet, MSDN usw., die sich auf Windows-Speichergrenzen und PAE beziehen, sind zum größten Teil völlig falsch oder irreführend.
Microsoft sind in dieser Hinsicht die schlimmsten Täter.
Ich bin neugierig, ob dies möglicherweise mit der Priorisierung des Speichers in neueren Windows-Versionen zusammenhängt. Mir ist bewusst, dass ich die Priorität eines Prozesses im Task-Manager erhöhen kann. Erhöht dies jedoch die Priorität der Arbeitsspeicherzuordnung im Gegensatz zu nur der Priorität des Prozessorthreads? Gibt es überhaupt solche Prioritäten dauerhaft zu setzen, ohne proprietäre Software zu verwenden? Ich stelle fest, dass Windows versucht, durch präventives Zwischenspeichern im RAM zu helfen, jedoch scheint dies bei R überhaupt nicht zu helfen. Gibt es überhaupt eine Möglichkeit, das Caching-Profil selektiv zu erzwingen oder zu ändern? Für mehr speicherintensive Arbeit würde ich es vorziehen, wenn nichts zwischengespeichert wurde, das ich eigentlich nicht verwende.
Es sollte so viel wie möglich zwischengespeichert werden
Ein großartiger Artikel, der viele Fehlinformationen entlarvt: Dateicache- Leistung und Optimierung .