powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / Java performance & GC
42 сообщений из 42, показаны все 2 страниц
Java performance & GC
    #37663267
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сижу- борюсь с outOfMemory. Диагноз стандартный char[].
Суть задачи - распарс текстового файла. Каждая строка храниться в HashMap(строка маппится по полям на экземпляр класс сущности некой). Сам файл huge!!!(боле нескольки гигов в gz)

Последовательность примерно такая:

readLine->parseLine->entityMapper->entityToCache.

Кроме кэша все переменные - локальные.

Читаю разнообразные GC типсы..но судя по всему - они по факту бесполезны.
1. Кто как эффективно боролся?:)
2. System.arraycopy(src, 0, dst, 0, src.length) - может ли подобная операция(над каждой строкой выполняется) привести к подобным последствия?
...
Рейтинг: 0 / 0
Java performance & GC
    #37663278
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинСуть задачи - распарс текстового файла. Каждая строка храниться в HashMap(строка маппится по полям на экземпляр класс сущности некой). Сам файл huge!!!(боле нескольки гигов в gz)

Давайте не углублятся в детали, а просто логически подумаем. Есть текстовый файл в несколько гигов. Его нужно распарсить в более сложную структуру. Соответственно новая структура легко занимает 3-4 гига. При чем здесь тогда вообще GC? Что именно нужно сделать с этим объемом данных?
...
Рейтинг: 0 / 0
Java performance & GC
    #37663288
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczОзверинСуть задачи - распарс текстового файла. Каждая строка храниться в HashMap(строка маппится по полям на экземпляр класс сущности некой). Сам файл huge!!!(боле нескольки гигов в gz)

Давайте не углублятся в детали, а просто логически подумаем. Есть текстовый файл в несколько гигов. Его нужно распарсить в более сложную структуру. Соответственно новая структура легко занимает 3-4 гига. При чем здесь тогда вообще GC? Что именно нужно сделать с этим объемом данных?

я это понимаю.

Каждая строка содержит ключ, по которому нужно агрегировать данные, т.е весь объем данных нужен, чтобы вычислить некие величины. Если НЕ брать в расчет возможность хранения "временных" данных в бд, то есть ли tips для подобных задач?;)
...
Рейтинг: 0 / 0
Java performance & GC
    #37663296
Leonidv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Озверин,

mapreduce.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663301
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Озвериня это понимаю.
А я нет. Какая конечная цель? Какой результат парсинга? Что на выходе?

ОзверинКаждая строка содержит ключ, по которому нужно агрегировать данные, т.е весь объем данных нужен, чтобы вычислить некие величины. Если НЕ брать в расчет возможность хранения "временных" данных в бд, то есть ли tips для подобных задач?;)
Нужно типа статистику посчитать по всем данным? Надо от задачи отталкиваться. Почему вы решили что OutOfMemoryError связан с работой GC, а не с банальной нехваткой памяти?
...
Рейтинг: 0 / 0
Java performance & GC
    #37663308
Leonidv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Либо хранить в ehcache и разрешить ему записывать данные на диск. Еще, похоже, есть вариант память перед CPU. Если задача позволяет, можно делать так. Находим первый ключ, обрабатываем все строки, для которых он нужен. Запоминаем его и находим второй ключ. И т.д. Минус в том, что файл будет прочитан столько раз, сколько у вас ключей. Плюс в том, что если ключей много, то нагрузка на память будет существенно меньше.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663317
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczОзвериня это понимаю.
А я нет. Какая конечная цель? Какой результат парсинга? Что на выходе?

ОзверинКаждая строка содержит ключ, по которому нужно агрегировать данные, т.е весь объем данных нужен, чтобы вычислить некие величины. Если НЕ брать в расчет возможность хранения "временных" данных в бд, то есть ли tips для подобных задач?;)
Нужно типа статистику посчитать по всем данным? Надо от задачи отталкиваться. Почему вы решили что OutOfMemoryError связан с работой GC, а не с банальной нехваткой памяти?

