msc vp - more io/s than i'm used to

Hello Y'all, IDS 10.00.UC5 - Red Hat EL 3 I'm looking at my onstat -g iov output and see that the micellaneous vp is doing work, I'm not used to seeing this. IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (Prim) -- Up 1 days 06:51:31 -- 1125252 Kbytes AIO I/O vps:class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors kio 0 i 44.0 213430 194379 19051 0 499294 0.4 0 kio 1 s 90.8 440710 426365 14345 0 1044377 0.4 0 kio 2 i 29.1 141048 125881 15167 0 331360 0.4 0 kio 3 i 8.8 42524 31808 10716 0 94044 0.5 0 msc 0 i 24.3 117747 0 0 0 111544 1.1 0 aio 0 i 0.0 231 82 0 0 231 1.0 0 aio 1 i 0.0 0 0 0 0 0 0.0 0 pio 0 i 0.0 0 0 0 0 0 0.0 0 lio 0 i 0.0 0 0 0 0 0 0.0 0 2 things have happened recently. We changed our NETTYPE parameters to get around to the APAR IC50796 THE TCP POLL THREAD CAN DEADLOCK WAITING ON NSF.LOCK MUTEX bug we were running into Previous settings NETTYPE soctcp,2,200,NET NETTYPE ipcshm,4,25,CPU Current settings NETTYPE soctcp,1,400,NET NETTYPE ipcshm,1,25,CPU and We recently switched HDR Primaries via the hdrmkpri.sh and hdrmksec.sh scripts. onstat -g stk for the msc vp 0 thread always looks like this IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (Prim) -- Up 1 days 06:59:28 -- 1125252 Kbytes Stack for thread: 5 msc vp 0 base: 0x69409000 len: 135168 pc: 0x0877eaca tos: 0x69429ef0state: sleeping vp: 9 0x0877eaca (oninit)yield_processor_mvp(0xffffffff, 0x693f3884, 0x483ebe5a, 0x693ff968, 0x0, 0x693ff968) 0x08789858 (oninit)iowork (0x693f39c8, 0x693ff968, 0x7, 0x0, 0x0, 0x0) 0x0877f1c4 (oninit)startup (0x28, 0x6942c138, 0x693fffa0, 0x2138, 0xd282e211, 0x0) 0x00000000 (*nosymtab*)0x0 No complaints of performance problems and I don't see any negative impact because of this, mostly just curious as to what the msc vp could be doing. The documentation gives only this for msc vp: Services requests for system calls that require a very large stack. That should tell me something, could going from 2 net vps to 1 net vp cause that 1 net vp to require a larger stack for the system call to check the socket for new data? Thanks, Andrew

On May 29, 9:41 am, "Andrew Ford" <af...@networkip.net> wrote: > Hello Y'all, > > IDS 10.00.UC5 - Red Hat EL 3 > > I'm looking at my onstat -g iov output and see that the micellaneous vp is doing work, I'm not used to seeing this. > > IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (Prim) -- Up 1 days 06:51:31 -- 1125252 Kbytes > > AIO I/O vps:> class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors > kio 0 i 44.0 213430 194379 19051 0 499294 0.4 0 > kio 1 s 90.8 440710 426365 14345 0 1044377 0.4 0 > kio 2 i 29.1 141048 125881 15167 0 331360 0.4 0 > kio 3 i 8.8 42524 31808 10716 0 94044 0.5 0 > msc 0 i 24.3 117747 0 0 0 111544 1.1 0 > aio 0 i 0.0 231 82 0 0 231 1.0 0 > aio 1 i 0.0 0 0 0 0 0 0.0 0 > pio 0 i 0.0 0 0 0 0 0 0.0 0 > lio 0 i 0.0 0 0 0 0 0 0.0 0 > > 2 things have happened recently. > > We changed our NETTYPE parameters to get around to the APAR IC50796 THE TCP POLL THREAD CAN DEADLOCK WAITING ON NSF.LOCK MUTEX bug > we were running into > > Previous settings > > NETTYPE soctcp,2,200,NET > NETTYPE ipcshm,4,25,CPU> > Current settings > > NETTYPE soctcp,1,400,NET > NETTYPE ipcshm,1,25,CPU> > and > > We recently switched HDR Primaries via the hdrmkpri.sh and hdrmksec.sh scripts. > > onstat -g stk for the msc vp 0 thread always looks like this> > IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (Prim) -- Up 1 days 06:59:28 -- 1125252 Kbytes> > Stack for thread: 5 msc vp 0 > base: 0x69409000 > len: 135168 > pc: 0x0877eaca > tos: 0x69429ef0> state: sleeping > vp: 9 > > 0x0877eaca (oninit)yield_processor_mvp(0xffffffff, 0x693f3884, 0x483ebe5a, 0x693ff968, 0x0, 0x693ff968) > 0x08789858 (oninit)iowork (0x693f39c8, 0x693ff968, 0x7, 0x0, 0x0, 0x0) > 0x0877f1c4 (oninit)startup (0x28, 0x6942c138, 0x693fffa0, 0x2138, 0xd282e211, 0x0) > 0x00000000 (*nosymtab*)0x0 > > No complaints of performance problems and I don't see any negative impact because of this, mostly just curious as to what the msc vp > could be doing. The msc vp is responsible for doing the majority of the system calls involved in authenticating a new incoming connection request. I've never actually looked at onstat -g iov to look at msc vp work. I suspect each "op" it is doing is being counted in it's totalops column and I believe each new connection request is probably more then 1 system call to verify the authentication. Somewhere along the way we actually allow you to start multiple msc vps to attempt to increase incoming connection performance. I don't recall which version that was introduced in, I think it's somewhere in the 11 family though. Another note, changing your NETTYPE shouldn't impact the amount of work the msc vp would be doing. The biggest impact on the amount of work the msc vp would be doing is the number of incoming connection requests. Could your system just be doing more short term connections so connections are just coming and going more frequently? > > The documentation gives only this for msc vp: Services requests for system calls that require a very large stack. > > That should tell me something, could going from 2 net vps to 1 net vp cause that 1 net vp to require a larger stack for the system > call to check the socket for new data? No, I don't believe that would be the case. Also the reason the documentation says what it says about the msc vp is because IDS moves the stack area for that oninit process to it's own spot. Then the IDS code has ways to check that if there is enough space in that stack area to perform the next call it would need to make. However, since the msc vp does a significant amount of OS system library calls, we don't know how much stack space those calls will require so it makes it difficult to ensure that one of these OS calls wouldn't blow out the stack. That's why it would be recommended that you increase the stack area for that process, since IDS has much less control over how much stack area is going to be needed compared to how much stack area is left. > > Thanks, > > Andrew