Re: Problem of datastorage after compute finished

[Michael Jay]

Really appreciate for your reply, Andrei. 
Now I understand why the result didn't store on the same node where it was
calculated. I will try your suggestions.
But there still remain a problem that job b,d,f were calculated on Node_B,
the results were lost. No partitions store these jobs' results.
thanks again.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: ignite cluster in AWS - s3 discovery

[vkulichenko]

Are there any exceptions on startup?

-Val



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

AW: Discrepancy between cache.Size() / Visorcmd and SQL query resultset

[Bellenger, Dominique]

Hey Stanislav,
I was able to get into a situation like described before but the server nodes 
are not under pressure any more. The cache state seems to stay corrupted. I was 
able to restart the client and even then the client does not see the whole 
cache content (but with the sql query) and gets "not found" errors when trying 
to load objects it wants to load because the keys were spit out by the sql 
query.
I am able to reproduce the situation, if the load is applied to the servers 
while one of them is inserting new objects with LoadCache method. I switched to 
REPLICATED mode in the meantime and the problem still exists.

Current situation:
I have 138285 objects (SQLLine "SELECT COUNT(*) FROM [cache]") which 
corresponds to the object count read from the database to fill the cache.
The SQL query being executed on the client is "select count(*) FROM [cache] 
WHERE Field1 IN 
('d1719313-4921-43c5-82b7-4924a6c3e6e3','bff55ebc-b353-4193-a827-703cd32b45f0','fbf4fea6-11f5-41bc-8018-e230904574b1')
 AND Field2 IN (3,1,4,7);"
This query gives constantly 120284 hits in SQLLine. On the client node I get 
the same result - at least most of the time. Sometimes the client only gets 
3753 as result at the moment. The client does the query every 10 to 15 seconds.
Now about the numbers that visor (and `cache.GetSize()` on the client) reports: 
72935 (Split up into 1866 on the first and 71069 on the second node).

Therefore I've 65350 objects that are seen by SQL (everytime using SQLLine, 
most of the times seen by the client) and that are not seen by visor / by 
`cache.GetSize()` executed on the client.

I will extract the configuration and some log data as soon as possible. I'll 
also try to replace LoadCache with a DataStreamer. Maybe it helps.

Cheers,
Dome

-Ursprüngliche Nachricht-
Von: Stanislav Lukyanov  
Gesendet: 13 April 2018 18:26
An: user@ignite.apache.org
Betreff: Re: Discrepancy between cache.Size() / Visorcmd and SQL query resultset

Hi,

Could you please share your configuration files, cache configurations, logs 
from all nodes and the code snippets you use to do the queries (visor commands, 
SQL, etc)?

Thanks,
Stan

