Помогите победить пэйджинг в связке с Ораклом.


Главная Форумы POWER Systems AIX/Hardware Помогите победить пэйджинг в связке с Ораклом.

В этой теме 1 ответ, 2 участника, последнее обновление  Дмитрий 8 года/лет, 7 мес. назад.

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

    ksn
    Участник

    Ситуация такая :

    Есть IBM p570 (Power6). Созданна на нем LPAR с 5 Gb оперативки и 0.6 CPU. Диск получает через VIOS с полки.

    Работала себе маленькая база Oracle 10g, на Intel сервере. Появилась необходимость перенести ее на p570.

    После миграции на p570 система стала переодически как бы подвисать. Иногда даже минут на 10 (в 9 утра когда есть по 4-5 активных коннекта к БД). Проблема как я думаю связана с «пэйджингом» памяти. В такие моменты наблюдается подобная картина:
    kthr memory page faults cpu
    —— ———— ———————— ———— ————————
    r b avm fre re pi po fr sr cy in sy cs us sy id wa pc ec
    0 0 1495356 28250 0 16 0 0 0 0 1130 975 575 58 42 0 0 0.60 99.8
    3 0 1496031 27539 0 37 0 0 0 0 744 2419 1524 96 4 0 0 0.60 100.3
    4 0 1496035 27518 0 17 0 0 0 0 290 1666 782 98 1 0 0 0.60 100.0
    7 0 1496106 27398 0 19 0 0 0 0 228 2685 514 98 2 1 0 0.59 99.1
    5 0 1496115 27251 0 166 0 0 0 0 256 2671 721 99 1 0 0 0.60 100.4
    3 1 1464924 58324 0 120 0 0 0 0 235 2729 703 95 5 0 0 0.60 99.9
    4 0 1465329 56932 0 1 0 0 0 0 149 2252 431 99 1 0 0 0.60 100.0
    4 0 1465325 56936 0 0 0 0 0 0 166 2301 457 99 1 0 0 0.60 99.9
    3 0 1465321 56940 0 0 0 0 0 0 148 2153 405 99 1 0 0 0.60 99.9
    4 0 1465324 56937 0 0 0 0 0 0 175 2379 488 99 1 0 0 0.60 99.9
    4 0 1488267 10162 0 2 0 0 0 0 1047 1136 289 65 35 0 0 0.60 100.0
    7 0 1497761 1488 0 0 795 1927 2276 0 1144 1945 459 68 31 1 0 0.60 99.5
    1 3 1499309 1488 0 0 1548 1536 2178 0 240 1070 1072 60 7 31 2 0.41 67.5
    2 2 1501188 1488 0 0 1873 1920 2830 0 96 206 588 92 8 0 0 0.60 100.0
    2 2 1502566 1488 0 0 1310 1408 2892 0 118 59 631 94 6 0 0 0.60 99.9
    2 2 1489552 39537 0 1 1278 768 1129 0 207 1112 721 75 25 1 0 0.60 99.6
    kthr memory page faults cpu
    —— ———— ———————— ———— ————————
    r b avm fre re pi po fr sr cy in sy cs us sy id wa pc ec
    4 1 1489781 39868 0 8 566 0 0 0 365 4403 649 96 3 1 0 0.60 99.5
    2 1 1491482 38200 0 56 88 0 0 0 286 3589 918 97 3 0 0 0.60 99.8
    2 1 1491514 38086 0 81 0 0 0 0 220 3284 624 98 2 0 0 0.60 99.7

    Вчера после очередного подвисания на минут 15 на консоль выдавало:
    Paging space low
    И при попытке запуска vmstat было сообщение:
    There is not enought memory availably now
    База малюсенькая. 10-12 постоянно висящих неактивных сессий от Цитриксов ну и в моменты нагрузки 3-4 активных сеанса от пользователей.
    Не думал, что будут какие либо проблемы. Расширил оперативку до 5 Гигов. Все равно мало 🙂
    Вот как настроенно:

    SQL> show sga

    Total System Global Area 1610612736 bytes
    Fixed Size 2084400 bytes
    Variable Size 1006633424 bytes
    Database Buffers 587202560 bytes
    Redo Buffers 14692352 bytes

    sga_target=1610612736
    pga_aggregate_target=104857600

    Выставлял в соответсвии с рекомендациями VMO:
    root@prod2_main:/#vmo -a
    cpu_scale_memp = 8
    data_stagger_interval = 161
    defps = 1
    force_relalias_lite = 0
    framesets = 2
    htabscale = n/a
    kernel_heap_psize = 4096
    kernel_psize = 4096
    large_page_heap_size = 0
    lgpg_regions = 0
    lgpg_size = 0
    low_ps_handling = 1
    lru_file_repage = 0
    lru_poll_interval = 10
    lrubucket = 131072
    maxclient% = 20
    maxfree = 1088
    maxperm = 250020
    maxperm% = 20
    maxpin = 1059004
    maxpin% = 80
    mbuf_heap_psize = 65536
    memory_affinity = 1
    memory_frames = 1310720
    memplace_data = 2
    memplace_mapped_file = 2
    memplace_shm_anonymous = 2
    memplace_shm_named = 2
    memplace_stack = 2
    memplace_text = 2
    memplace_unmapped_file = 2
    mempools = 1
    minfree = 960
    minperm = 37503
    minperm% = 3
    nokilluid = 0
    npskill = 10048
    npsrpgmax = 80384
    npsrpgmin = 60288
    npsscrubmax = 80384
    npsscrubmin = 60288
    npswarn = 40192
    num_spec_dataseg = 0
    numpsblks = 1286144
    page_steal_method = 0
    pagecoloring = n/a
    pinnable_frames = 1187186
    psm_timeout_interval = 5000
    pta_balance_threshold = n/a
    relalias_percentage = 0
    rpgclean = 0
    rpgcontrol = 2
    scrub = 0
    scrubclean = 0
    soft_min_lgpgs_vmpool = 0
    spec_dataseg_int = 512
    strict_maxclient = 1
    strict_maxperm = 0
    v_pinshm = 0
    vm_modlist_threshold = -1
    vmm_fork_policy = 1
    vmm_mpsize_support = 1
    wlm_memlimit_nonpg = 1
    root@prod2_main:/#

    root@prod2_main:/#lsattr -E -l sys0 -a realmem
    realmem 5242880 Amount of usable physical memory in Kbytes False

    root@prod2_main:/#lsps -a
    Page Space Physical Volume Volume Group Size %Used Active Auto Type
    hd6 hdisk0 rootvg 5024MB 28 yes yes lv
    root@prod2_main:/#
    Раздел с Ораклом смонтирован с CIO:
    /dev/oralv /u01 jfs2 Mar 30 21:49 rw,cio,log=INLINE

    Вообщем спасайте 🙂
    Уверен, что такая БД может работать и на 3 Гигах свободно, а тут 5 и мало….

  • #2794

    Дмитрий
    Участник

    svmon -Put 10
    покажет top-10 процессов, больше всего использующих память, с детализацией.
    По крайней мере, будет ясно, кто грузит систему.
    (скорее всего, оракл, конечно).

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