Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Java |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
razliv Member Откуда: Сообщений: 1067 |
Здравствуйте, столкнулся с проблемой: Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded При заполнении HashMap, большим значением элементов. Есть ли возможность свопа на диск, или другого способа экономичной работы с большим количеством данных ? |
30 янв 19, 10:24 [21797503] Ответить | Цитировать Сообщить модератору |
Андрей Панфилов Member Откуда: Москва > Melbourne Сообщений: 3016 |
razliv, http://www.mapdb.org/ |
30 янв 19, 11:20 [21797575] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 38770 |
Есть достаточно быстрые коробочные продукты с интерфейсом похожим на Map<> которые создавались в Google и Facebook. И изначально проектировались для очень большого хранилища. Щас доступны к юзанию. Смотрите. https://github.com/facebook/rocksdb/tree/master/java/src/main/java/org/rocksdb https://github.com/google/leveldb Будьте внимательны. Раньше их реализация была написаны на С++ и на Java был вынесен интерфейс. Как щас я не знаю. Возможно что-то было полносью портировано. Не следил за новостями. |
30 янв 19, 11:40 [21797596] Ответить | Цитировать Сообщить модератору |
Озверин Member Откуда: Ростов-на-Дону Сообщений: 4785 |
razliv, начать бы конечно с того, что выделить чуть больше памяти? -xmx, -xms |
30 янв 19, 11:56 [21797610] Ответить | Цитировать Сообщить модератору |
razliv Member Откуда: Сообщений: 1067 |
Спасибо большое за ответы ! Озверин, Тут уже увеличением памяти не поможешь :( Спасибо буду пробовать гибриды collections и db :) именно то что и хотелось ! |
30 янв 19, 14:02 [21797767] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 38770 |
Оптимизированы-ли они по записи? Если чел туда будет заливать терабайты информации - это будет тоже немаловажно. Ждать ему минуту. Час. Или сутки. Хорошая тема для бенчмарка. |
30 янв 19, 14:14 [21797783] Ответить | Цитировать Сообщить модератору |
razliv Member Откуда: Сообщений: 1067 |
Майтон А что есть "оптимизированны по записи" ? |
30 янв 19, 15:53 [21797963] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 38770 |
Для дисковых операций random-access губителен. Поэтому те структуры данных которые планируется хранить на диске и модифицировать часто и много - дополняют логом транзакций. Это было очень актуально в этоху магнитных дисков. Для SSD - не знаю. Недо тестировать. Но сам по себе факт наличия подобной структуры говорит просто о зрелости проекта. Незрелые проекты обычно надеются что random-access "прокатит". |
30 янв 19, 16:10 [21797985] Ответить | Цитировать Сообщить модератору |
Андрей Панфилов Member Откуда: Москва > Melbourne Сообщений: 3016 |
а кого random-access-то губит, как и зачем? |
||
30 янв 19, 20:34 [21798263] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 38770 |
Андрей Панфилов, давайте рассуждать. Автору нужен HashMap. На диске. HashMap в основе своей природы несет функционал произвольного доступа к бакету. Поскольку речь идет о том что часть данных будет лежать на диске - мы должны придумать как обеспечить максимальную пропускную способность диска. Java предлагает два базовых функционала. RandomAccessFile и FileOutputStream. Оба из них уже оптимизированы через NIO по максимуму поэтому мы будем счиать что NIO нам не нужен. Первый пригоден для чтений записей рандомно. В любое место диска. Второй - только последовательно. Первый создает жёсткую нагрузку на кеши и на механику диска. Второй - более мягкий. Суммарная пропускная способность random-access file будет зависеть от порядка чтения. А порядок у нас - произвольный (вспоминаем hashCode()). По чтению и по записи будет примерно одинаково плохо. И чем крупнее будет база - тем сильнее тормоза. Но чтобы мы почувствовали этот эффект - надо хотя-бы 2-4 раза превысить доступный объем памяти чтобы убрать эффекты кешей ОС которые нам любезно подсовывает операционка. Поэтому я говорил о терабайтах. На мегабайтах разницы особой не будет. Суммарная пропускная способность FileOutputStream (последовательный доступ) будет максимально быстрой для вашего диска. К паспортной скорости HDD не приблизится но в силу архитектуры будет достаточно быстрой что программисту там уже нечего оптимизировать. Скорость - as is. Можно провести эксперимент - читать терабайтный файл последовательно. А потом тот-же файл блоками (по 1,2,4,16 Mb) как хотите произвольно и замерять как просядет скорость. На этом свойстве основанны журналирующие оптимизации практически всех DBMS. DBMS фактически "откладывает на потом" запись в сегмент данных. Сначала она журналирует (FileOutputStream) а потом уже в фоне дописывает в данные когда есть возможность. Но главное - не блокировать ожидание записи. Та дисковая DBMS которая не использует эту возможность - либо плоха. Либо предназначена только для работы in-memory. Про MappedByteBuffer я сейчас не готов говорить. Это - сложная тема и она перекликается с реализацией этой техники в ОС. Я кстати поднимал новогодний топик на эту тему. Где то есть. |
30 янв 19, 20:50 [21798271] Ответить | Цитировать Сообщить модератору |
Андрей Панфилов Member Откуда: Москва > Melbourne Сообщений: 3016 |
/** * Writes <code>len</code> bytes from the specified byte array * starting at offset <code>off</code> to this file output stream. * * @param b the data. * @param off the start offset in the data. * @param len the number of bytes to write. * @exception IOException if an I/O error occurs. */ public void write(byte b[], int off, int len) throws IOException { writeBytes(b, off, len, append); }Наличие offset в параметрах метода какбы намекает, что через FileOutputStream мы можем писать в "любой" (его зачем-то int объявили, а в RandomAccessFile seek принимает long, но не суть потому что есть getChannel().position()) участок файла - это и есть же произвольный доступ, разве нет? С точки зрения операционной системы между FileOutputStream и RandomAccessFile только в том, что RandomAccessFile можно открыть с O_SYNC или O_DSYNC, а так оба этих жавских API утилизируют одни и те же системные вызовы open/seek/write/close - разница по большому счету только в API со стороны жавы.
|
||||||
31 янв 19, 04:59 [21798379] Ответить | Цитировать Сообщить модератору |
вадя Member Откуда: Екатеринбург Сообщений: 15192 |
|
||
31 янв 19, 06:43 [21798393] Ответить | Цитировать Сообщить модератору |
Siemargl Member Откуда: 010100 Сообщений: 6036 |
Надо это производителям почти всех СУБД рассказать, а то они не знают =) Топик - бери любую удобную key-value dbms |
||
31 янв 19, 09:39 [21798460] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 38770 |
Здесь offset - применительно не к файлу а к источнику. К массиву байтов. По поводу API операционной системы - вы правы. Почти все файловые API в конечно счете будут сводится к open/fseek/read/write/close для Unix и к другим CreateFile.. (там более длинное название в Windows). И на уровне железа будут отображаться в атомарные операции записи сектора на диск для HDD или для какой-то примитивной операции передачи данных блочно для SSD. |
||
31 янв 19, 10:52 [21798517] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 38770 |
В самом начале топика я выразил сомнение по поводу скорости инициализации подобной дисковой мапы. Инициализация предполагает запись. Про эксперимент - пока отложим. |
||||
31 янв 19, 10:54 [21798518] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 38770 |
Я говорил о физическом уровне. Об оптимзиации дисковых операций в DBMS. Вы (очень резко) прыгнули в ACID (atomicity, durability) про которые мы еще не говорили. Да и автор пока не выставлял требований. Хотя журнал (redo-log, write-ahead-log) может быть использован для обеспечения durability. Да. Я сейчас не помню как там в этих key-value хранилищах. Но обычно владелец волен выбирать режим в котором он будет работать. Транзакционный или не транзакционный. А для многих операций уровня ETL, bulk-load и прочих (массовых) манипуляций с данными обычно разработчик или DBA сознательно выбирает не-транзакционный режим. Например стартует биржевая система. Она должна в несколько минут прогрузить данные из обычной БД в свой более быстрый key-value. Я-бы здесь сознательно выбирал отключение транзакций ибо нету еще никаких пользователей (система в процессе загрузки) и сама по себе операция достаточно проста по реакции на ошибку. Если что-то пошло не так - просто загрузим еще разик. Нам важнее быстро стартовать операционный день. А после старта уже пул коннекшенов подключится в режиме транзакций как и положено. |
||
31 янв 19, 11:05 [21798529] Ответить | Цитировать Сообщить модератору |
Озверин Member Откуда: Ростов-на-Дону Сообщений: 4785 |
Андрей Панфилов, наличие оффсета как бе намекает, откуда из массива переданных байт начинать писать, а не "куда". |
31 янв 19, 11:08 [21798532] Ответить | Цитировать Сообщить модератору |
Андрей Панфилов Member Откуда: Москва > Melbourne Сообщений: 3016 |
|
||||
31 янв 19, 11:22 [21798541] Ответить | Цитировать Сообщить модератору |
Озверин Member Откуда: Ростов-на-Дону Сообщений: 4785 |
Андрей Панфилов, что там реализовано в java - вообще никого не волнует, если SSD физически при записи работает с блоками по 1mb(или по сколько там?). И каждая рандомная запись блока размером меньшим 1 mb будет сопровождаться определенным кол-вом IOPs: -прочесть весь блок из 1 метра -заменить в нем на наш маленький блок -записать обратно Отсюда проистекает так называемая оптимизация под железо, когда пишут сразу "нужным" размером блока", а не маленькими или большими, про то (частично) майтон и говорит. |
31 янв 19, 11:30 [21798556] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 38770 |
Аккурат в новый год у меня была попытка выпрыгнуть из Java условностей и прыгнуть в недра ОС (в основном меня интересовали Windows-10 и Linux последних версий ядра) чтобы понять что там и как. К сожалению сообщество отреагировало вяло. Толи салат Оливье был плох толи Шампанськое... Вот он кстати https://www.sql.ru/forum/1307294/tyapnichnyy-novogodniy-mmap |
||
31 янв 19, 11:44 [21798575] Ответить | Цитировать Сообщить модератору |
Leonid Kudryavtsev Member Откуда: Сообщений: 7387 |
Года три назад, у LevelDB драйвера для жава были какие-то ну очень кривые. Да и по тестам, отзывам, нишевой продукт с массой специфики Когда для себя выбирал, остановился на банальном SQL Lite, лично мне скорости вполне хватило. По тестам в И-нет (сам не тестил) особого профита у LevelDb не видно, а проблемы на форуме часто описывают. Ну нафиг такие эксперементы ))) |
31 янв 19, 11:53 [21798585] Ответить | Цитировать Сообщить модератору |
вадя Member Откуда: Екатеринбург Сообщений: 15192 |
|
||
31 янв 19, 11:53 [21798586] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 38770 |
Надо спросить у автора. Мысль здравая. |
||||
31 янв 19, 11:56 [21798591] Ответить | Цитировать Сообщить модератору |
Андрей Панфилов Member Откуда: Москва > Melbourne Сообщений: 3016 |
|
||
31 янв 19, 12:08 [21798608] Ответить | Цитировать Сообщить модератору |
mayton Member Откуда: loopback Сообщений: 38770 |
Я-бы очень не хотел обсуждать тему кеша ОС. Она очень путает карты. Особенно когда хранилище превысило память на 10-100% а мы ради этого уже втащили в постановку key-value БД. У нас нет чистой алгоритмизации а есть эвристика на тему что попадет в кеш и что вобще автор будет делать с базой в части статистики. Я беру самый самый worst case. Когда размер БД в несколько раз уже превысил доступную память и соотв все кеши бесполезны. Рассматривать этот диапазон 10-100% я не хочу. Мне это просто неинтересно. |
31 янв 19, 12:40 [21798665] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Java | ![]() |