Bellenger, Dominique wrote
> Hey Igniters,
> 
> I've the following setup (Ignite .NET 2.4): 2 Server nodes, 1 client 
> node doing SQL-queries on the cache periodically (every 20 Seconds in my 
> case).
> The cache is filled with 110_000 entries from a database, using 
> "LoadCache" method. Key is a string representation of a number, 
> nothing fancy here.
> 
> Situation: Both server nodes are put under pressure by doing 
> affinity-run compute jobs on both nodes, affecting all cache entries 
> (read, change, put every entry).
> 
> I made the following observations:
> 
>   1.  Visorcmd showed that the entries were distributed like 60_000 on 
> one node and 34_000 on the other. The same sum (94_000) was shown on 
> the client side on every periodic "tick" when calling "GetSize" on the 
> cache instance 
> (https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Cache/ICache.cs#L685).
> 
> 
>  *   Why are there entries missing? Running SELECT Count(*) on the
> Cache with SQLLine reports back 110_000 entries.
>  *   Why are the entries not distributed 50/50 (or nearly 50/50)?
> 
> 
>   1.  On the client, the SQL query invoked on every "tick" returned 
> sometimes 110_000 entries, sometimes 60_000 or 34_000. There was no 
> error or warning in the client or server log about failing SQL queries.
>  *   In a partitioned cache both servers do a query and the results
> are merged, if I understood correctly. It seems to me that one of the 
> servers sometimes returns an empty result set and therefore the client 
> gets a too small result set. Question is: why does this happen even 
> without a warning on the server nodes about a failing query?
>   2.  In that situation the client is not able to load a specific 
> entry from the cache multiple times using TryGet(TK key, out TV value) 
> (https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Cache/ICache.cs#L297).
> Those entries definitely are existing in the cache.
>   3.  In that situation on one of both server nodes I get errors that 
> an entry could not be loaded (like in 3) but on the affinity-server node!).
> In my understanding the compute jobs shall get executed on the primary 
> node for the given key. And this node is not able to load an entry by 
> that key (when under heavy CPU pressure)?
> 
> Something is strange here. Any ideas?
> 
> Cheers,
> Dome





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite Data Streamer Hung after a period

[dkarachentsev]

Hi,

Blocked threads show only the fact that there are no tasks to process in
pool. Do you use persistence and/or indexing? Could you please attach your
configs and logs from all nodes? Please take few sequential thread dumps
when throughput is low.

Thanks!
-Dmitry 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Discrepancy between cache.Size() / Visorcmd and SQL query resultset

[Stanislav Lukyanov]

Hi,

Could you please share your configuration files, cache configurations, logs
from all nodes and the code snippets you use to do the queries (visor
commands, SQL, etc)?

Thanks,
Stan

Bellenger, Dominique wrote
> Hey Igniters,
> 
> I've the following setup (Ignite .NET 2.4): 2 Server nodes, 1 client node
> doing SQL-queries on the cache periodically (every 20 Seconds in my case).
> The cache is filled with 110_000 entries from a database, using
> "LoadCache" method. Key is a string representation of a number, nothing
> fancy here.
> 
> Situation: Both server nodes are put under pressure by doing affinity-run
> compute jobs on both nodes, affecting all cache entries (read, change, put
> every entry).
> 
> I made the following observations:
> 
>   1.  Visorcmd showed that the entries were distributed like 60_000 on one
> node and 34_000 on the other. The same sum (94_000) was shown on the
> client side on every periodic "tick" when calling "GetSize" on the cache
> instance
> (https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Cache/ICache.cs#L685).
> 
> 
>  *   Why are there entries missing? Running SELECT Count(*) on the
> Cache with SQLLine reports back 110_000 entries.
>  *   Why are the entries not distributed 50/50 (or nearly 50/50)?
> 
> 
>   1.  On the client, the SQL query invoked on every "tick" returned
> sometimes 110_000 entries, sometimes 60_000 or 34_000. There was no error
> or warning in the client or server log about failing SQL queries.
>  *   In a partitioned cache both servers do a query and the results
> are merged, if I understood correctly. It seems to me that one of the
> servers sometimes returns an empty result set and therefore the client
> gets a too small result set. Question is: why does this happen even
> without a warning on the server nodes about a failing query?
>   2.  In that situation the client is not able to load a specific entry
> from the cache multiple times using TryGet(TK key, out TV value)
> (https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Cache/ICache.cs#L297).
> Those entries definitely are existing in the cache.
>   3.  In that situation on one of both server nodes I get errors that an
> entry could not be loaded (like in 3) but on the affinity-server node!).
> In my understanding the compute jobs shall get executed on the primary
> node for the given key. And this node is not able to load an entry by that
> key (when under heavy CPU pressure)?
> 
> Something is strange here. Any ideas?
> 
> Cheers,
> Dome





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Problem of datastorage after compute finished

[aealexsandrov]

Hi Michael,

As I see from your configuration you are going to have cluster with two
ignite servers and PARTITIONED cache.

You can't choose directly on what node will be stored your cache entities
because ignite will use its own affinity function that will maps keys to
partitions (not nodes).

In this case data from your cache could be stored on both nodes.

What you can to do:

1)Create two caches and setup the node filters for them:

https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/CacheConfiguration.html#setNodeFilter-org.apache.ignite.lang.IgnitePredicate-

2)Ignite can try to give you guarantee that entities calculated on Node A
will be stored on one node and entities calculated on node B will be stored
on another. But there is no guarantee that it will be the same nodes where
it was calculated. setup your own AffinityKey. For example something like
that:

public static class EntityKey {
public EntityKey(String id, long nodeId) {
this.id = id;
this.nodeId = nodeId;
}

private String id;

// Subscriber ID which will be used for affinity.
@AffinityKeyMapped
private long nodeId;

public long getNodeId() {
return nodeId;
}

public String getId() {
return id;
}

}

