Re: SOLR Config on Dev Center

[Dieudonné Madishon NGAYA]

You have  to explicitly add one of your  SOLR Search node Datacenter  in  
Dev-Center to perform SOLR Queries.

> On Sep 26, 2019, at 12:40 AM, Elliott Sims  wrote:
> 
> Datastax might be a better resource for this.  This mailing list is pretty 
> good about questions that apply to DSE and Apache Cassandra, but the SOLR 
> integration is pretty specific to DSE.
> 
> On Wed, Sep 25, 2019 at 7:15 PM kumar bharath  > wrote:
> Hi All, 
> 
> We are having a 6 node cluster with two data centers(DSE 5.1 Cassandra).One 
> of the data centers is SOLR enabled. 
> Do I need to explicitly add the SOLR Search node in  Dev-Center to perform 
> SOLR Queries.?
> 
> Thanks for you response in advance.
> 
> Regards,
> Bharath Kumar B

Re: Fw: read request is slow

[Dieudonné Madishon NGAYA]

Never mind : nodetool sjk help

On Mon, Mar 18, 2019 at 9:36 AM Dieudonné Madishon NGAYA 
wrote:

> Hi, please send us result of: nodetool help sjk
>
> On Mon, Mar 18, 2019 at 9:28 AM ishib...@gmail.com 
> wrote:
>
>> Hi!
>>
>> This is interesting note for me.
>>
>> We have C* 3.11.1, but ‘sjk’ still  unexpected parameters for nodetool
>> utility.
>>
>> Am I  missed something or ‘sjk’ available as separate rpm-package?
>>
>>
>>
>> Best regards, Ilya
>>
>>
>> 
>> Тема: Re: read request is slow
>> От: Dieudonné Madishon NGAYA
>> Кому: user@cassandra.apache.org
>> Копия:
>>
>>
>>
>> For your information,since cassandra 3.0, it includes ttop and other
>> options inside sjk
>> nodetool sjk
>>
>> https://docs.datastax.com/en/cassandra/3.0/cassandra/tools/toolsSjk.html
>>
>>
>>
>>
>>
>>
>>
>> *From:* Jon Haddad [mailto:j...@jonhaddad.com]
>> *Sent:* Saturday, March 16, 2019 5:25 PM
>> *To:* user@cassandra.apache.org
>> *Subject:* Re: read request is slow
>>
>>
>>
>> I'm guessing you're getting 100MB from the comments in the config, which
>> suggest 100MB per core.  This advice is pretty outdated and should be
>> updated.
>>
>>
>>
>> I'd use 8GB total heap and 4GB new gen as a starting point.  I really
>> suggest reading up on how GC works, I linked to a post in an earlier email.
>>
>>
>>
>> These are the flags you'd need to set in your jvm.options, or
>> jvm-server.options depending on the version you're using:
>>
>>
>>
>> -Xmx8G
>>
>> -Xms8G
>>
>> -Xmn4G
>>
>>
>>
>> 1 core is probably going to be a problem, Cassandra creates a lot of
>> threads and relies on doing work concurrently.  I wouldn't use less than 8
>> cores in a production environment.
>>
>>
>> ---
>> This message and any attachment are confidential and may be privileged or
>> otherwise protected from disclosure. If you are not the intended recipient
>> any use, distribution, copying or disclosure is strictly prohibited. If you
>> have received this message in error, please notify the sender immediately
>> either by telephone or by e-mail and delete this message and any attachment
>> from your system. Correspondence via e-mail is for information purposes
>> only. AO Raiffeisenbank neither makes nor accepts legally binding
>> statements by e-mail unless otherwise agreed.
>> ---
>>
>> - To
>> unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For
>> additional commands, e-mail: user-h...@cassandra.apache.org
>
> --
>
> Best regards
> _
>
> [image:
> https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]
> <https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour>
><https://twitter.com/dmnbigdata>   <https://www.instagram.com/>
> <https://www.linkedin.com/in/dngaya/>
>
> *Dieudonne Madishon NGAYA*
> Datastax, Cassandra Architect
> *P: *7048580065
> *w: *www.dmnbigdata.com
> *E: *dmng...@dmnbigdata.com
> *Private E: *dmng...@gmail.com
> *A: *Charlotte,NC,28273, USA
>
-- 

