Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Out of memory errror - есть ли возможность Свопа ?  [new]
razliv
Member

Откуда:
Сообщений: 1088
Здравствуйте, столкнулся с проблемой:


Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded


При заполнении HashMap, большим значением элементов.
Есть ли возможность свопа на диск, или другого способа экономичной работы с большим
количеством данных ?
30 янв 19, 10:24    [21797503]     Ответить | Цитировать Сообщить модератору
 Re: Out of memory errror - есть ли возможность Свопа ?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3184
razliv,

http://www.mapdb.org/
30 янв 19, 11:20    [21797575]     Ответить | Цитировать Сообщить модератору
 Re: Out of memory errror - есть ли возможность Свопа ?  [new]
mayton
Member

Откуда: loopback
Сообщений: 39940
Есть достаточно быстрые коробочные продукты с интерфейсом похожим на 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]     Ответить | Цитировать Сообщить модератору
 Re: Out of memory errror - есть ли возможность Свопа ?  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5055
razliv, начать бы конечно с того, что выделить чуть больше памяти? -xmx, -xms
30 янв 19, 11:56    [21797610]     Ответить | Цитировать Сообщить модератору
 Re: Out of memory errror - есть ли возможность Свопа ?  [new]
razliv
Member

Откуда:
Сообщений: 1088
Спасибо большое за ответы !

Озверин,

Тут уже увеличением памяти не поможешь :(

Спасибо буду пробовать гибриды collections и db :) именно то что и хотелось !
30 янв 19, 14:02    [21797767]     Ответить | Цитировать Сообщить модератору
 Re: Out of memory errror - есть ли возможность Свопа ?  [new]
mayton
Member

Откуда: loopback
Сообщений: 39940
Оптимизированы-ли они по записи? Если чел туда будет заливать терабайты информации - это будет
тоже немаловажно. Ждать ему минуту. Час. Или сутки. Хорошая тема для бенчмарка.
30 янв 19, 14:14    [21797783]     Ответить | Цитировать Сообщить модератору
 Re: Out of memory errror - есть ли возможность Свопа ?  [new]
razliv
Member

Откуда:
Сообщений: 1088
Майтон

А что есть "оптимизированны по записи" ?
30 янв 19, 15:53    [21797963]     Ответить | Цитировать Сообщить модератору
 Re: Out of memory errror - есть ли возможность Свопа ?  [new]
mayton
Member

Откуда: loopback
Сообщений: 39940
Для дисковых операций random-access губителен. Поэтому те структуры данных
которые планируется хранить на диске и модифицировать часто и много - дополняют
логом транзакций. Это было очень актуально в этоху магнитных дисков. Для SSD - не знаю.
Недо тестировать. Но сам по себе факт наличия подобной структуры говорит просто о зрелости
проекта. Незрелые проекты обычно надеются что random-access "прокатит".
30 янв 19, 16:10    [21797985]     Ответить | Цитировать Сообщить модератору
 Re: Out of memory errror - есть ли возможность Свопа ?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3184
