Here we go, another week, another issue on our 9.31 IDS, running on a virtual HPUX 11i PA-RISC container under an Itanium host running HPUX11.23.

We've set up both onsoctcp and onipcshm connections which both work normally for ages and then suddenly at some arbitrary time the oncotcp connections will become unavailable - any attempted connections (whether command line "database fred@instancesoc" or from dbaccess using the 'Connect' menu option) just sit on "connecting...".

We have two virtualised containers, one for our dev system and one for live, and the onsoctcp connections on the live container are the ones that die. You can't connect to the live machine instance via sockets from either the live or dev machines, but you can access the instances on the dev container so it seems the live container is the one playing up. Connecting via shm is unaffected.

I'm not a sysadmin, just a DBA who's had this lot dumped on him to be told "administer this" (for the purposes of reducing expenditure, natch) so any clues as to where to look would be greatly appreciated!
The only resolution to date has been to take down and restart the container (just taking the instance down doesn't help).

TIA

Malc

Hello Malc,

had an issue simular on vmware linux and i added shm connections so the engine would react whenever it happened again.. of course it did and we found out later
that V@d@*&^%# rebooted our router to the internet and screwing up the whole 
network because they loaded without telling us new configuration stuff....

it sounds like a broken network, to get some more info you may feed to HP and or informix is using tusc when trying to connect 

eq 

tusc dbaccess sysmaster@instance_soc


or have a look at stack traces from the database.

See you

Superboer.



Am Freitag, 26. September 2014 16:15:45 UTC+2 schrieb Malc P:
> Here we go, another week, another issue on our 9.31 IDS, running on a virtual HPUX 11i PA-RISC container under an Itanium host running HPUX11.23.
> 
> We've set up both onsoctcp and onipcshm connections which both work normally for ages and then suddenly at some arbitrary time the oncotcp connections will become unavailable - any attempted connections (whether command line "database fred@instancesoc" or from dbaccess using the 'Connect' menu option) just sit on "connecting...".
> 
> We have two virtualised containers, one for our dev system and one for live, and the onsoctcp connections on the live container are the ones that die. You can't connect to the live machine instance via sockets from either the live or dev machines, but you can access the instances on the dev container so it seems the live container is the one playing up. Connecting via shm is unaffected.
> 
> I'm not a sysadmin, just a DBA who's had this lot dumped on him to be told "administer this" (for the purposes of reducing expenditure, natch) so any clues as to where to look would be greatly appreciated!
> The only resolution to date has been to take down and restart the container (just taking the instance down doesn't help).
> 
> TIA
> 
> Malc

On Friday, September 26, 2014 8:15:45 AM UTC-6, Malc P wrote:
> Here we go, another week, another issue on our 9.31 IDS, running on a virtual HPUX 11i PA-RISC container under an Itanium host running HPUX11.23.
> 
> 
> 
> We've set up both onsoctcp and onipcshm connections which both work normally for ages and then suddenly at some arbitrary time the oncotcp connections will become unavailable - any attempted connections (whether command line "database fred@instancesoc" or from dbaccess using the 'Connect' menu option) just sit on "connecting...".
> 
> 
> 
> We have two virtualised containers, one for our dev system and one for live, and the onsoctcp connections on the live container are the ones that die. You can't connect to the live machine instance via sockets from either the live or dev machines, but you can access the instances on the dev container so it seems the live container is the one playing up. Connecting via shm is unaffected.
> 
> 
> 
> I'm not a sysadmin, just a DBA who's had this lot dumped on him to be told "administer this" (for the purposes of reducing expenditure, natch) so any clues as to where to look would be greatly appreciated!
> 
> The only resolution to date has been to take down and restart the container (just taking the instance down doesn't help).
> 
> 
> 
> TIA
> 
> 
> 
> Malc

Malc - 

Whereas ipcshm connections are limited to 50 by default or whatever NETTYPE is set to, soctcp connection structures can grow regardless of NETTYPE but it's typically a function of semaphores available. Boxes today typically don't run short of semaphores but I'd check that metric. 

But - my first thought was the same as Eric - working with HP looking closely at the VM on Itanium. 

You haven't upgraded the 9.31 version recently have you? I don't mean beyond 9.31 (as much as I'm sure you'd like to do that), but to a later version of 9.31 that perhaps has a known bug related to this issue. 

Thanks -
Mark

The Mark Scranton Group
"All Informix ...  all the time."
www.markscranton.com

Le vendredi 26 septembre 2014 16:15:45 UTC+2, Malc P a écrit :
> Here we go, another week, another issue on our 9.31 IDS, running on a virtual HPUX 11i PA-RISC container under an Itanium host running HPUX11.23.
> 
> 
> 
> We've set up both onsoctcp and onipcshm connections which both work normally for ages and then suddenly at some arbitrary time the oncotcp connections will become unavailable - any attempted connections (whether command line "database fred@instancesoc" or from dbaccess using the 'Connect' menu option) just sit on "connecting...".
> 
> 
> 
> We have two virtualised containers, one for our dev system and one for live, and the onsoctcp connections on the live container are the ones that die. You can't connect to the live machine instance via sockets from either the live or dev machines, but you can access the instances on the dev container so it seems the live container is the one playing up. Connecting via shm is unaffected.
> 
> 
> 
> I'm not a sysadmin, just a DBA who's had this lot dumped on him to be told "administer this" (for the purposes of reducing expenditure, natch) so any clues as to where to look would be greatly appreciated!
> 
> The only resolution to date has been to take down and restart the container (just taking the instance down doesn't help).
> 
> 
> 
> TIA
> 
> 
> 
> Malc

Malc,

this answer looks obvious, but if this configuration has been working for ages on a physical PA-RISC platform and does not work well on VM, I would envolve HP support and their Itanium VM specialists :-)

Or maybe think about running IDS with a version younger than 14 years on Itanium ... I agree budgets are envolved, but this is a production environment

I would try to search for differences of VM configuration between dev and prod VMs. Sorry no to have more ideas.

Eric

Eric