Best regards
_

[image:
https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]
<https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour>
   <https://twitter.com/dmnbigdata>   <https://www.instagram.com/>
<https://www.linkedin.com/in/dngaya/>

*Dieudonne Madishon NGAYA*
Datastax, Cassandra Architect
*P: *7048580065
*w: *www.dmnbigdata.com
*E: *dmng...@dmnbigdata.com
*Private E: *dmng...@gmail.com
*A: *Charlotte,NC,28273, USA

Re: Fw: read request is slow

[Dieudonné Madishon NGAYA]

Hi, please send us result of: nodetool help sjk

On Mon, Mar 18, 2019 at 9:28 AM ishib...@gmail.com 
wrote:

> Hi!
>
> This is interesting note for me.
>
> We have C* 3.11.1, but ‘sjk’ still  unexpected parameters for nodetool
> utility.
>
> Am I  missed something or ‘sjk’ available as separate rpm-package?
>
>
>
> Best regards, Ilya
>
>
> ----
> Тема: Re: read request is slow
> От: Dieudonné Madishon NGAYA
> Кому: user@cassandra.apache.org
> Копия:
>
>
>
> For your information,since cassandra 3.0, it includes ttop and other
> options inside sjk
> nodetool sjk
>
> https://docs.datastax.com/en/cassandra/3.0/cassandra/tools/toolsSjk.html
>
>
>
>
>
>
>
> *From:* Jon Haddad [mailto:j...@jonhaddad.com]
> *Sent:* Saturday, March 16, 2019 5:25 PM
> *To:* user@cassandra.apache.org
> *Subject:* Re: read request is slow
>
>
>
> I'm guessing you're getting 100MB from the comments in the config, which
> suggest 100MB per core.  This advice is pretty outdated and should be
> updated.
>
>
>
> I'd use 8GB total heap and 4GB new gen as a starting point.  I really
> suggest reading up on how GC works, I linked to a post in an earlier email.
>
>
>
> These are the flags you'd need to set in your jvm.options, or
> jvm-server.options depending on the version you're using:
>
>
>
> -Xmx8G
>
> -Xms8G
>
> -Xmn4G
>
>
>
> 1 core is probably going to be a problem, Cassandra creates a lot of
> threads and relies on doing work concurrently.  I wouldn't use less than 8
> cores in a production environment.
>
>
> ---
> This message and any attachment are confidential and may be privileged or
> otherwise protected from disclosure. If you are not the intended recipient
> any use, distribution, copying or disclosure is strictly prohibited. If you
> have received this message in error, please notify the sender immediately
> either by telephone or by e-mail and delete this message and any attachment
> from your system. Correspondence via e-mail is for information purposes
> only. AO Raiffeisenbank neither makes nor accepts legally binding
> statements by e-mail unless otherwise agreed.
> ---
>
> - To
> unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional
> commands, e-mail: user-h...@cassandra.apache.org

-- 

Best regards
_

[image:
https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]
<https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour>
   <https://twitter.com/dmnbigdata>   <https://www.instagram.com/>
<https://www.linkedin.com/in/dngaya/>

*Dieudonne Madishon NGAYA*
Datastax, Cassandra Architect
*P: *7048580065
*w: *www.dmnbigdata.com
*E: *dmng...@dmnbigdata.com
*Private E: *dmng...@gmail.com
*A: *Charlotte,NC,28273, USA

Re: read request is slow

[Dieudonné Madishon NGAYA]

For your information,since cassandra 3.0, it includes ttop and other
options inside sjk
nodetool sjk
https://docs.datastax.com/en/cassandra/3.0/cassandra/tools/toolsSjk.html

