Управление лучшей памятью (кучей) на Solaris 10

Question

У меня есть код c встроенным SQL для Oracle через Pro * C.

Всякий раз, когда я делаю вставку или обновление (ниже данный примера обновления),

update TBL1 set COL1 = :v, . . . where rowid = :v 

Для управления сыпучих вставок и обновления, я выделил несколько кусков памяти для вставки в объеме и совершить один раз. Другие распределения памяти тоже происходят по мере необходимости. Как лучше управлять памятью (кучей) для распределения динамической памяти? Один из вариантов заключается в том, чтобы размер кучи настраивался во время соединения GNU. Я использую g ++ версию 2.95, я знаю, что это довольно старая версия, но она должна использовать это для наследия. Поскольку исполняемый файл (работает на Solaris 10), построенный на основе obce, может работать в нескольких производственных средах с различными ресурсами, одноразовый размер для распределения размера кучи может оказаться неприемлемым. В качестве альтернативы нужен какой-то механизм, при котором кучи могут упруго расти по мере необходимости. В отличие от Linux, Solaris, я думаю, не имеет понятия перераспределенной памяти. Таким образом, распределение памяти может потерпеть неудачу с помощью ENOMEM, если осталось больше свободного места. Что может быть лучшей стратегией, чтобы знать, что мы можем пересечь уровень опасности, и теперь мы должны либо освободить куски, которые мы храним, если они выполняются с использованием или передачей блоков памяти в Oracle DB, если они все еще не загружены и, наконец, DEALLOCATE. Любая стратегия, которую вы могли бы предложить?

Answer 1

Одним из решений было бы использование мягких ограничений в вашем коде для различных целей, например. что обрабатывается только 100 транзакций одновременно, а другие транзакции должны ждать, пока предыдущие не будут освобождены. Это гарантирует предсказуемое поведение, поскольку никакая часть кода не может использовать больше памяти, чем разрешено.

Вопрос: У вас действительно заканчивается память в приложении или вы фрагментируете свою память и не можете получить достаточный большой непрерывный блок памяти? Стратегии обработки каждого случая различны.

Answer 2

C не java, где размер кучи фиксируется при запуске.

Куча и стек скомпилированного приложения C имеют одинаковое пространство виртуальной памяти и динамически изменяются.

Размер этого пространства зависит от того, компилируете ли вы 32-битную или 64-разрядную бинарную версию, а также то, является ли ваше ядро ​​32-разрядным или 64-битным (на оборудовании SPARC оно всегда 64 бит).

Если у вас недостаточно ОЗУ и вы хотите, чтобы Solaris принимала большое резервирование памяти в любом случае, аналогично тому, как Linux перегружает память, вы можете просто добавить достаточное количество свопов для резервирования, которое будет поддерживаться фактическим хранилищем.

Если по какой-то причине вы несчастны с Solaris LibC распределителя памяти, вы можете оценить альтернативные из них в комплекте, как libumem, mtmalloc или третья сторона hoard. См. http://www.oracle.com/technetwork/articles/servers-storage-dev/mem-alloc-1557798.html.