Das Problem stellte sich heraus, eine Kombination von Windows 7, .NET 4.5 (oder eigentlich die 4.0-Laufzeit) und die starke Verwendung von Tail-Rekursion in F #/Deedle.
Mit dem Visual Concert Visualizer von Visual Studio habe ich bereits festgestellt, dass die meiste Zeit damit verbracht wird, in Invoke-Aufrufen zu warten. Bei genauerem Hinsehen dieses Ergebnis in der folgenden Anrufverfolgung:
ntdll.dll:RtlEnterCriticalSection
ntdll.dll:RtlpLookupDynamicFunctionEntry
ntdll.dll:RtlLookupFunctionEntry
clr.dll:JIT_TailCall
<some Deedle/F# thing>.Invoke
für diese Funktion Suche gab mehrere Artikel und Forenthreads anzeigt, dass F # unter Verwendung von in einer Menge Anrufe zu JIT_TailCall führen kann und dass .NET 4.6 verfügt über eine neuen JIT-Compiler, der sich mit einigen Problemen in Bezug auf diese Aufrufe zu befassen scheint. Ich habe zwar keine Probleme mit Sperren/Synchronisation gefunden, aber das hat mir die Idee gegeben, dass das Aktualisieren auf .NET 4.6 eine Lösung sein könnte.
Auf meinem eigenen Windows 8.1-System, das auch .NET 4.5 verwendet, tritt das Problem jedoch nicht auf. Nach der Suche ein wenig nach ähnlichen Invoke rufen fand ich, dass die Anrufverfolgung auf diesem System sah wie folgt aus:
ntdll.dll:RtlAcquireSRWLockShared
ntdll.dll:RtlpLookupDynamicFunctionEntry
ntdll.dll:RtlLookupFunctionEntry
clr.dll:JIT_TailCall
<some Deedle/F# thing>.Invoke
Offenbar in Windows 8 (0,1) wurde der Verriegelungsmechanismus auf etwas weniger streng, geändert, die in Folge in viel weniger Notwendigkeit, auf das Schloss zu warten.
Also nur mit der Zielsystemkombination von Windows 7's striktes Sperren und weniger effizientem JIT-Compiler von .NET 4.5, verursachte F # 's starke Verwendung der Tail-Rekursion Probleme. Nach dem Update auf .NET 4.6 ist das Problem verschwunden und unser Dienst läuft wie erwartet.
Ich glaube nicht, dass Deedle eine ausgeklügelte Thread - Synchronisation ausführt, die dazu führen würde, dass das Programm langsam läuft - obwohl Sie, wenn Sie aus mehreren Threads auf denselben Frame/Serie zugreifen, möglicherweise Auswirkungen auf CPU - Caches haben Overhead der Parallelisierung ist größer als der Nutzen davon. –
@TomasPetricek Für unsere Verwendung können die Threads als ziemlich unabhängig angesehen werden. Natürlich fällt es mir schwer zu sagen, was in Bibliotheken passiert (oder noch tiefer in CLR). Soweit ich in der Lage war zu messen (z. B. mit Intels PCM), ist Caching kein Problem. Die seltsame Sache ist, dass Sie zumindest erwarten würden, dass es ähnlich wie das aktuelle System läuft, wenn die Anzahl der Threads (auf beiden Systemen) begrenzt wird. – mweerden
Haben Sie im Code genügend Sleep-Anweisungen, die den Thread inaktiv machen, sobald er nichts mehr zu tun hat? Es scheint so, als würden Threads konkurrieren, sie könnten einfach Looping ohne Pausen machen? –