Разобрался наконец-таки с старой проблемой - оракл с несколькими инстансами на хосте не мог использовать выделенную ему память. Хотя предварительно все просчитывалось.

Оказалось, что когда при загрузке стартуем системы друг за другом под sidadm, не только оракл ест huge pages но и сам сервер приложения. То есть к моменту старта 3го инстанса(к примеру) на сервере больших страниц не остается даже для оракла т.к. они сожраны 2мя предыдущими приложениями.

Вопрос, решается 2мя путями:
1. стартовать ораклы до сапов
2. правами через группу vm.hugetlb_shm_group

но чето стало интересно: получается САП сам "неорганизованно" использует большие страницы, а не запихать ли его в huge pages принудительно по нотам?

нашел ,что нужно делать так:
es/use_mprotect = FALSE
es/implementation = std
em/largepages = TRUE
em/initial_size_MB = 4096
es/use_shared_memory = true

но уже описание первого параметра говорит что делать так не стоит.

Собственно вопрос: кто-нибудь запихивал САП на большие страницы? как ощущения?

по джава инстансам отдельная песня конечно, но тоже комментарии приветствуются.

зы
transparent huge pages на этом сервере запрещены

А для какой операционной системы у вас поиск впечатлений на свою голову...?

linux

честно говоря даже не знал что huge_pages где-то еще есть.

да, делала пару лет назад - при сайзинге неплохо так ошиблись, решили застарелую проблему таким вот методом под руководством сапа. За год, что система просуществовала на том сервере, все было неплохо, ну а потом переехали

но легче инстанс снести конечно

Ну как бы нота намекает -- >
989935 - Use of Linux 'Huge Pages' for SAP Application Server

Solution

Important:

Must never be used in the customer system because mprotect is deactivated.
Set in benchmark systems only. May improve performance.

P.S. у нас много систем где oracle на Huge_Pages , проблем не было как у вас.