Самая большая куча, используемая в управляемой среде? (.net / java)
Какую самую большую кучу вы лично использовали в управляемой среде, такой как Java или .NET? С какими проблемами производительности вы столкнулись, и получали ли вы в конечном итоге убывающую отдачу, чем больше была куча?
Ответы 5
Я не уверен, что вы имеете в виду под кучей, но если вы имеете в виду используемую память, я использовал совсем немного, 2 ГБ +. У меня есть веб-приложение, которое обрабатывает изображения, и для анализа ему требуется загрузить в память 2 больших файла сканирования.
Были проблемы с производительностью. Windows заменяла бы много оперативной памяти, и тогда это приводило бы к множеству ошибок страниц. Никогда не было необходимости в более чем 2 изображениях за раз, поскольку все запросы получали эти изображения (я разрешал только 1 сеанс для каждого изображения, установленного за раз)
Например, настройка файлов для первоначального просмотра займет около 5 секунд. Выполнение простого анализа и масштабирования будет довольно быстрым после запоминания, порядка от 0,1 до 0,5 секунды.
Мне все еще нужно было оптимизировать, поэтому я в конечном итоге подготовил файлы и разделил их на более мелкие части и работал только с теми частями, которые требовались пользователю в то время.
Я использовал от 2 до 5 ГБ памяти в java, но обычно, когда я получаю более 2 ГБ, я действительно начинаю думать об оптимизации памяти. Уменьшение отдачи может варьироваться от отсутствия оптимизации, когда это необходимо, потому что у вас много памяти, до отсутствия памяти для кешей ОС / диска (что может помочь вашему приложению в целом).
Для Java я рекомендую следить за использованием памяти в каждом поколении с течением времени. Вы создаете много временных объектов или имеете долгосрочные объекты, потребляющие много памяти? Зная эти вещи, можно сделать большую оптимизацию памяти.
В .Net, в 32-разрядной версии Windows, вы можете реально использовать только 1,4 ГБ памяти, прежде чем все станет действительно неприятным (исключения из памяти). Это связано с ограничением в 32-битных окнах, которое ограничивает использование одним процессом более 2 ГБ ОЗУ. Есть переключатель / 3GB, который вы можете поместить в свой boot.ini, но это лишь немного продвинет вас вперед. Если вы хотите использовать много памяти, вам следует серьезно подумать о работе в 64-битной версии Windows.
В настоящее время у меня есть производственное приложение с 6 ГБ памяти. Вам также понадобится 64-битный компьютер, чтобы JVM могла решить эту проблему. Сборщик мусора - действительно единственное (что я нашел до сих пор), где производительность снижается с размером, и то только если вы вручную запускаете System.GC, который заставляет JVM приводить все к резкой остановке при прохождении. Объектов на 6 ГБ. Тоже занимает добрых 20 секунд. Поведение GC по умолчанию не делает этого, кстати, вы должны быть достаточно тупыми, чтобы заставить его это сделать. Также стоит изучить настройку JVM такого размера.
Вы также можете найти такие вещи, как распределенные и кластерные JVM, извините, у них нет хороших ссылок, так как я не слишком внимательно изучал этот вариант, хотя я нашел ссылки на более крупные установки.
Я работаю в 64-битной системе .Net, которая обычно использует 9–12 ГБ, а иногда и 20 ГБ. Я не видел никаких проблем с производительностью даже при сборке мусора, и я очень внимательно искал, так как не ожидал, что он будет работать так хорошо.
Более ранняя версия слишком долго удерживала некоторые объекты, что приводило к случайным сборщикам мусора, освобождающим более 3 ГБ. Даже тогда заметного влияния на производительность не было. Система работает на 16-ядерном сервере с 32 ГБ оперативной памяти, что, вероятно, помогает ...