На выходе - расчет статистики.

1. задача - это расчет статистики
2. задача - баланс между выделения памяти под heap size, т.е - чем меньше, тем лучше ;) На данный момент я под задачу выделил 1200m.

Над каждой строкой примерно следующие операции выполняются:
String readLine()
String[] parse(String line)
MyEntity createEntity(String[] line)

//логика примерно такая, если объект по ключу уже есть в кэше, расчитываем некие величиные его полей, если нет - в мапу кидаем просто)
void cacheMyEntity()->hashMap
void groupMyEntity()-hashMap
...
Рейтинг: 0 / 0
Java performance & GC
    #37663331
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeonidvЛибо хранить в ehcache и разрешить ему записывать данные на диск. Еще, похоже, есть вариант память перед CPU. Если задача позволяет, можно делать так. Находим первый ключ, обрабатываем все строки, для которых он нужен. Запоминаем его и находим второй ключ. И т.д. Минус в том, что файл будет прочитан столько раз, сколько у вас ключей. Плюс в том, что если ключей много, то нагрузка на память будет существенно меньше.

Файл в запакованном виде 4 гига. Боюсь соврать, там вроде 27 миллионов записей.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663332
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Озверин,
колись и не стесняйся лохануться. Просто нужен свежий взгляд.
95 процентов всех причин - простые (с - статистика авиапроисшествий).
...
Рейтинг: 0 / 0
Java performance & GC
    #37663335
Leonidv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинLeonidvЛибо хранить в ehcache и разрешить ему записывать данные на диск. Еще, похоже, есть вариант память перед CPU. Если задача позволяет, можно делать так. Находим первый ключ, обрабатываем все строки, для которых он нужен. Запоминаем его и находим второй ключ. И т.д. Минус в том, что файл будет прочитан столько раз, сколько у вас ключей. Плюс в том, что если ключей много, то нагрузка на память будет существенно меньше.

Файл в запакованном виде 4 гига. Боюсь соврать, там вроде 27 миллионов записей.
Не уловил связи между этой информацией и моим ответом :)
...
Рейтинг: 0 / 0
Java performance & GC
    #37663337
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Почему вы решили что OutOfMemoryError связан с работой GC, а не с банальной нехваткой памяти?

Строки имеют свойство переиспользовать char[], при, например substring().Не получается ли так что String[] у вас все экземпляры ссылаются на String целой строки, которую вы считали?

В MyEntity много строк?

Почему был выбран подход чтения строками, а не потоком символов?
...
Рейтинг: 0 / 0
Java performance & GC
    #37663338
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Озверин,
колись и не стесняйся лохануться. Просто нужен свежий взгляд.
95 процентов всех причин - простые (с - статистика авиапроисшествий).

Так а чего колоться? Я сижу туплю...спрашивайте ;)
...
Рейтинг: 0 / 0
Java performance & GC
    #37663352
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczПочему вы решили что OutOfMemoryError связан с работой GC, а не с банальной нехваткой памяти?

Строки имеют свойство переиспользовать char[], при, например substring().Не получается ли так что String[] у вас все экземпляры ссылаются на String целой строки, которую вы считали?

В MyEntity много строк?

Почему был выбран подход чтения строками, а не потоком символов?

Насчет CG - нельзя же себя ругать, поругал его )

Не получается ли так что String[] у вас все экземпляры ссылаются на String целой строки, которую вы считали?
разумно. Сейчас будем смотреть.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663357
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На сколько сложно отказатся от String в пользу char[] и CharSequence?
...
Рейтинг: 0 / 0
Java performance & GC
    #37663385
Большой Синий Кит
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeonidvОзверин,

mapreduce.

Вот правильный ответ.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663391
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Большой Синий КитLeonidvmapreduce.
Вот правильный ответ.
Обоснуй.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663418
Большой Синий Кит
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Blazkowicz,