mayton
Для дисковых операций random-access губителен. Поэтому те структуры данных
которые планируется хранить на диске и модифицировать часто и много - дополняют
логом транзакций.
Все уснуть не могу - пытаюсь понять как связано первое предложение со вторым:
  • В жаве условно есть три варианта что-то читать и писать (в порядке уменьшения тормознутости): старые добрые I/OStreams, RandomAccessFile и MappedByteBuffer
  • лог транзакций (он же журнал) нужен чтобы поддержать atomicity и durability - и тут вообще пофиг как доступ к файлу организован

    а кого random-access-то губит, как и зачем?
  • 30 янв 19, 20:34    [21798263]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39940
    Андрей Панфилов,

    давайте рассуждать. Автору нужен 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]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3184
    mayton
    Java предлагает два базовых функционала. RandomAccessFile и FileOutputStream. Оба из них
    уже оптимизированы через NIO по максимуму поэтому мы будем счиать что NIO нам не нужен.
    Первый пригоден для чтений записей рандомно. В любое место диска. Второй - только последовательно.
    Первый создает жёсткую нагрузку на кеши и на механику диска. Второй - более мягкий.
    Это как вообще? Вот смотрим сигнатуру:

        /**
         * 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 со стороны жавы.

    mayton
    Можно провести эксперимент - читать терабайтный файл последовательно.
    А потом тот-же файл блоками (по 1,2,4,16 Mb) как хотите произвольно и замерять как просядет скорость.
    Вы-таки определитесь, пишите вы или читаете.

    mayton
    На этом свойстве основанны журналирующие оптимизации практически всех DBMS.
    DBMS фактически "откладывает на потом" запись в сегмент данных. Сначала она журналирует
    (FileOutputStream) а потом уже в фоне дописывает в данные когда есть возможность.
    Но главное - не блокировать ожидание записи.
    Журнал в БД обеспечивает atomicity и durability, к производительности это никакого отношения не имеет, откуда по-вашему возьмется производительность, если с журналом нужно уже в два места писать, а запись в журнал "последовательная" (да еще и с O_SYNC) не потому что так быстрее, а потому что чтобы данные не потерять.
    31 янв 19, 04:59    [21798379]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    вадя
    Member

    Откуда: Екатеринбург
    Сообщений: 15471
    razliv
    При заполнении HashMap, большим значением элементов.
    Есть ли возможность свопа на диск, или другого способа экономичной работы с большим
    интересно а перенос HashMap в субд не поможет?
    31 янв 19, 06:43    [21798393]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    Siemargl
    Member

    Откуда: 010100
    Сообщений: 6114
    Андрей Панфилов
    .....
    Но главное - не блокировать ожидание записи.
    Журнал в БД обеспечивает atomicity и durability, к производительности это никакого отношения не имеет, откуда по-вашему возьмется производительность, если с журналом нужно уже в два места писать, а запись в журнал "последовательная" (да еще и с O_SYNC) не потому что так быстрее, а потому что чтобы данные не потерять.[/quot]
    Надо это производителям почти всех СУБД рассказать, а то они не знают =)


    Топик - бери любую удобную key-value dbms
    31 янв 19, 09:39    [21798460]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39940
    Андрей Панфилов
        /**
         * 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 со стороны жавы.

    Здесь offset - применительно не к файлу а к источнику. К массиву байтов.

    По поводу API операционной системы - вы правы. Почти все файловые API в конечно счете
    будут сводится к open/fseek/read/write/close для Unix и к другим CreateFile.. (там более длинное
    название в Windows). И на уровне железа будут отображаться в атомарные операции
    записи сектора на диск для HDD или для какой-то примитивной операции передачи данных блочно
    для SSD.
    31 янв 19, 10:52    [21798517]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39940
    Андрей Панфилов
    mayton
    Можно провести эксперимент - читать терабайтный файл последовательно.
    А потом тот-же файл блоками (по 1,2,4,16 Mb) как хотите произвольно и замерять как просядет скорость.
    Вы-таки определитесь, пишите вы или читаете.

    В самом начале топика я выразил сомнение по поводу скорости инициализации подобной дисковой мапы.
    Инициализация предполагает запись.

    Про эксперимент - пока отложим.
    31 янв 19, 10:54    [21798518]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39940
    Андрей Панфилов
    Журнал в БД обеспечивает atomicity и durability, к производительности это никакого отношения не имеет, откуда по-вашему возьмется производительность, если с журналом нужно уже в два места писать, а запись в журнал "последовательная" (да еще и с O_SYNC) не потому что так быстрее, а потому что чтобы данные не потерять.

    Я говорил о физическом уровне. Об оптимзиации дисковых операций в DBMS.

    Вы (очень резко) прыгнули в ACID (atomicity, durability) про которые мы еще не говорили. Да и автор пока не выставлял
    требований. Хотя журнал (redo-log, write-ahead-log) может быть использован для обеспечения durability. Да.

    Я сейчас не помню как там в этих key-value хранилищах. Но обычно владелец волен выбирать режим в котором
    он будет работать. Транзакционный или не транзакционный.

    А для многих операций уровня ETL, bulk-load и прочих (массовых) манипуляций с данными обычно разработчик
    или DBA сознательно выбирает не-транзакционный режим. Например стартует биржевая система. Она должна
    в несколько минут прогрузить данные из обычной БД в свой более быстрый key-value. Я-бы здесь сознательно
    выбирал отключение транзакций ибо нету еще никаких пользователей (система в процессе загрузки) и сама
    по себе операция достаточно проста по реакции на ошибку. Если что-то пошло не так - просто загрузим еще разик.
    Нам важнее быстро стартовать операционный день. А после старта уже пул коннекшенов подключится в режиме
    транзакций как и положено.
    31 янв 19, 11:05    [21798529]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5055
    Андрей Панфилов, наличие оффсета как бе намекает, откуда из массива переданных байт начинать писать, а не "куда".
    31 янв 19, 11:08    [21798532]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3184
    mayton
    Здесь offset - применительно не к файлу а к источнику. К массиву байтов.
    Тогда понятно чего там int, тем не менее fos.getChannel().position() будет делать seek().

    mayton
    По поводу API операционной системы - вы правы. Почти все файловые API в конечно счете
    будут сводится к open/fseek/read/write/close для Unix и к другим CreateFile.. (там более длинное
    название в Windows). И на уровне железа будут отображаться в атомарные операции
    записи сектора на диск для HDD или для какой-то примитивной операции передачи данных блочно
    для SSD.
    Там еще есть DMA, оно же zero-copy и пр. MappedByteBuffer в жаве именно его реализует.
    31 янв 19, 11:22    [21798541]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    Озверин
    Member

    Откуда: Ростов-на-Дону
    Сообщений: 5055
    Андрей Панфилов, что там реализовано в java - вообще никого не волнует, если SSD физически при записи работает с блоками по 1mb(или по сколько там?). И каждая рандомная запись блока размером меньшим 1 mb будет сопровождаться определенным кол-вом IOPs:

    -прочесть весь блок из 1 метра
    -заменить в нем на наш маленький блок
    -записать обратно

    Отсюда проистекает так называемая оптимизация под железо, когда пишут сразу "нужным" размером блока", а не маленькими или большими, про то (частично) майтон и говорит.
    31 янв 19, 11:30    [21798556]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39940
    Андрей Панфилов
    Там еще есть DMA, оно же zero-copy и пр. MappedByteBuffer в жаве именно его реализует.

    Аккурат в новый год у меня была попытка выпрыгнуть из Java условностей и прыгнуть
    в недра ОС (в основном меня интересовали Windows-10 и Linux последних версий ядра)
    чтобы понять что там и как. К сожалению сообщество отреагировало вяло. Толи
    салат Оливье был плох толи Шампанськое...

    Вот он кстати https://www.sql.ru/forum/1307294/tyapnichnyy-novogodniy-mmap
    31 янв 19, 11:44    [21798575]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    Leonid Kudryavtsev
    Member

    Откуда:
    Сообщений: 7525
    Года три назад, у LevelDB драйвера для жава были какие-то ну очень кривые. Да и по тестам, отзывам, нишевой продукт с массой специфики

    Когда для себя выбирал, остановился на банальном SQL Lite, лично мне скорости вполне хватило. По тестам в И-нет (сам не тестил) особого профита у LevelDb не видно, а проблемы на форуме часто описывают. Ну нафиг такие эксперементы )))
    31 янв 19, 11:53    [21798585]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    вадя
    Member

    Откуда: Екатеринбург
    Сообщений: 15471
    Озверин
    -прочесть весь блок из 1 метра
    -заменить в нем на наш маленький блок
    -записать обратно
    а не делает ли это всё update из любой субд?
    31 янв 19, 11:53    [21798586]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39940
    вадя
    razliv
    При заполнении HashMap, большим значением элементов.
    Есть ли возможность свопа на диск, или другого способа экономичной работы с большим
    интересно а перенос HashMap в субд не поможет?

    Надо спросить у автора. Мысль здравая.
    31 янв 19, 11:56    [21798591]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3184
    Озверин
    Отсюда проистекает так называемая оптимизация под железо, когда пишут сразу "нужным" размером блока", а не маленькими или большими, про то (частично) майтон и говорит.
    Оно возникает только если запись идет мимо кеша ФС, т.е. файлы нужно открывать с O_DIRECT и дальше приседать, что, к примеру, в Linux не рекомендуется делать.
    31 янв 19, 12:08    [21798608]     Ответить | Цитировать Сообщить модератору
     Re: Out of memory errror - есть ли возможность Свопа ?  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39940
    Я-бы очень не хотел обсуждать тему кеша ОС. Она очень путает карты. Особенно когда хранилище
    превысило память на 10-100% а мы ради этого уже втащили в постановку key-value БД.

    У нас нет чистой алгоритмизации а есть эвристика на тему что попадет
    в кеш и что вобще автор будет делать с базой в части статистики.

    Я беру самый самый worst case. Когда размер БД в несколько раз уже превысил доступную
    память и соотв все кеши бесполезны.

    Рассматривать этот диапазон 10-100% я не хочу. Мне это просто неинтересно.
    31 янв 19, 12:40    [21798665]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
    Все форумы / Java Ответить