|
|
|
Stream и память
|
|||
|---|---|---|---|
|
#18+
lleming больше похоже подправление кода и постоянный перезапуск, и одна из кривых версий кода хранила ссылки и получили OOM или RAM не осталось на машинке свободной прям в этот раз. но эта версия тут же была исправлена и теперь не вспомнить какая из версий кидала OOM. OOM можно получить если бомбить память быстрее чем GC успевает освобождать ее. решается круткой edem для краковременных объектов чтобы не успевали как old помечаться объекты (у меня на 60мб не успевает чистить эдем и все в old попадает но тут объем маленький GC и так с лихвой успевает 60Мб проверять) врядли,я не использую hot reload ,такчто сомнительно что новый джава процесс будет каким то образом конфликтовать с убитым процессом так же в тесте был простейший класс и 1 метод - тоесть финты со стороны JIT тоже не подходяд скорей всего что то пошло не так при снятии тред дампа,это же тоже не бесплатно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2022, 18:17 |
|
||
|
Stream и память
|
|||
|---|---|---|---|
|
#18+
[quot lleming#22423238] Прям целый набор взаимоисключающих параграфов. Не хочется активности ГЦ тогда не тащи данные в JVM просто спроси сразу число в том месте где данные хранятся те. БД. /quot] не в бд,а в кеше Хезелькаст второе я ж не сказал что вот так буду делать - я просто эксперементировал,сейчас я чотко понимаю,что такой процесс не вызовет у нас проблем в части OOM ,но вызовет другую проблему- будет тратиться процессорное время на слишком частые проходы ГЦ- понятное дело что это не то что я хочу и таки работу этого метода лучше делегировать хезелю,благо у него есть достаточно продвинутый api ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2022, 18:24 |
|
||
|
Stream и память
|
|||
|---|---|---|---|
|
#18+
adminDontSleep скорей всего что то пошло не так Нагрузочный тест при 256. Ошибка должна повторятся.. А счас нет ни ошибки ни дампа ни теста. Он тебе: "вот 10 причин" Ты ему: "вряд ли... скорее всего это 11-я" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2022, 18:39 |
|
||
|
Stream и память
|
|||
|---|---|---|---|
|
#18+
И надо обязательно разделить вопросы Hazelcast от вопросов Java-Stream. При малейшем сомнении на тему того как работает stream - мы выбрасываем stream из кода и заменяем его на цикл. Цикл прозрачен. Это базовая алгоритмическая конструкция. И все подкапотные аллокации мы видим. По хазелькасту - использовать его методы в ПЕРВУЮ очередь. Тоесть все count, filtering, группировки и прочие операции хазель-алгебры мы делаем в запросе. Это технологично. Это правильно. И никто не скажет что велосипед. Точно также работают и с реляционными базами. Максимум процессинга на уровне БД. А вот делать копию выборки на клиента и что-то гонять в стримах - это велосипед. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2022, 18:58 |
|
||
|
Stream и память
|
|||
|---|---|---|---|
|
#18+
а как hazel запущен отдельно ? или builtin в каждую ноду ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2022, 19:26 |
|
||
|
Stream и память
|
|||
|---|---|---|---|
|
#18+
lleming, Правильный вопрос черт возьми. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2022, 20:40 |
|
||
|
Stream и память
|
|||
|---|---|---|---|
|
#18+
И, что характерно - ответ уже имеется: 22420286 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2022, 05:49 |
|
||
|
|
start [/forum/topic.php?fid=59&gotonew=1&tid=2120265]: |
0ms |
get settings: |
25ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
10ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
190ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 308ms |
| 0 / 0 |