Best regards
_

[image:
https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]
<https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour>
   <https://twitter.com/dmnbigdata>   <https://www.instagram.com/>
<https://www.linkedin.com/in/dngaya/>

*Dieudonne Madishon NGAYA*
Datastax, Cassandra Architect
*P: *7048580065
*w: *www.dmnbigdata.com
*E: *dmng...@dmnbigdata.com
*Private E: *dmng...@gmail.com
*A: *Charlotte,NC,28273, USA


On Sun, Mar 17, 2019 at 12:39 PM Jeff Jirsa  wrote:

> Also https://github.com/aragozin/jvm-tools
>
> Especially
> https://github.com/aragozin/jvm-tools/blob/master/sjk-core/docs/TTOP.md
>
>
>
> On Sun, Mar 17, 2019 at 9:04 AM Dieudonné Madishon NGAYA <
> dmng...@gmail.com> wrote:
>
>> Hi,
>> Below some different tools to monitor cassandra:
>> 1) Nodetool
>> Nodetool has many options
>> 2)Jconsole
>> 3) Opscenter
>> 4) tools like top, htop, vmstats, sar, dstat etc ... are also very
>> usefull.
>>
>> Best regards
>> _
>>
>> [image:
>> https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]
>> <https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour>
>><https://twitter.com/dmnbigdata>   <https://www.instagram.com/>
>> <https://www.linkedin.com/in/dngaya/>
>>
>> *Dieudonne Madishon NGAYA*
>> Datastax, Cassandra Architect
>> *P: *7048580065
>> *w: *www.dmnbigdata.com
>> *E: *dmng...@dmnbigdata.com
>> *Private E: *dmng...@gmail.com
>> *A: *Charlotte,NC,28273, USA
>>
>>
>> On Sun, Mar 17, 2019 at 12:48 AM Sundaramoorthy, Natarajan <
>> natarajan_sundaramoor...@optum.com> wrote:
>>
>>> Also would like to know  what monitoring should I setup so that if it
>>> happens again I can provide more information. Thanks
>>>
>>>
>>>
>>>
>>>
>>> *From:* Jon Haddad [mailto:j...@jonhaddad.com]
>>> *Sent:* Saturday, March 16, 2019 5:25 PM
>>> *To:* user@cassandra.apache.org
>>> *Subject:* Re: read request is slow
>>>
>>>
>>>
>>> I'm guessing you're getting 100MB from the comments in the config, which
>>> suggest 100MB per core.  This advice is pretty outdated and should be
>>> updated.
>>>
>>>
>>>
>>> I'd use 8GB total heap and 4GB new gen as a starting point.  I really
>>> suggest reading up on how GC works, I linked to a post in an earlier email.
>>>
>>>
>>>
>>> These are the flags you'd need to set in your jvm.options, or
>>> jvm-server.options depending on the version you're using:
>>>
>>>
>>>
>>> -Xmx8G
>>>
>>> -Xms8G
>>>
>>> -Xmn4G
>>>
>>>
>>>
>>> 1 core is probably going to be a problem, Cassandra creates a lot of
>>> threads and relies on doing work concurrently.  I wouldn't use less than 8
>>> cores in a production environment.
>>>
>>>
>>>
>>> On Sun, Mar 17, 2019 at 3:12 AM Dieudonné Madishon NGAYA <
>>> dmng...@gmail.com> wrote:
>>>
>>> Starting point for me: max_heap_size to 8gb and heap_newsize to 100mb.
>>> Then restart node by node then watch system.log to see if you are seeing G.C
>>>
>>>
>>>
>>> On Sat, Mar 16, 2019 at 9:56 AM Sundaramoorthy, Natarajan <
>>> natarajan_sundaramoor...@optum.com> wrote:
>>>
>>> So you guys are suggesting
>>>
>>>
>>>
>>> MAX_HEAP_SIZE  by 8/12/16GB
>>>
>>>
>>>
>>> And
>>>
>>>
>>>
>>> HEAP_NEWSIZE to 100 MB
>>>
>>>
>>>
>>> And
>>>
>>>
>>>
>>> heap with 50% of that as a starting point? Hw do I do this?
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>>> *From:* Dieudonné Madishon NGAYA [mailto:dmng...@gmail.com]
>>> *Sent:* Saturday, March 16, 2019 12:15 AM
>>> *To:* user@cassandra.apache.org
>>> *Subject:* Re: read request is slow
>>>
>>>
>>>
>>> I agreed with jon haddad , your MAX_HEAP_SIZE 

