Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4A07D9CE.80200@tweakers.net>
Date: Mon, 11 May 2009 09:54:54 +0200
From: Arjen van der Meijden <acmmailing@tweakers.net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: users@activemq.apache.org
Subject: Re: too many open files
References: <23473539.post@talk.nabble.com> <4A07BCF2.8030504@tweakers.net>
 <23478321.post@talk.nabble.com>
In-Reply-To: <23478321.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Well, that is really mostly the default config with some small differences.

- I completely commented out the "destinationPolicy"-tag. This also 
disables the per-queue/topic size limits.
- I upped the memoryUsage to 200 mb, the storeUsage to 1 gb and the 
tempUsage to 1 gb.
- I changed the connector uri's (for stomp and openwire) to contain 
"?transport.closeAsync=false".

These settings aren't really well thought through and only aimed at our 
very high connect/send/disconnect rate, they're just changes that should 
disable or enlarge some of the limitations I was running in to.

And as you could see from the issue-report, I used a different JAVA_OPTS 
to allow for some larger heap and such.

Best regards,

Arjen

On 11-5-2009 9:29, DataMover wrote:
> 
> I looked at that issue url you gave and wow, had a lot of great info.
> 
> Any chance one could get a copy of the configuration xml file you created
> that solved the issue for you.
> Just to get some ideas.
> 
> I had upped the memory limits via the etc security limit file and that at
> least seemed to increase the load and slow the system down. Have not tried
> it again after that.
> 
> As far as upping the queue sizes, is there a limit?
> Are there best practices anywhere?
> 
> 
> 
> Arjen van der Meijden wrote:
>> There may be at one or more of these three issues that I ran into:
>>
>> - You actually have a too low setting for the open files. Try increasing 
>> it (see man ulimit etc, be careful that normally only root can increase 
>> it beyond 1024, but other programs, including su do inherit it).
>>
>> - You're opening and closing connections too fast, this is what we had:
>> http://issues.apache.org/activemq/browse/AMQ-1739
>> Adding the "?transport.closeAsync=false"-parameter to the url helped us 
>> here.
>>
>> - You're queues may be getting larger than the limits. Especially the 
>> 5mb per queue limit in the default configuration is easy to hit. Once I 
>> raised the global limits and removed the per-queue/topic limits it has 
>> worked stable for several months in a row (since feb 19 our single 
>> broker has queued and dequeued over 300M tiny messages).
>>
>> 30 and 250 producers isn't that many, so unless they're maxing out your 
>> broker system on some other resource than file pointers, my guess is the 
>> single machine should be able to handle them.
>>
>> Best regards,
>>
>> Arjen
>>
>> On 10-5-2009 22:03 DataMover wrote:
>>> I have seems several posts on this but I have not been able to solve our
>>> situation.
>>>
>>> We have 30 clients (producers) working with one activemq server.
>>> All worked amazingly well.
>>>
>>> Then we tried a test with around 250 clients.
>>>
>>> That would get many transport errors.
>>> Increasing the file limits on the os caused the system to come to a crawl
>>> with no benefit.
>>>
>>> I am assuming the problem can be solved with multiple brokers being run.
>>> One question is do they have to be on different machines, or can we have
>>> multiple activemqs running on the same server, each listening on a
>>> different
>>> ip?
>>>
>>>
>>
>