Записей очень много. Производить конечный расчет можно только имея все записи распарсенными. Загрузить их все в виде объектов не получается - очень много памяти. То есть нужно уменьшить количество записей, которые нужно распарсить. Остается только одно - mapreduce. Честно говоря, ничего другого, на мой взгляд, нету. Синхронно производить обработку этих данных для получения их в более компактной форме, или нет - это уже неважно. Но идея именно в этом. А это мапредьюс.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663429
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Blazkowicz В MyEntity много строк?




По сути myEntity - это одна строка.
String[] values
myEntity.setColumn0(values[0]);
myEntity.setColumn1(values[1]);
myEntity.setColumn2(values[2]);
myEntity.setColumnN(values[N]);

Но.
Для примера

ключ1, поле1=1, поле2=10
ключ1, поле1=2, поле2=10
ключ1, поле1=5, поле2=15

если у строк ключ совпадает, то мы просто в 1ой сущности суммируем поле1 и поле2, т.е. не факт, что каждая новая строка создат и кинет в кэш новую сущность
...
Рейтинг: 0 / 0
Java performance & GC
    #37663433
Большой Синий Кит
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинBlazkowicz В MyEntity много строк?




По сути myEntity - это одна строка.
String[] values
myEntity.setColumn0(values[0]);
myEntity.setColumn1(values[1]);
myEntity.setColumn2(values[2]);
myEntity.setColumnN(values[N]);

Но.
Для примера

ключ1, поле1=1, поле2=10
ключ1, поле1=2, поле2=10
ключ1, поле1=5, поле2=15

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

Ну вот, мапредьюс.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663436
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинПо сути myEntity - это одна строка.
если у строк ключ совпадает, то мы просто в 1ой сущности суммируем поле1 и поле2, т.е. не факт, что каждая новая строка создат и кинет в кэш новую сущность
Какая длина строки и сколько уникальных по ключу сущностей в файле?
...
Рейтинг: 0 / 0
Java performance & GC
    #37663439
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Большой Синий Кит,
а почему БД не подходит:
- сливаем сырые данные
- в фоне достаём - обработал - положил
?
...
Рейтинг: 0 / 0
Java performance & GC
    #37663445
Большой Синий Кит
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Большой Синий Кит,
а почему БД не подходит:
- сливаем сырые данные
- в фоне достаём - обработал - положил
?

Почему не подходит? Подходит, согласен. Просто тут ведь нет в исходных данных БД...
...
Рейтинг: 0 / 0
Java performance & GC
    #37663450
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Большой Синий Кит,
а почему БД не подходит:
- сливаем сырые данные
- в фоне достаём - обработал - положил
?
Импортируем в MySQL. Пишем SQL запрос. Profit!
...
Рейтинг: 0 / 0
Java performance & GC
    #37663452
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczОзверинПо сути myEntity - это одна строка.
если у строк ключ совпадает, то мы просто в 1ой сущности суммируем поле1 и поле2, т.е. не факт, что каждая новая строка создат и кинет в кэш новую сущность
Какая длина строки и сколько уникальных по ключу сущностей в файле?

Длина строки сильно варьироваться может. Условно мы говорим о 1500 символах в строке. (примерно такой порядок)
Насчет кол-ва сущностей, очень трудно сказать.

1 уникальный ключ на строку - может быть
>1 уникального ключа на строку - тоже(работаю с логом стороннего разработчика, за что купил, как говорится)
<1 уникального ключа на строку - если она будет агрегирована с предыдущими строками
...
Рейтинг: 0 / 0
Java performance & GC
    #37663460
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczPetro123Большой Синий Кит,
а почему БД не подходит:
- сливаем сырые данные
- в фоне достаём - обработал - положил
?
Импортируем в MySQL. Пишем SQL запрос. Profit!

