You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@usergrid.apache.org by "John D. Ament" <jo...@apache.org> on 2015/02/09 00:14:01 UTC
Re: Cassandra Memory Requirements?
So wanted to give more info to see if there's any recommendation (otherwise
I'll start bugging the cassandra ML)
Our use case is something like two apps involved. One app writes to a
custom collection in usergrid (actually both do this), and we've let it
grow to 12k entities in that collection.
Now, second app comes in and starts reading those messages to see what to
do next. Queries for the collection are using 60 as a limit (a performance
limit on the eventual receiver). We read the message, do some work, and
then delete that entity from the collection.
This to me isn't a lot of data, others may disagree though. Anyways, we
have a 3 node cassandra cluster where we're seeing Usergrid respond pretty
fast, but ends up waiting on Cassandra for most of the time (3+ seconds per
query).
This is what each server is running:
-XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
-XX:ThreadPriorityPolicy=42 -Xms4G
-Xmx4G -Xmn800M -XX:+HeapDumpOnOutOfMemoryError -Xss256k
-XX:StringTableSize=1000003
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+UseTLAB -XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways -XX:+UseCondCardMark
Any thoughts are very much appreciated.
John
On Thu Jan 29 2015 at 12:30:47 PM Dave <sn...@gmail.com> wrote:
> On Thu, Jan 29, 2015 at 10:04 AM, John D. Ament <jo...@apache.org>
> wrote:
>
>> Hi all,
>>
>> Just wondering, does anyone have any recommendations for memory to deploy
>> for cassandra?
>>
>
> I usually give Cassandra as much heap as I can spare, up to about 10GB.
> I've heard that there are garbage collection problems above that level.
>
> - Dave
>
>
>
Re: Cassandra Memory Requirements?
Posted by Todd Nine <to...@gmail.com>.
Hey John,
Try applying this CQL file. You'll need to update the keyspaces
replication factor to match your distribution. Note that this required
cassandra 1.2.x or greater.
On Mon Feb 09 2015 at 2:21:00 PM John D. Ament <jo...@apache.org>
wrote:
> Also, our DBAs were wondering if there's any recommended values for
> concurrent reads or caching.
>
> John
>
>
> On Mon Feb 09 2015 at 3:36:26 PM John D. Ament <jo...@apache.org>
> wrote:
>
>> I'm not sure about consistency level, based on a screen shot I'm seeing
>> QUORUM.
>>
>> Replication factor is 3.
>>
>> Thanks,
>>
>> John
>>
>>
>> On Mon Feb 09 2015 at 3:17:35 PM Todd Nine <to...@gmail.com> wrote:
>>
>>> Usergrid query. In that case you definitely shouldn't have slowness.
>>> That query is a direct range scan, then multiget of entities. What
>>> consistency level and replication factor are you running?
>>>
>>>
>>> On Mon Feb 09 2015 at 10:58:58 AM John D. Ament <jo...@apache.org>
>>> wrote:
>>>
>>>> Sorry I wasn't sure if you meant the underlying cassandra query or the
>>>> usergrid query.
>>>>
>>>> The usergrid query is simply
>>>>
>>>> /{org}/{app}/{collection}
>>>>
>>>> With param: ql=order%20by%20created%20asc
>>>>
>>>> John
>>>>
>>>>
>>>> On Mon Feb 09 2015 at 12:55:14 PM Todd Nine <to...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hey John,
>>>>> As Dave said. I'm assuming you're running version 1.0 right?
>>>>> Version 1.0 has a much slower query engine than UG 2.0. In UG 1.0, we
>>>>> don't have term scoring, cardinality stats etc. Therefore, the more
>>>>> complex the query you input, the slower the results, since it requires
>>>>> iteration of the candidate term sets to perform the union/intersection with
>>>>> the terms provided. We've fixed this in 2.0 by just using ES, which
>>>>> leverages the speed and optimizations that have been built into Lucene.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon Feb 09 2015 at 7:03:17 AM Dave <sn...@gmail.com> wrote:
>>>>>
>>>>>> On Sun, Feb 8, 2015 at 6:14 PM, John D. Ament <jo...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> So wanted to give more info to see if there's any recommendation
>>>>>>> (otherwise I'll start bugging the cassandra ML)
>>>>>>>
>>>>>>> Our use case is something like two apps involved. One app writes to
>>>>>>> a custom collection in usergrid (actually both do this), and we've let it
>>>>>>> grow to 12k entities in that collection.
>>>>>>>
>>>>>>> Now, second app comes in and starts reading those messages to see
>>>>>>> what to do next. Queries for the collection are using 60 as a limit (a
>>>>>>> performance limit on the eventual receiver). We read the message, do some
>>>>>>> work, and then delete that entity from the collection.
>>>>>>>
>>>>>>> This to me isn't a lot of data, others may disagree though.
>>>>>>> Anyways, we have a 3 node cassandra cluster where we're seeing Usergrid
>>>>>>> respond pretty fast, but ends up waiting on Cassandra for most of the time
>>>>>>> (3+ seconds per query).
>>>>>>>
>>>>>>> This is what each server is running:
>>>>>>> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
>>>>>>> -XX:ThreadPriorityPolicy=42 -Xms4G
>>>>>>> -Xmx4G -Xmn800M -XX:+HeapDumpOnOutOfMemoryError -Xss256k
>>>>>>> -XX:StringTableSize=1000003
>>>>>>> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>>>>>>> -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8
>>>>>>> -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75
>>>>>>> -XX:+UseCMSInitiatingOccupancyOnly
>>>>>>> -XX:+UseTLAB -XX:+CMSParallelInitialMarkEnabled
>>>>>>> -XX:+CMSEdenChunksRecordAlways -XX:+UseCondCardMark
>>>>>>>
>>>>>>> Any thoughts are very much appreciated.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> It might be helpful if you can share the actual queries you are
>>>>>> making.
>>>>>>
>>>>>> - Dave
>>>>>>
>>>>>>
>>>>>
Re: Cassandra Memory Requirements?
Posted by "John D. Ament" <jo...@apache.org>.
Also, our DBAs were wondering if there's any recommended values for
concurrent reads or caching.
John
On Mon Feb 09 2015 at 3:36:26 PM John D. Ament <jo...@apache.org>
wrote:
> I'm not sure about consistency level, based on a screen shot I'm seeing
> QUORUM.
>
> Replication factor is 3.
>
> Thanks,
>
> John
>
>
> On Mon Feb 09 2015 at 3:17:35 PM Todd Nine <to...@gmail.com> wrote:
>
>> Usergrid query. In that case you definitely shouldn't have slowness.
>> That query is a direct range scan, then multiget of entities. What
>> consistency level and replication factor are you running?
>>
>>
>> On Mon Feb 09 2015 at 10:58:58 AM John D. Ament <jo...@apache.org>
>> wrote:
>>
>>> Sorry I wasn't sure if you meant the underlying cassandra query or the
>>> usergrid query.
>>>
>>> The usergrid query is simply
>>>
>>> /{org}/{app}/{collection}
>>>
>>> With param: ql=order%20by%20created%20asc
>>>
>>> John
>>>
>>>
>>> On Mon Feb 09 2015 at 12:55:14 PM Todd Nine <to...@gmail.com> wrote:
>>>
>>>> Hey John,
>>>> As Dave said. I'm assuming you're running version 1.0 right?
>>>> Version 1.0 has a much slower query engine than UG 2.0. In UG 1.0, we
>>>> don't have term scoring, cardinality stats etc. Therefore, the more
>>>> complex the query you input, the slower the results, since it requires
>>>> iteration of the candidate term sets to perform the union/intersection with
>>>> the terms provided. We've fixed this in 2.0 by just using ES, which
>>>> leverages the speed and optimizations that have been built into Lucene.
>>>>
>>>>
>>>>
>>>>
>>>> On Mon Feb 09 2015 at 7:03:17 AM Dave <sn...@gmail.com> wrote:
>>>>
>>>>> On Sun, Feb 8, 2015 at 6:14 PM, John D. Ament <jo...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> So wanted to give more info to see if there's any recommendation
>>>>>> (otherwise I'll start bugging the cassandra ML)
>>>>>>
>>>>>> Our use case is something like two apps involved. One app writes to
>>>>>> a custom collection in usergrid (actually both do this), and we've let it
>>>>>> grow to 12k entities in that collection.
>>>>>>
>>>>>> Now, second app comes in and starts reading those messages to see
>>>>>> what to do next. Queries for the collection are using 60 as a limit (a
>>>>>> performance limit on the eventual receiver). We read the message, do some
>>>>>> work, and then delete that entity from the collection.
>>>>>>
>>>>>> This to me isn't a lot of data, others may disagree though. Anyways,
>>>>>> we have a 3 node cassandra cluster where we're seeing Usergrid respond
>>>>>> pretty fast, but ends up waiting on Cassandra for most of the time (3+
>>>>>> seconds per query).
>>>>>>
>>>>>> This is what each server is running:
>>>>>> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
>>>>>> -XX:ThreadPriorityPolicy=42 -Xms4G
>>>>>> -Xmx4G -Xmn800M -XX:+HeapDumpOnOutOfMemoryError -Xss256k
>>>>>> -XX:StringTableSize=1000003
>>>>>> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
>>>>>> -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8
>>>>>> -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75
>>>>>> -XX:+UseCMSInitiatingOccupancyOnly
>>>>>> -XX:+UseTLAB -XX:+CMSParallelInitialMarkEnabled
>>>>>> -XX:+CMSEdenChunksRecordAlways -XX:+UseCondCardMark
>>>>>>
>>>>>> Any thoughts are very much appreciated.
>>>>>>
>>>>>
>>>>>
>>>>> It might be helpful if you can share the actual queries you are making.
>>>>>
>>>>> - Dave
>>>>>
>>>>>
>>>>
Re: Cassandra Memory Requirements?
Posted by "John D. Ament" <jo...@apache.org>.
I'm not sure about consistency level, based on a screen shot I'm seeing
QUORUM.
Replication factor is 3.
Thanks,
John
On Mon Feb 09 2015 at 3:17:35 PM Todd Nine <to...@gmail.com> wrote:
> Usergrid query. In that case you definitely shouldn't have slowness.
> That query is a direct range scan, then multiget of entities. What
> consistency level and replication factor are you running?
>
>
> On Mon Feb 09 2015 at 10:58:58 AM John D. Ament <jo...@apache.org>
> wrote:
>
>> Sorry I wasn't sure if you meant the underlying cassandra query or the
>> usergrid query.
>>
>> The usergrid query is simply
>>
>> /{org}/{app}/{collection}
>>
>> With param: ql=order%20by%20created%20asc
>>
>> John
>>
>>
>> On Mon Feb 09 2015 at 12:55:14 PM Todd Nine <to...@gmail.com> wrote:
>>
>>> Hey John,
>>> As Dave said. I'm assuming you're running version 1.0 right? Version
>>> 1.0 has a much slower query engine than UG 2.0. In UG 1.0, we don't have
>>> term scoring, cardinality stats etc. Therefore, the more complex the query
>>> you input, the slower the results, since it requires iteration of the
>>> candidate term sets to perform the union/intersection with the terms
>>> provided. We've fixed this in 2.0 by just using ES, which leverages the
>>> speed and optimizations that have been built into Lucene.
>>>
>>>
>>>
>>>
>>> On Mon Feb 09 2015 at 7:03:17 AM Dave <sn...@gmail.com> wrote:
>>>
>>>> On Sun, Feb 8, 2015 at 6:14 PM, John D. Ament <jo...@apache.org>
>>>> wrote:
>>>>
>>>>> So wanted to give more info to see if there's any recommendation
>>>>> (otherwise I'll start bugging the cassandra ML)
>>>>>
>>>>> Our use case is something like two apps involved. One app writes to a
>>>>> custom collection in usergrid (actually both do this), and we've let it
>>>>> grow to 12k entities in that collection.
>>>>>
>>>>> Now, second app comes in and starts reading those messages to see what
>>>>> to do next. Queries for the collection are using 60 as a limit (a
>>>>> performance limit on the eventual receiver). We read the message, do some
>>>>> work, and then delete that entity from the collection.
>>>>>
>>>>> This to me isn't a lot of data, others may disagree though. Anyways,
>>>>> we have a 3 node cassandra cluster where we're seeing Usergrid respond
>>>>> pretty fast, but ends up waiting on Cassandra for most of the time (3+
>>>>> seconds per query).
>>>>>
>>>>> This is what each server is running:
>>>>> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
>>>>> -XX:ThreadPriorityPolicy=42 -Xms4G
>>>>> -Xmx4G -Xmn800M -XX:+HeapDumpOnOutOfMemoryError -Xss256k
>>>>> -XX:StringTableSize=1000003
>>>>> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
>>>>> -XX:SurvivorRatio=8
>>>>> -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75
>>>>> -XX:+UseCMSInitiatingOccupancyOnly
>>>>> -XX:+UseTLAB -XX:+CMSParallelInitialMarkEnabled
>>>>> -XX:+CMSEdenChunksRecordAlways -XX:+UseCondCardMark
>>>>>
>>>>> Any thoughts are very much appreciated.
>>>>>
>>>>
>>>>
>>>> It might be helpful if you can share the actual queries you are making.
>>>>
>>>> - Dave
>>>>
>>>>
>>>
Re: Cassandra Memory Requirements?
Posted by Todd Nine <to...@gmail.com>.
Usergrid query. In that case you definitely shouldn't have slowness.
That query is a direct range scan, then multiget of entities. What
consistency level and replication factor are you running?
On Mon Feb 09 2015 at 10:58:58 AM John D. Ament <jo...@apache.org>
wrote:
> Sorry I wasn't sure if you meant the underlying cassandra query or the
> usergrid query.
>
> The usergrid query is simply
>
> /{org}/{app}/{collection}
>
> With param: ql=order%20by%20created%20asc
>
> John
>
>
> On Mon Feb 09 2015 at 12:55:14 PM Todd Nine <to...@gmail.com> wrote:
>
>> Hey John,
>> As Dave said. I'm assuming you're running version 1.0 right? Version
>> 1.0 has a much slower query engine than UG 2.0. In UG 1.0, we don't have
>> term scoring, cardinality stats etc. Therefore, the more complex the query
>> you input, the slower the results, since it requires iteration of the
>> candidate term sets to perform the union/intersection with the terms
>> provided. We've fixed this in 2.0 by just using ES, which leverages the
>> speed and optimizations that have been built into Lucene.
>>
>>
>>
>>
>> On Mon Feb 09 2015 at 7:03:17 AM Dave <sn...@gmail.com> wrote:
>>
>>> On Sun, Feb 8, 2015 at 6:14 PM, John D. Ament <jo...@apache.org>
>>> wrote:
>>>
>>>> So wanted to give more info to see if there's any recommendation
>>>> (otherwise I'll start bugging the cassandra ML)
>>>>
>>>> Our use case is something like two apps involved. One app writes to a
>>>> custom collection in usergrid (actually both do this), and we've let it
>>>> grow to 12k entities in that collection.
>>>>
>>>> Now, second app comes in and starts reading those messages to see what
>>>> to do next. Queries for the collection are using 60 as a limit (a
>>>> performance limit on the eventual receiver). We read the message, do some
>>>> work, and then delete that entity from the collection.
>>>>
>>>> This to me isn't a lot of data, others may disagree though. Anyways,
>>>> we have a 3 node cassandra cluster where we're seeing Usergrid respond
>>>> pretty fast, but ends up waiting on Cassandra for most of the time (3+
>>>> seconds per query).
>>>>
>>>> This is what each server is running:
>>>> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
>>>> -XX:ThreadPriorityPolicy=42 -Xms4G
>>>> -Xmx4G -Xmn800M -XX:+HeapDumpOnOutOfMemoryError -Xss256k
>>>> -XX:StringTableSize=1000003
>>>> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
>>>> -XX:SurvivorRatio=8
>>>> -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75
>>>> -XX:+UseCMSInitiatingOccupancyOnly
>>>> -XX:+UseTLAB -XX:+CMSParallelInitialMarkEnabled
>>>> -XX:+CMSEdenChunksRecordAlways -XX:+UseCondCardMark
>>>>
>>>> Any thoughts are very much appreciated.
>>>>
>>>
>>>
>>> It might be helpful if you can share the actual queries you are making.
>>>
>>> - Dave
>>>
>>>
>>
Re: Cassandra Memory Requirements?
Posted by "John D. Ament" <jo...@apache.org>.
Sorry I wasn't sure if you meant the underlying cassandra query or the
usergrid query.
The usergrid query is simply
/{org}/{app}/{collection}
With param: ql=order%20by%20created%20asc
John
On Mon Feb 09 2015 at 12:55:14 PM Todd Nine <to...@gmail.com> wrote:
> Hey John,
> As Dave said. I'm assuming you're running version 1.0 right? Version
> 1.0 has a much slower query engine than UG 2.0. In UG 1.0, we don't have
> term scoring, cardinality stats etc. Therefore, the more complex the query
> you input, the slower the results, since it requires iteration of the
> candidate term sets to perform the union/intersection with the terms
> provided. We've fixed this in 2.0 by just using ES, which leverages the
> speed and optimizations that have been built into Lucene.
>
>
>
>
> On Mon Feb 09 2015 at 7:03:17 AM Dave <sn...@gmail.com> wrote:
>
>> On Sun, Feb 8, 2015 at 6:14 PM, John D. Ament <jo...@apache.org>
>> wrote:
>>
>>> So wanted to give more info to see if there's any recommendation
>>> (otherwise I'll start bugging the cassandra ML)
>>>
>>> Our use case is something like two apps involved. One app writes to a
>>> custom collection in usergrid (actually both do this), and we've let it
>>> grow to 12k entities in that collection.
>>>
>>> Now, second app comes in and starts reading those messages to see what
>>> to do next. Queries for the collection are using 60 as a limit (a
>>> performance limit on the eventual receiver). We read the message, do some
>>> work, and then delete that entity from the collection.
>>>
>>> This to me isn't a lot of data, others may disagree though. Anyways, we
>>> have a 3 node cassandra cluster where we're seeing Usergrid respond pretty
>>> fast, but ends up waiting on Cassandra for most of the time (3+ seconds per
>>> query).
>>>
>>> This is what each server is running:
>>> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
>>> -XX:ThreadPriorityPolicy=42 -Xms4G
>>> -Xmx4G -Xmn800M -XX:+HeapDumpOnOutOfMemoryError -Xss256k
>>> -XX:StringTableSize=1000003
>>> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
>>> -XX:SurvivorRatio=8
>>> -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75
>>> -XX:+UseCMSInitiatingOccupancyOnly
>>> -XX:+UseTLAB -XX:+CMSParallelInitialMarkEnabled
>>> -XX:+CMSEdenChunksRecordAlways -XX:+UseCondCardMark
>>>
>>> Any thoughts are very much appreciated.
>>>
>>
>>
>> It might be helpful if you can share the actual queries you are making.
>>
>> - Dave
>>
>>
>
Re: Cassandra Memory Requirements?
Posted by Todd Nine <to...@gmail.com>.
Hey John,
As Dave said. I'm assuming you're running version 1.0 right? Version
1.0 has a much slower query engine than UG 2.0. In UG 1.0, we don't have
term scoring, cardinality stats etc. Therefore, the more complex the query
you input, the slower the results, since it requires iteration of the
candidate term sets to perform the union/intersection with the terms
provided. We've fixed this in 2.0 by just using ES, which leverages the
speed and optimizations that have been built into Lucene.
On Mon Feb 09 2015 at 7:03:17 AM Dave <sn...@gmail.com> wrote:
> On Sun, Feb 8, 2015 at 6:14 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>> So wanted to give more info to see if there's any recommendation
>> (otherwise I'll start bugging the cassandra ML)
>>
>> Our use case is something like two apps involved. One app writes to a
>> custom collection in usergrid (actually both do this), and we've let it
>> grow to 12k entities in that collection.
>>
>> Now, second app comes in and starts reading those messages to see what to
>> do next. Queries for the collection are using 60 as a limit (a performance
>> limit on the eventual receiver). We read the message, do some work, and
>> then delete that entity from the collection.
>>
>> This to me isn't a lot of data, others may disagree though. Anyways, we
>> have a 3 node cassandra cluster where we're seeing Usergrid respond pretty
>> fast, but ends up waiting on Cassandra for most of the time (3+ seconds per
>> query).
>>
>> This is what each server is running:
>> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
>> -XX:ThreadPriorityPolicy=42 -Xms4G
>> -Xmx4G -Xmn800M -XX:+HeapDumpOnOutOfMemoryError -Xss256k
>> -XX:StringTableSize=1000003
>> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
>> -XX:SurvivorRatio=8
>> -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75
>> -XX:+UseCMSInitiatingOccupancyOnly
>> -XX:+UseTLAB -XX:+CMSParallelInitialMarkEnabled
>> -XX:+CMSEdenChunksRecordAlways -XX:+UseCondCardMark
>>
>> Any thoughts are very much appreciated.
>>
>
>
> It might be helpful if you can share the actual queries you are making.
>
> - Dave
>
>
Re: Cassandra Memory Requirements?
Posted by Dave <sn...@gmail.com>.
On Sun, Feb 8, 2015 at 6:14 PM, John D. Ament <jo...@apache.org> wrote:
> So wanted to give more info to see if there's any recommendation
> (otherwise I'll start bugging the cassandra ML)
>
> Our use case is something like two apps involved. One app writes to a
> custom collection in usergrid (actually both do this), and we've let it
> grow to 12k entities in that collection.
>
> Now, second app comes in and starts reading those messages to see what to
> do next. Queries for the collection are using 60 as a limit (a performance
> limit on the eventual receiver). We read the message, do some work, and
> then delete that entity from the collection.
>
> This to me isn't a lot of data, others may disagree though. Anyways, we
> have a 3 node cassandra cluster where we're seeing Usergrid respond pretty
> fast, but ends up waiting on Cassandra for most of the time (3+ seconds per
> query).
>
> This is what each server is running:
> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
> -XX:ThreadPriorityPolicy=42 -Xms4G
> -Xmx4G -Xmn800M -XX:+HeapDumpOnOutOfMemoryError -Xss256k
> -XX:StringTableSize=1000003
> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
> -XX:SurvivorRatio=8
> -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75
> -XX:+UseCMSInitiatingOccupancyOnly
> -XX:+UseTLAB -XX:+CMSParallelInitialMarkEnabled
> -XX:+CMSEdenChunksRecordAlways -XX:+UseCondCardMark
>
> Any thoughts are very much appreciated.
>
It might be helpful if you can share the actual queries you are making.
- Dave