Как сейчас обстоят дела с фрагментацией кучи? [закрыт]

Давным-давно была система DOS и у нее была проблема - для многих приложений типа серверов баз данных при долгой работе куча сильно фрагментировалась. И хотя свободное место в куче было, некоторые запросы не могли быть выполнены, так как не было непрерывного свободного участка кучи.

Время шло и сейчас у нас есть и много памяти в ОЗУ и есть своп-файл. Но тем не менее и объемы данных выросли.

Вопросы:

1. Как сейчас обстоят дела с фрагментацией кучи? Есть ли проблема фрагментации кучи для приложений, которые должны работать с аптаймом в годы и десятилетия типа поисковых машин гугла или баз данных центробанков во всем мире?

2. Есть ли реализации куч со сжатием? Применяются ли они в реальных приложениях?

UPD1:

Еще вопросы:

3. Как обстоят дела с фрагментацией кучи в языках со сбором мусора типа Явы? Если Ява-приложение работает долго, то вполне возможен такой вариант, что свободное место в куче есть, но нет непрерывного свободного места для размещения очередной переменной. Есть ли сжатие кучи в Ява и других языках со сборкой мусора?

4. Да собственно и системная куча в операционных системах тоже подвержена фрагментации. Там постоянно создаются/уничтожаются системные объекты типа семафоров и буферов межпроцессорного обмена. Системная куча тоже может фрагментироваться до потери работоспособности. Выполняется ли сжатие системной кучи в современных ОС?

UPD2:

Я правильно понимаю, что под сжатием/дефрагментацией кучи вы понимаете не просто слияние 2-х смежных участков, ставших свободными (это всегда и всюду было)? – avp 3 часа назад

Естественно, не только это. Нужно в куче иметь информацию о всех выданных указателях и при сжатии кучи корректировать эти указатели в программе. Конечно, при такой схеме указатель будет классом, а не просто машинным адресом. Может быть понадобится счетчик экземпляров указателя. Может быть понадобится организовать эти указатели в список и при сжатии кучи все их корректировать, двигаясь по списку.

UPD3:

Нет, просто интересно что вы думаете про ресурсы, которые понадобятся для корректировки всех указателей (ссылок) на данные в перемещаемых фрагментах – avp 7 секунд назад

Дополнительные ресурсы понадобятся, это несомненно. Но это лучше, чем аварийное завершение приложения или отказ в обслуживании по причине фрагментированной кучи. Другое дело, не очень понятно, насколько это актуально. Для сеансных приложений типа утром запустил Word, написал документ, закрыл Word, это может быть и не очень актуально. А для серверов, которые должны работать годами не выключаясь и внутри которых постоянно идет нарезка памяти это может быть актуально. Но пока что никто не поделился информацией, насколько это актуально. Хотя, конечно, большие фирмы должны проводить такие исследования, насколько часто у них встает проблема фрагментированности кучи.

UPD4:

@pepsicoca1, "для серверов, которые должны работать годами не выключаясь" -- обычно при построении надежных систем в них предусматривается вероятность отказа любого компонента и соответственно процедуру переключения на резервную конфигурацию. Например, в HA серверах это обычно называют переключением пакета. Если монитор обнаруживает неисправность, он выполняет эту процедуру. Если требуются регламентные работы (скажем, по железу), то ее выполняет админ. Если пакет (прикладной софт) сам диагностирует неполадки, то он шлет сообщение монитору. И т.д. и т.п. – avp 13 часов назад

Аппаратное резервирование на уровне RAID массивов позволяет по-горячему менять дисковые накопители. Да и меняют их не по факту сбоя, а по достижению выработки ХХХ часов, гарантированных производителем.

Если же действительно стоит две разные физически базы данных, работающих параллельно, то один сервер должен работать, а второй должен аппаратно(!) зеркалится. Если первый сервер сбойнул (по любой причине, включая фрагментацию кучи), то второй должен стартануть и в реальном времени(!) перехватить обслуживание на себя.

UPD5:

@avp, Я понимаю так, как нужно. Не все данные хранятся сжатыми, система сжимает только ту информацию, которую считает необходимой. Дальше обсуждать нет желания. – AR Hovsepyan 14 часов назад

Кстати, это свежая идея. Куча с архивацией/деархивацией в реальном времени, по типу сжатого тома в дисковой подсистеме. Для однотипных данных может дать реальную экономию памяти. :-)