Error -25580 on connections
Andrew Hamm
what's the latest word on error -25580 during runtime (not during engine
boot, when it means you haven't got enough semaphores configured).
There's plenty of messages in the google history for this ng, but not much
clear resolution. The best I can find is from Tsutomu Ogiwara, referencing
bug #147889, in reply to a message with a few ideas to try, and another
message referencing bug #114935.
None of the messages that I've waded through says definitively whether the
problem is solved or solvable.
Some reference is made to kernel parameters SEMMNU and SUMUME. SEMMNU is
only mentioned in a footnote at the end of the release notes (whoops - not
listed in the top section where everyone looks) and SEMMNU is not mentioned
at all in the release notes.
Both of these params are configured very small by default on HP-UX 11i, so
I've bumped all the appropriate SEM params to 8192 in the hope that it will
fix it.
Platform is a new HP-UX 11i, IDS 7.31.UD2R1, RDS 7.20.UD6
--
Voiceover: Would you like a giraffe?
Mooooo!
Voiceover: Have one delivered! Just log on to www.petsovernight.com,
and we'll send you a giraffe... overnight. Pets Overnight dot Com -
delivering little bundles of love, in a box... directly to your door.
Mooooo!
Andrew Hamm
>
>what's the latest word on error -25580 during runtime (not during engine
>boot, when it means you haven't got enough semaphores configured).
>
1) disabled KAIO (and setup suitable NUMAIOVPS in it's absence)
2) Bumped the almost undocumented (for HP) kernel params SEMMNU and SEMUME
to match SEMMAP SEMMNI and SEMMNS at 8192 values
3) Ensured that the SHMMAX is such that the engine can allocate one
coalesced shared memory segment for the resident and virtual segments.
4) left the client processes connecting thru soctcp (the problem was
occuring for ipcshm but the change to soctcp did not make the problem go
away).
-25580 has not occurred since then.
Now we'll take a few days to progressively restore the KAIO and use of
ipcshm for clients and make sure it's still clean. I've got a strong gut
feeling that it's the missing kernel params. IIRC, those params are
mentioned for SCO but not for HP. Never seemed to matter before *puzzled
look*
I'll dribble in a few more messages so that it's on record - the next sucker
doing a google search can then find a definitive statement on the problem;
Simmons, Keith
Andrew
This might be of some assistance. We are running 7.31 UD3 on HP UX 10.20 and
have set the following as recommended in the release notes
($INFORMIXDIR/release/en_us/0333/IDS_7.3):-
SHMMAX: 1GB
SHMMNI: 512
SHMSEG: 256
SEMMNI: 4096
SEMMNS: 4096
NFILE: 51548
ipcs -as will show what semaphores are actually in use.
Keith Simmons
Banner Business Supplies Limited
Informix Certified Professional
-> -----Original Message-----
-> From: Andrew Hamm [mailto:ah...@sanderson.net.au]
-> Sent: Wednesday, May 29, 2002 8:51 AM
-> To: inform...@iiug.org
-> Subject: Re: Error -25580 on connections
->
->
-> Andrew Hamm wrote in message ...
-> >
-> >what's the latest word on error -25580 during runtime (not
-> during engine
-> >boot, when it means you haven't got enough semaphores configured).
-> >
-> I haven't had any feedback on this, but for the record, we've:
->
-> 1) disabled KAIO (and setup suitable NUMAIOVPS in it's absence)
-> 2) Bumped the almost undocumented (for HP) kernel params
-> SEMMNU and SEMUME
-> to match SEMMAP SEMMNI and SEMMNS at 8192 values
-> 3) Ensured that the SHMMAX is such that the engine can allocate one
-> coalesced shared memory segment for the resident and virtual
-> segments.
-> 4) left the client processes connecting thru soctcp (the problem was
-> occuring for ipcshm but the change to soctcp did not make
-> the problem go
-> away).
->
-> -25580 has not occurred since then.
->
-> Now we'll take a few days to progressively restore the KAIO
-> and use of
-> ipcshm for clients and make sure it's still clean. I've got
-> a strong gut
-> feeling that it's the missing kernel params. IIRC, those params are
-> mentioned for SCO but not for HP. Never seemed to matter
-> before *puzzled
-> look*
->
-> I'll dribble in a few more messages so that it's on record -
-> the next sucker
-> doing a google search can then find a definitive statement
-> on the problem;
-> --
-> Voiceover: Would you like a giraffe?
-> Mooooo!
-> Voiceover: Have one delivered! Just log on to www.petsovernight.com,
-> and we'll send you a giraffe... overnight. Pets Overnight dot Com -
-> delivering little bundles of love, in a box... directly to your door.
-> Mooooo!
->
->
->
**********************************************************************************
This message is sent in strict confidence for the addressee only. It may
contain legally privileged information. The contents are not to be disclosed
to anyone other than the addressee. Unauthorised recipients are requested
to preserve this confidentiality and to advise the sender immediately of any
error in transmission.
This footnote also confirms that this email message has been swept for the
presence of computer viruses, however we cannot guarantee that this message
is free from such problems.
**********************************************************************************
David Williams
"Andrew Hamm" <ah...@sanderson.net.au> wrote in message
news:ad219u$tir6i$1...@ID-79573.news.dfncis.de...
> Andrew Hamm wrote in message ...
> >
> >what's the latest word on error -25580 during runtime (not during engine
> >boot, when it means you haven't got enough semaphores configured).
> >
> I haven't had any feedback on this, but for the record, we've:
>
> 1) disabled KAIO (and setup suitable NUMAIOVPS in it's absence)
> 2) Bumped the almost undocumented (for HP) kernel params SEMMNU and SEMUME
> to match SEMMAP SEMMNI and SEMMNS at 8192 values
> 3) Ensured that the SHMMAX is such that the engine can allocate one
> coalesced shared memory segment for the resident and virtual segments.
> 4) left the client processes connecting thru soctcp (the problem was
> occuring for ipcshm but the change to soctcp did not make the problem go
> away).
>
> -25580 has not occurred since then.
>
> Now we'll take a few days to progressively restore the KAIO and use of
> ipcshm for clients and make sure it's still clean. I've got
ipcshm for clients means that the limit of maximum
connections in the NETTYPE parmeter is a hard limit.
onipcshm - once you reach the limit on number of
connections in NETTYPE then more connections fail
onsoctcp - once you reach the limit on number of
connections in NETTYPE then the number of connection
'handles'(??) is expanded.
Andrew Hamm
>
>
Thanks guys for the replies so far. Looks like my 2nd posting has jinxed the
site - the problem did not occur yesterday, but has occurred in a few bursts
today.
The shmem, semas and connectors are high enough for the client load etc. A
key point with this bug is that *existing* connections are suddenly
returning this error. The application programmers have traced the errorlog
statements back to random SQL statements which are well into the body of the
4GL, not related to the establishment of the connection.
The only remaining idea that showed up in the history for this newsgroup is
some reference to the keepalive factors on TCP connections. The suggestion
(untested) was to play with the keepalives (presumably to disable it or some
other action). I need to look into this.
Anyway, tracking the fault through Informix tech support and the HP website
for patches, it all starts to get ugly.
Informix tech support has tied this problem back to HP patch PHNE_23456,
although this patch only applies to HP 11.00 not to HP 11i (aka HP 11.11)
From visiting the HP patch site:
The equivalence status of this particular patch on HP 11.11 is "Unknown",
not "Fixed" or replaced with another patch specific to HP 11.11.
The history of this patch is a sad and sorry affair.
When I look at patch PHNE_23456, it says that it still exhibits bugs and has
been replaced by PHNE_24715.
When I look at patch PHNE_24715, it says that it still exhibits bugs and has
been replaced by PHNE_25423.
When I look at patch PHNE_25423, it says that it still exhibits bugs and you
should go back to the earlier PHNE_22397 which did not exhibit these bugs (I
suppose it exhibited other bugs). It then goes on to say that in May 2002
they intend to release PHNE_26771 which (presumably they PROMISE) will fix
all the bugs.
Of course, all this is relevant to HP 11.00 not 11.11
The Informix techie referenced HP case number 1200021954, which he did not
have the text for. Once again, this case # is related to HP 11.00
Stay tooned - same Bug Station, same Bug Time.
Andrew Hamm
>
>[complaints about errer -25580]
>
Hokay - all these HP 11.00 patches fix the little IFX problem with the
recv( ) system call. They also fix about 50 other HP bugs each, and
obviously not very well since there's quite a chain of them ;-)
PHNE_23456
PHNE_24715
PHNE_25423
PHNE_26771
An HP engineer has found an equivalent HP 11i patch: PHNE_25644
I'll post again maybe on wednesday if it's looking fixed - or if it's not !
Andrew Hamm
engine. It must be distinguished from the same error which can occur when
you attempt to boot the engine. In this last case, you most likely haven't
set it up properly.
The -25580 error generally pops out when there is unexpected errors when
receiving data on a socket (ie network connection). This error can manifest
in two places: in the application (eg 4GL) or in the engine.
If the 4GL gets the error then it should be in the errorlog file (assuming
you are using that; if you are not, give yourself a sharp slap).
If the engine gets the error then it should appear in the message file for
the engine - ie MSGPATH file from the $ONCONFIG. This is the kind of error
that most people including tech support are familiar with, and will assume.
Unexpected errors on the socket recv can occur because:
1) the connection has unexpectedly dropped out
2) some sort of network error (eg down link) has broken the connection
3) bugs in the O/S - the kernel can return a bad value or do silly things.
Since the recv( ) system call interacts with all sorts of socket options and
high priority messages etc, it's quite a complicated function, so it's easy
understand why it can suffer bugs.
HP-UX is known to suffer from a recv bug which affects the engine. Possibly
it also affects 4GL processes, but I found no reports of this. Maybe that's
because people don't check their 4GL error logs ;-)
Recently someone mentioned this bug on NT, and also on Linux (?). With NT,
of course you'd expect bugs. For Linux, being relatively young, it's
probably got significant bugs lurking too.
The HP patches mentioned in the previous messages allegedly solve the
problem for HP 11.00: 'cumulative ARPA Transport'. The latest patch for
HP-UX 11.11 is PHNE_25644 "cumulative ARPA Transport patch" - this looks
promising for HP 11i but there is no experience that it's a fix yet. For
other O/S you'll have to track them down any patches yourself.
Anyway, if you are getting -25580 errors then you need to check if your
connectivity is reliable. If you are sure it is, then start to blame O/S
bugs.
For the site I've been involved in, the errors were turning up in the 4GL
error log. Turns out, the site was shutting down the engine every night
(why, I don't know, just an old habit) and if any users left processes
running, they stayed running. Then the users would turn up in the morning,
click on a 4GL (4JS GUI) session, it would attempt to talk to the engine and
then crap out with a -25580 error.
So it turns out that the *engine* -25580 error was not the error we were
dealing with, but it took a while to realise that it's a different case. It
was only from talking to an astute user that the admin of the site suddenly
realised what was going on.
Hence, we've patched the HP 11i, but did not necessarily require it. Damn.