After we raised the max processes to 3000 we quit getting the fork function failed error which was our original problem. Right now, things are working ok but since I've never seen this behavior before on 5 other similar installs, I don't know how to predict where the limit is. In other words, how many of these aioserver processes are going to get created so that we would start seeing the fork function failures again? And, why don't they ever go away, even when the database is shut down? How will all these processes effect overall resource use/consumption?
I'm just concerned that there's some problem underlying this that's not being addressed by setting the max processes up so high. Thanks for the reply! Karen -----Original Message----- Sent: Tuesday, March 25, 2003 2:43 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] processes? Hi Karen, I'm by no means an expert, but I had my hands on a similar environment, lower 64-bit AIX version and 64-bit Oracle, 8.1.7.4. Those aioserver processes were everywhere too. Looked to me like they just sat there and didn't create any problems - as far as I could tell. What problems are you seeing?? Lisa 100% Monkey Mama, and DBA -----Original Message----- Sent: Tuesday, March 25, 2003 9:59 AM To: Multiple recipients of list ORACLE-L All, I've got a new install that is doing something I've never seen before. AIX 5.1 (patchset 3 I believe) 32-bit kernel on an IBM 6M2 with 16GB Memory and 4 disks (RAID 0-1) and Oracle 8.1.7.4 32-bit has been installed. For AIX here's some info: default ulimit is unlimited for everything max processes = 3000 (now, started at 800) min aioservers = 10 max aioservers = 400 When attempting to do anything in Oracle, particularly attempting to run a script to create a database or any object creation, hundreds of aioserver processes owned by oracle are started. If you issue ps -aux almost 500 of these guys show up, but if you ps -ef you don't see them at all. The total, once started, never go away... even if you shutdown the database. The only way to get rid of them is to reboot the server. Originally, we were getting a fork function failed error and couldn't even create anything but have been able to get rid of that message by setting max processes to 3000 (originally 800) but as far as I'm concerned, this is just masking the problem. We can do stuff but it doesn't explain why all those processes are out there and why they don't ever seem to go away. I'm getting ready to try setting disk_asycnh_io=FALSE to see if it stops creating all those processes but even if it does, then what? We have 5 other AIX installs that have not had this trouble (none however on this particular hardware but same OS and Oracle version). I'm thinking it's time for an iTAR but thought I'd see if anyone had any ideas on what's going on here? Thanks, Karen Morton -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Karen Morton INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Karen Morton INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
