Конечно нет! Но и смысл таких тестов не в том чтобы посмотреть у какой среды какие эвристики по выделению памяти, а в том, чтобы узнать сколько потребляют корутины/асинки-авейты/зелёные треды/у кого что. А в таком случае надо смотреть на реально используемую память а не на жировые запасы, которые по факту могут и не использоваться никогда.
Грубо говоря нужна оценка "сколько влезет зелёных потоков в 1гб хипа", а не "сколько захочет забрать у системы тот или иной gc при 100500 потоках.
К слову у OpenJDK много разных gc. И при разных gc исходный тест без явных ограничений может показать разные результаты. Потому как эвристики будут разные.
Вообще если такой тест делать по уму, то он ой как не просто строится. По хорошему там для jvm надо загрузить таски в пул, а потом через jmx выуживать сколько хипа и оффхипа потрачено. Смотреть на процесс снаружи для jvm несколько бессмысленно.
Ну почему же? Мы же смотрим именно аппетиты задачи по памяти? Значит должны смотреть именно на реально использованную память, а не на то, что jvm взяла прозарас. Так можно jvm заставить хоть 64гб, хоть 1тб забрать себе. Но реально используемая память от этого не изменится.
Java, если её явно не ограничить, берёт память про запас. Так что тут может быть весьма сильная наводка. Я бы попробовал для каждого теста подбирать параметр -Xmx. Подбирая его так, чтобы он был минимальным, но позволял выполняться приложению.
Не просто текст, а оформить как код. Чтобы глаза при чтении не ломать. Но за статьи спасибо. Как раз думал как подступиться, чтобы сыновьям докер объяснить :)
Ещё могу добавить, что надо быть осторожным при включении JFR в JVM под нагрузкой. Это может менять горячие пути исполнения и приводить к резкому протуханию скомпилированного машинного кода. Сталкивался с ситуацией, когда после включения на ходу приложение просто переставало откликаться на довольно продолжительный срок. По этой причине предпочитаю если и включать JFR, то сразу при старте. С ротацией записываемых данных.
Заодно можно изучать картину произошедшего задним числом, когда аномалия уже случилась. У JFR можно попросить кусок записи за интересующий промежуток времени и спокойно его изучить.
Очень бы хотелось продолжения, т.к. нередко сталкиваюсь с последствиями недопонимания этих концепций в различном коде. А у вас очень хорошо получается объяснять.
Вообще сейчас вспомнил, как в Kotlin изменения делают, а потом интеншены под эти изменения пилят, чтобы автоматически мигрировать на новые версии.
По идее с помощью этого инструмента можно попробовать аналогично и со своими проектами поступать. Например не просто депрекейтить какой-либо метод с указанием на что заменить. А прямо интеншен сделать, чтобы и заменяло сразу.
Но тут понадобится отдельный скилл написания таких вещей...
Перехожу по ссылке "доступен" и... Извините, запрошенная вами страница не найдена.
Конечно нет!
Но и смысл таких тестов не в том чтобы посмотреть у какой среды какие эвристики по выделению памяти, а в том, чтобы узнать сколько потребляют корутины/асинки-авейты/зелёные треды/у кого что.
А в таком случае надо смотреть на реально используемую память а не на жировые запасы, которые по факту могут и не использоваться никогда.
Грубо говоря нужна оценка "сколько влезет зелёных потоков в 1гб хипа", а не "сколько захочет забрать у системы тот или иной gc при 100500 потоках.
К слову у OpenJDK много разных gc. И при разных gc исходный тест без явных ограничений может показать разные результаты. Потому как эвристики будут разные.
Вообще если такой тест делать по уму, то он ой как не просто строится.
По хорошему там для jvm надо загрузить таски в пул, а потом через jmx выуживать сколько хипа и оффхипа потрачено.
Смотреть на процесс снаружи для jvm несколько бессмысленно.
К слову было бы любопытно включить сюда ещё и Kotlin с его корутинами включить.
Ну почему же? Мы же смотрим именно аппетиты задачи по памяти? Значит должны смотреть именно на реально использованную память, а не на то, что jvm взяла прозарас. Так можно jvm заставить хоть 64гб, хоть 1тб забрать себе. Но реально используемая память от этого не изменится.
Java, если её явно не ограничить, берёт память про запас. Так что тут может быть весьма сильная наводка.
Я бы попробовал для каждого теста подбирать параметр -Xmx. Подбирая его так, чтобы он был минимальным, но позволял выполняться приложению.
Уж сколько таких постов и хоть бы кто-то разъяснил суть этих настроек. Ну чтобы осознанно их тыкать, а не наобум...
Не просто текст, а оформить как код. Чтобы глаза при чтении не ломать.
Но за статьи спасибо. Как раз думал как подступиться, чтобы сыновьям докер объяснить :)
Да вообще-то были двойники. Когда отпечатки пальцев начали снимать массово, а не только у приступников, то начали и двойники обнаруживаться.
Да вот с запчастями для инфраструктуры у нас тоже как-то не очень...
Ещё могу добавить, что надо быть осторожным при включении JFR в JVM под нагрузкой. Это может менять горячие пути исполнения и приводить к резкому протуханию скомпилированного машинного кода. Сталкивался с ситуацией, когда после включения на ходу приложение просто переставало откликаться на довольно продолжительный срок. По этой причине предпочитаю если и включать JFR, то сразу при старте. С ротацией записываемых данных.
Заодно можно изучать картину произошедшего задним числом, когда аномалия уже случилась. У JFR можно попросить кусок записи за интересующий промежуток времени и спокойно его изучить.
Не силён в ноутбуках... Что-то у меня упорно не находит модуль pixeldrawer :(
Вот тут все тесты с тестконтейнерами: https://github.com/javister/javister-docker-base/tree/master/tests/simple/src/test/java/com/github/javister/docker/testing/base
Очень бы хотелось продолжения, т.к. нередко сталкиваюсь с последствиями недопонимания этих концепций в различном коде. А у вас очень хорошо получается объяснять.
Жду продолжения!
Хм. А вот если у меня есть самопальная железка на esp32 с микрофоном, я могу как-то записанный на ней звук отправить в Алису, как голосовую команду?
Вообще сейчас вспомнил, как в Kotlin изменения делают, а потом интеншены под эти изменения пилят, чтобы автоматически мигрировать на новые версии.
По идее с помощью этого инструмента можно попробовать аналогично и со своими проектами поступать. Например не просто депрекейтить какой-либо метод с указанием на что заменить. А прямо интеншен сделать, чтобы и заменяло сразу.
Но тут понадобится отдельный скилл написания таких вещей...
Да. Заработало.
Но лично мне плагин пока нравится больше, т.к. даёт больше полезной информации именно для написания скриптов в фильтрах.
Но всё равно спасибо!
Ого! Век живи — век учись!
Но это уже не для рядовой разработки, я так понимаю. Иначе так глубоко не прятали бы.
А это точно не плагином каким-нибудь делается? У меня нету такого пункта меню...
О! А это действительно может немного облегчить жизнь. Спасибо!
Хотя от необходимости справки это не избавляет. Но хотя бы упрощает понимание структуры.