backups
User on IDS 11.70.FC7W3 (Linux) saw repeated dynamic virtual shared-memory segment allocations, each accompanied by "dynamically allocated 1000000 locks", seemingly during backups, and asked whether backups cause this and how to trace the culprit. Replies said backups aren't the cause: it's lock-table growth from sessions holding millions of locks (use onstat -u / onstat -g sql; LOCK TABLE IN EXCLUSIVE MODE for big batch operations; extra locks go in virtual memory, hence new segments). Suggestions for unattended detection: hook the ALARMPROGRAM (lock escalation and segment allocation trigger it), scheduler tasks, and SESSION_LIMIT_LOCKS; Art Kagel also advised upgrading to 12.10.xC6+ due to 11.70 memory-leak bugs. No confirmation of the final cause is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Trying to find what created lots of V mem segments, I found that during 2 backups lots of blocks where allocated. Do any kind of backup creates blocks on ony kind of dbspace?. What kind of monitoring should I do to catch V segment creators? 10:25:28 Dynamically allocated new virtual shared memory segment (size 134400KB) 10:25:28 Memory sizes:resident:912080 KB, virtual:2700836 KB, no SHMTOTAL limit 10:25:28 dynamically allocated 1000000 locks 10:26:07 Dynamically allocated new virtual shared memory segment (size 134400KB) 10:26:07 Memory sizes:resident:912080 KB, virtual:2835236 KB, no SHMTOTAL limit 10:26:07 dynamically allocated 1000000 locks 10:26:31 Dynamically allocated new virtual shared memory segment (size 134400KB) 10:26:31 Memory sizes:resident:912080 KB, virtual:2969636 KB, no SHMTOTAL limit 10:26:31 dynamically allocated 1000000 locks 10:28:53 Dynamically allocated new virtual shared memory segment (size 134400KB) 10:28:53 Memory sizes:resident:912080 KB, virtual:3104036 KB, no SHMTOTAL limit 10:28:53 dynamically allocated 1000000 locks
Version and platform? Art On Mar 15, 2016 08:08, "JACOBO BALBUENA" <jacobo.bc@gmail.com> wrote: > Trying to find what created lots of V mem segments, I found that during 2 > backups lots of blocks where allocated. > > Do any kind of backup creates blocks on ony kind of dbspace?. > > What kind of monitoring should I do to catch V segment creators? > > 10:25:28 Dynamically allocated new virtual shared memory segment (size > 134400KB) > 10:25:28 Memory sizes:resident:912080 KB, virtual:2700836 KB, no SHMTOTAL > limit > 10:25:28 dynamically allocated 1000000 locks > 10:26:07 Dynamically allocated new virtual shared memory segment (size > 134400KB) > 10:26:07 Memory sizes:resident:912080 KB, virtual:2835236 KB, no SHMTOTAL > limit > 10:26:07 dynamically allocated 1000000 locks > 10:26:31 Dynamically allocated new virtual shared memory segment (size > 134400KB) > 10:26:31 Memory sizes:resident:912080 KB, virtual:2969636 KB, no SHMTOTAL > limit > 10:26:31 dynamically allocated 1000000 locks > 10:28:53 Dynamically allocated new virtual shared memory segment (size > 134400KB) > 10:28:53 Memory sizes:resident:912080 KB, virtual:3104036 KB, no SHMTOTAL > limit > 10:28:53 dynamically allocated 1000000 locks > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --047d7bd76bea33ff91052e15b7cd
I would first look at the applications running. T= here is an
application
which is consuming lots (over 4 million) of locks= . A simple onstat
-u
should provide you with who is consuming the = locks. Then I would
run an onstat -g sql {session=5Fid} to s= ee what they are doing.
John F. Miller III
STSM, Lead &n= bsp;Architect
[1]miller3@us.ibm.com
503-747-1366
IBM Informix Dynamic Server (IDS)
[2]-----ids-bounces@iiug.org wrote: -----
>To: <= a target=3D"=5Fblank"
href=3D"mailto:ids@iiug.org">ids@iiug.org
>= From: "JACOBO BALBUENA"
>Sent by: [3]ids-bounces@iiug.org
>Date: 03/15/2016 = 05:08AM
>Subject: backups [36743]
>
>Trying to find what= created lots of V mem segments, I found that
>during 2
>backu= ps lots of blocks where allocated.
>
>Do any kind of backup cr= eates blocks on ony kind of dbspace?.
>
>What kind of monitori= ng should I do to catch V segment creators?
>
>10:25:28 Dynami= cally allocated new virtual shared memory segment
>(size
>1344= 00KB)
>10:25:28 Memory sizes:resident:912080 KB, virtual:2700836 KB,= no
>SHMTOTAL
>limit
>10:25:28 dynamically allocated 10= 00000 locks
>10:26:07 Dynamically allocated new virtual shared memor= y segment
>(size
>134400KB)
>10:26:07 Memory sizes:resi= dent:912080 KB, virtual:2835236 KB, no
>SHMTOTAL
>limit
&g= t;10:26:07 dynamically allocated 1000000 locks
>10:26:31 Dynamically= allocated new virtual shared memory segment
>(size
>134400KB)=
>10:26:31 Memory sizes:resident:912080 KB, virtual:2969636 KB,
no>SHMTOTAL
>limit
>10:26:31 dynamically allocated 1000000= locks
>10:28:53 Dynamically allocated new virtual shared memory seg= ment
>(size
>134400KB)
>10:28:53 Memory sizes:resident:= 912080 KB, virtual:3104036 KB, no
>SHMTOTAL
>limit
>10:= 28:53 dynamically allocated 1000000 locks
>
>
>*********=
************************************************************
>*******= ***
> Forum Note: Use "Reply" to post a response in the discussion =
forum.
>
>
>
References
1. 3D"mailto:miller3@us.ibm.com"
2. 3D"mailto:-----ids-bounces@i=
3. file://localhost/tmp/3D"mai=
Hi Jacob, tock table growth caused these shared memory allocations, probably some=20 large UPDATE or DELETE (or load?) operation modifying millions of rows=20 within a single transaction. Nothing to do with backups most probably. LOCK TABLE <tab> IN EXCLUSIVE MODE; might help avoid this with large=20 table maintenance operations. Beyond this, as long as you can afford and your machine can provide enough = memory, no adverse impact by added shared memory segments. In case you've experienced 'blocks', it might have been this presumably=20 huge lock list that caused others to wait or experience slow down. Andreas Legner Informix L2 support. From: "JACOBO BALBUENA" <jacobo.bc@gmail.com> To: ids@iiug.org Date: 15.03.2016 13:08 Subject: backups [36743] Sent by: ids-bounces@iiug.org Trying to find what created lots of V mem segments, I found that during 2=20 backups lots of blocks where allocated.=20 Do any kind of backup creates blocks on ony kind of dbspace?.=20 What kind of monitoring should I do to catch V segment creators?=20 10:25:28 Dynamically allocated new virtual shared memory segment (size=20 134400KB)=20 10:25:28 Memory sizes:resident:912080 KB, virtual:2700836 KB, no SHMTOTAL=20 limit=20 10:25:28 dynamically allocated 1000000 locks=20 10:26:07 Dynamically allocated new virtual shared memory segment (size=20 134400KB)=20 10:26:07 Memory sizes:resident:912080 KB, virtual:2835236 KB, no SHMTOTAL=20 limit=20 10:26:07 dynamically allocated 1000000 locks=20 10:26:31 Dynamically allocated new virtual shared memory segment (size=20 134400KB)=20 10:26:31 Memory sizes:resident:912080 KB, virtual:2969636 KB, no SHMTOTAL=20 limit=20 10:26:31 dynamically allocated 1000000 locks=20 10:28:53 Dynamically allocated new virtual shared memory segment (size=20 134400KB)=20 10:28:53 Memory sizes:resident:912080 KB, virtual:3104036 KB, no SHMTOTAL=20 limit=20 10:28:53 dynamically allocated 1000000 locks=20 ***************************************************************************= ****=20 Forum Note: Use "Reply" to post a response in the discussion forum.=20
11.70.FC7W3 uname -a Linux bbdd2-pro.xunta.es 2.6.32-504.el6.x86_64 #1 SMP Tue Sep 16 01:56:35 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux I'm starting to guess they are lying to me and they are launching something that may cause those locks increase. Anyway the question about if informix blocks something during backups is still valid as I don't really know the answer. Is there some kind of trace that won't impact perfomance and would help me finding the reason of V segments increase. I usually can find if it's happening when I'm there to see it, but if happens on weekends or in the night I don't know how can I see it. As a side note, thanks a lot for the help AK, I don't want to spam the forum with thanks notes, but you surely deserve them.
Version 11.70 has several bugs that can cause memory leaks and allocations a couple of which were not fixed until v12. I would strongly recommend upgrading to v12.10.xC6 or later. Art On Mar 15, 2016 12:49, "JACOBO BALBUENA" <jacobo.bc@gmail.com> wrote: > 11.70.FC7W3 > uname -a > Linux bbdd2-pro.xunta.es 2.6.32-504.el6.x86_64 #1 SMP Tue Sep 16 01:56:35 > EDT > 2014 x86_64 x86_64 x86_64 GNU/Linux > > I'm starting to guess they are lying to me and they are launching something > that may cause those locks increase. Anyway the question about if informix > blocks something during backups is still valid as I don't really know the > answer. > > Is there some kind of trace that won't impact perfomance and would help me > finding the reason of V segments increase. I usually can find if it's > happening when I'm there to see it, but if happens on weekends or in the > night > I don't know how can I see it. > > As a side note, thanks a lot for the help AK, I don't want to spam the > forum > with thanks notes, but you surely deserve them. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a113eca06be01ec052e1a56ce
The lock table escalation and the shared memory segment allocations both trigger the execution of the alarm program. So you can adapt the script to collect some data. You could also use the scheduler and custom tasks to regularly monitor sessions that have more than a certain number of locks. And you can use the SESSION_LIMIT_LOCKS to prevent a single session from using too many (you decide how many are too many) locks. On 11.70 I believe this is not documented but it's there and should work. Regards. On Tue, Mar 15, 2016 at 3:12 PM, JACOBO BALBUENA <jacobo.bc@gmail.com> wrote: > 11.70.FC7W3 > uname -a > Linux bbdd2-pro.xunta.es 2.6.32-504.el6.x86_64 #1 SMP Tue Sep 16 01:56:35 > EDT > 2014 x86_64 x86_64 x86_64 GNU/Linux > > I'm starting to guess they are lying to me and they are launching something > that may cause those locks increase. Anyway the question about if informix > blocks something during backups is still valid as I don't really know the > answer. > > Is there some kind of trace that won't impact perfomance and would help me > finding the reason of V segments increase. I usually can find if it's > happening when I'm there to see it, but if happens on weekends or in the > night > I don't know how can I see it. > > As a side note, thanks a lot for the help AK, I don't want to spam the > forum > with thanks notes, but you surely deserve them. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --047d7bdc11d601d0da052e1d6f82
A (maybe minor) point on memory growth/allocations ... the initial LOCKS structure is allocated in the RESIDENT portion of the engine. Any new structures are allocated in the VIRTUAL portion, thus the new segment allocations. Thanks - Mark Scranton The Mark Scranton Group mark@markscranton.com