Re: read request is slow

[Dieudonné Madishon NGAYA]

Hi,
Below some different tools to monitor cassandra:
1) Nodetool
Nodetool has many options
2)Jconsole
3) Opscenter
4) tools like top, htop, vmstats, sar, dstat etc ... are also very usefull.

Best regards
_

[image:
https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]
<https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour>
   <https://twitter.com/dmnbigdata>   <https://www.instagram.com/>
<https://www.linkedin.com/in/dngaya/>

*Dieudonne Madishon NGAYA*
Datastax, Cassandra Architect
*P: *7048580065
*w: *www.dmnbigdata.com
*E: *dmng...@dmnbigdata.com
*Private E: *dmng...@gmail.com
*A: *Charlotte,NC,28273, USA


On Sun, Mar 17, 2019 at 12:48 AM Sundaramoorthy, Natarajan <
natarajan_sundaramoor...@optum.com> wrote:

> Also would like to know  what monitoring should I setup so that if it
> happens again I can provide more information. Thanks
>
>
>
>
>
> *From:* Jon Haddad [mailto:j...@jonhaddad.com]
> *Sent:* Saturday, March 16, 2019 5:25 PM
> *To:* user@cassandra.apache.org
> *Subject:* Re: read request is slow
>
>
>
> I'm guessing you're getting 100MB from the comments in the config, which
> suggest 100MB per core.  This advice is pretty outdated and should be
> updated.
>
>
>
> I'd use 8GB total heap and 4GB new gen as a starting point.  I really
> suggest reading up on how GC works, I linked to a post in an earlier email.
>
>
>
> These are the flags you'd need to set in your jvm.options, or
> jvm-server.options depending on the version you're using:
>
>
>
> -Xmx8G
>
> -Xms8G
>
> -Xmn4G
>
>
>
> 1 core is probably going to be a problem, Cassandra creates a lot of
> threads and relies on doing work concurrently.  I wouldn't use less than 8
> cores in a production environment.
>
>
>
> On Sun, Mar 17, 2019 at 3:12 AM Dieudonné Madishon NGAYA <
> dmng...@gmail.com> wrote:
>
> Starting point for me: max_heap_size to 8gb and heap_newsize to 100mb.
> Then restart node by node then watch system.log to see if you are seeing G.C
>
>
>
> On Sat, Mar 16, 2019 at 9:56 AM Sundaramoorthy, Natarajan <
> natarajan_sundaramoor...@optum.com> wrote:
>
> So you guys are suggesting
>
>
>
> MAX_HEAP_SIZE  by 8/12/16GB
>
>
>
> And
>
>
>
> HEAP_NEWSIZE to 100 MB
>
>
>
> And
>
>
>
> heap with 50% of that as a starting point? Hw do I do this?
>
>
>
> Thanks
>
>
>
>
>
> *From:* Dieudonné Madishon NGAYA [mailto:dmng...@gmail.com]
> *Sent:* Saturday, March 16, 2019 12:15 AM
> *To:* user@cassandra.apache.org
> *Subject:* Re: read request is slow
>
>
>
> I agreed with jon haddad , your MAX_HEAP_SIZE is very small. you have lot
> of RAM (256 GB), you can start your  MAX_HEAP_SIZE  by 8GB and increase if
> necessary.
>
> Since you have only 1 physical core if i understood , you can set your 
> HEAP_NEWSIZE
> to 100 MB
>
>
>
> Best regards
>
> _
>
>
> [image:
> https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]
> <https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour>
><https://twitter.com/dmnbigdata>   <https://www.instagram.com/>
> <https://www.linkedin.com/in/dngaya/>
>
> *Dieudonne Madishon NGAYA*
> Datastax, Cassandra Architect
> *P: *7048580065
> *w: *www.dmnbigdata.com
> *E: *dmng...@dmnbigdata.com
> *Private E: *dmng...@gmail.com
> *A: *Charlotte,NC,28273, USA
>
>
>
>
>
>
>
> On Sat, Mar 16, 2019 at 1:07 AM Jon Haddad  wrote:
>
> I can't say I've ever used 100MB new gen with Cassandra, but in my
> experience I've found small new gen to be incredibly harmful for
> performance.  It doesn't surprise me at all that you'd hit some serious GC
> issues.  My guess is you're filling up the new gen very quickly and
> promoting everything in very quick cycles, leading to memory fragmentation
> and soon after full GCs.  2GB is a tiny heap and I would never, under any
> circumstances, run a 2GB heap in a production environment.  I'd only use
> under 8 GB in a circle CI free tier for integration tests.
>
>
>
> I suggest you use a minimum of 8, preferably 12-16GB of total heap with
> 50% of that as a starting point.  There's a bunch of posts floating around
> on the topic, here's one I wrote:
> http://thelastpickle.com/blog/2018/04/11/gc-tuning.html
>
>
>
> Jon
>
>
>
> On Sat, Mar 16, 2019 at 5:49 PM Sundaramoorthy, Natarajan <
> natarajan_sundaramoor...@optum.com> wrote:
>
> Here you go. Thanks
>
>

