Memory/Processes

[Nobody's Hero]

I have a real stable N4000 with 6 gbytes of mem running 11.0 that is having a memory resource issue. I have 3 processes running that are taking up about 4 gbytes of mem if I read it right.

CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
2 ? 6663 oracle 241 20 1482M 583M run 666:49 65.71 65.59 oraclefsprd
0 ? 4813 oracle 241 20 1485M 591M run 671:31 58.66 58.56 oraclefsprd
6 ? 7408 oracle 241 20 1495M 600M run 713:00 58.18 58.08 oraclefsprd


The processes have a parent ID of '1'. Plus they have been running a long time. Would it be safe to kill these processes that have a pid=1?

Will it give me back some memory, or is there something else I can try, besides shutting down unneeded processes.

10x
RPM

[Nobody's Hero]

output from ps:

[ihshp8:/var/mail]# ps -ef | grep 7408 | grep -v grep
oracle 7408 1 239 10:28:37 ? 917:45 oraclefsprd (DESCRIPTION=(LOCAL=no)(ADDRESS=(PROTOCOL=BEQ)))
[ihshp8:/var/mail]# ps -ef | grep 6663 | grep -v grep
oracle 6663 1 255 16:17:15 ? 871:27 oraclefsprd (DESCRIPTION=(LOCAL=no)(ADDRESS=(PROTOCOL=BEQ)))
[ihshp8:/var/mail]# ps -ef | grep 4813 | grep -v grep
oracle 4813 1 255 16:11:11 ? 877:09 oraclefsprd (DESCRIPTION=(LOCAL=no)(ADDRESS=(PROTOCOL=BEQ)))

[Ollie R]

Hi,

The processes are oracle sessions connected to the Oracle Listener. Even if they have a PPID of 1, they can still be active, so be very careful!

I'd check around to see if anyone is running long reports or huge queries. The timestamps indicate that the processes are not that old.

Ollie.

[Bernhard Mueller]

Robert,

I assume this is production system so
just to be on the safe side I'd suggest you
- arrange a downtime,
- shutdown this database (see it goes down cleanly)
- check for leftover processes
- reboot
- restart db

Regards,
Bernhard

[Pete Randall]

As a general rule, process with a parent ID of 1 are orphans or zombies. I would *try* to kill them if you can. True zombies, however, will not be affected by the kill command and the only solution is to reboot.

You may also want to think about any possible ill-effects to your database, as I see these are Oracle processes.

Probably the safest thing to do is to re-boot.


Pete

[Rajeev Shukla]

Hi,
This sometimes happens when someone runs a big query or report and then realising that its taking time, disconnect their sessions and the process are zombie as identified before.
But they should still not be eating memory in real terms. What do you see from swapinfo?
And to get rid of this the safe thing is to take a downtime, bring down the instance, normally that will remove these zombie process and if not just reboot the server.

Rajeev

[Krishna Prasad]

Since they are Oracle shadow processes I would go ahead and kill them.

The fact that the parent process is "1" tells me it is an old process in this case. I don't think you would have any processes that connect to the Oracle listener by init.

Also, you may want to abort the old sessions internal to oracle.

[Steve Steel · Accepted solution]

Hi



signum signame Name Description
___________________________________________________________________________
0 SIGNULL Null Check access to pid
1 SIGHUP Hangup Terminate; can be trapped
2 SIGINT Interrupt Terminate; can be trapped
3 SIGQUIT Quit Terminate with core dump; can be trapped
9 SIGKILL Kill Forced termination; cannot be trapped
15 SIGTERM Terminate Terminate; can be trapped
24 SIGSTOP Stop Pause the process; cannot be trapped
25 SIGTSTP Terminal stop Pause the process; can be trapped
26 SIGCONT Continue Run a stopped process


Try kill -25 PPID

If you get complaints you can -26 it and if after a while noone has moaned then remove it


Steve Steel

[Claudio Cilloni]

Don't kill those processes using kill -9... I made this some days ago on a production machine, and Oracle gave me a big head-ache for two days!
This forum helped :-)

Ciao
Claudio

[Ian Lochray]

Despite the fact that these processes have a parten PID of 1 they are NOT zombie processes. This is just the way Oracle works when processing remote requests. If you kill them off then you are likely to get an irate phone call from someone running a large Oracle report asking why their report died.
You need to identify what remote processes have started these Oracle shadows. Log on to sqlplus as the system user and execute the following SQL. This should show you the culprits. You can then ask them what they are up to.
select
a.terminal "Name",
substr(a.program,1,38) "Program",
substr(a.username,1,8) "SQL User",
substr(a.osuser,1,9) "UNIX User",
substr(b.spid,1,6) "Shadow",
substr(a.status,1,2) "St"
from
v$session a,
v$process b
where
a.osuser not in ('codaadm', 'troplive') and
a.type not in 'BACKGROUND' and
a.paddr = b.addr
order by
a.program;

[Steven E. Protter]

These processes appear to be active, seemingly ruling out zombies. If they are contuing to collect CPU cycles they are getting work done.

The question is, is that work meaningful. The query at right before this post should tell you who did this.

These processes will resist a kill -9 because the parent is process 1. This happens sometimes, though database trouble is possible.

To directly answer your question, its probably not safe to kill these guys, they look bullet proof. Someone may have already tried to kill them.

I am thinking you have some poorly tuned sql out there and or some huge reports that should not be run by daylight. Time to talk to the application folks.

You do need to schedule a database shutdown. As a backup you should be prepared to reboot.

SEP