After that use it as follow:

IgniteCache cache =
ignite.getOrCreateCache(cfg);

cache.putIfAbsent( new EntityKey(hid, 0), monthValues ) //from node
A
cache.putIfAbsent( new EntityKey(hid, 1), monthValues ) //from node
B

Thanks,
Andrei








--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

ignite cluster in AWS - s3 discovery

[Tim Heizer]

I have a node running in AWS launched from the apache ignite ami which runs 
ignite in a docker container. The ignite container runs. However, it does not 
register it's ip in the discovery S3 bucket. Can anyone that has this running 
in AWS let me know what I'm missing here?

I created a public s3 bucket with my config and also created an s3 bucket for 
discovery.

The IAM user created for this has full s3 permissions.

I also have an IAM role that has full s3 permissions and am launching the 
instance with this role.

When launching the instance I provide the following user data to be passed:

IGNITE_CONFIG=http://MY-IGNITE-BUCKET-NAME.s3-website-us-east-1.amazonaws.com/ignite-amazon-config.xml
OPTION_LIBS=ignite-log4j,ignite-aws
ES_BUCKET= MY-DISCOVERY-BUCKET-NAME
AWS_ACCESS_KEY=ABCDEFGHIJKLMOPQRST
AWS_SECRET_KEY=SeMBTApExiaP2Xj+czYUEsWB4k2gJhFi6LfNwoPH
IGNITE_CONFIG=latest


This is the content of my config file:


  

  


  


  

  

  

Intermittent Spikes in Response Time

[Chris Berry]

Greetings,

We've been running a large, high volume, low latency Ignite Compute Grid in
Production for a few months now, and, in general, things are going quite
well.
But we see a handful of large spikes a day in our application (approx. 1 per
hour)
And thus far we've been at a loss as to explain what is causing them.

Of course, we ruled out the usual suspects immediately.
*  Garbage collection (using G1) is excellent -- with few pauses, a max
pause of 100ms, and typical pauses < 40ms.
*  We also see no Host activity that correlates with the Spikes, including
CPU and Network or Disk I/O
*  And we can find no noisy neighbors in AWS (CPU Stolen, etc)
*  We see no evident Thread blocking 

The symptoms are always the same. 
*  It occurs on a handful of Nodes (typically 2 out of 38 Nodes) 
*  We always see ComputeTaskTimeoutCheckedException ERRORs.
*  It results in a handful of failed Requests (Timeouts) to our Clients. 
 *  10 to 30, out of 1000s of concurrent Requests in the Grid
 *  Each Request is for a batch of 100s of "computations" that are
map/reduced onto the Grid.
 *  So. In all, a relatively very small number of computations are
affected (0.00X %) 
*  It is very often the same two Nodes involved in the Spikes!!
 *  We run in AWS, so the Nodes are different for each deployment.

When a Spike occurs 
*  We see nothing odd in the logs.
*  All the Exceptions we see are symptoms of the Spike and not the cause.
*  We did occasionally see some Ignite socketWriteTimeouts, but we increased
the timeout to work around this, and they are gone now.

Our Grid;
*  Has millions of cache entries in 9 separate caches.
*  Has caches that all use the same Affinity key, and thus, all cache access
is local to a given Node, once computation is mapped there.
*  Is predominantly read-only.
*  Has 1 Primary and 3 Backups
*  Allows read access to the Backups for computation.
*  Caches are primed via Kafka streams, using DataStreamers. 
 *  After the initial priming, data is a relative trickle.

So. Finally. My questions;

I strongly suspect that some sort of cache rebalancing, or some such, is
occurring and causing this behavior??
*  Is this logical??
*  How would I validate this??
*  Is there any logging (or Interceptors) that we could enable to track
whether my hunch is correct??
*  We appear to see less Spikes -- with less Backups and less Nodes. Does
that make sense??
*  Is there any tuning (config) that could help eliminate the problem??

Any wisdom that the Mailing List may have would be greatly appreciated.

Thanks much, 
-- Chris 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: How do you configure affinityKey in xml

[ilya.kasnacheev]

Hello!

