Улучшено использование памяти сервером Vert.x.

У меня есть веб-сервер Vert.x, который предоставляет службу Websocket. Сервер Vert.x отправляет некоторые данные клиенту, когда клиент регистрируется на сервере, а затем клиент отправляет ACK обратно на сервер, чтобы убедиться, что эти данные уже доставлены надежно.

Я обнаружил, что сервер Vert.x потребляет много памяти после завершения всей работы.

Ниже приведены шаги для воспроизведения проблемы:

  1. Config JVM parameter before starting our test:
    • Open /vert.x-2.02-final/bin/
    • Измените значение JVM_OPTS с "" на "-Xms128M -Xmx128M"
    • Сохраните и выйдите, измените serverIpAddress на IP-адрес вашего сервера в VertXSocketClient.
  2. Клиент зарегистрируется на канале веб-сокета 1180 на сервере Vert.x. Вы можете получить код здесь: https://www.dropbox.com/s/ptenlx78iin8dmj/VertXSocketClient.java
  3. запустите testserver с помощью команды vertx run testserver.java

Использование памяти сервером Vert.x будет распечатано в вашей консоли в формате:

общая память - свободная память = используемая память (МБ)

System.gc()    
Runtime runtime = Runtime.getRuntime();
int mb = 1024 * 1024;
totalMemory = runtime.totalMemory() / mb;
freeMemory = runtime.freeMemory() / mb;

Я вызываю System.gc() каждые 5 секунд, чтобы освободить память. Да, я знаю. System.gc() не следует вызывать часто. Это негативно влияет на производительность системы. Используемая память не уменьшается без такой инструкции.

Вы можете скачать код здесь: https://www.dropbox.com/sh/6oxtfhgwffed72c/AAAX-BvYdGaTBgnRagxD9Bf-a/TestServer.java

  1. запустите VertXSocketClient с помощью команды vertx run VertXSocketClient.java

Клиент автоматически зарегистрируется на сервере канала веб-сокета, и экземпляр сервера отправит данные клиенту после завершения регистрации.

Вот пример кода для отправки данных клиенту:

byte[] serverResponseData = serverResponse.getBytes();
Buffer buffer= new Buffer(serverResponseData);  
ws.write(buffer);

С приведенным выше кодом используемая память будет составлять до 62 МБ после выполнения всей работы, тогда как если я закомментирую ws.write(buffer), то только до 15 МБ.

Я предполагаю, что сервер Vert.x всегда выделяет 62 МБ памяти на весь срок службы. Разве он не должен освобождать память после завершения работы?


person user3034559    schedule 13.08.2014    source источник
comment
Всем привет. Что именно вы ищете? Vert.x или, более конкретно, виртуальная машина не может знать, когда работа выполнена, и начинается ли действие, и многие, например. создаются потоки, создаются объекты для обработки соединений и т. д., конечно, он остается подготовленным и в некоторых случаях кэширует их. Я не изучал идеи вашего примера или Vert.x напрямую, но наличие одних пулов потоков и т. д. - это все, что запускается после ваших первых действий, слушая и ожидая большего. Некоторые будут позже удалены, некоторые никогда, потому что они ждут.   -  person INsanityDesign    schedule 14.08.2014
comment
Ваш общий размер процесса JVM составляет 15 МБ? это кажется маловероятным ... Как и вероятность того, что это 15 МБ только кучи.   -  person Pidster    schedule 15.08.2014
comment
Похоже, вы никогда не закрываете соединение WebSocket, поэтому оно останется открытым и доступным. Это, вероятно, объясняет использование памяти, которое вы видите. Увеличение использования памяти из-за вызова ws.write, вероятно, связано с увеличением размера буфера после записи, чтобы обеспечить возможность записи в будущем, хотя это всего лишь предположение. Однако я скажу, что на самом деле не нахожу эти цифры особенно высокими, поэтому я не уверен, почему вы беспокоитесь об этом.   -  person KennethJ    schedule 12.10.2014


Ответы (1)


Вам обязательно следует проверить конфигурацию Hazelcast map, если вы используете Vert.x. Возможно, это не связано с вашей проблемой и использованием Vert.x, но у меня были похожие проблемы с использованием памяти, и я обнаружил, что моя конфигурация (в cluster.xml) не подходит для моих вариантов использования.

Некоторые моменты, которые вы должны проверить в конфигурации Hazelcast:

  • backup-count — по умолчанию у Hazelcast есть одна резервная копия синхронизации.
  • time-to-live-seconds - Максимальное время в секундах, в течение которого каждая запись карты остается на карте, по умолчанию равно 0 (infinite).
  • max-idle-seconds - Максимальное время в секундах, в течение которого каждая запись остается бездействующей на карте, по умолчанию равно 0 (infinite).
  • eviction-policy - NONE политика выселения для Карт используется по умолчанию

Дополнительные сведения см. в документации по карте Hazelcast.

person lu_ko    schedule 06.12.2016