Version 7.31 FC2 on HP_UX 11.0

Just wondering if anyone out there is running this combination of database/hardware. We have recently purchased an HP "N" class server, and are trying to run with it. The performance is great and I have tuned everything as best I can, but since adding several hundred users, I am getting assert failures about once a day, consequently bringing the engine down. Our 7.31 UC2 instances on HP_UX 10.20 are rock solid, but for some reason we are having these issues on this machine. Informix is helping diligently with the case, but I am looking for any possible cause. Just a quick blurb on the af follows. If anyone has an interest in looking at more I will post or send all the information I have. af.file: 16:49:09 16:49:09 Informix Dynamic Server Version 7.31.FC2 Software SerialNumber AAC# J734621 16:49:09 Assert Failed: yield_processor: Stack overflow in thread 8579 16:49:09 Who: Session(8543, anitag@anitag.utcourts.gov, -96399, 744860424) Thread(8579, sqlexec, c00000002e62f040, 1) File: mt.c Line: 2180 16:49:09 Stack for thread: 8579 sqlexec base: 0xc00000002c160028 len: 36864 pc: 0x0000000000000000 tos: 0xc00000002c169340 state: ready vp: 1 Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.

Hi I have a "N" class running hpux 11 informix 7.31fc2-1. We only configured it last month and it hasn't gone live yet but it is locking up on a regular basis. It has been shipped to Australia and my isdn link isn't gong to be set up til next week so I don't know hwat the users mean by locked up yet. Other problems we have had when setting it up are that it does not support dbcockpit / onprobe. We have also been disappointed that our normal backup strategy of onbar and Omniback will not work as Omniback does not support 64 bit database ports yet. I should have access to our new server on Monday I will let you know if we are getting the same error as you. Regards Fergus C Hayne Unix/Informix/Baan System Administrator Brand-Rex Limited Tel: +44 (01592) 778450 Email: fhayne@brand-rex.com <clintk@my-deja.com> wrote in message news:7qnkgs$nq1$1@nnrp1.deja.com... > Just wondering if anyone out there is running this combination of > database/hardware. We have recently purchased an HP "N" class server, > and are trying to run with it. The performance is great and I have tuned > everything as best I can, but since adding several hundred users, I am > getting assert failures about once a day, consequently bringing the > engine down. > Our 7.31 UC2 instances on HP_UX 10.20 are rock solid, but for some > reason we are having these issues on this machine. Informix is helping > diligently with the case, but I am looking for any possible cause. Just > a quick blurb on the af follows. If anyone has an interest in looking at > more I will post or send all the information I have. > > af.file: > > 16:49:09 > 16:49:09 Informix Dynamic Server Version 7.31.FC2 Software Serial> Number AAC# J734621 > > 16:49:09 Assert Failed: yield_processor: Stack overflow in thread 8579 > 16:49:09 Who: Session(8543, anitag@anitag.utcourts.gov, -96399, > 744860424) > Thread(8579, sqlexec, c00000002e62f040, 1) > File: mt.c Line: 2180 > 16:49:09 Stack for thread: 8579 sqlexec> > base: 0xc00000002c160028 > len: 36864 > pc: 0x0000000000000000 > tos: 0xc00000002c169340 > state: ready > vp: 1 > > > > Sent via Deja.com http://www.deja.com/ > Share what you know. Learn what you don't.

Stupid question, maybe, but have you tried increasing the stack size? -- Bashar Chalabi CTL, London <clintk@my-deja.com> wrote in message news:7qnkgs$nq1$1@nnrp1.deja.com... > Just wondering if anyone out there is running this combination of > database/hardware. We have recently purchased an HP "N" class server, > and are trying to run with it. The performance is great and I have tuned > everything as best I can, but since adding several hundred users, I am > getting assert failures about once a day, consequently bringing the > engine down. > Our 7.31 UC2 instances on HP_UX 10.20 are rock solid, but for some > reason we are having these issues on this machine. Informix is helping > diligently with the case, but I am looking for any possible cause. Just > a quick blurb on the af follows. If anyone has an interest in looking at > more I will post or send all the information I have. > > af.file: > > 16:49:09 > 16:49:09 Informix Dynamic Server Version 7.31.FC2 Software Serial> Number AAC# J734621 > > 16:49:09 Assert Failed: yield_processor: Stack overflow in thread 8579 > 16:49:09 Who: Session(8543, anitag@anitag.utcourts.gov, -96399, > 744860424) > Thread(8579, sqlexec, c00000002e62f040, 1) > File: mt.c Line: 2180 > 16:49:09 Stack for thread: 8579 sqlexec> > base: 0xc00000002c160028 > len: 36864 > pc: 0x0000000000000000 > tos: 0xc00000002c169340 > state: ready > vp: 1 > > > > Sent via Deja.com http://www.deja.com/ > Share what you know. Learn what you don't.

In article <JTcB3.84$xa4.1135@news.colt.net>, "Bashar" <bashar@ctl.com> wrote: > Stupid question, maybe, but have you tried increasing the stack size? > > -- > Bashar Chalabi > CTL, London > Actually a very good question. I have just in the last several days increased the STACKSIZE ONCONFIG parameter (I have not needed to do this on our 10.20 instances running the same application). I have since found out that the default size of 32K is not even close to adequate. I originally increased it to 64K and now to 128K, and at this level the problem has disappeared. So problem solved, and thanks for asking the question. One point however, to quote the Administrators Guide "When the database server performs recursive database tasks, as in some stored procedures(like mine), for example, it explicitly checks for the possibility of stack-size overflow and automatically expands the stack." -- NOT TRUE, at least not in this release... Clint G. Kunz Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.

I went live three weeks ago with this combo on an 4-way K580 with 2gig of RAM backed by an EMC 3430. This is a warehouse management system with 100 rf terminal directed order pickers. I am having no problems with the database, just some problems with 4gl. I am running a 128k stack size. I migrated from a 8-way IBM J-40 with 7335 arrays and the performance is roughly 2 - 4 times faster. I am getting deadlock problems with my 4gl programs. These are the same programs that ran on the IBM with no problem. I am hoping the faster performance is the problem and more things are running concurrently and not a database bug. Not having ONBAR, oncockpit and xtree is a pain but the worst thing is that 4gl must connect through sockets instead of shared memory or stream pipes. I am turning about 120-150 million tcp/ip packets a second. I bet the performance will be even better when 4gl can talk shared memory to the 64-bit engine - if it ever happens. I'll post again if I run into any problems. Kirk Waterhouse UNIX Systems/PeopleSoft/Database Administrator CIBA Vision IS Department Ph:678-415-3177 Fx:678-415-2714 kirk.waterhouse@cibavision.novartis.com Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.