core dumps

[Rob O'Connor]

Hello Everyone:
Kinda odd question. Several of our oracle programmers complaining that the system has too much core dumps. I checked perf view and glance plus for possible problems. Looking for application and any process that may be of conflict. There was nothing out of the ordinary except high memory usage. I set the kernal parameters much higher and still the same problem. I was wondering if anyone has run to similar situation and can recommend performance tuning. It's possible that the hardware is unable to support the database but I need to all other possibility. Thank you all for your help.

H

[Ramkumar Devanathan]

H,

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xf98719434a69d711abdc0090277a778c,00.html

Details please.

:)

- ramd.

[Cheryl Griffin]

What version of Oracle? What version of HP-UX?

[Steven E. Protter]

If its a real core dump, try q4 analysis. Instructions attached:

SEP

[Rob O'Connor]

sorry,

L2000 server -2 360mhz processor. 2GB RAM.

Running 11.11 and oracle 9i.

Thanks.

[Paddy_1]

can you give me the output of the following core analysis program.that would yield me more info to solve the problem

[Bill McNAMARA_1]

file core

to find out what application core dumped.

what core

to find out the application software versions.


a quick and dirty core analysis would be to use
# gdb /path/to/application /path/to/core
(gdb) bt
.
.
.
(gdb) quit
#

This will give you the stack trace of the core dump. Note that the application and core need to be gdb'd on the same (or equally sw installed) host.

Delving deeper into cores requires application source code. But just install latest patches on your box and check your kernel params based on the reason for the core.

LAter,
Bill

[Bill McNAMARA_1]

file core

to find out what application core dumped.

what core

to find out the application software versions.


a quick and dirty core analysis would be to use
# gdb /path/to/application /path/to/core
(gdb) bt
.
.
.
(gdb) quit
#

This will give you the stack trace of the core dump. Note that the application and core need to be gdb'd on the same (or equally sw installed) host.

Delving deeper into cores requires application source code. But just install latest patches on your box and check your kernel params based on the reason for the core.

LAter,
Bill

PS: get gdb from http://www.hp.com/go/developer
(http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,548,00.html)

[Rob O'Connor]

Thanks everyone. Just talk with several programmers. They just clean all the core files and core dumps. I looked up the info Steve and Bill provided but since core dumps has just be cleaned, there wasn't much useful info. I'll keep you up to date. Thanks again

[Pete Randall]

To tell you the truth, I suspect poor programming practices on the part of your developers, but it's possible that you may be able to do some tuning that might help.

As far as having lots of core dumps around, using up file system space. Try putting the following entry in cron to remove core files older than two days:

00 02 * * * /usr/bin/find / -type f -name "core" -mtime +2 -exec rm {} \;


Pete