dbTalk Databases Forums  

nsf.lock mutex wait

comp.databases.informix comp.databases.informix


Discuss nsf.lock mutex wait in the comp.databases.informix forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Cesar Inacio Martins
 
Posts: n/a

Default nsf.lock mutex wait - 10-03-2010 , 12:20 PM






Hi,

IFX 11.50 FC5W4* HPUX

With some frequency I identify sessions waiting for the nsf.lock mutex .
This wait occur into "sendsocket" function (onstat -g stk)
What I already read about this wait mutex,* can occur when have more than1 cpu vps.

In this case we have 12 cpus.

This behave can have some relation with the configuration bellow?
NETTYPE soctcp,3,250,CPU
(configured to CPU, not NET)

Regards
Cesar

Reply With Quote
  #2  
Old   
JonnyTDI@Usenet-News.net
 
Posts: n/a

Default Re: nsf.lock mutex wait - 10-03-2010 , 02:20 PM






On 03/10/2010 18:20, Cesar Inacio Martins wrote:
Quote:
Hi,

IFX 11.50 FC5W4 HPUX

With some frequency I identify sessions waiting for the nsf.lock mutex .
This wait occur into "sendsocket" function (onstat -g stk)
What I already read about this wait mutex, can occur when have more than
1 cpu vps.

In this case we have 12 cpus.

This behave can have some relation with the configuration bellow?
NETTYPE soctcp,3,250,CPU
(configured to CPU, not NET)

Regards
Cesar


How many active sessions?

And you should really be running on NET VPs.

Reply With Quote
  #3  
Old   
Cesar Inacio Martins
 
Posts: n/a

Default Re: nsf.lock mutex wait - 10-03-2010 , 04:34 PM



Hi Jonny,

Is around of 400-500 sessions.

Cesar

--- Em dom, 3/10/10, JonnyTDI (AT) Usenet-News (DOT) net <JonnyTDI (AT) Usenet-News (DOT) net> escreveu:

De: JonnyTDI (AT) Usenet-News (DOT) net <JonnyTDI (AT) Usenet-News (DOT) net>
Assunto: Re: nsf.lock mutex wait
Para: informix-list (AT) iiug (DOT) org
Data: Domingo, 3 de Outubro de 2010, 16:20

On 03/10/2010 18:20, Cesar Inacio Martins wrote:
Quote:
Hi,

IFX 11.50 FC5W4 HPUX

With some frequency I identify sessions waiting for the nsf.lock mutex .
This wait occur into "sendsocket" function (onstat -g stk)
What I already read about this wait mutex, can occur when have more than
1 cpu vps.

In this case we have 12 cpus.

This behave can have some relation with the configuration bellow?
NETTYPE soctcp,3,250,CPU
(configured to CPU, not NET)

Regards
Cesar


How many active sessions?

And you should really be running on NET VPs.
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list

Reply With Quote
  #4  
Old   
david@smooth1.co.uk
 
Posts: n/a

Default Re: nsf.lock mutex wait - 10-04-2010 , 06:43 PM



On 3 Oct, 18:20, Cesar Inacio Martins
<cesar_inacio_mart... (AT) yahoo (DOT) com.br> wrote:
Quote:
Hi,

IFX 11.50 FC5W4* HPUX

With some frequency I identify sessions waiting for the nsf.lock mutex .
This wait occur into "sendsocket" function (onstat -g stk)
What I already read about this wait mutex,* can occur when have more than 1 cpu vps.

In this case we have 12 cpus.

This behave can have some relation with the configuration bellow?
NETTYPE soctcp,3,250,CPU
(configured to CPU, not NET)

Regards
Cesar
http://www.iiug.org/resources/faq/ifaq06e.htm.1#6.74

The nfs lock is used as part of the system to allow a specific file
number to be duplicated to all of the VPS.
It comes into play most often when a new socket/tli connection has
been established and the other VPs need to be able to write to that
socket.

The most important thing that you can do to gather information about
the problem is "onstat -g ath", "onstat -g stk all", "onstat -g lmx",
and "onstat -g wmx"

Cna you post the output from these? What exact hardware is the running
on? How fast are the cpus?

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.