Unix Technical Forum

Re: Informix 9.40 crash after stress test.

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 ...


Go Back   Unix Technical Forum > Database Server Software > Informix

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-19-2008, 07:19 PM
Mark D. Stock
 
Posts: n/a
Default Re: Informix 9.40 crash after stress test.


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
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-19-2008, 07:20 PM
sharad
 
Posts: n/a
Default Re: Informix 9.40 crash after stress test.

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



Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
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
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 10:57 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com