я честно сказать первым делом предложил именно этот вариант. Но "начальство" сверху сильно меня ограничило ;)
я как бе заметил, что для агрегирования большого кол-ва даанных бд и созданы..но там что то с ресурсами сервака и одновременной работой нескольих таких паресров.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663470
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Большой Синий КитPetro123Большой Синий Кит,
а почему БД не подходит:
- сливаем сырые данные
- в фоне достаём - обработал - положил
?
Почему не подходит? Подходит, согласен. Просто тут ведь нет в исходных данных БД...
Есть сходные задачи:
5000 датчиков льют данные. Их надо обработать.
- пишем быстро
- не торопясь обрабатываем.
Главное что статистика не оперирует сразу ВСЕМИ - тогда можно в ОРМ
- если сразу всеми, тогда SQL операторы
...
Рейтинг: 0 / 0
Java performance & GC
    #37663474
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
просто у БД память GC не кончается
...
Рейтинг: 0 / 0
Java performance & GC
    #37663478
Большой Синий Кит
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,

:)
Согласен
...
Рейтинг: 0 / 0
Java performance & GC
    #37663485
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинДлина строки сильно варьироваться может. Условно мы говорим о 1500 символах в строке. (примерно такой порядок)
Насчет кол-ва сущностей, очень трудно сказать.

1 уникальный ключ на строку - может быть
>1 уникального ключа на строку - тоже(работаю с логом стороннего разработчика, за что купил, как говорится)
<1 уникального ключа на строку - если она будет агрегирована с предыдущими строками

Теперь я озадачен, чуть более чем полностью. Имеем 4Гб упакованый файл (zip). Можно предположить что после распаковки там 6-8Гиг. Не меньше. Теперь это всё надо считать в кучу 1.2Гб, так чтобы оно туда поместилось. Так?
...
Рейтинг: 0 / 0
Java performance & GC
    #37663521
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczОзверинДлина строки сильно варьироваться может. Условно мы говорим о 1500 символах в строке. (примерно такой порядок)
Насчет кол-ва сущностей, очень трудно сказать.

1 уникальный ключ на строку - может быть
>1 уникального ключа на строку - тоже(работаю с логом стороннего разработчика, за что купил, как говорится)
<1 уникального ключа на строку - если она будет агрегирована с предыдущими строками

Теперь я озадачен, чуть более чем полностью. Имеем 4Гб упакованый файл (zip). Можно предположить что после распаковки там 6-8Гиг. Не меньше. Теперь это всё надо считать в кучу 1.2Гб, так чтобы оно туда поместилось. Так?

да, но хранение данных на винте и в памяти - разные вещи. В java достаточно эффективно организовано хранение символьных данных. Я не спорю, что 1200 вполне вероятно, что мало. Но есть подозрение, что может и хватить.
Подозрение основано на том, что еще недавно хватало ;) Я пока ищу, что такого я изменил, что перестало...по сути - добавил несколько полей в сущность....
...
Рейтинг: 0 / 0
Java performance & GC
    #37663572
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczТеперь я озадачен, чуть более чем полностью. Имеем 4Гб упакованый файл (zip). Можно предположить что после распаковки там 6-8Гиг. Не меньше. Теперь это всё надо считать в кучу 1.2Гб, так чтобы оно туда поместилось. Так?Не совсем. Если отсортировать распакованный поток, то возможны варианты.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663579
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovНе совсем. Если отсортировать распакованный поток, то возможны варианты.
У автора одна строка - одна сущность. И сколько сущностей он не знает.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663584
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинПодозрение основано на том, что еще недавно хватало ;) Я пока ищу, что такого я изменил, что перестало...по сути - добавил несколько полей в сущность....
А можно вернуть обратно и посмотреть график расхода кучи в jvisualvm? Может было на пределе?
...
Рейтинг: 0 / 0
Java performance & GC
    #37663594
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Blazkowicz,

