|
|
|
hugepages, что произойдет при их исчерпании
|
|||
|---|---|---|---|
|
#18+
Есть экземпляр Oracle 11.2, работает под RHEL. Сконфигурирован для работы с hugepages. Все работает, но вот есть один параметр в системе, который настораживает - hugepages_free. В процессе работы он постепенно "тает". Во время отработки тяжелых запросов в СУБД он "тает" быстрее. Что произойдет, если hugepages_free исчерпается, станет равным 0? Положительной динамики по повторному использованию уже выделенной памяти не видно. А вот постоянное уменьшение этого параметра говорит о том, что в какой-то момент возможности получить очередную страницу не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 15:14 |
|
||
|
hugepages, что произойдет при их исчерпании
|
|||
|---|---|---|---|
|
#18+
helgisbox, huge pages резервируется фиксированного объема при старте экземпляра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 15:18 |
|
||
|
hugepages, что произойдет при их исчерпании
|
|||
|---|---|---|---|
|
#18+
helgisboxВ процессе работы он постепенно "тает" Что именно "тает"? Что говорит "HugePages_Rsvd"? Код: plsql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 15:26 |
|
||
|
hugepages, что произойдет при их исчерпании
|
|||
|---|---|---|---|
|
#18+
Takurava, Код: sql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 15:35 |
|
||
|
hugepages, что произойдет при их исчерпании
|
|||
|---|---|---|---|
|
#18+
helgisbox, Reserved вместе с Free уменьшается. Разница между ними равна 4, постоянная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 15:37 |
|
||
|
hugepages, что произойдет при их исчерпании
|
|||
|---|---|---|---|
|
#18+
helgisboxhelgisbox, Reserved вместе с Free уменьшается. Разница между ними равна 4, постоянная.Не появилось мыслей? База зарезервировала под себя N страниц - пока они считаются free, но по мере надобности база себе их забирает. Если free чуть больше чем reserdev, то всё ок. Если один в один - надо смотреть в alert.log, что там: 11г - Large Pages configured > Large Pages used (Total Shared Global Region in Large Pages = 100%) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 12с - AVAILABLE_PAGES > EXPECTED_PAGES Код: plsql 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 16:14 |
|
||
|
hugepages, что произойдет при их исчерпании
|
|||
|---|---|---|---|
|
#18+
Пугает монотонность отъедания. По идее должен быть какой нибудь "reusage". То занято, к примеру 5000 стр из 8100 зарезервированных, то 3000, то 7900. А тут вроде как он работает постепенно доходя до предела. Что будет, если подойдет вплотную к числу зарезервированным, не появится ошибка и не остановится экземпляр, когда очередная попытка получить порцию памяти не завершится успехом? Есть какие-нибудь представления внутренние (может в x$ tables), где более подробно расписано и будет понятно, что это не монотонность в росте hugepages? Если есть ссылка на мануалы, прошу кинуть в меня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2017, 07:35 |
|
||
|
hugepages, что произойдет при их исчерпании
|
|||
|---|---|---|---|
|
#18+
helgisboxкогда очередная попытка получить порцию памяти не завершится успехом? Попытка получить память увенчалась успехом при старте экземпляра, больше попыток именно получить память не будет, будут только попытки её использовать . И переиспользовать. Но не освобождать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2017, 09:30 |
|
||
|
hugepages, что произойдет при их исчерпании
|
|||
|---|---|---|---|
|
#18+
проходил мимо..., Внутри самого экземпляра как можно увидеть сколько страниц уже по факту сейчас используется, а сколько свободно? С точки зрения ОС они зарезервированы и по мере необходимости будут продолжать отъедаться. С точки зрения ОС резерв постепенно разбирается - тут нет криминала. А вот что делает экземпляр с этом памятью, ка узнать? Монотонный рост - это результат фрагментации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2017, 10:50 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39526512&tid=1885191]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
174ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 242ms |
| total: | 526ms |

| 0 / 0 |
