|   | 
	 
  
    | 
RSS Feed - WebSphere MQ Support
 | 
RSS Feed - Message Broker Support
 |   
 
  
	     | 
	 | 
   
 
  
	|  Failed to attach shared memory segment | 
	« View previous topic :: View next topic »  | 
   
  
  	
	  
		
		
		  | Author | 
		  Message
		 |  
		
		  | jimmycallaghan11 | 
		  
		    
			  
				 Posted: Wed Mar 12, 2008 9:33 am    Post subject: Failed to attach shared memory segment | 
				     | 
			   
			 
		   | 
		 
		
		   Newbie
 
 Joined: 12 Mar 2008 Posts: 3
  
  | 
		  
		    
			  
				Hi all,
 
 
We're running JBoss and MQ on our Debian server and recently we've started to see this error:
 
 
Probe Type        :- MSGAMQ6119
 
Probe Severity    :- 2
 
Probe Description :- AMQ6119: An internal WebSphere MQ error has occurred   (Failed to attach shared memory segment: shmat(ShmId 0x00040008) [rc=-1 errno=12] Cannot allocate memory)
 
 
Now I would have thought that JBoss and MQ would keep themselves to themselves and that one should not influence the other. However, when I restart my JBoss server the problem disappears for about 20 hours but then the errors start coming in again. My thought is that as JBoss is running, it slowly uses more and more shared memory until MQ can no longer get what it needs.
 
 
I suppose my questions are:
 
1. Does my theory about JBoss sound OK? Can shared memory be consumed in this way?
 
2. How can I find out what is using the shared memory that MQ is trying to get?
 
 
We've doubled the maximum shared memory segment size but it's had little effect. Nothing has changed much on the server over the last 2 years but this started happening last week.
 
 
Any pointers in the right direction would be appreciated. | 
			   
			 
		   | 
		 
		
		  | Back to top | 
		  
		  	
		   | 
		 
		
		    | 
		 
		
		  | jefflowrey | 
		  
		    
			  
				 Posted: Wed Mar 12, 2008 9:36 am    Post subject:  | 
				     | 
			   
			 
		   | 
		 
		
		   Grand Poobah
 
 Joined: 16 Oct 2002 Posts: 19981
  
  | 
		  
		    
			  
				Likely, you've deployed an app into JBOSS that has a bindings connection handle leak. _________________ I am *not* the model of the modern major general. | 
			   
			 
		   | 
		 
		
		  | Back to top | 
		  
		  	
		   | 
		 
		
		    | 
		 
		
		  | jimmycallaghan11 | 
		  
		    
			  
				 Posted: Wed Mar 12, 2008 10:13 am    Post subject:  | 
				     | 
			   
			 
		   | 
		 
		
		   Newbie
 
 Joined: 12 Mar 2008 Posts: 3
  
  | 
		  
		    
			  
				Thanks for the incredibly swift reply!
 
 
However, at the risk of sounding dumb, what do you mean by a "bindings connection handle leak"? If I do a:
 
 
ps aux | grep amqzlaa0
 
 
I can see that there are only 9 connections and this number never really changes. When we got the problem I look at top and can see that there's not a lot of memory spare. However, it seems that JBoss isn't using more than its 2Mb that I've given it (and we've got 4Mb available). I will put a memory monitor on JBoss and see what trend we get overnight. | 
			   
			 
		   | 
		 
		
		  | Back to top | 
		  
		  	
		   | 
		 
		
		    | 
		 
		
		  | jimmycallaghan11 | 
		  
		    
			  
				 Posted: Thu Mar 13, 2008 1:52 am    Post subject: Shared Memory | 
				     | 
			   
			 
		   | 
		 
		
		   Newbie
 
 Joined: 12 Mar 2008 Posts: 3
  
  | 
		  
		    
			  
				We are running a failover hardware architecture for this application. Basically we have two servers with identical applications on them (MQ and JBOSS). When requests are not answered by the primary server, the secondary answers them. Our shared memory is occurring on the secondary server at the moment and comparing the memory between the two shows some interesting differences.
 
 
Running ipcs -m on the primary gives:
 
   
	| Code: | 
   
  
	
 
------ Shared Memory Segments --------
 
key        shmid      owner      perms      bytes      nattch     status
 
0x85803fad 0          mqm       666        1000       28
 
0x05803ff0 98307      mqm       666        8790016    25
 
0x05804000 163845     mqm       666        18178048   24
 
0x05804003 262152     mqm       644        8790016    1
 
0x0580400f 589842     mqm       666        131072     17
 
0x05804010 622611     mqm       666        1159168    2
 
0x05804011 655380     mqm       666        327680     5
 
0x05804129 786456     mqm       666        8192       1
 
0x0580412a 819225     mqm       666        8192       1 | 
   
 
 
 
on the secondary
 
   
	| Code: | 
   
  
	
 
------ Shared Memory Segments --------
 
key        shmid      owner      perms      bytes      nattch     status
 
0x85887346 0          mqm       666        1000       30
 
0x0588738b 98307      mqm       666        8790016    27
 
0x0588739b 163845     mqm       666        12713984   26
 
0x0588739e 262152     mqm       644        8790016    1
 
0x058873aa 589842     mqm       666        131072     19
 
0x058873ab 622611     mqm       666        1159168    2
 
0x058873ac 655380     mqm       666        327680     5
 
0x0588747d 786456     mqm       666        8192       1
 
0x0588748f 819225     mqm       666        8192       1
 
0x058874b2 983070     mqm       666        3637248    24
 
0x05887521 1245222    mqm       666        7270400    23
 
0x05887524 1343529    mqm       666        14536704   23
 
 | 
   
 
 
 
As you can see, mqm is using significantly more shared memory on the secondary server than it is on the primary. I would normally put this down to load but the primary gets FAR more load than the secondary. | 
			   
			 
		   | 
		 
		
		  | Back to top | 
		  
		  	
		   | 
		 
		
		    | 
		 
		
		  | 
		    
		   | 
		 
	   
	 | 
   
 
  
	     | 
	 | 
	Page 1 of 1 | 
   
 
 
 
  
  	
	  
		
		  
 
  | 
		  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
  | 
  		 
	   
	 | 
   
 
  	 | 
	  |