For that, you can use keyConfiguration property on igniteCache:












It is poorly documented, unfortunately, I've raised submit a ticket about
that:https://issues.apache.org/jira/browse/IGNITE-8253

Regards,




--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Problem of datastorage after compute finished

[Michael Jay]

Hi, all! I am trying to use the computegird of ignite to do some compute job,
but I met a problem.
I started two server nodes(different host) to form a clustergroup. Node_A
was started by eclipse, Node_B was started by ignite.cmd, two nodes had the
same configurations except heap size(Node_A heap_size=25G, Node_B
heap_size=10G).
I totally had 6 jobs(a,b,c,d,e,f) to compute and I expected to store the
computation result where the job was done(for example, job a was executed by
Node_A, then the computation result of job a was stored in Node_A). In my
case, reduce is not necessary, moreover, the computation result doesn't need
to be returned. I just want to split the tasks and store the result after
computation is finished.
Actually, Node_A executed job a,c,e and Node_B executed job b,d,f. However
Node_B didn't store the results of job b,d,f, Node_A stored the result of
job c,e, Node_B stored the result of job a. 
I could't figure out why remote node(Node_B) didn't execut the task of
storing the computation result and Node_A didn't store all the jobs' result
that it dealed with?
Is there something wrong with applying of  computetasksplitadapter is this
case?
Below are my code, config.xml and Node_A's log.(code run in Node_A)
thanks for reply! ComputeTaskSplitExample.java

  
default-config.xml
  
ignite-bcd6a658.log
 
 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Discrepancy between cache.Size() / Visorcmd and SQL query resultset

[Bellenger, Dominique]

Hey Igniters,

I've the following setup (Ignite .NET 2.4): 2 Server nodes, 1 client node doing 
SQL-queries on the cache periodically (every 20 Seconds in my case).
The cache is filled with 110_000 entries from a database, using "LoadCache" 
method. Key is a string representation of a number, nothing fancy here.

Situation: Both server nodes are put under pressure by doing affinity-run 
compute jobs on both nodes, affecting all cache entries (read, change, put 
every entry).

I made the following observations:

  1.  Visorcmd showed that the entries were distributed like 60_000 on one node 
and 34_000 on the other. The same sum (94_000) was shown on the client side on 
every periodic "tick" when calling "GetSize" on the cache instance 
(https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Cache/ICache.cs#L685).


 *   Why are there entries missing? Running SELECT Count(*) on the Cache 
with SQLLine reports back 110_000 entries.
 *   Why are the entries not distributed 50/50 (or nearly 50/50)?


  1.  On the client, the SQL query invoked on every "tick" returned sometimes 
110_000 entries, sometimes 60_000 or 34_000. There was no error or warning in 
the client or server log about failing SQL queries.
 *   In a partitioned cache both servers do a query and the results are 
merged, if I understood correctly. It seems to me that one of the servers 
sometimes returns an empty result set and therefore the client gets a too small 
result set. Question is: why does this happen even without a warning on the 
server nodes about a failing query?
  2.  In that situation the client is not able to load a specific entry from 
the cache multiple times using TryGet(TK key, out TV value) 
(https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Cache/ICache.cs#L297).
 Those entries definitely are existing in the cache.
  3.  In that situation on one of both server nodes I get errors that an entry 
could not be loaded (like in 3) but on the affinity-server node!). In my 
understanding the compute jobs shall get executed on the primary node for the 
given key. And this node is not able to load an entry by that key (when under 
heavy CPU pressure)?

Something is strange here. Any ideas?

Cheers,
Dome

RE: Slow Ignite Cache with multi-nodes

[linrick]

Dear Sam and Nikolai,

My case is similar to this one (Performance with increase in node) .

So, could you tell me how to deal with this problem about decreasing 
performances of cache with multi nodes?

If any idea could be shared with me, I highly appreciate it.

Rick

From: linr...@itri.org.tw [mailto:linr...@itri.org.tw]
Sent: Friday, April 13, 2018 3:23 PM
To: user@ignite.apache.org
Subject: RE: Slow Ignite Cache with multi-nodes


Hi Roman,



I think that my case is similar to this one: 
http://apache-ignite-users.70518.x6.nabble.com/Performance-with-increase-in-node-td9378.html

(Performance with increase in node)



From those discussions, I found the two tips to properly use cache in ignite 
node.

1. Cache has to be warmed up. When the cache is used for the second or third 
time, the speed of write is faster, as shown:

1-th experiment, Put 1 KV data: spend 6,431 milliseconds

2-th experiment, Put 1 KV data: spend 3,603 milliseconds

3-th experiment, Put 1 KV data: spend 3,961 milliseconds

2. With increasing server nodes, it is better to increase the number of client 
nodes.



Here, I do not know reasons about the above tips to accelerate cache.

In addition, if the increased number of client nodes can improve performance of 
cache, how to set the configures between client nodes?

Because I do not know to set these, experiment results about the tip 2 are not 
shown in here.



In order to reproduce my situation, I provided my code to all.



The configure in server node is:

IgniteConfiguration cfg  = new IgniteConfiguration();

cfg.setClientMode(false);  //server

TcpDiscoveryMulticastIpFinder ipFinder = new TcpDiscoveryMulticastIpFinder();

ipFinder.setMulticastGroup("224.1.2.4");

TcpDiscoverySpi spi = new TcpDiscoverySpi();

spi.setIpFinder(ipFinder);

cfg.setDiscoverySpi(spi);



The configures in two client nodes are:

One client:

TcpDiscoveryMulticastIpFinder ipFinder = new TcpDiscoveryMulticastIpFinder();

ipFinder.setMulticastGroup("224.1.2.4");

ipFinder.setAddresses(Arrays.asList("ubuntu7","ubuntu9"));

TcpDiscoverySpi spi = new TcpDiscoverySpi();

spi.setIpFinder(ipFinder);

cfg.setDiscoverySpi(spi);



the other client to write data into cache[igniteCachePut]):

