Фикс BungeeCord - расход оперативной памяти.

На данный момент проблема расхода памяти решена. Тему решил не бросать, а выкладывать свежие сборки с исправлениями, т.к. по непонятной причине, разработчики проблему признали и обещали включить исправление, но делать это не спешат.

UPD 15.10.15


Свежая сборка - 1087 BungeeCord !
- Исправлено управление channel buffers. Расход ОЗУ в 10 раз меньше
(у меня лично вместо 2-4 Гб теперь 200-300 Мб)
- Убрано сообщение в консоли "InitialHandler has connected"
- Принимаются идеи, что еще можно косметически улучшить.

13.08.15
- Исправлено управление channel buffers.
- Поддерживает подключение клиентов 1.7.10 (на сервере должен быть установлен плагин ProtocolSupport by Schevchik)
- Поддержка клиентов MCPC+
- Вырезано сообщение об устаревшей версии с задержкой старта.
скачать
(*Если вы не планируете использовать клиенты 1.7.10, то рекомендуется предыдущая версия. Там есть некоторые улучшения, т.к. базируется на более свежей сборке)







ПРЕДИСТОРИЯ ТЕМЫ:

У меня работает два прокси-сервера BungeeCord.

Первый - с включеным ОнЛайн - мод. Через него заходят, правда, не так много людей - в день средний он-лайн 15-20 чел., но он работает неделями, при этом использует всего 200 Мб. Есть несколько плагинов (BAT, TabListPlus, Redis, Yamler)

Второй - ОнЛайн - мод офф, вот с ним проблема.. Плагины те же самые, что и на первом. Игроков побольше, чел. 30-50. По началу берёт так же 200Мб, но потом больше,больше... в итоге, через сутки работы >4Гб. Самое интересное, что ночью, когда остаётся 5-10 чел на сервере, память не высвобождается..

Вот решил поинтересоваться, у кого какой расход.

 

Строка запуска таже?

 

Я както не парюсь на счёт банджи. Я тупо выделил ей 5гигов.

 

Версия Банжи одна и та же, строка запуска одинаковая. java -server -Xmx8G -Dfile.encoding=UTF-8 -jar BungeeCord.jar
Плагины одинаковые. Всё отличие- в одной online mod, в другой offline. Чутьё говорит, где-то тут собака порылась..
Ведь такой расход не нормально, поскольку при 200 чел. он-лайн доходило до 10Гб. Как же работают сервера, где тысячи людей??
В то же время разработчики заявляют, что прокси очень экономен, и потребляет в среднем 5мБ на человека..

 

Дурачок что ли?) Не выделяй ему памяти максимальной ВООБЩЕ. Вот норм строка запуска: java -jar BungeeCord.jar.
Читай хоть иногда описание к тому, что качаешь. на дженкинсе все было же написанно...

 

Ну зачем так резко.. Запускал в десятках различных комбинациях, в т.ч. и такой. Без ограничения, за сутки пожирает до 10 Гб, и ночью, когда народу мало, не высвобождает, приходится каждый день перезапускать вручную.

Спрошу по другому,каким образом онлайн-мод может так влиять? Что при этом меняется?
(ничего не трогая, только в настройках ставлю онлайн-мод, и прекрасно работает на 75-100 Мб)

 

Сегодня был онлайн 39, банджа сейчас использует 542мб.

 

Ну чтож, кто поможет акромя самог себя)
Засучил рукава, заскрипел мозгами, скинул дамп памяти за день работы.
Первое, что удивило, это 28млн объектов))


Второе- что весь OldGen забит Netty.. Кто подскажет, куда дальше копать??

 

Честно, уже всё перепробовал.. Даже полностью переустановил систему вчера, всё ПО свежее, чистое. Java8-45.. И всё равно - включаю он-лайн мод - 150Мб, ничего больше не меняя ставлю автономный - за час - гигабайт..
Была надежда, что обновление ПО поможет, ан нет.. Значит, буду копать внутренности Банжи. Разбираться, в чём отличие он-лайн и офф-лайн режима в коде.

 

Попробуй эти аргументы, но навряд ли они помогут, но всё же попробуй.

Код:

 java -Dfile.encoding=utf-8 -Xincgc -server -Xmx8192M -Xms100M -XX:MaxPermSize=640M -XX:+UseConcMarkSweepGC -XX:+UseBiasedLocking -XX:+AggressiveOpts -XX:UseSSE=4 -XX:+UseFastAccessorMethods -XX:+OptimizeFill -XX:+DisableExplicitGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+CMSParallelRemarkEnabled -XX:MaxGCPauseMillis=30 -XX:TargetSurvivorRatio=90 -jar BungeeCord.jar nogui -o true

 

Спасибо за подсказку, пробовал как последнюю надежду - результат тот же. В течении дня heap не спеша растёт до немыслимого размера.

Немного напряг мозги, почитал/поискал, использовал разные методы профилирования, и пришел к выводу, что причиной заполнения памяти является использование DirectByteBuffer, куда закидывает данные протокол Netty.

Вот инфографика:


Вот какую информацию нашел на просторах сети:

Спойлер: eclipse

