Срочно нужна помощь проблеме «вываливания» в пэйджинг


Главная Форумы POWER Systems AIX/Hardware Срочно нужна помощь проблеме «вываливания» в пэйджинг

В этой теме 25 ответов, 4 участника, последнее обновление  yota 6 года/лет, 2 мес. назад.

  • Автор
    Сообщения
  • #12625

    michael034
    Участник

    Коллеги, доброй ночи.

    Ситуация такая. Переползли на новый lpar(сервер p7). В lparе 112Гб памяти, запущен Оракл. Суммарная SGA — 86Гб. Процессов сейчас не много в силу времени суток, соответственно еще чего-то жрется в PGA. Смотрю Nmon — свободной памяти aix постоянно держит на границе ~28Гб, при этом улетел в своп по мере некоторой жизни экземпляра на ~14Гб. Память свободную строго держит 28.1-28.2Гб. Сейчас место в пэйджинг добавил, так и живу пока…

    Мои настройки vmo(отличные от стандартных):

    strict_maxperm = «1»
    maxpin% = «90»
    maxperm% = «3»
    maxclient% = «3»
    minperm% = «1»

    minfree и maxfree стандартные — 960 и 1088
    Пулов памяти — 14

    vmstat -v
    29360128 memory pages
    28456672 lruable pages
    7370007 free pages
    14 memory pools
    1546676 pinned pages
    90.0 maxpin percentage
    1.0 minperm percentage
    3.0 maxperm percentage
    1.3 numperm percentage
    383190 file pages
    0.0 compressed percentage
    0 compressed pages
    1.3 numclient percentage
    3.0 maxclient percentage
    383190 client pages
    0 remote pageouts scheduled
    0 pending disk I/Os blocked with no pbuf
    62614 paging space I/Os blocked with no psbuf
    2228 filesystem I/Os blocked with no fsbuf
    0 client filesystem I/Os blocked with no fsbuf
    183 external pager filesystem I/Os blocked with no fsbuf
    73.6 percentage of memory used for computational pages

    В моем понимании(как это было в 5.3) я должен срываться в пэйджинг на отсечке ~960*14*4к, что совсем на 28Гб непохоже.

    Где я ошибаюсь и чего недопонимаю и зачем AIX держит столько памяти свободной, просветите плиз?
    Заранее спасибо, надеюсь на помощь.

  • #12626

    yota
    Участник

    А с чего вы взяли, что у вас своп используется. Из приведенных данных это не следует. То, что аикс занял некоторое место в свопе отнюдь не означает что оно активно используется. Если хотите гарантировано, чтобы SGA в своп не попадала, тогда LOCK_SGA=True в Оракле, или лучше используйте 64К страницы памяти для SGA.

  • #12627

    michael034
    Участник

    Page Space Physical Volume Volume Group Size %Used Active Auto Type Chksum
    paging01 hdisk69 swapvg 61440MB 1 yes yes lv 0
    paging00 hdisk4 swapvg 20224MB 66 yes yes lv 0
    hd6 hdisk0 rootvg 512MB 0 no no lv 0

    nmon тоже показывает использование свопа, диски в активно пишут )

    lock_sga + v_pinshm=1 я использовал как раз до перехода на новый lpar. И еще выкладывал эту sga большими страницами памяти — по 16Гб. Сейчас решили обойтись без больших страниц. А как директивно использовать страницу в 64к?

    И главное — есть ответ на вопрос зачем аикс держит свободную память на грвнице 28Гб? Какой настройкой это определяется?

  • #12628

    michael034
    Участник

    Вдогон настройки Vmo

    root@mmb-trub-way4bkp[/]> vmo -a
    ame_cpus_per_pool = n/a
    ame_maxfree_mem = n/a
    ame_min_ucpool_size = n/a
    ame_minfree_mem = n/a
    ams_loan_policy = n/a
    enhanced_affinity_affin_time = 1
    enhanced_affinity_vmpool_limit = 10
    esid_allocator = 0
    force_relalias_lite = 0
    kernel_heap_psize = 65536
    lgpg_regions = 0
    lgpg_size = 0
    low_ps_handling = 1
    maxfree = 1088
    maxperm = 853692
    maxpin = 26512042
    maxpin% = 90
    memory_frames = 29360128
    memplace_data = 0
    memplace_mapped_file = 0
    memplace_shm_anonymous = 0
    memplace_shm_named = 0
    memplace_stack = 0
    memplace_text = 0
    memplace_unmapped_file = 0
    minfree = 960
    minperm = 284559
    minperm% = 1
    nokilluid = 0
    npskill = 163328
    npswarn = 653312
    num_locks_per_semid = 1
    numpsblks = 20905984
    pinnable_frames = 27802014
    relalias_percentage = 0
    scrub = 0
    v_pinshm = 0
    vmm_default_pspa = 0
    vmm_klock_mode = 1
    wlm_memlimit_nonpg = 1

  • #12629

    yota
    Участник

    nmon тоже показывает использование свопа, диски в активно пишут )

    Ещё раз, использование свопа — это существенно отличные от нуля цифры в столбцах pi,po вывода vmstat. А никак не % занятого места в своп разделе. Это надеюсь понятно?

    lock_sga + v_pinshm=1 я использовал как раз до перехода на новый lpar. И еще выкладывал эту sga большими страницами памяти — по 16Гб. Сейчас решили обойтись без больших страниц. А как директивно использовать страницу в 64к?

    Что значит директивно? Создаются необходимы условия, и оракл сам использует 64К страницы. Причем в отличие он уродских 16ГБ страниц их не нужно предварительно выделять (резервировать) статически. 64К выделяются и освобождаются на ходу, можете в nmon’е посмотреть само ядро AIX их активно использует.

  • #12630

    michael034
    Участник

    «Создаются необходимы условия»
    Можно поинтересоваться какие и как? Насчет предварительного выделения — именно это и заставило отказаться от больших страниц.

    «А никак не % занятого места в своп разделе»
    Это наверное ветром надуло… )

    «Ещё раз, использование свопа — это существенно отличные от нуля цифры в столбцах pi,po вывода vmstat»
    Это настолько понятно, что даже приводить здесь вывод vmstast постеснялся… )

    Сейчас у меня своп практически не растет — вот вывод:

    kthr memory page faults cpu
    —— ———— ———————— ———— ————————
    r b avm fre re pi po fr sr cy in sy cs us sy id wa pc ec
    7 0 24458326 7162537 0 234 0 0 0 0 7988 75997 9011 10 2 87 1 4.87 20.3
    5 1 24446355 7173944 0 563 0 0 0 0 16049 95675 17146 8 1 86 5 3.95 16.5
    10 0 24464365 7155666 0 138 0 0 0 0 6953 68124 6970 9 1 88 1 4.65 19.4
    4 0 24446150 7173365 0 103 0 0 0 0 3374 21576 3599 8 1 90 1 4.17 17.4
    6 1 24461439 7157693 0 381 0 0 0 0 16295 111635 15845 9 1 88 2 4.25 17.7
    9 1 24460344 7158169 0 308 0 0 0 0 8749 70786 9817 10 2 87 1 4.83 20.1
    6 1 24446160 7171668 0 659 0 0 0 0 18152 99731 19768 8 1 87 4 4.16 17.3
    10 0 24460219 7156958 0 321 0 0 0 0 8719 75557 9561 10 2 88 1 4.78 19.9

  • #12631

    yota
    Участник

    «Ещё раз, использование свопа — это существенно отличные от нуля цифры в столбцах pi,po вывода vmstat»
    Это настолько понятно, что даже приводить здесь вывод vmstast постеснялся… )

    Тогда в чем паника, судя по выводу у вас своп не используется. По крайней мере в этот момент 🙂

  • #12632

    michael034
    Участник

    В этот момент таки да )
    Мне непонятно почему я туда попал. Скорее всего как я понимаю из-за отсутствия v_pinshm=1 и lock_sga=true. Но почему аикс при таком количестве свободной памяти начал туда кидать и как ему сказать чтобы делал ЗНАЧИТЕЛЬНО позже — я не понимаю.

    Насчет страниц по 64к — как все-таки создать эти условия? Может линк на доку или white paper есть какой?

  • #12633

    yota
    Участник

    В этот момент таки да )
    Мне непонятно почему я туда попал. Скорее всего как я понимаю из-за отсутствия v_pinshm=1 и lock_sga=true. Но почему аикс при таком количестве свободной памяти начал туда кидать и как ему сказать чтобы делал ЗНАЧИТЕЛЬНО позже — я не понимаю.

    Да с чего вы взяли, что AIX у вас что-то накидал в своп? AIX просто заранее резервирует место в свопе, но это ещё не означает что уже свапинг пошел.

    Насчет страниц по 64к — как все-таки создать эти условия? Может линк на доку или white paper есть какой?

    Тынц и тынц.

  • #12634

    roman
    Участник

    По-моему, дефолтные настройки aix уже давно заранее не резервируют место в свопе. В связи с этим, раз у вас показывается % использования свопа, значит, когда-то ранее была ситуация недостатка ОЗУ. Другое дело, что в данный момент времени вполне вероятно (судя по выводу команд) такого недостатка нет. Просто после попадания страницы в своп, она не удаляется из него даже после того, как эта страница была снова перемещена в ОЗУ. Поэтому, в вашей ситуации можно сказать о следующем: в какой-то период времени ваш workload требовал очень много оперативной памяти, но в данный момент времени памяти вполне достаточно. Если пользователи не жалуются на производительность, причин беспокоиться нет. Теперь насчет «больших» страниц. У вас очень большая SGA. И по-моему вам лучше бы использовать их вместо 64KB при условии, что вы испытываете недостаток в процессорных ресурсах. Еще раз повторюсь, это лично мое мнение

  • #12639

    michael034
    Участник

    ну кончилось тем, что в следующую ночь я переложился как и раньше в большие страницы и выложил в них SGA. Соответственно теперь у меня SGA в 86Гб выложена и запинена в памяти, в lpar остается после этого порядка 26-27 Гб под PGA и данные юзеровсикх сессий, ни в какой своп ничего не попадает. Просто хотелось попробовать обойтись без запинивания, но если при этом я валюсь в своп, а чтобы не валиться надо держать оверхеад в 30-35Гб свободной памяти в разделе, ну его в лес такой способ — я лучше гвоздями прибью в памяти? если точно знаю свои потребности по памяти под все остальное кроме SGA.

  • #12672

    uxTuaHgp
    Участник

    APAR IZ99772 — PAGING 4K PAGES BECAUSE OF LACK OF 64K PAGE DEMOTIONS
    Пока предложено обходное решение: отключить использование 64К страниц памяти
    vmo -r -o vmm_mpsize_support=0

    Но ваще решение лучше, конечно, большие страницы памяти — это то что доктор прописал.
    В 64К страничках размещали?

  • #12673

    michael034
    Участник

    >>В 64К страничках размещали?
    Нет. У меня оракл 10.2.0.3 а он умеет ложиться в 64к страницы от 10.2.0.4(+ какой-то патч) и соответственно либо 4к страницы, либо 16М.

  • #12674

    uxTuaHgp
    Участник

    Ну тогда чтобы не лочить, можно сделать как я написал или дождаться, когда по APAR будет фикс.

  • #12677

    michael034
    Участник

    Так вот я я не пойму — в умных статьях пишут про то что запинивание моветон и прибегать к нему надо в последнюю очередь. Четко понимая что и для чего. В принципе я это понимаю ) просто хотелось попробовать без него — оценить разницу. Оценил. Запинивание победило за явным преимуществом… Что плохого в тоаком механизме работы с памятью кроме очевидной геморойности настройки(относительной) и необходимости при каждом изменении размера SGA менять настройку страниц рестартовывать lpar и т.п. ?

  • #12678

    yota
    Участник

    Так вот я я не пойму — в умных статьях пишут про то что запинивание моветон и прибегать к нему надо в последнюю очередь.

    На мой взгляд чушь собачья, почему везде пишут фиг знает, видимо так привыкли :laugh: Использовать для SGA большие страницы нужно однозначно, запиниваются они автоматически.

  • #12680

    uxTuaHgp
    Участник

    Ненене, самый свежий тренд — юзать 64К страницы — они пинятся автоматически и выделять ничего не надо, но оракл младше 10.2.0.4 этого не умеет.
    Не комильфо теперь юзать LARGE PAGES и LOCK_SGA, так как приходится прописывать размер пула страниц в ОС перед выделением их в оракле.
    В данном случае имеют право на жизнь и использование 4К страниц, если конфигурацию оракла приходится часто менять, и использование ладж пэйджес и LOCK_SGA.

  • #12684

    roman
    Участник

    Так вот я я не пойму — в умных статьях пишут про то что запинивание моветон и прибегать к нему надо в последнюю очередь. Четко понимая что и для чего.

    Правильно пишут. Ресурсы системы должны быть спланированы с учетом workload, который будет выполнятся. А это означает, что дефицита памяти не должно быть в принципе. Paging space — это не увеличение размера памяти, а крайний механизм, который применяется ОС в случае недостатка памяти. Это исключительная ситуация, которой надо избегать. Но если уж она возникла, дайте возможность aix’у самому решать, что выкидывать в своп, а не вынуждайте его выбирать из того, что не запинено. А если памяти предостаточно, то и пинить ничего не надо, все и так будет в ОЗУ. Так что совет вполне адекватный, но право выбора у вас все же есть.

  • #12686

    uxTuaHgp
    Участник

    Но если уж она возникла, дайте возможность aix’у самому решать, что выкидывать в своп, а не вынуждайте его выбирать из того, что не запинено. А если памяти предостаточно, то и пинить ничего не надо, все и так будет в ОЗУ. Так что совет вполне адекватный, но право выбора у вас все же есть.

    Поспорим?
    Откуда AIX знать, что за приложение ты выполняешь?
    Он настроен универсально, чтобы любой зеленый админ после первой ступени обучения по аиксу смог поставить приложение без претензий на эффективное использование ресурсов и максимальную производительность.
    Если речь заходит об энтерпрайз масштабах и затачивании хоста под одно единственное приложение, то кому как не производителю этого приложения и не администратору знать, как лучше распределить память и какая ее часть должна быть запинена.
    Так вот, если у меня трудится оракл и из 120ГБ памяти я отдаю ему 80, например под SGA (а там кэши, словари, и тд и тп), я хочу быть уверен, что эти страницы никогда в жизни не будут вытеснены на диск.
    А откуда об этом желании может знать AIX если для него все адресное пространство одинаковое?

  • #12690

    roman
    Участник

    вы меня совсем не услышали. Повторяю еще раз — в правильно настроенных системах paging’а быть не должно. Это, конечно, идеал, но к нему надо стремиться. А если нет paging’а, то зачем тогда пинить?
    Теперь конкретно по вашему рассуждению. А вы не задумывались над тем, что помимо того, что пините вы, aix тоже для своих нужд пинит страницы в памяти. В результате может так случится, что выбрасывать прийдется часто используемые страницы из того остатка незапиненых (в то время как большая часть SGA будет тупо простаивать, не активная в данный момент), и в результате у вас будет такая активность по paging’у, что никакой нормальной работы системы не будет

  • #12692

    yota
    Участник

    Ненене, самый свежий тренд — юзать 64К страницы — они пинятся автоматически и выделять ничего не надо, но оракл младше 10.2.0.4 этого не умеет.
    Не комильфо теперь юзать LARGE PAGES и LOCK_SGA, так как приходится прописывать размер пула страниц в ОС перед выделением их в оракле.

    Да я 64К и имел в виду 16Г это полное уродство, а автоматом пинятся любые большие страницы. Точнее они в принципе не свопятся.

  • #12693

    uxTuaHgp
    Участник

    Повторяю еще раз — в правильно настроенных системах paging’а быть не должно.

    Часто случается, что павильная настройка системы к пэйджингу отношения не имеет.
    Один дурацкий запрос в оракле, например, может выйти далеко за пределы PGA_AGGREGATE_TARGET.
    Если в таком случае не защититься от свопа — система может впасть в ступор очень надолго или навсегда.

  • #12694

    roman
    Участник

    вы обратно вернулись к теме планирования системы. Если у вас есть такие «тяжелые» запросы, надо планировать память под них. Я, честно говоря, не сталкивался с такими ситуациями, чтобы пин SGA мог помочь решить проблемы с чрезмерным увеличением PGA и последующим ступором системы. Даже с теоретической точки зрения это абсолютно разные области, и когда, например, происходит сортировка, все данные с SGA уже получены, и чтобы их отсортировать — SGA по сути уже не нужна. Может, проблема лежит где-то глубже? Или вы реально решали проблемы данных запросов просто запинив SGA?

  • #12695

    uxTuaHgp
    Участник

    конечно ПГА и СГА непосредственно не связаны
    Просто раздувание ПГА сверх меры повлечет пэйджинг, а если СГА не запинена, то весь инстанс деградирует, если конечно на этом инстансе не один единственный проблемный запрос.

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

  • #12972

    yota
    Участник

    up

  • #13024

    yota
    Участник

    ну кончилось тем, что в следующую ночь я переложился как и раньше в большие страницы и выложил в них SGA. Соответственно теперь у меня SGA в 86Гб выложена и запинена в памяти, в lpar остается после этого порядка 26-27 Гб под PGA и данные юзеровсикх сессий, ни в какой своп ничего не попадает.

    А можно вопрос, я так понимаю у вас 16М страницы счаз используются. За какое время у вас загружается этот lpar, в частности сколько времени он торчит на строчке

    Setting tunable parameters…

    при загрузке?

Для ответа в этой теме необходимо авторизоваться.