Elasticsearch - Zu viele offenen Dateien

Question

Ich weiß, dass dies ein bekanntes und diskutierte Problem, aber ich würde nur hier die Dimensionen erhalten mag:

Ich bin mit ElasticSearch 2.4 auf einer einzigen Ubuntu Sever 16.04 node (12 cores, 256G ram). Ich habe erhöht (und über _nodes/stats/process verifiziert).

Ich habe zwei Indizes mit je 10 Shards (da bald mehrere Knoten dem Cluster beitreten werden).

Jetzt schreibe ich mit bis zu 900 gleichzeitige Java TransportClients, was zu einem Kollaps des ElasticSearch-Servers innerhalb von Sekunden führt, eine "zu viele offene Dateien" Ausnahme werfen.

Fehle ich hier etwas? Sind 900 gleichzeitige Schreibvorgänge zu viel für eine einzelne Instanz? Oder sind 10 Shards zu viele für einen Knoten?

Answer 1

Hier ist, was der Fall entpuppte:

• Verbindung über das Java TransportClient einen großen Aufwand erstellt. Es verwendet nicht die HTTP-REST-API, sondern ein ES-Binärprotokoll. (wie erläutert here)
  • Abfragen über den TransportClient sind vernachlässigbar schneller als über REST.
  • Der TransportClient erstellt auf dem Client einen Thread-Pool, der ab sofort nicht konfigurierbar ist. Es wird mehrere Verbindungen aufrechterhalten, damit die Knoten und die Failover-Fähigkeit Cluster-Statistiken usw. abfragen können. Dies führt zu einer beträchtlichen Langzeitbelastung des Clients.
  • In unserem Fall hat jeder weitere angeschlossene TransportClient ca. 1000 offene Dateideskriptoren auf dem ES-Rechner erstellt.

Wir wechselten zu Jest Client, der erheblich die Belastung sowohl auf Client und Server reduziert. 900 gleichzeitig aktive Clients ergeben nun < 2000 Dateideskriptoren auf dem Server.

Dank Andrei Stefan für uns in die richtige Richtung.