Прямые ByteBuffers
ВытяжкойСтолы родной памяти другой вопрос, связанный с JVM ошибок. Симптомы, которые нужно посмотреть являются размер процесса растет, но использование кучи оставаясь относительно постоянной. И компилятор и NiO ByteBuffers может потре****ь родной памяти. Oracle ошибка 6210541 обсуждается еще нерешенная проблема которой сам JVM выделяет прямую ByteBuffer в некоторых обстоятельствах, а система никогда не собирает мусор, эффективно еды родной памяти. Блог Гая Korland обсуждает эту проблему здесь и здесь. Как компилятор потребляет родной памяти, отсутствие доступной памяти может проявляться в качестве JIT OutOfMemory исключениями, такими как Exception in thread "CompilerThread0" java.lang.OutOfMemoryError: requested xxx bytes for ChunkPool::allocate. Out of swap space? Exception in thread "CompilerThread0" java.lang.OutOfMemoryError: requested xxx bytes for ChunkPool::allocate. Out of swap space?

По умолчанию, Причал выделяет и управляет свой собственный бассейн прямых ByteBuffers Ио, если настроить НИО SelectChannelConnector. Он также выделяет MappedByteBuffers в памяти карты статических файлов с помощью настроек DefaultServlet. Тем не менее, вы могли бы быть уязвимы для этой проблемы распределения JVM ByteBuffer если вы отключили либо из этих вариантов. Например, если вы находитесь на Windows, вы можете отключить использование буферов памяти, отображается для статического файла кэша на DefaultServlet, чтобы избежать проблемы блокировки файлов.

Ссылка1

Спойлер: eclipse

Не используйте прямые буферы для короткоживущих, редко используемых объектов

Новый I / O (НИО) классов в java.nio позволяют создавать и использование прямых буферов. Эти буферы чрезвычайно увеличить пропускную за неоднократные деятельности I / O. Тем не менее, их создание и восстановление дороже, чем создание и рекультивации кучи на основе непрямых буферов, потому что прямые буферы управляются с помощью OS-специфический машинный код. Это добавленная стоимость управления делает прямые буферы плохой выбор для одноразового использования или редко используемых случаях. Прямые буферы также выходит за рамки сборщиком мусора в Java; следовательно, необдуманное использование прямых буферов может привести к утечке памяти. Наконец, часто распределение больших прямых буферов может привести к OutOfMemoryError.
Несовместимые Пример кода

Это несовместимые пример кода использует как кратковременный локальный объект, rarelyUsed-буфер, и долгоживущий, активно используется объект, heavilyUsedBuffer. Оба выделяются в не-динамической памяти; ни один не сборщиком мусора.

Ссылка2

По-идее, всё сходится. В буфере постепенно оседают некие данные от Netty, которые не вычищаются GC. Один программист писал, что буфер очищается, когда не него перестаёт ссылаться поток (java.lang.Thread ). В своём веб-приложении од сделал периодический сброс потока, и тогда связанные с ним данные собирались при следующем проходе GC. Но мне так не сделать, поскольку при этом будет выкидывать с сервера людей, которые висят на этом потоке..

Теперь осталось найти ответ на два вопроса:
- Эта проблема только у меня? Тогда какая особенность компьютера/интернет-канала может привести к ней?
- Как найти, какие данные и почему зависают в буфере и как их удалять?

Нужен совет гуру java, Шевчика или alexandrage, но они пока в эту тему не заглядывали)

 

У тебя последняя версия банджи? На скоко я знаю, что банджи нормально пингуеться с 1.7-1.8, и везде есть кнопка зайти на сервер в меню майна.[DOUBLEPOST=1436089678,1436089481][/DOUBLEPOST]У меня банджи работает больше 24 часов и есть всё волишь 729мб, онлайн около 35.

 

Это тоже много. После рестарта (у меня примерно такой-же он-лайн) банжи "летает" на 150-200 мб., и постепенно начинает заполнять этот долбаный буфер..

Для интереса, посмотри в javaVM, сколько у тебя сжирают данные в буфере, лежащие камнем?
Просмотреть именно объём буфера можно, установив в JVM плагин Visual-VM BufferMonitor.
И потом интересно, растёт ли у тебя расход памяти, если работать дольше (2-3 дня??) И высвобождается ли ночью, когда никого нет?

 

Можешь написать как это сделать? Просто я ничего не понял.

 

Эмм.. Java VisualVM есть у тебя? Если нет, то поставь)

 

Можешь написать как? Надо себе на комп ставить, или на хост? На хосте у меня Debian.
Сори за тупость.[DOUBLEPOST=1436093797,1436093361][/DOUBLEPOST]Установил на винду, как добавить туда удалёный хост?

 

Ааа, у тебя хостинг.. Я уже отвык от этого) Это приложения java, его нужно запускать на сервере.
http://visualvm.java.net/download.html
Видимо, нужно запускать на хосте, но как видеть, что оно выводит.. Интересный вопрос))




PS важное дополнение:
Я вычислил, что, когда присоединяется каждый игрок, DirectBuffer увеличивается на 16MB, но, когда игрок отключается, эта память не освобождается, а увеличивается еще на 16 мб !!


И соответственно, за день проходит около тысячи подключений, и в буфере собирается мусора на 3 гига..
Что это за дела??

 

Ты пробовал обновлять банджи?

 

не то слово.. И разные версии, и компилировал с исходников на гите, и даже сам изловчился обновить нетти (с 4023 на 4029) ).. Запускаю вообще без плагинов, с разными параметрами, на винде и юбунте, и всегда буфер ведёт себя одинаково - прибавляет по 16мб при присоединении, и еще 16мб при выходе. Gc этот буфер не вычищает даже принудительно.

 

Странно. Заддосил свой сервак майна ботами, 240 онлайн набил.


А используется стоко оперативки после атаки: