Максимальные параллельные соединения на orientdb 2.1.11

Question

У нас есть повторяющаяся ошибка на версии 2.1.11, при маршрутизации трафика в БД (при настройке 3 узла), в то время как мы используем только один из узлов на данный момент , потому что у нас были другие проблемы с распределенными узлами.

Ошибка, с которой мы сталкиваемся каждый раз, когда мы отправляем трафик, - это максимальное количество одновременных сеансов. (См. Снимок ошибки, как указано ниже).

2016-03-04 10: 17: 00: 594 светосигнальные устр Достигнуто максимальное количество одновременных соединений (макс = 1000, ток = 1000), отклонение входящего соединения от /10.43.1.238:43635 [OServerNetworkListener]

сервер конфигурации клиент для DB бассейна:

orient.db.minPool = 50 
orient.db.maxPool =100 

Во время этой ошибки в NetStats на клиенте:

150 TIME_WAIT 
99 ESTABLISHED 
10 LISTEN 
1 SYN_SENT 

Стенд одна конфигурация сервера является:

<handler  class="com.orientechnologies.orient.graph.handler.OGraphServerHandler"> 
<parameters> 
<parameter name="enabled" value="true"/> 
<parameter name="graph.pool.max" value="50"/> 
</parameters> 
</handler> 

<entry name="db.pool.min" value="100”/> 
<entry name="db.pool.max" value="400"/ > 

В момент возникновения ошибки сетевого сервера Статистика:

netstat -a | grep -i client-server | egrep -c 'ESTABLISHED|LISTEN|TIME' 949 

Распад соединений:

576 TIME_WAIT 
330 ESTABLISHED 
13 LISTEN 

H/W конфигурации: OS - DEBIAN сжимают 64 бит, JAVA 7, RAM 48G, двухъядерный сердечник.

Мы боимся увеличить ограничение по умолчанию для сетевых подключений (1000) и хотим выкопать, почему серверный сервер orientdb объединяет максимальные соединения. Было бы интересно узнать жизненный цикл OClientConnection, чтобы помочь нам понять, как транзакция открывается и закрывается.

Answer 1

@Lvca, я коллега Shobhit, оригинальный постер вопроса. Клиентская библиотека - eastdb-client-2.1.11.jar.

@Alessandro, я понял, что поведение по умолчанию для storage.keepOpen является истинным и должно быть явно установлено в false (путем добавления свойства на сервере или JVM), но интересно, что он делает и как это связано с проблема мы видим.

Кроме того, что может объяснить 570+ гнезд TIME_WAIT, поток/FD count также срабатывает одновременно, когда мы видим это предупреждение. Я подозреваю, что потоки orientdb накапливаются и блокируются на ресурсах, из-за которых он не может обрабатывать больше соединений и как мы сопоставляем это с клиентом?