SoRa,
это уже поздновато в этом systemstate dump видно лишь то, что PMON отправил ksuabt (ABORT)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
PROCESS 2: PMON
----------------------------------------
SO: 0x2ca31ea7a0, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0x2ca31ea7a0, name=process, file=ksu.h LINE:12721, pg=0
(process) Oracle pid:2, ser:1, calls cur/top: 0x2ca4d80228/0x2ca4d80228
flags : (0xe) SYSTEM
flags2: (0x0), flags3: (0x10)
intr error: 0, call error: 0, sess error: 0, txn error 0
intr queue: empty
ksudlp FALSE at location: 0
(post info) last post received: 605 609 13
last post received-location: ksu.h LINE:14042 ID:ksuabt
last process to post me: unknown (no pso)
last post sent: 0 0 19
last post sent-location: ksu.h LINE:14068 ID:ksuxfd
last process posted by me: 0x2ca31ea7a0 1 14
(latch info) wait_event=0 bits=0x0
Process Group: DEFAULT, pseudo proc: 0x2c637a4128
O/S info: user: oracle, term: UNKNOWN, ospid: 14865
OSD pid info: Unix process pid: 14865, image: oracle@cft-odb1 (PMON)
Вообще, по идее надо трейс самого pmon - посмотрите *14865.trc
Но, в целом, судя по алерту:
1.
2.
3.
4.
5.
6.
Mon Jul 05 08:27:58 2021
WARNING: Heavy swapping observed on system in last 5 mins.
pct of memory swapped in [0.02%] pct of memory swapped out [2.34%].
Please make sure there is no memory pressure and the SGA and PGA
are configured correctly. Look at DBRM trace file for more details.
Mon Jul 05 08:30:13 2021
+ из systemstate dump:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
$ grep -iP "sess.*mem" work_diag_14892_20210705083957.trc
2169262641712 session uga memory
6635297927696 session uga memory max
3409420064456 session pga memory
44364782072744 session pga memory max
-- formatted:
2`169`262`641`712 session uga memory
6`635`297`927`696 session uga memory max
3`409`420`064`456 session pga memory
44`364`782`072`744 session pga memory max
Скорее всего, PMON не смог выделить память и пошел отключаться.
Добавлю свои 5 копеек,
1) Покажите /proc/meminfo
Вам советуют установить Large Pages, при таких размерах SGA это не лишнее
Да и гарантирует, что SGA в swap не провалится
1.
2.
3.
4.
5.
6.
7.
8.
...
RECOMMENDATION:
Total System Global Area size is 180 GB. For optimal performance,
prior to the next instance restart:
1. Increase the number of unused large pages by
at least 92060 (page size 2048 KB, total size 180 GB) system wide to
get 100% of the System Global Area allocated with large pages
...
Единственно, "урежте осетра"
У Вас на "все остальное", включая систему остается 6Гиг
Там ничего кроме oracle не крутится?
банальный X gnome например/ Тот из-за утечек памяти 6 гигов за неделю вполне сожрать может
И да, советую установить sysstat
В следующий раз при падении, можно будет смотреть динамику потребления ресурсов системы, например
1.
2.
3.
4.
5.
6.
7.
-- swapping
sar -B -f /var/log/sa/saDD
-- swap use
sar -S -f /var/log/sa/saDD
-- run queue
sar -q -f /var/log/sa/saDD
где DD - день месяца
Если нужно определить кто пожрал память
Я использую следующий скрипт, с ограничение размера журнала процессов
(здесь отбираются 100 процессов по pcpu, но можно переделать сортировку например на rss
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
$ cat top.sh
#!/bin/sh
set -a
LANG=C.UTF-8
LOGFILE=top.lst
LOGSIZE=0
MAXLOGSIZE=157286400 ## 150M
DELAY=60
MAXPROC=100
SORTKEY=pcpu
set +a
while [ $LOGSIZE -le $MAXLOGSIZE ];
do
date +"==== %Y.%m.%d.%H:%M:%S ============================="
ps --sort -eo pcpu,pid,ppid,stat,stime,utime,vsize,size,rss,maj_flt,args | head -$MAXPROC
sleep $DELAY
LOGSIZE=`stat -c %s $LOGFILE`
done 2>&1 > $LOGFILE
## -- use
# nohup top.sh > /dev/null 2>&1 &
При падении, можно найти pid самой толстой редиски, и посмотреть уже ее trace, что она делала
Если интересует только память, то удобнее использовать smem вместо ps (выделенная строка)
ну и drift времени все же стоить посмотреть, Вы прислали trace уже после oracle restart
А интересует тот который упал
