Я пытаюсь обойти проблему, которая беспокоила меня некоторое время. В двух словах: на каком основании следует назначать максимальное пространство кучи для ресурсоемкого приложения и есть ли недостаток в том, что оно слишком велико?
У меня есть приложение, используемое для визуализации огромных медицинских данных, которые могут потреблять до нескольких гигабайт памяти, если несколько томов изображений открыты по размеру рядом. Кэширование данных для просмотра необходимо для плавного рабочего процесса. Программное обеспечение поддерживается рабочими станциями Windows и запускается с помощью загрузчика, который назначает размер кучи и запускает основное приложение. Фактическая память, необходимая основному приложению, прямо пропорциональна просматриваемым данным и не может быть определена загрузчиком, поскольку для этого потребовалось бы чтение данных, что, в конечном счете, заняло бы слишком много времени.
Таким образом, чтобы убедиться, что JVM имеет достаточно памяти во время запуска, мы устанавливаем xmx настолько большим, насколько это возможно, исходя из текущего дизайна, исходя из максимальной физической памяти рабочей станции. Однако есть ли в этом недостаток? Я читал (из сообщения от 2008 года), что собственные процессы могут занимать лишнее пространство кучи, что может привести к ошибкам памяти во время выполнения. Должен ли я также нюхать свободную виртуальную память или размер файла подкачки перед выделением места в куче? Как бы вы справились с этой ситуацией?
О, и это мой первый пост на этих форумах. Приятно познакомиться и быть нежным! :)
Обновление:
Спасибо за ответы на все вопросы. Я не уверен, правильно ли я выразил свои слова, но моя проблема возникла из-за того, что я ничего не знаю об оборудовании, на котором будет работать это программное обеспечение, но, тем не менее, хотел бы выделить как можно больше места в куче для программного обеспечения. .
Я пришел к решению выделить кучу из 70% физической памяти, ЕСЛИ доступно достаточное количество виртуальной памяти - в противном случае меньше.
