Excessive and sudden Virtual Segment allocation

Our development server instance runs perfectly happily day in, day out with plenty of Virtual memory as follows (IDS7.31, HP-UX 10.20) dev:dba:/users/dba>onstat -g seg Informix Dynamic Server Version 7.31.UC2 -- On-Line -- Up 21 days 17:02:11 -- 248456 Kbytes Segment Summary: id key addr size ovhd class blkused blkfree 49664 1381386241 c1d2f000 80330752 4484 R* 9799 7 (shared) 1381386241 c69cb000 153608192 2952 V 2058 16693 561672 1381386242 cfe5f000 2187264 644 M 260 7 Total: - - 236126208 - - 123117 16707 (* segment locked in memory) Under all day-to-day processing, this has been fine for a couple of years. Now one of our developers is testing a Java app via sockets from an NT box and all of a sudden we get loads of additional segments; the SQLs look pretty innoccuous (using onstat -g sql) - no huge GROUP BYs, ORDER BYs, multi-table joins or whatever. a check on memory usage by sessions shows: dev:dba:/users/dba>onstat -g ses|sort -n -r -k7|head 50021 inetuser - -1 tw00887 1 155213824 153336880 50117 inetuser - -1 twe_nt_w 1 909312 883328 50094 rxf ttyq0 14133 dev 1 638976 630160 50127 dcr ttype 15514 dev 1 557056 534680 50116 oxs ttyq7 15134 dev 1 524288 516096 50129 dxg ttyp5 18992 dev 1 475136 436336 50061 dag ttypf 11047 dev 1 114688 99608 50025 dag ttypf 7996 dev 1 90112 81568 50108 pjh ttyqf 14887 dev 1 81920 70696 50112 inetuser - -1 twe_nt_w 1 40960 28776 So 155Mb is used when the averag per user is normally 40 to 65 Kb. When the user 'inetuser' drops the connection, the segments are released and I can drop them with onmode -F. How can I check what the extra Vseg usage is caused by? Ta Malc -- XS2Mail: Check your mail anywhere http://www.xs2mail.com/

I have that issue with a long running application that grows, fortunately slowly. Start with onstat -g ses {sessionnumber} See which memory pool(s) is large and start from there. Talk to Tech support about what contributes to that memory pool. MW > -----Original Message----- > From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org]On > Behalf Of Malc_p > Sent: Wednesday, 10 September 2003 9:21 p.m. > To: ids@iiug.org > Subject: Excessive and sudden Virtual Segment allocation [1817] > > > Our development server instance runs perfectly happily day > in, day out with plenty of Virtual memory as follows > (IDS7.31, HP-UX 10.20) > dev:dba:/users/dba>onstat -g seg > > > > Informix Dynamic Server Version 7.31.UC2 -- On-Line -- Up > 21 days 17:02:11 -- > 248456 Kbytes > > > > Segment Summary: > > id key addr size ovhd class > blkused blkfree > 49664 1381386241 c1d2f000 80330752 4484 R* 9799 > 7 > (shared) 1381386241 c69cb000 153608192 2952 V 2058 > 16693 > 561672 1381386242 cfe5f000 2187264 644 M 260 > 7 > Total: - - 236126208 - - 123117 > 16707 > > > (* segment locked in memory) > > Under all day-to-day processing, this has been fine for a > couple of years. > Now one of our developers is testing a Java app via sockets > from an NT box and all > of a sudden we get loads of additional segments; the SQLs > look pretty innoccuous (using onstat -g sql) - no huge GROUP > BYs, ORDER BYs, multi-table joins or whatever. > a check on memory usage by sessions shows: > dev:dba:/users/dba>onstat -g ses|sort -n -r -k7|head > > 50021 inetuser - -1 tw00887 1 155213824 > 153336880 > 50117 inetuser - -1 twe_nt_w 1 909312 > 883328 > 50094 rxf ttyq0 14133 dev 1 638976 > 630160 > 50127 dcr ttype 15514 dev 1 557056 > 534680 > 50116 oxs ttyq7 15134 dev 1 524288 > 516096 > 50129 dxg ttyp5 18992 dev 1 475136 > 436336 > 50061 dag ttypf 11047 dev 1 114688 > 99608 > 50025 dag ttypf 7996 dev 1 90112 > 81568 > 50108 pjh ttyqf 14887 dev 1 81920 > 70696 > 50112 inetuser - -1 twe_nt_w 1 40960 > 28776 > So 155Mb is used when the averag per user is normally 40 to > 65 Kb. > When the user 'inetuser' drops the connection, the segments > are released and I can drop them with onmode -F. > How can I check what the extra Vseg usage is caused by? > Ta > Malc > > -- > XS2Mail: Check your mail anywhere http://www.xs2mail.com/