TcpDiscoveryMulticastIpFinder ipFinder = new TcpDiscoveryMulticastIpFinder();

ipFinder.setMulticastGroup("224.1.2.4");

ipFinder.setAddresses(Arrays.asList("ubuntu7","ubuntu9"));

TcpDiscoverySpi spi = new TcpDiscoverySpi();

spi.setIpFinder(ipFinder);

cfg.setDiscoverySpi(spi);



IgniteCache cacheKeyvalue = igniteNode.cache("igniteCachePut");

Int datasize =1;

int expertime = 3;

for (int j = 1; j <= expertime; j++) {

long starttime, endtime;

starttime = System.currentTimeMillis();

for (int i = 1; i <= datasize; i++) {

cacheKeyvalue.put(Integer.toString(i), Integer.toString(i));

}

endtime = System.currentTimeMillis();

System.out.println(j+"-th experiment");

System.out.println("Put " + datasize + " KV data: spend " + (endtime - 
starttime)  + " milliseconds");

}



If you have any idea about this problem, I am looking forward to hearing from 
you.



Thanks



Rick



-Original Message-
From: Roman Guseinov [mailto:ro...@gromtech.ru]
Sent: Tuesday, April 10, 2018 1:56 PM
To: user@ignite.apache.org
Subject: Re: Slow Ignite Cache with multi-nodes



Hi Rick,



It seems that you need to increase clients number to achieve better performance 
when you increase server nodes number. You can try to put data from different 
threads as well.



Also, you can set

CacheConfiguration.setWriteSynchronizationMode(CacheWriteSynchronizationMode.PRIMARY_SYNC).

The default value is FULL_SYNC which means that client node will wait for write 
or commit to complete on all participating remote nodes (primary and

backup) [1].



Performance Tips can be found here [2].



Best Regards,

Roman



[1]

https://apacheignite.readme.io/v1.1/docs/primary-and-backup-copies#section-synchronous-and-asynchronous-backups

[2] https://apacheignite.readme.io/docs/performance-tips







--

Sent from: http://apache-ignite-users.70518.x6.nabble.com/


--
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain 
confidential information. Please do not use or disclose it in any way and 
delete it if you are not the intended recipient.


--
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain 
confidential information. Please do not use or disclose it in any way and 
delete it if you are not the intended recipient.

RE: Slow Ignite Cache with multi-nodes

[linrick]

Hi Roman,



