Ich führe viele statistische Analysen mit R durch und nutze große Multicore-Instanzen auf AWS intensiv aus. Hauptsächlich für Hyperparametersuchen, Kreuzvalidierung und Bootstrapping.
Angenommen, ich habe eine Instanz mit cKernen und einen Job mit Replikaten, die jeweils r >= can Kerne ausgelagert werden . Aufgrund von Systemprozessen (z. B. meinem laufenden SSH-Client ) werden nun neben meinen Replikaten noch weitere Jobs ausgeführt. chtopc
Soweit ich die Funktionsweise des Betriebssystems verstehe, bedeutet dies, dass es einen Prozess gibt, der meine Jobs beendet, damit htop(und was auch immer) auf die Prozessoren zugreifen kann. Nachdem ich diesen verschiedenen Prozessen etwas Zeit gegeben habe, werden meine Jobs fortgesetzt.
Wenn ich mir anschaue htop, sehe ich viel Rot, gemischt mit Grün. Ist es richtig zu sagen, dass das Grün meine Arbeit ist und das Rot Hintergrundmaterial, das meine Arbeit ermöglicht?
Intuitiv scheint diese Art des Mischens nicht optimal zu sein. Hier ist also meine direkte Frage: Wenn ich Zugriff auf cKerne habe, sollte ich meine Replikationsaufträge allen zuweisen coder vielleicht c-1etwas anderes?
Ich stelle mir auch vor, dass es viele Details darüber gibt, wie Rechenressourcen Jobs zugewiesen werden, die ich nicht verstehe und übergehe. Was würde es bedeuten, wenn alle meine Jobs an c-1Kerne und alle Systemprozesse an den cthKern gehen würden? Würde das mein gesamtes htop grün machen, bis auf einen Balken? Und würde das irgendeinen Sinn ergeben?
Ich könnte zwar Benchmarking-Experimente durchführen, aber das wäre bei riesigen Instanzen und Datensätzen schwierig, und ich bin mir nicht sicher, was ich lernen würde, wenn man bedenkt, wie viele Dinge anwendungsspezifisch sein werden. Ich möchte also besser verstehen, wie die Dinge funktionieren.
Antwort1
Es ist schwierig, die genaue Auswirkung auf eine bestimmte Anwendung ohne Experimente zu kennen, ABER die allgemeine Faustregel lautet, dass es von Vorteil ist, die Anzahl der Kerne um einen kleinen Betrag zu überschreiten (die meisten Kompilierungshandbücher empfehlen beispielsweise, make mit der Anzahl der Kerne/Threads + 1 aufzurufen), aber eine große Überschreitung ist aufgrund des zusätzlichen Aufwands wahrscheinlich kontraproduktiv. Der Grund dafür ist, dass die anderen Threads noch fortfahren können, wenn einer (oder mehrere) der Tasks schläft und auf I/O oder Timer oder was auch immer wartet.
Die Arbeitsverschiebung (OS-Planung) findet auf allen modernen Betriebssystemen statt und ist etwas, mit dem wir arbeiten sollten, anstatt dagegen anzukämpfen. Wenn es den Anschein hat, dass etwas Unzusammenhängendes konkurriert, können Sie das nette Niveau Ihres Prozesses senken, aber auf einer dedizierten AWS-Instanz ... ist es schwer vorstellbar, dass das nötig ist.