За трендами гнаться != инженерия... Продукт-то продукт, но вопрос какой он получится. Если просто хотелки заказчика(бизнеса) реализовать, то скорее всего получится плохой продукт, который полон антифич, лок-инов и основан на таком же...

Господа, подскажите направление поиска - исследую проблему, в определенном тесте система при большой нагрузке на опредленной ноде(на других не воспроизводится) происходит GC пауза 400мс, что для нашего проекта не допустимо.

копание показало следующее:

GC 
  (CMS Final Remark) 
    [YG occupancy: 142247 K (294912 K)]
2019-03-13T07:38:30.656-0700: 24252.576: 
    [Rescan (parallel) , 0.0216770 secs]
2019-03-13T07:38:30.677-0700: 24252.598: 
    [weak refs processing, 0.0028353 secs]
    
2019-03-13T07:38:30.680-0700: 24252.601: 
    [class unloading, 0.3232543 secs]
    
2019-03-13T07:38:31.004-0700: 24252.924: 
    [scrub symbol table, 0.0371301 secs]
2019-03-13T07:38:31.041-0700: 24252.961: 
    [scrub string table, 0.0126352 secs]
    [1 CMS-remark: 2062947K(4792320K)] 2205195K(5087232K), 0.3986822 secs]
    
    [Times: user=0.63 sys=0.01, real=0.40 secs]
      

сначала я решил, что мб классов много нагрузилось, и теперь их долго выгружать, но обратил внимание на факты:
1. во первых порядок времени исполнения других шагов несоизмеримо мал, по сравнению с выгрузкой классов
2. классы выгружаются из метаспейса, а он менеджется операционной системой, в нашем случае это линукс(не Солярис)
3. системные вызовы выполнились за сотую долю секунду, а вот реальное время исполнения(вместе с блокировками и прочим) - уже 400мс, - такие различия в порядках времени исполнения наталкивают на возможную мысль, что поток GC был заблокирован операционной системой какое то время.

еще немного покапав, я натолкнулся на аткую вещь как huge pages в Linux, и что такие проблемы бывают если в JVM передан флаг -XX+UseLargePages, но не передан флаг -XX:+UseLargePagesInMetaspace(начиная с java8)

но проблема в том, что -XX+UseLargePages у нас не передается - так что я в тупике

буду очень благодарен, если кто нить подскажет направление движения. к сожалению ноду пока что забрали и до следующей недели все что у меня есть это логи GC за дату и несколько граффиков в системе мониторинга. ну и логи приложения

Я бы посмотрел в сторону jvm флагов про metaspace.  -XX:MetaspaceSize и иже с ним. Возможно пауза из-за того, что размер увеличивается и начинается перенос всех сущностей. Если динамически классы не создаются в рантайме то размер metaspace должен имхо устаканиться.

пока ковырял - наткнулся на такую штуку: https://chriswhocodes.com/hotspot_options_jdk8.html крайне еркомендую в азкладки добавить

Блин, вот спасибо! Прям от души

а вот нету никаких, и в системе мониторинга не вижу, что эта область памяти отслеживалась. ладно хоть логи GC есть, и на том спасибо

Хм, похоже, что скан метаспейса для CMS имеет квадратичную сложность:

зависимость от размера метаспейса к времени поиска на красном графике, на синем - квадратичная функция

так что видимо проблема именно в этом

Вы CMS GC используете? G1 не пробовали или на ваших сценариях он хуже себя показывает?

хуже показывает. если уж 400мс для нас критичная пауза)

хм, ок. у нас на G1 как раз всё ощутимо быстрей шуршать стало.

у нас видимо нет, в исследовании этого вопроса я не участвовал, но в целом у нас итак все довольно шустро, но вот иногда случаются печальные события, вроде этого)

А не пробовали вместо JVM что-то без пауз использовать? Erlang, например? 🙂

А хотя да, пробовали же 🙂

Может тогда Rust? =)
Если серьязно, то я вот хз - может анлоадинг классов такая операция что там особо её и не ускорить, там же наверняка ещё и JIT оказывается втянут в это безобразие.
Надо бы сначала понять с чего это оно вообще что-то выгружать пошло. Плюсую ответ Алексея про MetaspaceSize, ещё бы надо аппликейшен попрофилировать чтобы понять чего  он там вообще грузит.

Про metaspace size я имел ввиду выставить этот флаг, затем попробовать разные значения. То, что никаких флагов особо не выставляется это мы поняли.