Телеграмм чат группы jvmchat страница 18136

Всем привет! Никто не сталкивался с деградацией производительности при апгрейде spring boot с 2.3.5 до 2.4.1?
Суть - есть консольное спринг-бут приложение, только базовый стартер, environment=none. есть интерфейс, у которого ~150 реализацией, проаннотированных как

@Component
@Primary
@Scope("prototype")

Есть конфигурация, выступающая своего рода object provider, получающая инстанс _конкретного_ класса:

@Configuration
@RequiredArgsConstructor
public class DiagnosticConfiguration {

  private final ApplicationContext applicationContext;

  @Bean
  @Scope("prototype")
  public <T extends BSLDiagnostic> T diagnostic(Class<T> clazz) {
    return applicationContext.getBean(clazz);
  }

}

На 2.3.5 ~15000 инстанцирований бинов (разных типов) через конфигурацию занимало 12 секунд чистого процессорного времени. Простой апгрейд до 2.4.1 увеличивает это время до 75+ секунд. На flame graph видно, что львиную долю стал занимать CommonAnnotationBeanPostProcessor.postProcessProperties(PropertyValues, Object, String), хотя на 2.3.5 он вообще в flame graph не показывался.

Что изменилось? Куда можно покопать?

flame graph с проблемным местом:
https://i.postimg.cc/JhNfXY50/image.png

Версия java случайно заодно не менялась? Flamegraph пустой какой-то, а это, мне кажется, значит, что тормоз находится в synchronized-блоке там

источник

16:29пожаловаться #5

borsch in pro.jvm

привет

здесь есть контрибюторы в open-api-generator? у меня возникают проблемы при генерации кода для samples.
после генерации на винде все / превращаются в \\ хотя никаких изменений в самом файле нету. если запускаю кодогенерацию в docker'e, то вылезает проблема с clrf -> lf. если в докере пробовать подставить line.separator, чтоб генерить как-бы под виндой, то билд просто падает

источник

16:34пожаловаться #6

Alexandr Emelyanov in pro.jvm

borsch

Почему бы не сходить на гитхаб к ним?

источник

16:39пожаловаться #7

Nikita Gryzlov in pro.jvm

Dmitry Zvorygin

ну и посмотреть различия в flame graph - и посмотреть где именно начинаются различия

в 2.3.5 CommonAnnotationBeanPostProcessor вообще не светится. в этом графе скорее всего опущены "маленькие" вызовы, не могу гарантировать, что этот БПП вообще не вызывался. в блэйме по файлу за прошедший год изменения есть, но не в этой тяжелой функции
https://github.com/spring-projects/spring-framework/blame/3113917c553197fc5e25282b02c6dcc504e46dca/spring-context/src/main/java/org/springframework/context/annotation/CommonAnnotationBeanPostProcessor.java#L335

источник

16:46пожаловаться #8

Nikita Gryzlov in pro.jvm

Alexey Genus

нет, последовательный запуск на одной и той же машине

источник

16:47пожаловаться #9

Alexey Genus in pro.jvm

Я бы попробовал снять профиль на ожидание локов, возможно что-то даст

источник

16:48пожаловаться #10

Nikita Gryzlov in pro.jvm

снятие фильтров с графа показало занятную картинку
https://i.postimg.cc/pT9NcQNM/image.png

источник

16:48пожаловаться #11

Nikita Gryzlov in pro.jvm

а там, как вы и говорили, synchronized

    if (InjectionMetadata.needsRefresh(metadata, clazz)) {
      synchronized (this.injectionMetadataCache) {
        metadata = this.injectionMetadataCache.get(cacheKey);

источник

16:49пожаловаться #12

Nikita Gryzlov in pro.jvm

судя по блэйму эти строки менялись от 4 до 12 лет назад :) то есть проблема не в самом блоке как таковом, а в коде, который стал вызывать этот BPP по-другому/чаще.
в общем, я понял, надо ковырять профайлер дальше, спасибо

источник

16:51пожаловаться #13

Alexey Genus in pro.jvm

👍

источник

16:52пожаловаться #14

Artjom Kalita in pro.jvm

В 2.4 спринге есть актуатор эндпоинт который показывает стартап тайм статистику

источник

17:05пожаловаться #15

Nikita Gryzlov in pro.jvm

Artjom Kalita