08.09.2016 11:17
OlegON
 
Столкнулся с непонятной ситуацией при смене СХД.
Код:
uname -a
SunOS oracle0 5.11 11.1 sun4v sparc sun4v
Сейчас Hitachi, которая дохнет больше 2000 IOPS, что в итоге не устраивает, есть Huawei, на который надо перейти. Всего памяти
Код:
prtconf|grep Memory
Memory size: 483328 Megabytes
Все работает в рамках возможностей железа. И вот неприятный сюрприз при переходе на Huawei: при выделении некоторого значительного объема памяти, например, больше 50Гб базе (sga_target), вся система становится на колени. iostat, mpstat, vmstat, prstat никакой активности не выявляют в принципе, но по top возникает ожидание ядра в 15%. Сам top запускается полминуты.

Если запустить с небольшим количеством памяти, все просто летает. Но сам продукт расчитан на большое количество пользователей.

Ситуация повторяется на двух разных хостах, к которым цепляли этот Huawei. Уточню, что до нагрузки БД дело не доходит. Достаточно запустить базу (если она вообще запустится) и выполнить какой-то обращенный к системным вьюшкам запрос. Например, select sum(bytes) from dba_segments. Все, он уходит в задумчивость минут на 10.

Танцевал с приседаниями, чуть лучше становится, если отключать use_large_pages, но незначительно настолько, что есть предположения о погрешностях.

Код:
root@oracle0:~# ps -aef | grep ora | grep smon
  oracle  1863  1846   0   Sep 05 ?           1:40 ora_smon_ekk
root@oracle-db0:~# pmap –xs 1863 | grep ism
pmap: cannot examine –xs: no such process or core file
0000000380000000    1572864K rwxs-    [ dism shmid=0x2b ]
0000000400000000  266862592K rwxs-    [ dism shmid=0x2c ]
0000004400000000       4096K rwxs-    [ dism shmid=0x2d ]

root@oracle0:~# ipcs -dm
IPC status from <running system> as of Thursday, September  8, 2016 10:39:51 AM MSK
T         ID      KEY        MODE        OWNER    GROUP      ALLOC
Shared Memory:
m         45   0x9b22099c --rw-r-----   oracle oinstall           -
m         44   0x0        --rw-r-----   oracle oinstall           -
m         43   0x0        --rw-r-----   oracle oinstall           -
теряюсь в догадках, что это может быть...
13.09.2016 11:31
OlegON
 
По ходу приехали на баг

Цитата:
This issue is being worked under a non-published bug number 15858248 and is fixed in Solaris 11.2 SRU 13.6 which is publicly available.
предположил саппорт
29.09.2016 11:34
OlegON
 
Обновление до 11.3 проблему не решило. Пока принял решение отключить DISM.
Часовой пояс GMT +3, время: 01:17.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.