This is a discussion on Re: Informix 9.40 crash after stress test. within the Informix forums, part of the Database Server Software category; --> sharad wrote: > Hi Bill, > > Thanks for your suggetion . I had made changes as per suggetion ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| sharad wrote: > Hi Bill, > > Thanks for your suggetion . I had made changes as per suggetion so rerunning > stress test. but I had one question about I had set connection protocol is > soctcp ,I want to verify is now really using this protocol or not. if not > how to get use this protocol. and why it is using the this much shared > memory ? You see, I think you are confusing the two issues. Certainly you may have allocated multiple message segments, one per CPU VP IIRC, but these are not related to the virtual segments, which are being allocated by a session after they connect. A quick way to see if you are allocating shared memory segments for communication is to run onstat -g seg and see if you have any M segments. There was a similar thread recently on tracking what sessions are allocating segments, but it all gets very tricky. You will need to monitor the output of commands like onstat -g ses and onstat -g mem. As to the crash itself, you should report it, together with all details, to IBM Informix Tech support. > Parameter in onconfig file : > NETTYPE soctcp,4,150,NET > > sqlhosts: > fpt_server onsoctcp 9.182.25.49 INF > > $INFORMIXSERVER fpt_server That looks okay for TCP/IP connections, but are there any other entries for SHM connections? If there are, they will be allocating resources even if they are not being used. Cheers, -- Mark. +----------------------------------------------------------+-----------+ | Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /| | Mydas Solutions Ltd http://MydasSolutions.com |///// / //| | +-----------------------------------+//// / ///| | |We value your comments, which have |/// / ////| | |been recorded and automatically |// / /////| | |emailed back to us for our records.|/ ////////| +----------------------+-----------------------------------+-----------+ sending to informix-list |
| ||||
| Hi Marks & Bill, Thanks for your valuable suggetions.I could now see the connection protocol correctly, My server is usng soctcp protocol . so I could see the problem in allocating virtual segment. It seems that it is allocating more memory than SHMTOTAL. I really not able to find why it's allocating this much virtual memory and server is crashing due to this. This is latest online.log messages. ======================================== 17:33:56 Size of resident + virtual segments 83744KB + 314656KB > 367001KB 17:33:56 total allowed by configuration parameter SHMTOTAL 17:33:56 out of virtual shared memory 17:33:56 Assert Failed: No Exception Handler 17:33:56 IBM Informix Dynamic Server Version 9.40.UC2 17:33:56 Who: Session(39, informix@adolphus, 33176, 40216810) Thread(63, sqlexec, 401e7098, 1) File: mtex.c Line: 431 17:33:56 Results: Exception Caught. Type: MT_EX_OS, Context: mem 17:33:56 Action: Please notify IBM Informix Technical Support. 17:33:56 stack trace for pid 22212 written to /tmp/af.427afb4 17:33:56 See Also: /tmp/af.427afb4, shmem.427afb4.0 ======================================== can you suggest appropriate value need to be set for SHMVIRTSIZE ,SHMADD and SHMTOAL current values of SHMVIRTSIZE = 52500 SHMADD=32768 ,SHMTOTAL = 398400 my machine physical memory is 512MB. only one CPU. Here is current output of onstat -g mem ,onstat -g seg ========================================== onstat -g mem IBM Informix Dynamic Server Version 9.40.UC2 -- On-Line -- Up 17:30:08 -- 267328 Kbytes Pool Summary: name class addr totalsize freesize #allocfrag #freefrag afpool V 4000a020 4096 1168 5 1 tpcpool V 40654020 4096 576 3 1 seqpool V 4066f020 4096 2400 2 1 pnlpool V 40657020 4096 488 3 1 sbtlist V 4007d020 12288 5600 4 3 dstpool V 40653020 4096 1512 2 1 ampool V 40669020 4096 2128 7 1 main_loop() V 407c3020 28672 3824 35 6 sb_delundoq V 4009b020 28672 8424 4 3 XTF_mem V 406a7020 401408 7744 4 3 btscanner 0 V 408fe020 16384 1600 23 2 res-buff R 30388020 81932288 6520 2 2 onmode_mon V 40962020 12288 1600 14 4 lgflushpool V 408d8020 4096 2192 5 1 2 V 407d6020 12288 4296 13 2 rsam V 4010d020 323584 456 318 3 sscpool0 V 4064d020 8192 2808 2 2 3 V 407ed020 12288 4296 13 2 4 V 40804020 12288 4296 13 2 5 V 4081b020 12288 4296 13 2 6 V 40832020 12288 3088 19 5 aslogflush V 408d9020 12288 1600 14 4 aio V 40235020 909312 101736 186 46 opcinstpool V 40656020 4096 488 3 1 smartblob V 4007c020 4096 1288 4 1 gls V 40648020 28672 5544 348 4 DefConvWrit V 406a5020 139264 66168 118 18 resroutpool V 40659020 4096 1512 2 1 sb_delq V 40080020 28672 8424 4 3 resident R 30036020 3481600 6520 2 2 dictpool V 4064e020 12288 3832 5 2 mt V 4000b020 1003520 10512 4910 27 20 V 409cb020 38481920 912 797681 4 21 V 409e5020 12288 4296 13 2 17 V 40956020 38445056 4592 797086 14 aggpool V 40658020 4096 1512 2 1 18 V 40942020 38551552 3488 799318 14 19 V 409b3020 38678528 2792 801968 15 procpool V 40650020 4096 336 13 1 global V 40001020 5656576 66224 1191 19 ctcpool V 40655020 4096 1512 2 1 sb_arcspace V 4010a020 4096 832 4 1 sb_loheader V 400b6020 262144 25944 413 60 inhpool V 4066b020 4096 1968 9 1 opcpool V 4066a020 4096 1400 18 1 Blkpool Summary: name class addr size #blks mt V 4000ce10 1208320 23 global V 400078a8 0 0 ========================================== onstat -g seg IBM Informix Dynamic Server Version 9.40.UC2 -- On-Line -- Up 17:31:40 -- 267328 Kbytes Segment Summary: id key addr size ovhd class blkused blkfree 524301 1381451777 30000000 85753856 217404 R 20907 29 524302 1381451778 40000000 53772288 2248 V 13128 0 524303 1381451779 50000000 33554432 1624 V 8192 0 524304 1381451780 60000000 33554432 1624 V 8192 0 524305 1381451781 70000000 33554432 1624 V 8192 0 524306 1381451782 80000000 33554432 1624 V 2487 5705 Total: - - 273743872 - - 61098 5734 (* segment locked in memory) ========================================== Thanks in advance for any suggetion. -sharad "Mark D. Stock" <mdstock@mydassolutions.com> wrote in message news:bge1l5$ae8$1@terabinaries.xmission.com... > > sharad wrote: > > Hi Bill, > > > > Thanks for your suggetion . I had made changes as per suggetion so rerunning > > stress test. but I had one question about I had set connection protocol is > > soctcp ,I want to verify is now really using this protocol or not. if not > > how to get use this protocol. and why it is using the this much shared > > memory ? > > You see, I think you are confusing the two issues. Certainly you may > have allocated multiple message segments, one per CPU VP IIRC, but these > are not related to the virtual segments, which are being allocated by a > session after they connect. A quick way to see if you are allocating > shared memory segments for communication is to run onstat -g seg and see > if you have any M segments. > > There was a similar thread recently on tracking what sessions are > allocating segments, but it all gets very tricky. You will need to > monitor the output of commands like onstat -g ses and onstat -g mem. > > As to the crash itself, you should report it, together with all details, > to IBM Informix Tech support. > > > Parameter in onconfig file : > > NETTYPE soctcp,4,150,NET > > > > sqlhosts: > > fpt_server onsoctcp 9.182.25.49 INF > > > > $INFORMIXSERVER fpt_server > > That looks okay for TCP/IP connections, but are there any other entries > for SHM connections? If there are, they will be allocating resources > even if they are not being used. > > Cheers, > -- > Mark. > > +----------------------------------------------------------+-----------+ > | Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /| > | Mydas Solutions Ltd http://MydasSolutions.com |///// / file://| > | +-----------------------------------+//// / ///| > | |We value your comments, which have |/// / ////| > | |been recorded and automatically |// / /////| > | |emailed back to us for our records.|/ ////////| > +----------------------+-----------------------------------+-----------+ > > sending to informix-list |