правы были, филды сущности String с сылкой на char[] c изначальной строки с offset. Короче все 27 миллионов строк в памяти в итоге висят...где то я косячу.
...
Рейтинг: 0 / 0
Java performance & GC
    #37663630
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BlazkowiczИ сколько сущностей он не знает.В своё время "за ненахождением готового" клепал на коленке "отчёты по трафику". Читались логи TMeter-а, разбирались в sort-ready вид и конвейер "rexx скрипт1|sort|rexx скрипт2 > результат.tsv" выдавал данные для Excel-я.
Сколько будет строк на входе - известно только по порядку величины (сотни тысяч-миллионы - скриптец "информировал" в прогресс-столбце :)), а на выходе их должно было стать не более 50-60 тысяч. Становилось. Гарантированно :)
...
Рейтинг: 0 / 0
Java performance & GC
    #37663708
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Первоначальный итог?
задачу создавал в тестовом своем проекте, запускал с ключом -XX:+UseCompressedStrings. Когда код перенес в рабочий, ключ забыл. А он реально помогает ;)

Вторичная проблема
String[] values = line.parse();
Когда мы делаем нечто вроде
entity.setColumn1(values[1]);
entity.setColumn2(values[2]);
entity.setColumn3(values[3]);

map.put(entity);

то.
column1, column2, column3 ссылаются на 1 и тот же массив символов , но каждый со своим смещением, то есть они держат строку в памяти, не давая GC ее подчистить. А сам объект в мапе.

Вывод, при условии, что изначально line очень прилично длины, при setColumn копировать не ссылке, а по значению ;) Должно помочь.буду проверять.
...
Рейтинг: 0 / 0
Java performance & GC
    #37664184
Большой Синий Кит
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинBlazkowicz,

правы были, филды сущности String с сылкой на char[] c изначальной строки с offset. Короче все 27 миллионов строк в памяти в итоге висят...где то я косячу.

оффтоп
Blazkowicz обычно всегда как в воду глядит. :)
...
Рейтинг: 0 / 0
Java performance & GC
    #37664186
Большой Синий Кит
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
P.S. Кстати говоря, можно поглядеть на метод String.intern() - для вычитываемой строки :)
...
Рейтинг: 0 / 0
Java performance & GC
    #37664190
Большой Синий Кит
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Однако, ИМХО мапредьюс или СУБД для слива данных решение гораздо лучшее. С помощью СУБД проще.
...
Рейтинг: 0 / 0
Java performance & GC
    #37664210
Большой Синий Кит
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не, про интерн() лучше, пожалуй, забыть.
...
Рейтинг: 0 / 0
Java performance & GC
    #37664307
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинПо сути myEntity - это одна строка.
String[] values
myEntity.setColumn0(values[0]);
myEntity.setColumn1(values[1]);
myEntity.setColumn2(values[2]);
myEntity.setColumnN(values[N]);

Но.
Для примера

ключ1, поле1=1, поле2=10
ключ1, поле1=2, поле2=10
ключ1, поле1=5, поле2=15

если у строк ключ совпадает, то мы просто в 1ой сущности суммируем поле1 и поле2, т.е. не факт, что каждая новая строка создат и кинет в кэш новую сущностьНаверное самым эффективным будет применение СУБД в том или ином виде. Ваша структура ложится на реляционную модель довольно просто. Таблица для ключей, таблица для полей и таблица значений. Банальный EAV.

При работу с СУБД вам даже в памяти не нужно держать мапы сущьностей - ищите по ключу в БД. Если есть, то обновляете, иначе заливаете новую.

Если начальство на отрез не хочет полноценную СУБД - примените in-memory БД, которая при нехватке памяти скидывает данные на винт. Тогда даже при увеличении исходных данных в 10-ть! раз система будет работоспособной


PS при системе с БД ваш код даже не придется сильно исправлять. поскольку нет мапов, то строки сущностей не хранятся в памяти, а значит и объекты создаваемые в текущем коде будет нормально обрабатываться GC.
...
Рейтинг: 0 / 0
Java performance & GC
    #37664510
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
VoDA,

это было б следующим шагом, после всех провалов. Сижу - проверяю ;)
...
Рейтинг: 0 / 0
42 сообщений из 42, показаны все 2 страниц
Форумы / Java [игнор отключен] [закрыт для гостей] / Java performance & GC
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]