Ich habe eine Anwendung (C# .Net 3.5 und. NET 2.0), die mehrere Readfile-Operationen durchführt. Das System zeigt jedoch immer wieder hickups (Jitter). Ich habe VTune Profiler angeschlossen und führte eine Sperren & wartet Analyse, siehe das erste Bild unten.(Lesen) Datei E/A-Jitter
Die Analyse der Sperren und Wartezeiten zeigte, dass ein "Sync-Objekt: Stream-Dateipfad" dazu führt, dass die Anwendung auf allen Threads gesperrt (wartet) wird. Die CPU-Auslastung sinkt während dieser Zeit auf 0%.
Als nächstes verwendete ich SysInternals Process Monitor, um zu protokollieren, welche Operation ausgeführt wurde, als die hickups auftraten. Es zeigt einen FileRead-Vorgang an, der ca. 1 Sekunde, aber nur gelegentlich (Jitter). Siehe das zweite Bild.
Ein-Klick-große Version des Bildes: here
Einzelklick große Version des Bildes: here
Ich bin verwirrt. Was könnte diesen Jitter in File I/O verursachen? Es ist ein synchrones Lesen. Ich habe versucht, den Lesepuffer von 32.768b auf 4096b zu reduzieren, aber das hat nichts geändert. Vielleicht ist es wichtig zu beachten, dass die Maschine, die diese Zahlen sammelt, eine SSD hat. Auf Maschinen ohne SSDs sehen wir ähnliche Probleme.
Alle Leads in denen zu suchen wäre willkommen.
Quicklink große Version: 
Schnell größere Version: 
Sind Sie sicher, ist IO, nicht verarbeiten? Die GC-Sammlung würde dem Muster entsprechen. Nicht sicher, ob VTune es anzeigen kann, aber [WPA] (http://msdn.microsoft.com/en-us/library/windows/hardware/hh448170.aspx) kann die tatsächliche Ausführungszeit von IO im Gegensatz zur Zeit für das Blockieren von Apps anzeigen. –
Ich dachte das Gleiche, ich habe einen internen Garbarge Profiler verwendet, der keine sichtbaren Leads zeigte (keine GC2 Collections, welche die teuren sind). Dennoch bin ich mir immer noch nicht ganz sicher, ob GC vollständig verworfen werden kann, da es für mich schwierig ist, die GC2-Sammlungen mit den anderen Profiler-Protokollen zu vernetzen. Danke für die WPA, lass mich sehen ob ich sowas mit VTune reproduzieren kann. – bastijn
Fällt die CPU-Auslastung über das Board oder nur in den überwachten Threads auf Null? Wenn es wirklich Null ist, ist es wahrscheinlich nicht der GC (es blockiert alle verwalteten Threads, aber es verursacht idealerweise 100% CPU-Auslastung während dieser Zeit). Wenn es bis auf einen Thread null ist, ist es ein bisschen ein Hinweis auf GC als Täter. Und Sie irren sich, GC0 kann genau so langsam sein wie GC2, das hängt von Ihren Speichernutzungsmustern ab. – Luaan