Я работаю в веб-приложении java. В некоторых разделах я использую очень огромную переменную дерева, сохраняющую и сохраняющуюся в памяти (ОЗУ). Могу ли я перенести это в виртуальную память (своп). примечание: огромное имя дерева и адрес электронной почты для всех пользователей, которые используют в текстовом поле Ajax.Как использовать виртуальную память (своп в файловой системе Linux) в Java-программировании
В Linux нет стандартного способа принудительного обмена блоком памяти, поэтому у JVM не будет способа попросить ОС выполнить такую задачу.
Лучшее, что вы можете сделать, если хотите эту функцию, - это сериализовать дерево и записать необработанные данные в файл на диске, а затем вернуть его, когда вы будете готовы к этому.
Но вы, вероятно, этого не хотите, потому что запись на диск чрезвычайно медленная по сравнению с физической памятью.
Дело в том, что касается ОС, беспокоясь об этом. Можно с уверенностью предположить, что он знает лучший способ управления памятью, чем вы.
Позвольте OS, который использует ваш пользователь, позаботится об этом.
Ваша ОС автоматически управляет собственной памятью и выталкивает вещи в файл подкачки по мере необходимости.
Если у вас много данных, вы можете захотеть сохранить свои данные в базе данных вместо огромного дерева в памяти. Это, вероятно, позволит повысить масштабируемость вашего приложения, а также повысить производительность - это, безусловно, даст вам лучшую производительность, чем чтение и запись всей структуры на диск всякий раз, когда вам нужно искать или изменять запись.
Редактировать: Вам необязательно настраивать специальную машину базы данных. Учитывая, что в настоящее время вы пытаетесь сохранить все свои данные в памяти прямо сейчас, вы, вероятно, можете использовать встраиваемую базу данных, например HSQLDB или SQLite, которые имеют ограничения по размеру 16 ГБ и 2 Тб соответственно.
Я не могу использовать базу данных – SjB
Вы должны спросить себя «почему?» Если вы имеете дело с большим количеством данных и рассматриваете все это как монолит, который будет выгружен полностью или не в памяти, ваш дизайн, вероятно, нуждается в переосмыслении. – Mike
@SjB: есть ли техническая причина, по которой вы не можете использовать базу данных, или это скорее проблема с системным администратором? Я отредактировал свое сообщение, чтобы включить ссылки на пару баз данных, которые должны быть довольно просты в использовании, без какой-либо запутанной установки. – rob
Бегущее изображение java, которое частично просматривает страницы для обмена, является мертвым изображением java. Как только вы достигнете достаточно большого количества GC, вы снова можете перечислить все. Страница в этом случае достаточно плохая. Если на самом деле у вас на самом деле нет достаточного количества ОЗУ, вы в конечном итоге потерпите поражение, невосприимчив к крушению сервера. Paged Java is Bad (tm).
Если у вас достаточно ОЗУ для всего, вам не нужна свопа.
Заполните свой список в таблице базы данных, на диске, проиндексируйте его, ограничьте свои результирующие наборы и сделайте соответствующие запросы против него. Это будет чистая победа, и БД может кэшировать страницы, которые ей больше всего нравятся, поэтому вам не нужно об этом думать.
Или получить больше ОЗУ.
Мне интересно, что все говорят ему, что хранение предметов на диске ужасно ужасно неопределенно, и в то же время он рекомендует использовать базу данных, возможно, удаленную, которая будет хранить данные на диске .. на другом машина ..
Вы считаете, что система будет более эффективной при слепом обращении к файлу подкачки, чем в случае, если файл подкачки будет зависеть от кода, который знает, что ждет в будущем. гораздо эффективнее менять память, которая, как вы знаете, не будет использоваться какое-то время, чем система для просмотра всех элементов в памяти и попыток эффективно поместить некоторые из них в этот файл.
Конечно, вы ошибаетесь, вы все в порядке. ЛОКАЛЬНАЯ база данных была бы самым эффективным способом хранения данных в FILE (где он будет записан и прочитан). Если у вас нет доступа к локальной базе данных, введите код. Хешмап предназначен для хранения в памяти, а упорядоченный индексированный связанный список предназначен для хранения на диске. Пытаться нажимать прямо из памяти на диск без какого-либо рассмотрения эффективности обеих сред неэффективно.
Как об этом как о другом решении по одной и той же проблеме: я создаю много файлов на стороне сервера PDF, у меня есть 10 из 1000 клиентов, которые обычно хотят запускать отчеты в то же время месяца , Средний размер PDF может составлять 7-10Mb. Имея ограниченную кучу, «свопинг» данных во временный файл является допустимым способом создания PDF-файлов, так как мне нужно установить длину контента в ответе до потоковой передачи данных PDF клиенту.
Возможно, вместо того, чтобы просто допросить дизайн, некоторые полезные параметры могут быть удобными. Лично я ищу использование одного временного файла для каждого процесса или одновременного доступа к одному файлу «своп».
Что вы предложите?
В некоторых случаях, когда необходимо хранить данные на диске (например, см. Раздел DiskPageStore в веб-среде Wicket); но, в общем, вы должны оптимизировать свое приложение, чтобы не было необходимости хранить все эти данные одновременно в памяти. Для предложения ajax попробуйте ограничить количество результатов (пользователь может увидеть больше, набрав часть имени пользователя) или создать какую-то систему подкачки. – RMorrisey
Вы также можете сделать ваши объекты более легкими (например: вместо хранения дерева UserEmailObject, храните HashMap, сопоставляя пользователей с адресами электронной почты и заполняя их с помощью цикла или курсора). –
RMorrisey
«дайте OS беспокоиться об этом. Можно с уверенностью предположить, что он знает лучший способ управления памятью, чем вы». - отличный совет. – rob