Re: read request is slow

[Dieudonné Madishon NGAYA]

Starting point for me: max_heap_size to 8gb and heap_newsize to 100mb. Then
restart node by node then watch system.log to see if you are seeing G.C

On Sat, Mar 16, 2019 at 9:56 AM Sundaramoorthy, Natarajan <
natarajan_sundaramoor...@optum.com> wrote:

> So you guys are suggesting
>
>
>
> MAX_HEAP_SIZE  by 8/12/16GB
>
>
>
> And
>
>
>
> HEAP_NEWSIZE to 100 MB
>
>
>
> And
>
>
>
> heap with 50% of that as a starting point? Hw do I do this?
>
>
>
> Thanks
>
>
>
>
>
> *From:* Dieudonné Madishon NGAYA [mailto:dmng...@gmail.com]
> *Sent:* Saturday, March 16, 2019 12:15 AM
> *To:* user@cassandra.apache.org
> *Subject:* Re: read request is slow
>
>
>
> I agreed with jon haddad , your MAX_HEAP_SIZE is very small. you have lot
> of RAM (256 GB), you can start your  MAX_HEAP_SIZE  by 8GB and increase if
> necessary.
>
> Since you have only 1 physical core if i understood , you can set your 
> HEAP_NEWSIZE
> to 100 MB
>
>
>
> Best regards
>
> _
>
>
> [image:
> https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]
> <https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour>
><https://twitter.com/dmnbigdata>   <https://www.instagram.com/>
> <https://www.linkedin.com/in/dngaya/>
>
> *Dieudonne Madishon NGAYA*
> Datastax, Cassandra Architect
> *P: *7048580065
> *w: *www.dmnbigdata.com
> *E: *dmng...@dmnbigdata.com
> *Private E: *dmng...@gmail.com
> *A: *Charlotte,NC,28273, USA
>
>
>
>
>
>
>
> On Sat, Mar 16, 2019 at 1:07 AM Jon Haddad  wrote:
>
> I can't say I've ever used 100MB new gen with Cassandra, but in my
> experience I've found small new gen to be incredibly harmful for
> performance.  It doesn't surprise me at all that you'd hit some serious GC
> issues.  My guess is you're filling up the new gen very quickly and
> promoting everything in very quick cycles, leading to memory fragmentation
> and soon after full GCs.  2GB is a tiny heap and I would never, under any
> circumstances, run a 2GB heap in a production environment.  I'd only use
> under 8 GB in a circle CI free tier for integration tests.
>
>
>
> I suggest you use a minimum of 8, preferably 12-16GB of total heap with
> 50% of that as a starting point.  There's a bunch of posts floating around
> on the topic, here's one I wrote:
> http://thelastpickle.com/blog/2018/04/11/gc-tuning.html
>
>
>
> Jon
>
>
>
> On Sat, Mar 16, 2019 at 5:49 PM Sundaramoorthy, Natarajan <
> natarajan_sundaramoor...@optum.com> wrote:
>
> Here you go. Thanks
>
> - name: MAX_HEAP_SIZE
>
>   value: 2048M
>
> - name: MY_POD_NAMESPACE
>
>   valueFrom:
>
> fieldRef:
>
>   apiVersion: v1
>
>   fieldPath: metadata.namespace
>
> - name: HEAP_NEWSIZE
>
>   value: 100M
>
>
>
>
>
>
>
> *From:* Dieudonné Madishon NGAYA [mailto:dmng...@gmail.com]
> *Sent:* Friday, March 15, 2019 11:18 PM
> *To:* user@cassandra.apache.org
> *Subject:* Re: read request is slow
>
>
>
> Is it possible to have these parameters from cassandra-env.sh if they are
> set:
>
> MAX_HEAP_SIZE and HEAP_NEWSIZE
>
>
>
> Best regards
>
> _
>
>
> [image:
> https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]
> <https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour>
><https://twitter.com/dmnbigdata>   <https://www.instagram.com/>
> <https://www.linkedin.com/in/dngaya/>
>
> *Dieudonne Madishon NGAYA*
> Datastax, Cassandra Architect
> *P: *7048580065
> *w: *www.dmnbigdata.com
> *E: *dmng...@dmnbigdata.com
> *Private E: *dmng...@gmail.com
> *A: *Charlotte,NC,28273, USA
>
>
>
>
>
>
>
> On Sat, Mar 16, 2019 at 12:10 AM Sundaramoorthy, Natarajan <
> natarajan_sundaramoor...@optum.com> wrote:
>
> Thanks for the quick response.
>
>
>
> Here is the cassandra.yaml attached.
>
>
>
> 1.  What was the read request?  Are you fetching a single row, a
> million, something else?
>
>
>
> *Trying to get the details*
>
>
>
> 2. What are your GC settings?
>
>
>
> *I have no name!@cassandra-0:/etc/cassandra$ nodetool gcstats*
>
> *   Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC
> Elapsed (ms)   GC Reclaimed (MB) Collections  Direct Memory
> Byt

