Столкнулся с непонятной ситуацией при смене СХД.
Код:
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 -
теряюсь в догадках, что это может быть...