Сижу- борюсь с outOfMemory. Диагноз стандартный char[].
Суть задачи - распарс текстового файла. Каждая строка храниться в HashMap(строка маппится по полям на экземпляр класс сущности некой). Сам файл huge!!!(боле нескольки гигов в gz)

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

readLine->parseLine->entityMapper->entityToCache.

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

Читаю разнообразные GC типсы..но судя по всему - они по факту бесполезны.
1. Кто как эффективно боролся?:)
2. System.arraycopy(src, 0, dst, 0, src.length) - может ли подобная операция(над каждой строкой выполняется) привести к подобным последствия?

BlazkowiczОзверинСуть задачи - распарс текстового файла. Каждая строка храниться в HashMap(строка маппится по полям на экземпляр класс сущности некой). Сам файл huge!!!(боле нескольки гигов в gz)

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

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

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

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

LeonidvЛибо хранить в ehcache и разрешить ему записывать данные на диск. Еще, похоже, есть вариант память перед CPU. Если задача позволяет, можно делать так. Находим первый ключ, обрабатываем все строки, для которых он нужен. Запоминаем его и находим второй ключ. И т.д. Минус в том, что файл будет прочитан столько раз, сколько у вас ключей. Плюс в том, что если ключей много, то нагрузка на память будет существенно меньше.

Файл в запакованном виде 4 гига. Боюсь соврать, там вроде 27 миллионов записей.

Petro123Озверин,
колись и не стесняйся лохануться. Просто нужен свежий взгляд.
95 процентов всех причин - простые (с - статистика авиапроисшествий).

Так а чего колоться? Я сижу туплю...спрашивайте ;)

BlazkowiczПочему вы решили что OutOfMemoryError связан с работой GC, а не с банальной нехваткой памяти?

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

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

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

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

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

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, т.е. не факт, что каждая новая строка создат и кинет в кэш новую сущность

BlazkowiczОзверинПо сути myEntity - это одна строка.
если у строк ключ совпадает, то мы просто в 1ой сущности суммируем поле1 и поле2, т.е. не факт, что каждая новая строка создат и кинет в кэш новую сущность
Какая длина строки и сколько уникальных по ключу сущностей в файле?

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

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

BlazkowiczPetro123Большой Синий Кит,
а почему БД не подходит:
- сливаем сырые данные
- в фоне достаём - обработал - положил
?
Импортируем в MySQL. Пишем SQL запрос. Profit!

я честно сказать первым делом предложил именно этот вариант. Но "начальство" сверху сильно меня ограничило ;)
я как бе заметил, что для агрегирования большого кол-ва даанных бд и созданы..но там что то с ресурсами сервака и одновременной работой нескольих таких паресров.