Re: read request is slow

[Dieudonné Madishon NGAYA]

Hi,
I want to add something:
5. do you know on which table are you getting these reads timeout ?
6. if yes, can you see if you don't have  Excessive tombstone activity
7. how often do you run repair ?
8. can you send a system.log and also report of nodetool tpstats
9.  Swap is enabled   or not ?

Best regards
_

[image:
https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]

      


*Dieudonne Madishon NGAYA*
Datastax, Cassandra Architect
*P: *7048580065
*w: *www.dmnbigdata.com
*E: *dmng...@dmnbigdata.com
*Private E: *dmng...@gmail.com
*A: *Charlotte,NC,28273, USA


On Fri, Mar 15, 2019 at 11:32 PM Jon Haddad  wrote:

>
> 1. What was the read request?  Are you fetching a single row, a million,
> something else?
> 2. What are your GC settings?
> 3. What's the hardware in use?  What resources have been allocated to each
> instance?
> 4. Did you see this issue after a single request or is the cluster under
> heavy load?
>
> If you're going to share a config it's much easier to read as an actual
> text file rather than a double spaced paste into the ML.  In the future if
> you could share a link to the yaml you might get more eyes on it.
>
> Jon
>
> On Sat, Mar 16, 2019 at 3:57 PM Sundaramoorthy, Natarajan <
> natarajan_sundaramoor...@optum.com> wrote:
>
>> 3 pod deployed in openshift. Read request timed out due to GC collection.
>> Can you please look at below parameters and value to see if anything is out
>> of place? Thanks
>>
>>
>>
>>
>>
>> cat cassandra.yaml
>>
>>
>>
>> num_tokens: 256
>>
>>
>>
>>
>>
>>
>>
>> hinted_handoff_enabled: true
>>
>>
>>
>> hinted_handoff_throttle_in_kb: 1024
>>
>>
>>
>> max_hints_delivery_threads: 2
>>
>>
>>
>> hints_directory: /cassandra_data/hints
>>
>>
>>
>> hints_flush_period_in_ms: 1
>>
>>
>>
>> max_hints_file_size_in_mb: 128
>>
>>
>>
>>
>>
>> batchlog_replay_throttle_in_kb: 1024
>>
>>
>>
>> authenticator: PasswordAuthenticator
>>
>>
>>
>> authorizer: AllowAllAuthorizer
>>
>>
>>
>> role_manager: CassandraRoleManager
>>
>>
>>
>> roles_validity_in_ms: 2000
>>
>>
>>
>>
>>
>> permissions_validity_in_ms: 2000
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> partitioner: org.apache.cassandra.dht.Murmur3Partitioner
>>
>>
>>
>> data_file_directories:
>>
>> - /cassandra_data/data
>>
>>
>>
>> commitlog_directory: /cassandra_data/commitlog
>>
>>
>>
>> disk_failure_policy: stop
>>
>>
>>
>> commit_failure_policy: stop
>>
>>
>>
>> key_cache_size_in_mb:
>>
>>
>>
>> key_cache_save_period: 14400
>>
>>
>>
>>
>>
>>
>>
>> row_cache_size_in_mb: 0
>>
>>
>>
>> row_cache_save_period: 0
>>
>>
>>
>>
>>
>> counter_cache_size_in_mb:
>>
>>
>>
>> counter_cache_save_period: 7200
>>
>>
>>
>>
>>
>> saved_caches_directory: /cassandra_data/saved_caches
>>
>>
>>
>> commitlog_sync: periodic
>>
>> commitlog_sync_period_in_ms: 1
>>
>>
>>
>> commitlog_segment_size_in_mb: 32
>>
>>
>>
>>
>>
>> seed_provider:
>>
>> - class_name: org.apache.cassandra.locator.SimpleSeedProvider
>>
>>   parameters:
>>
>>   - seeds:
>> "cassandra-0.cassandra.ihr-ei.svc.cluster.local,cassandra-1.cassandra.ihr-ei.svc.cluster.local"
>>
>>
>>
>> concurrent_reads: 32
>>
>> concurrent_writes: 32
>>
>> concurrent_counter_writes: 32
>>
>>
>>
>> concurrent_materialized_view_writes: 32
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> disk_optimization_strategy: ssd
>>
>>
>>
>>
>>
>>
>>
>> memtable_allocation_type: heap_buffers
>>
>>
>>
>> commitlog_total_space_in_mb: 2048
>>
>>
>>
>>
>>
>> index_summary_capacity_in_mb:
>>
>>
>>
>> index_summary_resize_interval_in_minutes: 60
>>
>>
>>
>> trickle_fsync: false
>>
>> trickle_fsync_interval_in_kb: 10240
>>
>>
>>
>> storage_port: 7000
>>
>>
>>
>> ssl_storage_port: 7001
>>
>>
>>
>> listen_address: 10.130.7.245
>>
>>
>>
>> broadcast_address: 10.130.7.245
>>
>>
>>
>>
>>
>>
>>
>> start_native_transport: true
>>
>> native_transport_port: 9042
>>
>>
>>
>>
>>
>>
>>
>> start_rpc: true
>>
>>
>>
>> rpc_address: 0.0.0.0
>>
>>
>>
>> rpc_port: 9160
>>
>>
>>
>> broadcast_rpc_address: 10.130.7.245
>>
>>
>>
>> rpc_keepalive: true
>>
>>
>>
>> rpc_server_type: sync
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> thrift_framed_transport_size_in_mb: 15
>>
>>
>>
>> incremental_backups: false
>>
>>
>>
>> snapshot_before_compaction: false
>>
>>
>>
>> auto_snapshot: true
>>
>>
>>
>> tombstone_warn_threshold: 1000
>>
>> tombstone_failure_threshold: 10
>>
>>
>>
>> column_index_size_in_kb: 64
>>
>>
>>
>>
>>
>> batch_size_warn_threshold_in_kb: 5
>>
>>
>>
>> batch_size_fail_threshold_in_kb: 50
>>
>>
>>
>>
>>
>> compaction_throughput_mb_per_sec: 16
>>
>>
>>
>> compaction_large_partition_warning_threshold_mb: 100
>>
>>
>>
>> sstable_preemptive_open_interval_in_mb: 50
>>
>>
>>
>>
>>
>>
>>
>> read_request_timeout_in_ms: 5
>>
>> range_request_timeout_in_ms: 10
>>
>> write_request_timeout_in_ms: 

