segmentation error : coredump
Posted 26 June 2003 - 06:51 AM
After I have commented out the 4 lines in isamdef and if I am going to reboot the server, do I need to proceed the other steps? I.e., remove share memory etc.?
I am planning to change the isamdef and then recycle the server.
BTW, normally, this site will have about 80 - 100 users and they are running Oracle 126.96.36.199
Posted 26 June 2003 - 09:40 AM
I guess if you remove the isamlog file, then reboot, then create the isamlog file before anyone logs into ProIV or iscollect is started then that could be one way of doing it.
Personally, I would do it manually like I said, then reboot.
Even if you mainly use Oracle, do you have any files (like workfiles etc) in ProISAM?
Posted 26 June 2003 - 09:56 AM
Since customer scheduled a reboot tonight, so, I think I just amend the isamdef and recreate isamlog. I think it is OK not to do manual clean up of share memory etc.
The application does have some proisam work files but they are all small size.
So, the only big size proisam files are those bootstrap files.
Posted 26 June 2003 - 10:43 AM
Between creating the file and rebooting, iscollect or something could write to the isam log again, corrupting it... maybe.
Its not to do with the size of the ProISAM files, its the number of them.
Shared memory is used to hold all currently open ProISAM records and Locked ProISAM records. So the size of the shared memory segment needed is dependant on the number of users and the number of simultaneously open records in ProISAM.
If shared memory gets full, then this is logged in the isamlog file, normally as readable text.
If you keep getting messages in the isamlog, then shared memory needs to be increased. ie increase the value of SHMSIZE.
When shared memory gets full, first of all the system waits for the time defined in SHMDELAY, and will keep waiting for SHMRETRY times. If there are still no resources after that, the system will error and the session will go to @RFUNCT.
If you keep getting retries, then this makes it look like the system is running very slow, because its waiting all the time for resources.
Posted 26 June 2003 - 11:13 AM
Thanks for the elaboration.
I will see after reboot the server, will isamlog still capturing non text lines.
BTW, I suppose I cannot increase SHMSIZE as big as I will. It should be some trade off to increase it. What is the rule of thumb for this value? How can I know up to what value I can increase it?
The AIX box is running 4 CPU and 8G memory. Number of concurrent PRO-IV users is about 100 to 120.
Posted 26 June 2003 - 11:44 AM
In the past, I just keep increasing this value untill I stopped getting messages in isamlog.
At my last place, we had it set to 200,000 and the box had 4 CPUs and 6GB of memory with about 500-600 users.
It had to be this big because we did not use Oracle (We used ProISAM & Cisam).
If its just a few files you have in ProISAM, then you should not need such a large amount.
I would not just make it large for the sake of it. I would test and see. Because it will reserve memory even if its not used and therefor less memory will be available to Oracle etc.
If you give values to the other 4 vars instead of SHMSIZE, ProIV automatically creates shared memory the size it thinks you need for such a setup.
Posted 03 July 2003 - 03:02 AM
I changed the isamdef and let users run for a few days. To bad, PRO-IV is still producing isamlog.
I have changed to SHMSIZE to 100000.
I think I am going to enlarge SHMSIZE a bit and monitor it again.
Any more clues?
Do you think I need to check for
But don't know if AIX has these...
Posted 03 July 2003 - 05:11 AM
Im not sure if AIX has the semmaphore settings or not sorry...
It could be them, but I think that you get messages like ... 'SD_ENTER: Not enough Space On Device...' in ProIV when those values are low....
Posted 16 July 2003 - 10:08 AM
Have you talked to ProIV support, because you should not be getting that sort of stuff in that file.
Does the file keep getting bigger, or was it written too just once?
Are you still getting the core dumps?
You could try doing an 'isview' when your system is 'fairly' busy, zip it, and send me the results via email.
isview displays all the open ProISAM records and record locks, that your system has. IE all the records in shared memory.
Posted 17 July 2003 - 10:16 AM
Not sure if this will help you much Vol but..
The rather serious "output ending up in the wrong file" is usually caused by one of two things:
1/ Bad C code causing program memory corruption but not crashing immediately, after which all bets are off.
2/ Inadvertent (or otherwise) reassignment of the 'standard' C file-descriptors (stdout, stderr).
Since you have a coredump, you probably have memory corruption caused by bad C code, either in ProIV or linked with the kernel for your application. I'd say this is the more likely anyway.
ProISAM is, historically anyway, notoriously bad at handling out-of-disk-space errors. One particular case I remember involved running out of space for temporary sort files because they were on another filesystem to data files (ProIV uses ProISAM for its temporary sort files on Unix). Could be worth checking that - I seem to remember it apparently causing corruption in unrelated files.
Posted 17 July 2003 - 03:32 PM
I can't read the file as well. The file is supposed to be Text file but I don't know why it now contains unreadable characters.
I am not sure how to trace this issue. And I am too sure how often it produce coredump file. BTW, normally where is the coredump file be located in Unix? Under PRODATA? PROPATH?
Posted 17 July 2003 - 03:49 PM
The core file is normaly in the dir where you started proiv.
Ie wherre you were when you typed 'pro'
If you are starting pro from a script, beware that the script could 'cd' to somehwere first, this is where your core file would be.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users