net / http Server: zu viele offene Dateien Fehler
Ich versuche, einen einfachen Jobwarteschlangenserver mit einem Worker zu entwickeln, der ihn abfragt, aber ich habe ein Problem mit meinem net / http-Server festgestellt. Ich mache sicherlich etwas schlechtes, aber nach ca. 3 Minuten beginnt mein Server:
Ссылка
Zur Information erhält er 10 Anfragen pro Sekunde in meinem Testfall.
Hier sind zwei Dateien, um diesen Fehler zu reproduzieren:
%Vor%Ich habe bereits eine Suche nach diesem Fehler durchgeführt und ich habe eine interessante Antwort gefunden, aber keine davon hat mein Problem behoben.
Die erste Antwort, die ich gesehen habe, war, den Body in der http.Get-Antwort korrekt zu schließen, wie Sie sehen können.
Die zweite Antwort war, den Dateideskriptor ulimit meines Systems zu ändern, aber da ich nicht kontrollieren werde, wo meine App läuft, bevorzuge ich diese Lösung nicht (aber zur Information ist sie auf meinem System auf 1024 gesetzt)
Kann mir jemand erklären, warum dieses Problem auftritt und wie ich es in meinem Code beheben kann?
Vielen Dank für Ihre Zeit
BEARBEITEN:
BEARBEITEN SIE 2: In Kommentar Martin sagt, dass ich den Körper nicht schließe, ich habe versucht, es zu schließen (ohne zu verschieben), und es hat das Problem behoben. Danke Martin! Ich dachte, dass ich meinen Aufschub weiterführen werde, ich lag falsch.
3 Antworten
Ich habe einen Beitrag gefunden, der das Grundproblem erklärt in viel mehr Details. Nathan Smith erklärt sogar, wie Timeouts auf der TCP-Ebene kontrolliert werden können, falls nötig. Im Folgenden finden Sie eine Zusammenfassung von allem, was ich zu diesem speziellen Problem finden konnte, sowie die Best Practices, um dieses Problem in Zukunft zu vermeiden.
Problem
Wenn eine Antwort empfangen wird, unabhängig davon, ob response-body erforderlich ist oder nicht, wird die Verbindung aufrechterhalten, bis der response-body-Stream geschlossen wird. Schließen Sie daher, wie in diesem Thread erwähnt, immer den Antwort-Body. Auch wenn Sie den Body-Inhalt nicht verwenden / lesen müssen:
%Vor%Best Practice
Wie von Nathan Smith erwähnt, verwenden Sie nie http.DefaultClient in Produktionssystemen, dies beinhaltet Aufrufe wie http.Get , da% cos_de% an seiner Basis verwendet wird.
Ein weiterer Grund, http.DefaultClient zu vermeiden, ist, dass es ein Singleton (Paketlevelvariable) ist, was bedeutet, dass der Garbage Collector nicht versucht, es zu bereinigen, was dazu führt, dass nachfolgende Streams / Sockets im Leerlauf bleiben.
Erstellen Sie stattdessen Ihre eigene Instanz von http.DefaultClient und denken Sie daran, immer eine vernünftige http.Client anzugeben:
Sicherheitsnetz
Das Sicherheitsnetz ist für diesen Neuling im Team, der die Fehlmengen von Timeout nicht kennt. Oder sogar diese sehr nützliche, aber nicht so aktive Open-Source-Bibliothek, die immer noch mit http.DefaultClient -Aufrufen gespickt ist.
Da http.DefaultClient ein Singleton ist, können wir die Einstellung http.DefaultClient leicht ändern, um sicherzustellen, dass Legacy-Code nicht dazu führt, dass inaktive Verbindungen geöffnet bleiben.
Ich finde es am besten, dies in der Timeout -Datei in der package main -Funktion festzulegen:
Bitte beachten Sie, dass in einigen Fällen die Einstellung in /etc/sysctl.conf net.ipv4.tcp_tw_recycle = 1
Kann diesen Fehler verursachen, weil TCP-Verbindungen geöffnet bleiben.
Tags und Links go