Re: update manually rows in cassandra

[Dieudonné Madishon NGAYA]

Hi ,
In your case, do you want to insert json file data into cassandra ?

Best regards
_

[image:
https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]

      


*Dieudonne Madishon NGAYA*
Datastax, Cassandra Architect
*P: *7048580065
*w: *www.dmnbigdata.com
*E: *dmng...@dmnbigdata.com
*Private E: *dmng...@gmail.com
*A: *Charlotte,NC,28273, USA


On Wed, Mar 13, 2019 at 4:04 PM Sundaramoorthy, Natarajan <
natarajan_sundaramoor...@optum.com> wrote:

>
>
> *Something got goofed up in database. Data is in json format. We have data
> in some file have to match the data in file and update the database. Can
> you please tell how to do it? New to cassandra. Thanks *
>
>
>
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>

Re: Cluster size "limit"

[Dieudonné Madishon NGAYA]

Hi  Ahmed Eljami,
Problem is not only number of nodes.
what is your capacity per node ?
recommandations from Datastax is keeping data per node near or below 1 TB.
Exceeding this value has  the following effects:

   - .Extremely long times (days) for bootstrapping new nodes.
   - .Impacts maintenance (day-to-day operations), such as recovering,
   adding, and replacing nodes.
   - .Reduces efficiency when running repairs.
   - .Significantly extends the time it takes to expand datacenters.
   - .Substantially increases compactions per node.

Higher capacity nodes works best with static data and low access rates.

Best regards
_

[image:
https://www.facebook.com/DMN-BigData-371074727032197/?modal=admin_todo_tour]

      


*Dieudonne Madishon NGAYA*
Datastax, Cassandra Architect
*P: *7048580065
*w: *www.dmnbigdata.com
*E: *dmng...@dmnbigdata.com
*Private E: *dmng...@gmail.com
*A: *Charlotte,NC,28273, USA


On Wed, Mar 13, 2019 at 11:58 AM Ahmed Eljami 
wrote:

> Hi,
>
> We are planning to add a third datacenter to our cluster (already has 2
> datacenter, every datcenter has 50 nodes, so 100 nodes in total).
>
> My fear is that an important number of nodes per cluster (> 100) could
> cause a lot of problems like gossip duration, maintenance (repair...)...
>
> I know that it depends on use cases, volume of data and many other thing,
> but I would like that you share your  experiences with that.
>
> Thx
>
>
>
>