I think that my case is similar to this one: 
http://apache-ignite-users.70518.x6.nabble.com/Performance-with-increase-in-node-td9378.html

(Performance with increase in node)



From those discussions, I found the two tips to properly use cache in ignite 
node.

1. Cache has to be warmed up. When the cache is used for the second or third 
time, the speed of write is faster, as shown:

1-th experiment, Put 1 KV data: spend 6,431 milliseconds

2-th experiment, Put 1 KV data: spend 3,603 milliseconds

3-th experiment, Put 1 KV data: spend 3,961 milliseconds

2. With increasing server nodes, it is better to increase the number of client 
nodes.



Here, I do not know reasons about the above tips to accelerate cache.

In addition, if the increased number of client nodes can improve performance of 
cache, how to set the configures between client nodes?

Because I do not know to set these, experiment results about the tip 2 are not 
shown in here.



In order to reproduce my situation, I provided my code to all.



The configure in server node is:

IgniteConfiguration cfg  = new IgniteConfiguration();

cfg.setClientMode(false);  //server

TcpDiscoveryMulticastIpFinder ipFinder = new TcpDiscoveryMulticastIpFinder();

ipFinder.setMulticastGroup("224.1.2.4");

TcpDiscoverySpi spi = new TcpDiscoverySpi();

spi.setIpFinder(ipFinder);

cfg.setDiscoverySpi(spi);



The configures in two client nodes are:

One client:

TcpDiscoveryMulticastIpFinder ipFinder = new TcpDiscoveryMulticastIpFinder();

ipFinder.setMulticastGroup("224.1.2.4");

ipFinder.setAddresses(Arrays.asList("ubuntu7","ubuntu9"));

TcpDiscoverySpi spi = new TcpDiscoverySpi();

spi.setIpFinder(ipFinder);

cfg.setDiscoverySpi(spi);



the other client to write data into cache[igniteCachePut]):

TcpDiscoveryMulticastIpFinder ipFinder = new TcpDiscoveryMulticastIpFinder();

ipFinder.setMulticastGroup("224.1.2.4");

ipFinder.setAddresses(Arrays.asList("ubuntu7","ubuntu9"));

TcpDiscoverySpi spi = new TcpDiscoverySpi();

spi.setIpFinder(ipFinder);

cfg.setDiscoverySpi(spi);



IgniteCache cacheKeyvalue = igniteNode.cache("igniteCachePut");

Int datasize =1;

int expertime = 3;

for (int j = 1; j <= expertime; j++) {

long starttime, endtime;

starttime = System.currentTimeMillis();

for (int i = 1; i <= datasize; i++) {

cacheKeyvalue.put(Integer.toString(i), Integer.toString(i));

}

endtime = System.currentTimeMillis();

System.out.println(j+"-th experiment");

System.out.println("Put " + datasize + " KV data: spend " + (endtime - 
starttime)  + " milliseconds");

}



If you have any idea about this problem, I am looking forward to hearing from 
you.



Thanks



Rick



-Original Message-
From: Roman Guseinov [mailto:ro...@gromtech.ru]
Sent: Tuesday, April 10, 2018 1:56 PM
To: user@ignite.apache.org
Subject: Re: Slow Ignite Cache with multi-nodes



Hi Rick,



It seems that you need to increase clients number to achieve better performance 
when you increase server nodes number. You can try to put data from different 
threads as well.



Also, you can set

CacheConfiguration.setWriteSynchronizationMode(CacheWriteSynchronizationMode.PRIMARY_SYNC).

The default value is FULL_SYNC which means that client node will wait for write 
or commit to complete on all participating remote nodes (primary and

backup) [1].



Performance Tips can be found here [2].



Best Regards,

Roman



[1]

https://apacheignite.readme.io/v1.1/docs/primary-and-backup-copies#section-synchronous-and-asynchronous-backups

[2] https://apacheignite.readme.io/docs/performance-tips







--

Sent from: http://apache-ignite-users.70518.x6.nabble.com/


--
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain 
confidential information. Please do not use or disclose it in any way and 
delete it if you are not the intended recipient.

How do you configure affinityKey in xml

[hulitao198758]

How do you configure affinityKey in apache ignite and implement the Join
between multiple partition caches after the JDBC client connects to the
cluster?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/