Mehrere Server sind über RPC verbunden. Es gibt Zeiten, in denen Apps im Betriebssystem zu viele RPC-Aufrufe haben, was dazu führt, dass das Netzwerk geschlossen wird. Was ist der beste Weg, um mein Betriebssystem zu debuggen oder zu konfigurieren?
"msg":"sending ping message: write tcp 127.0.0.1:36802->127.0.0.1:1234: use of closed network connection"
"msg":"handle me:write tcp4 127.0.0.1:1234->127.0.0.1:56244: write: broken pipe"
Antwort1
Sie erwähnen nicht, welche Fehlerbehebung Sie durchgeführt haben, um zu dem Schluss zu gelangen, dass dies auf zu viele RPC-Aufrufe zurückzuführen ist, oder irgendwelche Details zum Status der Netzwerkverbindungen zum Zeitpunkt des Fehlers. Ich gehe davon aus, dass dieser Fehler durch Port-Erschöpfung aufgrund fehlender Verbindungspools zustande kommt.
Um zu prüfen, ob die Ports erschöpft sind, verwenden Sie netstat, um den Status der Ports auf dem Server abzurufen. Wenn eine übermäßige Anzahl von Ports aufgelistet ist, liegt wahrscheinlich ein Port-Erschöpfungsproblem vor.
gRPC bündelt Verbindungen automatisch, jedoch kann schlecht geschriebener Code die ordnungsgemäße Funktion beeinträchtigen, indem zu viele neue gRPC-Kanäle erstellt werden, anstatt vorhandene wiederzuverwenden. Ich habe auf die Dokumentation von Microsoft verwiesen, da dort beschrieben wird, wie das Erstellen neuer Kanäle zur Erstellung neuer HTTP/2-Verbindungen führt.
Um dies zu korrigieren, müssen Sie Ihren Code prüfen und ihn ändern, um Kanäle besser wiederzuverwenden.
Bewährte Methoden zur Leistung mit gRPC
Bei gRPC-Anrufen sollte ein gRPC-Kanal wiederverwendet werden. Durch die Wiederverwendung eines Kanals können Anrufe über eine vorhandene HTTP/2-Verbindung gemultiplext werden.
Wenn für jeden gRPC-Aufruf ein neuer Kanal erstellt wird, kann sich die dafür benötigte Zeit erheblich verlängern. Jeder Aufruf erfordert mehrere Netzwerk-Roundtrips zwischen Client und Server, um eine neue HTTP/2-Verbindung herzustellen:
Bewährte Methoden für die Leistung
Verwenden Sie Stubs und Kanäle nach Möglichkeit immer wieder.
Dabei können Sie Unix Domain Sockets anstelle von TCP-Sockets in Betracht ziehen. Wenn diese Anwendungen letztendlich verteilt auf mehreren Rechnern laufen, sollten Sie bei TCP-Sockets bleiben. Wenn sie immer auf derselben Maschine laufen, sollten Sie Unix Domain Sockets in Betracht ziehen.
So erstellen Sie einen GRPC-Dienst über einen lokalen Socket statt über Inet in Scala/Java