Question on BinaryObject
Hello, Do I understand correctly, that each BinaryObject that is returned by IgniteCache.get() and IgniteCache.getAll() method calls on a local node contains an internal on-heap byte array, and object unmarshalling occurs from that array, and not from off-heap memory?
unsubscribe
> On Jan 21, 2021, at 5:17 PM, akorensh wrote: > > Hi, > Can you actually see what the data distribution of itemid is. > > AffinityKey will direct Ignite to use that specific column (itemid) for > partition mapping. > If the data in itemid is in a narrow range, then all data will be put into > fewer partitions. > This might affect loading times. > > more here: > https://ignite.apache.org/docs/latest/data-modeling/data-partitioning > https://ignite.apache.org/docs/latest/data-modeling/affinity-collocation > > Affinity mapping takes up more memory as various intermediate objects are > created. > Make sure you've allocated sufficient memory > > Can you collect/analyze GC logs to see whether you are running out of > heap. > https://apacheignite.readme.io/docs/jvm-and-system-tuning > > https://apacheignite.readme.io/docs/jvm-and-system-tuning#debugging-memory-usage-issues-and-gc-pauses > > > If you are sure that enough recourses are allocated, and the system still > takes a long time, > add the Ignite Server log, and the GC logs here. > Thanks, Alex > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
There is no property called StartSize in CacheConfiguration
I am reading performance tips on Ignite.Net (https://apacheignite-net.readme.io/docs/performance-tips#section-tune-cache-start-size) and upon "Tune Cache Start Size", there should be a property called "StartSize" in CacheConfiguration. But there is no such property. What should the configuration property for setting initial cache size? Cannot find it on API documentation. Anyone can help? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Fair queue polling policy?
Hello Stan, Have a bit thought about this again. The problem is that I used round robin and populate the distributed queue on node1 and node2 BUT still the queue.take is not equally called from both servers and this means that ignite is artificially increasing network traffic IMO. > It’s probably due to that the first value (when the queue is empty) always has the same key Shouldn't the implementation prefer polling clients that are local to the "put" if the queue is empty? Regards Peter Am 04.12.18 um 19:07 schrieb Peter: > Hello Stan, > > Thanks for your detailed answer on this topic. > > I think you are right that this is no bug and currently I do not see a > problem with this, except that the documentation > <https://apacheignite.readme.io/v2.6/docs/queue-and-set#section-cache-queues-and-load-balancing> > is a bit misleading:/Given this approach, threads on remote nodes will > only start working on the next job when they have completed the > previous one, hence creating ideally balanced system where every node > only takes the number of jobs it can process, and not more. / > > I think without round robin this is not 100% true: "creating ideally > balanced system" > > Allow me a further question as I have speed problems for objects in > the KB-size range. Which overhead can be expected from the distributed > queue? Can I assume roughly the same numbers like when sending these > objects via http (round robin) or can it be several times slower like > I currently observe in my test environment? > > Regards > Peter > > Am 03.12.18 um 19:02 schrieb Stanislav Lukyanov: >> >> I think what you’re talking about isn’t fairness, it’s round-robinness. >> >> You can’t distribute a single piece of work among multiple nodes >> fairly – one gets it and others don’t. >> >> Yes, it could be using different node each time, but it I don’t >> really a use case for that. >> >> >> >> The queue itself isn’t a load balancer implementation, it doesn’t >> even need to care about fairness or anything. >> >> All it need is to implement queue interface efficiently. >> >> >> >> I think I can explain the fact that one node gets the data most of >> the time. >> >> It’s probably due to that the first value (when the queue is empty) >> always has the same key – and always ends up on the same node. >> >> So the behavior is not in that the same client get’s the value – it’s >> in that the same server always stores the first (second, third) value. >> >> When all the servers try to get and remove the same value, the one >> closest to it (i.e. the one storing it) wins. >> >> We probably could randomize the distribution – but it’s going to cost >> us in terms of code complexity and, maybe, performance. >> >> >> >> Overall, I don’t think it’s a bug in Ignite, and we would need a >> solid justification to change the behavior. >> >> >> >> Do you have a use case when a random distribution is important? >> >> >> >> Stan >> >> >> >> *From: *Peter <mailto:graphhop...@gmx.de> >> *Sent: *30 ноября 2018 г. 17:30 >> *To: *user@ignite.apache.org <mailto:user@ignite.apache.org> >> *Subject: *Re: Fair queue polling policy? >> >> >> >> Hello, >> >> >> >> I have found this discussion >> <http://apache-ignite-users.70518.x6.nabble.com/Clearing-a-distributed-queue-hangs-after-taking-down-one-node-td7353.html> >> about the same topic and indeed the example there works and the >> queues poll fair. >> >> >> >> And when I tweak the sleep after put and take, so that the queue >> stays mostly empty all the, I can reproduce the unfair behaviour! >> >> https://github.com/karussell/igniteexample/blob/master/src/main/java/test/IgniteTest.java >> >> >> >> I'm not sure if this is a bug as it should be the responsibility of >> the client to avoid overloading itself. E.g. in my case this happened >> because I allowed too many threads for the tasks on the polling side, >> leading to too frequent polling, which leads to this mostly empty queue. >> >> >> >> But IMO it should be clarified in the documentation as one expects a >> round robin behaviour even for empty queues. And e.g. in low latency >> environments and/or environments with many clients this could make >> problems. I have created an issue about it here: >> https://issues.apache.org/jira/browse/IGNITE-10496 >> >> >> >> Kind Regards
Re: Fair queue polling policy?
Hello Stan, Thanks for your detailed answer on this topic. I think you are right that this is no bug and currently I do not see a problem with this, except that the documentation <https://apacheignite.readme.io/v2.6/docs/queue-and-set#section-cache-queues-and-load-balancing> is a bit misleading:/Given this approach, threads on remote nodes will only start working on the next job when they have completed the previous one, hence creating ideally balanced system where every node only takes the number of jobs it can process, and not more. / I think without round robin this is not 100% true: "creating ideally balanced system" Allow me a further question as I have speed problems for objects in the KB-size range. Which overhead can be expected from the distributed queue? Can I assume roughly the same numbers like when sending these objects via http (round robin) or can it be several times slower like I currently observe in my test environment? Regards Peter Am 03.12.18 um 19:02 schrieb Stanislav Lukyanov: > > I think what you’re talking about isn’t fairness, it’s round-robinness. > > You can’t distribute a single piece of work among multiple nodes > fairly – one gets it and others don’t. > > Yes, it could be using different node each time, but it I don’t really > a use case for that. > > > > The queue itself isn’t a load balancer implementation, it doesn’t even > need to care about fairness or anything. > > All it need is to implement queue interface efficiently. > > > > I think I can explain the fact that one node gets the data most of the > time. > > It’s probably due to that the first value (when the queue is empty) > always has the same key – and always ends up on the same node. > > So the behavior is not in that the same client get’s the value – it’s > in that the same server always stores the first (second, third) value. > > When all the servers try to get and remove the same value, the one > closest to it (i.e. the one storing it) wins. > > We probably could randomize the distribution – but it’s going to cost > us in terms of code complexity and, maybe, performance. > > > > Overall, I don’t think it’s a bug in Ignite, and we would need a solid > justification to change the behavior. > > > > Do you have a use case when a random distribution is important? > > > > Stan > > > > *From: *Peter <mailto:graphhop...@gmx.de> > *Sent: *30 ноября 2018 г. 17:30 > *To: *user@ignite.apache.org <mailto:user@ignite.apache.org> > *Subject: *Re: Fair queue polling policy? > > > > Hello, > > > > I have found this discussion > <http://apache-ignite-users.70518.x6.nabble.com/Clearing-a-distributed-queue-hangs-after-taking-down-one-node-td7353.html> > about the same topic and indeed the example there works and the queues > poll fair. > > > > And when I tweak the sleep after put and take, so that the queue stays > mostly empty all the, I can reproduce the unfair behaviour! > > https://github.com/karussell/igniteexample/blob/master/src/main/java/test/IgniteTest.java > > > > I'm not sure if this is a bug as it should be the responsibility of > the client to avoid overloading itself. E.g. in my case this happened > because I allowed too many threads for the tasks on the polling side, > leading to too frequent polling, which leads to this mostly empty queue. > > > > But IMO it should be clarified in the documentation as one expects a > round robin behaviour even for empty queues. And e.g. in low latency > environments and/or environments with many clients this could make > problems. I have created an issue about it here: > https://issues.apache.org/jira/browse/IGNITE-10496 > > > > Kind Regards > Peter > > > > Am 30.11.18 um 01:44 schrieb Peter: > > Hello, > > My aim is a queue for load balancing that is described in the > documentation > > <https://apacheignite.readme.io/v2.6/docs/queue-and-set#section-cache-queues-and-load-balancing>: > create an "ideally balanced system where every node only takes the > number of jobs it can process, and not more." > > I'm using jdk8 and ignite 2.6.0. I have successfully set up a two > node ignite cluster where node1 has same CPU count (8) and same > RAM as node2 but slightly slower CPU (virtual vs. dedicated). I > created one unbounded queue in this system (no collection > configuration, also no config for cluster except > TcpDiscoveryVmIpFinder). > > I call queue.put on both nodes at an equal rate and have one > non-ignite-thread per node that does "queue.take()" and what I > expect is t
Re: Fair queue polling policy?
Hello, I have found this discussion <http://apache-ignite-users.70518.x6.nabble.com/Clearing-a-distributed-queue-hangs-after-taking-down-one-node-td7353.html> about the same topic and indeed the example there works and the queues poll fair. And when I tweak the sleep after put and take, so that the queue stays mostly empty all the, I can reproduce the unfair behaviour! https://github.com/karussell/igniteexample/blob/master/src/main/java/test/IgniteTest.java I'm not sure if this is a bug as it should be the responsibility of the client to avoid overloading itself. E.g. in my case this happened because I allowed too many threads for the tasks on the polling side, leading to too frequent polling, which leads to this mostly empty queue. But IMO it should be clarified in the documentation as one expects a round robin behaviour even for empty queues. And e.g. in low latency environments and/or environments with many clients this could make problems. I have created an issue about it here: https://issues.apache.org/jira/browse/IGNITE-10496 Kind Regards Peter Am 30.11.18 um 01:44 schrieb Peter: > > Hello, > > My aim is a queue for load balancing that is described in the > documentation > <https://apacheignite.readme.io/v2.6/docs/queue-and-set#section-cache-queues-and-load-balancing>: > create an "ideally balanced system where every node only takes the > number of jobs it can process, and not more." > > I'm using jdk8 and ignite 2.6.0. I have successfully set up a two node > ignite cluster where node1 has same CPU count (8) and same RAM as > node2 but slightly slower CPU (virtual vs. dedicated). I created one > unbounded queue in this system (no collection configuration, also no > config for cluster except TcpDiscoveryVmIpFinder). > > I call queue.put on both nodes at an equal rate and have one > non-ignite-thread per node that does "queue.take()" and what I expect > is that both machines go equally fast into the 100% CPU usage as both > machines poll at their best frequency. But what I observe is that the > slower node (node1) gets approx. 5 times more items via queue.take > than node2. This leads to 10% CPU usage on node2 and 100% CPU usage on > node1 and I never had the case where it was equal. > > What could be the reason? Is there a fair polling configuration or > some anti-affine? Or is it required to do queue.take() inside a > Runnable submitted via ignite.compute().something? > > I also played with CollectionConfiguration.setCacheMode but the > problem persists. Any pointers are appreciated. > > Kind Regards > Peter >
Fair queue polling policy?
Hello, My aim is a queue for load balancing that is described in the documentation <https://apacheignite.readme.io/v2.6/docs/queue-and-set#section-cache-queues-and-load-balancing>: create an "ideally balanced system where every node only takes the number of jobs it can process, and not more." I'm using jdk8 and ignite 2.6.0. I have successfully set up a two node ignite cluster where node1 has same CPU count (8) and same RAM as node2 but slightly slower CPU (virtual vs. dedicated). I created one unbounded queue in this system (no collection configuration, also no config for cluster except TcpDiscoveryVmIpFinder). I call queue.put on both nodes at an equal rate and have one non-ignite-thread per node that does "queue.take()" and what I expect is that both machines go equally fast into the 100% CPU usage as both machines poll at their best frequency. But what I observe is that the slower node (node1) gets approx. 5 times more items via queue.take than node2. This leads to 10% CPU usage on node2 and 100% CPU usage on node1 and I never had the case where it was equal. What could be the reason? Is there a fair polling configuration or some anti-affine? Or is it required to do queue.take() inside a Runnable submitted via ignite.compute().something? I also played with CollectionConfiguration.setCacheMode but the problem persists. Any pointers are appreciated. Kind Regards Peter
Re: Speed Expectations for Ignite Queue
To answer my own question: the speed seems to be expected and lays in the same range like e.g. redis+redisson Peter Am 26.11.18 um 16:32 schrieb Peter: > > Hello, > > I'm currently trying Apache Ignite and love the concept. > > I have created a simple example of what I'm trying to achieve > (producer&consumer): > > https://github.com/karussell/igniteexample/blob/master/src/main/java/test/MyIgnite.java > > My assumption is that the default settings are tuned to get a setup > that is okayish-fast and also without persistence and so comparing the > speed to LinkedBlockingQueue shouldn't be that unfair. My expectation > here is that ignite is 10-50x slower due to serialization overhead > still happening for localhost. > > But it seems that ignite queue is 100-500 times slower. What am I > doing wrong here or did I simply have too optimistic expectations? > Maybe non-default settings like here > <http://apache-ignite-users.70518.x6.nabble.com/Impact-of-connectionsPerNode-and-pairedConnection-td18996.html> > would be better suited? See also MyIgniteSingle1.java where I also > warm up everything before measuring the speed. I also tried various > different JVM settings > <https://apacheignite.readme.io/docs/jvm-and-system-tuning> without > success. > > Kind Regards > Peter > > PS: I cross-posted this a few days ago on SO: > https://stackoverflow.com/q/53454232/194609 >
Speed Expectations for Ignite Queue
Hello, I'm currently trying Apache Ignite and love the concept. I have created a simple example of what I'm trying to achieve (producer&consumer): https://github.com/karussell/igniteexample/blob/master/src/main/java/test/MyIgnite.java My assumption is that the default settings are tuned to get a setup that is okayish-fast and also without persistence and so comparing the speed to LinkedBlockingQueue shouldn't be that unfair. My expectation here is that ignite is 10-50x slower due to serialization overhead still happening for localhost. But it seems that ignite queue is 100-500 times slower. What am I doing wrong here or did I simply have too optimistic expectations? Maybe non-default settings like here <http://apache-ignite-users.70518.x6.nabble.com/Impact-of-connectionsPerNode-and-pairedConnection-td18996.html> would be better suited? See also MyIgniteSingle1.java where I also warm up everything before measuring the speed. I also tried various different JVM settings <https://apacheignite.readme.io/docs/jvm-and-system-tuning> without success. Kind Regards Peter PS: I cross-posted this a few days ago on SO: https://stackoverflow.com/q/53454232/194609
Re: Get Field Names In Select Query
If you don't do GetAll() and just do Query(new SqlFieldsQuery...), the FieldsQueryCursor returned will have the column count and name of your result set. Hope this help. On Tuesday, November 20, 2018, 8:43:22 PM EST, siva wrote: Hi, How to get the field names in select query? I am using sql api to create tables (Not based on model class because table and its fields need to create dynamically and its fields more than 100). Let Assume i want to create a person table it contains more than 100 fields and i am creating like bellow with out model class / cache.query(new SqlFieldsQuery( "CREATE TABLE Persons (id LONG PRIMARY KEY, name VARCHAR,jurney date,,) WITH "template=replicated,CACHE_NAME=Persons)).getAll()/ Query: --- Get All The Person Details Based On Person Id And Journey Date If i use SqlFields query i am not able to get the field names along with the values. If i use SqlQuery i need to mention model class -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Ignite.Net - Defining SQL Schema without using QuerySqlField custom attribute
Yes. I just found out the hard way yesterday by debugging through the
Ignite.Net source code and reached the same understanding. Thank you.
On Wednesday, November 21, 2018, 6:12:16 AM EST, Pavel Tupitsyn
wrote:
There is a subtle issue with DateTime and SQL [1]
If you always use UTC in Ignite (which you should), the proper thing to do
is:var igniteCfg = new IgniteConfiguration
{
BinaryConfiguration = new BinaryConfiguration
{
Serializer = new BinaryReflectiveSerializer
{
ForceTimestamp = true
}
}
};
var ignite = Ignition.Start(igniteCfg);
This way SQL-compatible format is enforced, and non-UTC values will cause an
exception.[1]
https://apacheignite-net.readme.io/docs/platform-interoperability#section-type-compatibility
On Tue, Nov 20, 2018 at 12:06 AM Peter Sham wrote:
Sure. Hope this won't get too long and will still be readable from e-mail, and
thank you for helping. Really appreciate it.
using System;using System.Collections.Generic;using System.Linq;using
System.Text;using System.Threading.Tasks;using Apache.Ignite.Core;using
Apache.Ignite.Core.Cache;using Apache.Ignite.Core.Cache.Query;using
Apache.Ignite.Core.Cache.Configuration;
namespace SimpleCase{ class SimpleCaseDemoOnIssue { const string
SAMPLE_CACHE_NAME = @"simple_case_demo"; const string SAMPLE_TABLE_NAME =
@"t_sample_entity";
static void Main(string[] args) { var ignite = Ignition.Start();
Console.WriteLine("This is some simple code demonstrating the issue involving
.Net DateTime type"); Console.WriteLine("Sample starts ...");
Console.WriteLine();
var cache = ignite.GetOrCreateCache(new
CacheConfiguration(SAMPLE_CACHE_NAME) { SqlSchema = "PUBLIC" });
Console.WriteLine("Created cache " + SAMPLE_CACHE_NAME);
var createTalbeSql = $"create table if not exists {SAMPLE_TABLE_NAME}
(entityid int, textfield varchar, datefield timestamp, primary key (entityid))
" + $"with \"key_type=int, value_type={typeof(SampleEntity).FullName}\"";
Console.WriteLine("Creating table ..."); Console.WriteLine(createTalbeSql);
Console.WriteLine();
cache.Query(new SqlFieldsQuery(createTalbeSql)).GetAll();
Console.WriteLine($"Call ignite.GetCache(\"SQL_PUBLIC_{SAMPLE_TABLE_NAME.ToUpper()}\")");
Console.WriteLine(); var entityCache = ignite.GetCache($"SQL_PUBLIC_{SAMPLE_TABLE_NAME.ToUpper()}"); var cfg =
entityCache.GetConfiguration();
Console.WriteLine($"Printing Cache configuration of {cfg.Name}");
Console.WriteLine(); foreach(var eachEntity in cfg.QueryEntities) {
Console.WriteLine($"QueryEntity: TableName = {eachEntity.TableName} /
ValueTypeName = {eachEntity.ValueTypeName}");
Console.WriteLine(string.Format("QueryField: {0,-15} {1,-15} {2,-15}", "Name",
"FieldType", "FieldTypeNmae")); foreach (var eachField in eachEntity.Fields) {
Console.WriteLine(string.Format(" {0,-15} {1,-15} {2,-15}",
eachField.Name, eachField.FieldType.FullName, eachField.FieldTypeName)); } }
Console.WriteLine();
Console.WriteLine("Going to put data to cache ..."); Console.WriteLine(); var
entity0 = new SampleEntity(); entityCache.Put(entity0.EntityId, entity0);
var entity1 = entityCache.Get(entity0.EntityId); Console.WriteLine("Data put
is ... " + entity1); Console.WriteLine();
var sql1 = $"select t.textfield from {SAMPLE_TABLE_NAME} t";
Console.WriteLine("Executing this ==> " + sql1); Console.WriteLine("which
should succeed ... "); try { var result1 = entityCache.Query(new
SqlFieldsQuery(sql1)).GetAll().FirstOrDefault(); Console.WriteLine("Result =
{0}", result1 == null ? "N/A" : result1[0].ToString()); } catch (Exception ex)
{ Console.WriteLine($"Thrown {ex.GetType().FullName}"); } Console.WriteLine();
var sql2 = $"select t.datefield from {SAMPLE_TABLE_NAME} t";
Console.WriteLine("Executing this ==> " + sql2); Console.WriteLine("which
should failed ... "); try { var result2 = entityCache.Query(new
SqlFieldsQuery(sql2)).GetAll().FirstOrDefault(); Console.WriteLine("Result =
{0}", result2 == null ? "N/A" : result2[0].ToString()); } catch (Exception ex)
{ Console.WriteLine($"Thrown {ex.GetType().FullName}"); } Console.WriteLine();
var sql3 = $"update {SAMPLE_TABLE_NAME} set datefield = sysdate where entityid
= {entity1.EntityId}"; Console.WriteLine("Executing this ==> " + sql3);
Console.WriteLine("which should succeed ... "); try { var result3 =
entityCache.Query(new SqlFieldsQuery(sql3)).GetAll(); Console.WriteLine("Result
returned = " + result3.First()[0]); } catch (Exception ex) {
Console.WriteLine($"Thrown {ex.GetType().FullName}"); } Console.WriteLine();
Re: How to get the column names(or fieldsNames) of existing ignite sql table
From what I understand, the first cache created by getOrCreate, where you will
be using to run the SQLFieldsQuery to create your table, is just a dummy. So
name it as anything other than "Persons". Yes. It may sound counter
intuitive. I'm still learning so may learn the reason behind it later.
Hope this help.
On Tuesday, November 20, 2018, 1:51:37 AM EST, siva
wrote:
Hi ,
Thank You for Reply,
*And for question 2, I think, yes, from my learning, SQL Create Table always
create another cache with default naming like SQL_PUBLIC_
. But according to manual, you can override the name by supplying options
after "with".*
IgniteCache cache = ignite.getOrCreateCache(new
CacheConfiguration<>().setSqlSchema("PUBLIC").setName("Persons").setSqlEscapeAll(true));
If i give same cacheName as mentioned in the above configuration in "With"
cluse getting exception
cacheName "Persons" already created.
cache.query(new SqlFieldsQuery(
"CREATE TABLE IF NOT Exists Persons(id LONG PRIMARY KEY,
name VARCHAR,dojurney date) WITH \"template=replicated,CACHE_NAME=Persons
,affinity_key=id\"")).getAll();
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Ignite.Net - Defining SQL Schema without using QuerySqlField custom attribute
Sure. Hope this won't get too long and will still be readable from e-mail, and
thank you for helping. Really appreciate it.
using System;using System.Collections.Generic;using System.Linq;using
System.Text;using System.Threading.Tasks;using Apache.Ignite.Core;using
Apache.Ignite.Core.Cache;using Apache.Ignite.Core.Cache.Query;using
Apache.Ignite.Core.Cache.Configuration;
namespace SimpleCase{ class SimpleCaseDemoOnIssue { const string
SAMPLE_CACHE_NAME = @"simple_case_demo"; const string SAMPLE_TABLE_NAME =
@"t_sample_entity";
static void Main(string[] args) { var ignite = Ignition.Start();
Console.WriteLine("This is some simple code demonstrating the issue involving
.Net DateTime type"); Console.WriteLine("Sample starts ...");
Console.WriteLine();
var cache = ignite.GetOrCreateCache(new
CacheConfiguration(SAMPLE_CACHE_NAME) { SqlSchema = "PUBLIC" });
Console.WriteLine("Created cache " + SAMPLE_CACHE_NAME);
var createTalbeSql = $"create table if not exists {SAMPLE_TABLE_NAME}
(entityid int, textfield varchar, datefield timestamp, primary key (entityid))
" + $"with \"key_type=int, value_type={typeof(SampleEntity).FullName}\"";
Console.WriteLine("Creating table ..."); Console.WriteLine(createTalbeSql);
Console.WriteLine();
cache.Query(new SqlFieldsQuery(createTalbeSql)).GetAll();
Console.WriteLine($"Call ignite.GetCache(\"SQL_PUBLIC_{SAMPLE_TABLE_NAME.ToUpper()}\")");
Console.WriteLine(); var entityCache = ignite.GetCache($"SQL_PUBLIC_{SAMPLE_TABLE_NAME.ToUpper()}"); var cfg =
entityCache.GetConfiguration();
Console.WriteLine($"Printing Cache configuration of {cfg.Name}");
Console.WriteLine(); foreach(var eachEntity in cfg.QueryEntities) {
Console.WriteLine($"QueryEntity: TableName = {eachEntity.TableName} /
ValueTypeName = {eachEntity.ValueTypeName}");
Console.WriteLine(string.Format("QueryField: {0,-15} {1,-15} {2,-15}", "Name",
"FieldType", "FieldTypeNmae")); foreach (var eachField in eachEntity.Fields) {
Console.WriteLine(string.Format(" {0,-15} {1,-15} {2,-15}",
eachField.Name, eachField.FieldType.FullName, eachField.FieldTypeName)); } }
Console.WriteLine();
Console.WriteLine("Going to put data to cache ..."); Console.WriteLine(); var
entity0 = new SampleEntity(); entityCache.Put(entity0.EntityId, entity0);
var entity1 = entityCache.Get(entity0.EntityId); Console.WriteLine("Data put
is ... " + entity1); Console.WriteLine();
var sql1 = $"select t.textfield from {SAMPLE_TABLE_NAME} t";
Console.WriteLine("Executing this ==> " + sql1); Console.WriteLine("which
should succeed ... "); try { var result1 = entityCache.Query(new
SqlFieldsQuery(sql1)).GetAll().FirstOrDefault(); Console.WriteLine("Result =
{0}", result1 == null ? "N/A" : result1[0].ToString()); } catch (Exception ex)
{ Console.WriteLine($"Thrown {ex.GetType().FullName}"); } Console.WriteLine();
var sql2 = $"select t.datefield from {SAMPLE_TABLE_NAME} t";
Console.WriteLine("Executing this ==> " + sql2); Console.WriteLine("which
should failed ... "); try { var result2 = entityCache.Query(new
SqlFieldsQuery(sql2)).GetAll().FirstOrDefault(); Console.WriteLine("Result =
{0}", result2 == null ? "N/A" : result2[0].ToString()); } catch (Exception ex)
{ Console.WriteLine($"Thrown {ex.GetType().FullName}"); } Console.WriteLine();
var sql3 = $"update {SAMPLE_TABLE_NAME} set datefield = sysdate where entityid
= {entity1.EntityId}"; Console.WriteLine("Executing this ==> " + sql3);
Console.WriteLine("which should succeed ... "); try { var result3 =
entityCache.Query(new SqlFieldsQuery(sql3)).GetAll(); Console.WriteLine("Result
returned = " + result3.First()[0]); } catch (Exception ex) {
Console.WriteLine($"Thrown {ex.GetType().FullName}"); } Console.WriteLine();
Console.WriteLine("Executing again ==> " + sql2); Console.WriteLine("which
should succeed ... "); try { var result4 = entityCache.Query(new
SqlFieldsQuery(sql2)).GetAll().FirstOrDefault(); Console.WriteLine("Result =
{0}", result4 == null ? "N/A" : result4[0].ToString()); } catch (Exception ex)
{ Console.WriteLine($"Thrown {ex.GetType().FullName}"); } Console.WriteLine();
Ignition.Stop(null, true); Console.WriteLine("Sample stopped ..."); } }
class SampleEntity { public SampleEntity() { // just setup with dummy value
for testing. this.EntityId = 1; this.TextField = "Dummy data for 1";
this.DateField = DateTime.Now.ToUniversalTime(); } public int EntityId { get;
set; } public string TextField { get; set; } public DateTime DateField { get;
set; } public override string ToString() { return $"EntityId = {this.EntityId};
TextField = {this.TextField}; DateField = {this.DateField.ToString()}"; } }}
Re: How to get the column names(or fieldsNames) of existing ignite sql table
Hello, I don't think you can get all the tables created in a cache by SQL. I'm learning this stuff and hit the same questions and figure I can find it out by the following steps in code (I'm coding c# and don't know if the methods apply in Java). Get all cache names from IIgnite by GetCachenames() Loop through all the caches in getting them one by one by IIgnite.GetCache() Get the cache configuration by GetConfiguration on IICache Loop through QueryEntities on cache configuration Each QueryEntity would hold the table name, even with those created by SQL. In fact, within QueryEntity you will have Fields which are the columns. And for question 2, I think, yes, from my learning, SQL Create Table always create another cache with default naming like SQL_PUBLIC_. But according to manual, you can override the name by supplying options after "with". Happy Coding! Peter Sham sham.pe...@gmail.com (https://link.getmailspring.com/link/1542461644.local-9c4bedcc-4679-v1.5.2-31660...@getmailspring.com/0?redirect=mailto%3Asham.peter%40gmail.com&recipient=dXNlckBpZ25pdGUuYXBhY2hlLm9yZw%3D%3D) On Nov 17 2018, at 5:42 am, Dmitry Lazurkin wrote: > > Hello. > On 17.11.2018 13:25, siva wrote: > > Quetions: > > === > > 1.How to get the existing table columnNames ? > > > > i am trying to use this query but its throwing exception > > *select COLUMN_NAME from INFORMATION_SCHEMA.COLUMNS where > > TABLE_NAME='Person'* > > > You need query with setLocal(true). I don't known how to do this with > thin client. >
Re: Ignite.Net - Defining SQL Schema without using QuerySqlField custom attribute
Additional findings. Actually the SQL schema defined by running sql create table works fine except for the date field. So I suspect the error message "BinaryInvalidTypeException: Unknown pair [platformId=0, typeId=-1854586790]" would probably mean the framework cannot find a mapping between Java timestamp to .Net DateTime. Any help from anyone is most welcome! -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Ignite.Net - Defining SQL Schema without using QuerySqlField custom attribute
Hello, I’m trying to learn Ignite.Net and has been following examples bundled with source or binary distribution. However, when I try to define SQL Schema that will match an object either by sql create table statement or using QueryEntity in cache configuration, without resorting to QuerySqlFieldAttribute, I kept hitting an exception which said class org.apache.ignite.binary.BinaryInvalidTypeException: Unknown pair [platformId=0, typeId=-1854586790]"; SQL statement … Does anyone has an example that showcase how to define SQL Schema for an object without using custom attribute? Thank you very much.
Re: Ignite RPM Package Installation error: Failed dependencies: java-1.8.0 is needed by apache-ignite-2.4.0-1.noarch
Bhaskar, ignitevisorcmd.sh currently resides in /usr/share/docs/apache-ignite/bin directory (as an example). Not sure how to correctly run it - I guess it should be either copied to /usr/share/apache-ignite/bin or run with defined IGNITE_HOME env variable. On Fri, 15 Jun 2018 at 01:24, bhaskar wrote: > Thanks Petr, > I could start Ignite in service mode not able to find ignitevisorcmd.sh to > see topology. What is the location of ignitevisorcmd.sh in Ignite Service > mode? > Thanks > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: Ignite RPM Package Installation error: Failed dependencies: java-1.8.0 is needed by apache-ignite-2.4.0-1.noarch
Which Linux do you have? Currently packages are designed to be compatible with CentOS and RHEL. To satisfy dependencies, any rpm package that provides “java-1.8.0” should be installed as well (java-1.8.0-openjdk for instance). On Wed, 13 Jun 2018 at 01:42, bhaskar wrote: > I am trying to Install Ignite using RPG package, downloaded > apache-ignite-2.4.0-1.noarch.rpm from > https://www.apache.org/dist/ignite/rpm. > > Getting Java dependency error but JDK is already instaled, what is missing > here? > > # rpm -Uvh apache-ignite-2.4.0-1.noarch.rpm > warning: apache-ignite-2.4.0-1.noarch.rpm: Header V4 RSA/SHA1 Signature, > key > ID f67fe6f2: NOKEY > error: Failed dependencies: > java-1.8.0 is needed by apache-ignite-2.4.0-1.noarch > # echo $JAVA_HOME > /etc/jdk1.8.0_121 > > Thanks > Bhaskar > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: Agent not able to connect
Humphrey, AFAIK, Web Console Standalone is deliberately designed to have self-contained Web Agent. Can you try separate Web Console docker image from experimental nightly build? [1] [1] https://ci.ignite.apache.org/viewLog.html?buildId=1320479&buildTypeId=Releases_NightlyRelease_ApacheIgniteNightlyRelease3AssembleDockerImageIgnite8526&tab=artifacts&guest=1 On Wed, 30 May 2018 at 19:52, Humphrey wrote: > Looks like it can't connect to the webconsole as the webconsole is only > listening to localhost: > > Start listening on 127.0.0.1:3000 > > How can we change this so that the agents (which have different IP) in the > cluster are able to communicate with the webconsole? > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: hasOffHeapPointer
Hi Andrey, thank you for your answer! I've observed it the past few days and it happens quite randomly. I can't really interpret the answer, because I haven't configured a AccessedEvictionPolicy. Do you mean that the stored entry has the same hash-code and therefore it doesn't get replaced? Kind regards, Peter 2017-03-08 14:08 GMT+01:00 Andrey Mashenkov : > Hi Peter, > > I think the message is not relevant. > It means, Entry had been load from Offhead earlier was evicted to Offheap > back (as AccessedEvictionPolicy is configured) without changes. So, there > is no need to rewrite Offheap data. > You shouldn't bother about this. > > On Sat, Mar 4, 2017 at 2:47 PM, Peter Schmitt > wrote: > >> Hi Andrey, >> >> see https://github.com/ps4os/ignite_offheap_test/blob/master >> /src/main/java/demo/RunIgniteTester.java#L83 >> >> Kind regards, >> Peter >> >> >> >> 2017-03-03 13:35 GMT+01:00 Andrey Mashenkov : >> >>> Hi Peter, >>> >>> It looks like offheap entry was evicted from cache and it won't to be >>> swapped by some reason. >>> Would you please share cache configuration? >>> >>> On Fri, Mar 3, 2017 at 2:59 AM, Peter Schmitt < >>> peter.schmitt@gmail.com> wrote: >>> >>>> Hello Ignite-Community! >>>> >>>> All our Ignite caches are offheap. >>>> Now I've found the following entry in the logs: >>>> "Value did not change, skip write swap entry..." >>>> >>>> Checking the source-code I can see that it can just happen in >>>> case hasOffHeapPointer returns true. What does that mean? We just have >>>> "soft references" between caches. In our case cache-entries don't have >>>> references to entries in other caches via a reference-variable pointing to >>>> those entries. Instead we store the key (in most cases a string) of the >>>> other cache-entry and do a lookup (once needed). >>>> >>>> Any hint is appreciated, >>>> Peter >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Andrey V. Mashenkov >>> >> >> > > > -- > Best regards, > Andrey V. Mashenkov >
Re: hasOffHeapPointer
Hi Andrey, see https://github.com/ps4os/ignite_offheap_test/blob/master/src/main/java/demo/RunIgniteTester.java#L83 Kind regards, Peter 2017-03-03 13:35 GMT+01:00 Andrey Mashenkov : > Hi Peter, > > It looks like offheap entry was evicted from cache and it won't to be > swapped by some reason. > Would you please share cache configuration? > > On Fri, Mar 3, 2017 at 2:59 AM, Peter Schmitt > wrote: > >> Hello Ignite-Community! >> >> All our Ignite caches are offheap. >> Now I've found the following entry in the logs: >> "Value did not change, skip write swap entry..." >> >> Checking the source-code I can see that it can just happen in >> case hasOffHeapPointer returns true. What does that mean? We just have >> "soft references" between caches. In our case cache-entries don't have >> references to entries in other caches via a reference-variable pointing to >> those entries. Instead we store the key (in most cases a string) of the >> other cache-entry and do a lookup (once needed). >> >> Any hint is appreciated, >> Peter >> > > > > -- > Best regards, > Andrey V. Mashenkov >
hasOffHeapPointer
Hello Ignite-Community! All our Ignite caches are offheap. Now I've found the following entry in the logs: "Value did not change, skip write swap entry..." Checking the source-code I can see that it can just happen in case hasOffHeapPointer returns true. What does that mean? We just have "soft references" between caches. In our case cache-entries don't have references to entries in other caches via a reference-variable pointing to those entries. Instead we store the key (in most cases a string) of the other cache-entry and do a lookup (once needed). Any hint is appreciated, Peter
Re: Whole cache-entries in log-files found
Hi Val, thank you for the answer! Kind Regards, Peter 2017-03-02 23:31 GMT+01:00 vkulichenko : > Hi Peter, > > Starting with 1.9 (which is about to be released) it will be possible to > avoid key-value printout by setting this system property: > > -DIGNITE_TO_STRING_INCLUDE_SENSITIVE=true > > -Val > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/Whole-cache-entries-in-log-files- > found-tp10999p11003.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Whole cache-entries in log-files found
Hello Ignite-Community! I saw that Ignite sometimes logs whole cache-entries. In addition to the whole content of an entry, such log entries contain e.g. Ignite-details like extras=GridCachedObsoleteEntryExtras and messages like "Value did not change, skip write swap entry". Why does Ignite create such log-entries which consist of the cache-entry-content and some Ignite-Metadata? How can I disable it? Any hint is appreciated, Peter
Re: OFFHEAP_TIERED and memory fragmentation
Hi Alexey, I see. That sounds reasonable on that level (and is something different). What is your plan to limit the overhead/impact of detecting and moving around such small chunks? Kind regards, Peter 2017-02-03 14:52 GMT+01:00 Alexey Goncharuk : > Peter, > > A page is a minimal entity that is allowed to be moved on OS level. If I > have a chunk of memory allocated in the middle of a page, OS won't be able > to move it during defragmentation (at least this is how things worked last > time I checked). In the new approach, we are able to move this chunk within > the page, this is the key difference compared to the old off-heap approach. > > Note, that fine-grained per-entry locking does not imply a byte array per > entry. We will still have our old GridCacheMapEntry object, but it will be > created only during a cache read or update, and will be GC-ed immediately > after cache operation completes. A value itself, on the other hand, will be > stored off-heap. Your measurements confirm that pure off-heap cache > outperforms both options for on-heap caches in terms of GC, so I do not see > any problems here. > > Thanks, > Alexey > > 2017-01-26 23:23 GMT+03:00 Peter Schmitt : > >> Hi Alexey, >> >> a modern OS won't give you a physical address. Instead you get virtual >> memory which allows the OS to support features like defragmentation. >> "fine-grained per-entry" sounds like a byte-array for every entry. >> We tested something like that and the result is again higher GC pauses. >> In our case a FGC with off-heap caches takes e.g. up to 1s. >> With the same data and using on-heap caches it takes up to 25s. >> With a byte-array per entry we get about 4s for a FGC. >> With some optimizations you might get down a bit, however, in view of the >> FGC time I fear that such an approach causes a significant impact for >> applications which need to keep huge caches. >> >> Kind regards, >> Peter >> >> >> >> 2017-01-26 15:57 GMT+01:00 Alexey Goncharuk : >> >>> Hi Peter, >>> >>> Leaving defragmentation to Ignite is one of the reasons we are trying >>> PageMemory approach. In Ignite 1.x we basically use OS memory allocator to >>> place a value off-heap. Once the OS has given us a pointer, the memory >>> cannot be moved around unless we free this region, thus the fragmentation. >>> On the other hand, with PageMemory approach we can define the page layout >>> ourselves and, given fine-grained per-entry locking, move values around in >>> memory. This makes memory management more complicated and usually defines >>> some restrictions on the data structures, but we expect this will give us >>> more control over the data. >>> >>> For example, one of the tricks we can do in the future is cluster-wide >>> cache snapshots: we simply dump the continuous region of memory on disk and >>> get a node-local caches snapshot. This is impossible to do using current >>> off-heap approach. >>> >>> --AG >>> >>> 2017-01-25 12:32 GMT+03:00 Peter Schmitt : >>> >>>> Hi Val, >>>> >>>> fair enough :-) >>>> However, in the source-code it looks like "Flexible and precise >>>> per-cache memory limit" is supported already. >>>> At least each GridUnsafeMemory instance (in each GridCacheContext) >>>> receives the value from CacheConfiguration.getOffHeapMaxMemory). >>>> I haven't debugged it, but the instances are created per cache. >>>> >>>> Furthermore, I'm not sure about the memory-page concept, because you >>>> would get pages on top of pages (used by a modern OS). >>>> Sounds like even more fragmentation and in this case Ignite would need >>>> to do the defragmentation. >>>> >>>> Kind regards, >>>> Peter >>>> >>>> >>>> >>>> 2017-01-25 1:56 GMT+01:00 vkulichenko : >>>> >>>>> I don't think I will be able to explain better than it's done in the >>>>> ticket >>>>> :) Current approach is naive and not always effective for multiple >>>>> reasons. >>>>> >>>>> -Val >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: http://apache-ignite-users.705 >>>>> 18.x6.nabble.com/OFFHEAP-TIERED-and-memory-fragmentation-tp1 >>>>> 0218p10235.html >>>>> Sent from the Apache Ignite Users mailing list archive at Nabble.com. >>>>> >>>> >>>> >>> >> >
Re: OFFHEAP_TIERED and memory fragmentation
Hi Alexey, a modern OS won't give you a physical address. Instead you get virtual memory which allows the OS to support features like defragmentation. "fine-grained per-entry" sounds like a byte-array for every entry. We tested something like that and the result is again higher GC pauses. In our case a FGC with off-heap caches takes e.g. up to 1s. With the same data and using on-heap caches it takes up to 25s. With a byte-array per entry we get about 4s for a FGC. With some optimizations you might get down a bit, however, in view of the FGC time I fear that such an approach causes a significant impact for applications which need to keep huge caches. Kind regards, Peter 2017-01-26 15:57 GMT+01:00 Alexey Goncharuk : > Hi Peter, > > Leaving defragmentation to Ignite is one of the reasons we are trying > PageMemory approach. In Ignite 1.x we basically use OS memory allocator to > place a value off-heap. Once the OS has given us a pointer, the memory > cannot be moved around unless we free this region, thus the fragmentation. > On the other hand, with PageMemory approach we can define the page layout > ourselves and, given fine-grained per-entry locking, move values around in > memory. This makes memory management more complicated and usually defines > some restrictions on the data structures, but we expect this will give us > more control over the data. > > For example, one of the tricks we can do in the future is cluster-wide > cache snapshots: we simply dump the continuous region of memory on disk and > get a node-local caches snapshot. This is impossible to do using current > off-heap approach. > > --AG > > 2017-01-25 12:32 GMT+03:00 Peter Schmitt : > >> Hi Val, >> >> fair enough :-) >> However, in the source-code it looks like "Flexible and precise >> per-cache memory limit" is supported already. >> At least each GridUnsafeMemory instance (in each GridCacheContext) >> receives the value from CacheConfiguration.getOffHeapMaxMemory). >> I haven't debugged it, but the instances are created per cache. >> >> Furthermore, I'm not sure about the memory-page concept, because you >> would get pages on top of pages (used by a modern OS). >> Sounds like even more fragmentation and in this case Ignite would need to >> do the defragmentation. >> >> Kind regards, >> Peter >> >> >> >> 2017-01-25 1:56 GMT+01:00 vkulichenko : >> >>> I don't think I will be able to explain better than it's done in the >>> ticket >>> :) Current approach is naive and not always effective for multiple >>> reasons. >>> >>> -Val >>> >>> >>> >>> -- >>> View this message in context: http://apache-ignite-users.705 >>> 18.x6.nabble.com/OFFHEAP-TIERED-and-memory-fragmentation-tp1 >>> 0218p10235.html >>> Sent from the Apache Ignite Users mailing list archive at Nabble.com. >>> >> >> >
Re: OFFHEAP_TIERED and memory fragmentation
Hi Val, fair enough :-) However, in the source-code it looks like "Flexible and precise per-cache memory limit" is supported already. At least each GridUnsafeMemory instance (in each GridCacheContext) receives the value from CacheConfiguration.getOffHeapMaxMemory). I haven't debugged it, but the instances are created per cache. Furthermore, I'm not sure about the memory-page concept, because you would get pages on top of pages (used by a modern OS). Sounds like even more fragmentation and in this case Ignite would need to do the defragmentation. Kind regards, Peter 2017-01-25 1:56 GMT+01:00 vkulichenko : > I don't think I will be able to explain better than it's done in the ticket > :) Current approach is naive and not always effective for multiple reasons. > > -Val > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/OFFHEAP-TIERED-and-memory-fragmentation-tp10218p10235. > html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Re: OFFHEAP_TIERED and memory fragmentation
Hi Val, that means it depends a lot on the OS and if/how it handles virtual memory-pages. So why do you plan to change that? Thanks, Peter 2017-01-25 0:14 GMT+01:00 vkulichenko : > Random means anywhere in empty memory space. When you create an entry, a > new > block is create for this value only. If you remove an entry, memory is > released. Once removed, it can be used by any application including Ignite. > Basically, the actual location where memory is allocated is defined by OS. > > Cache clear will free all the memory consumed by entries in this cache. > > -val > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/OFFHEAP-TIERED-and-memory-fragmentation-tp10218p10232. > html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Re: OFFHEAP_TIERED and memory fragmentation
Hi Val, What does randomly mean in this context? If one entry is removed, does Ignite reuse the space for new entries with the same or smaller size? Does Ignite organize it in small blocks? If yes, what happens if all entries stored in a block were removed? What does happen in case of a cache-clear? Thanks, Peter 2017-01-24 20:10 GMT+01:00 vkulichenko : > Hi Peter, > > Current implementation rendomly allocates memory for each value when it's > added, and frees memory when the entry is removed. Therefore, the > segmentation is possible if you constantly remove entries and create new > once. In case you usually *update* instead, especially with low throughput > that you have, I would not expect any problems. > > -Val > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/OFFHEAP-TIERED-and-memory-fragmentation-tp10218p10227. > html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
OFFHEAP_TIERED and memory fragmentation
Hello Ignite-Community! I just found IGNITE-3477 and esp. "Continuous put/remove operations with OFFHEAP_TIERED mode lead to uncontrollable memory fragmentation" How does Ignite handle OFFHEAP_TIERED caches currently (= how does it store the data)? I just tried to create some tests to get an impression of the fragmentation, however, I couldn't see a huge issue. In my case I've 30gb Offheap memory available and about 5 caches storing about 3gb of data (after starting the application). Every entry of the caches gets updated every few days the latest and some several times a day. However, I would like to avoid that cache-fragmentation hits the application out of the blue and therefore I try to get an impression about those internals. Any hint is appreciated, Peter
Re: Reusing Ignite-Marshaller leads to a Memory-Leak
Hi Denis, I think I've found the issue. Ignite skips references to Ignite-Caches. Moving away from the Ignite-Cache, but using the Ignite-Marshaller caused the issue. So it isn't an issue Ignite can prevent. Removing those references did it. Thanks for listening, Peter 2017-01-22 6:15 GMT+01:00 Denis Magda : > Sorry, didn’t pay attention that the size of every object is 1 KB. Then I > would suggest to share your test/heap dump to see what happens. > > — > Denis > > On Jan 21, 2017, at 9:10 PM, Denis Magda wrote: > > Hello Peter, > > This behavior is expected. Look, you serialize 2000 objects * 1000 KB > which gives ~ 2 GB in total. After that you hold the references to these > objects by putting them into an ordinary hash map. The objects will not be > removed from the heap until the map keeps them. > > One the other side, when the same objects are placed into an off-heap > cache they will be collected from the heap because at the end there will be > no reachable references to them. > > — > Denis > > On Jan 21, 2017, at 2:46 PM, Peter Schmitt > wrote: > > Hello Ignite-Community! > > I would like to use the Marshaller from Ignite for de-/serialising objects. > I would like to re-use it, because it's very fast and I'm using Ignite > anyway. > > I tried it with: > > //every thread gets the Marshaller via: > GridKernalContext ctx = ((IgniteKernal) ignite).context(); > Marshaller marshaller = ctx.grid().configuration().getMarshaller(); > > -> > > byte serializedResult[] = marshaller.marshal(obj); > or > Object deserializedResult = marshaller.unmarshal(serializedResult, > ctx.getClass().getClassLoader()); > > In a simple test it worked very well (and fast). > However, once I'm using larger Objects (e.g. 2000 instances each ~1kb > after marshalling) and store the results in a map, the Heap consumption > grows a lot (almost 2gb in few seconds). > If I store the same objects in an Ignite OffHeap-Cache, the (OffHeap) > memory-consumption is minimal. > In the debugger I saw that the heap grows once those 2000 instances get > processed. > (A manually triggered GC can just release few mb.) > > I even tried to re-use the marshaller, but nothing changed. > At runtime BinaryMarshaller is used which wraps GridBinaryMarshaller. > > Any hint to get rid of the leak is appreciated, > Peter > > > >
Reusing Ignite-Marshaller leads to a Memory-Leak
Hello Ignite-Community! I would like to use the Marshaller from Ignite for de-/serialising objects. I would like to re-use it, because it's very fast and I'm using Ignite anyway. I tried it with: //every thread gets the Marshaller via: GridKernalContext ctx = ((IgniteKernal) ignite).context(); Marshaller marshaller = ctx.grid().configuration().getMarshaller(); -> byte serializedResult[] = marshaller.marshal(obj); or Object deserializedResult = marshaller.unmarshal(serializedResult, ctx.getClass().getClassLoader()); In a simple test it worked very well (and fast). However, once I'm using larger Objects (e.g. 2000 instances each ~1kb after marshalling) and store the results in a map, the Heap consumption grows a lot (almost 2gb in few seconds). If I store the same objects in an Ignite OffHeap-Cache, the (OffHeap) memory-consumption is minimal. In the debugger I saw that the heap grows once those 2000 instances get processed. (A manually triggered GC can just release few mb.) I even tried to re-use the marshaller, but nothing changed. At runtime BinaryMarshaller is used which wraps GridBinaryMarshaller. Any hint to get rid of the leak is appreciated, Peter
Re: Ignite Thread count
Hi Val, any information which helps to improve the performance for that use-case. Kind regards, Peter 2016-09-10 1:09 GMT+02:00 vkulichenko : > Peter, > > What kind of information you're looking for? > > -Val > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/Ignite-Thread-count-tp7636p7644.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Re: Ignite Thread count
Hi Val, thank you for your hint! I just found out that reducing public-thread-pool-size results in a lower write-performance. At least I could reproduce it. Are there any other information out there besides https://apacheignite.readme.io/docs/performance-tips ? Kind regards, Peter 2016-09-09 23:53 GMT+02:00 vkulichenko : > Hi Peter, > > You can probably set connectorConfiguration to null to disable the REST > server at all (unless you need it, of course). Other than that, you used > all > the settings that can influence the number of threads. Ignite is designed > to > be a distributed system, so it doesn't allow to disable discovery, > communication or other crucial components. > > -Val > > > > -- > View this message in context: http://apache-ignite-users.705 > 18.x6.nabble.com/Ignite-Thread-count-tp7636p7638.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Ignite Thread count
Hello Ignite-Community! as some of you might have read, I'm using Ignite as local Off-heap caches only. I limited the discovery to localhost and therefore I don't need threads which are just active to handle e.g. grid topics. I would like to reduce the amount of threads to an minimum. The Off-heap cache-access (read/write) should be fast, but everything else isn't needed. It might not matter a lot in an average case to have some additional threads, however, the server as well as the cache are under heavy load and therefore every useless context-switch should be avoided. I'm currently experimenting with the following config: IgniteConfiguration configuration = new IgniteConfiguration() .setDiscoverySpi(localNodeDiscovery) //limit to localhost .setDaemon(false); TcpCommunicationSpi communicationSpi = new TcpCommunicationSpi(); communicationSpi.setSelectorsCount(1); configuration.setCommunicationSpi(communicationSpi); ConnectorConfiguration connectorConfiguration = new ConnectorConfiguration(); connectorConfiguration.setSelectorCount(1); configuration.setConnectorConfiguration(connectorConfiguration); configuration.setClockSyncFrequency(Integer.MAX_VALUE); configuration.setUtilityCachePoolSize(1); configuration.setManagementThreadPoolSize(1); configuration.setPublicThreadPoolSize(1); configuration.setRebalanceThreadPoolSize(1); configuration.setSystemThreadPoolSize(4); and CacheConfiguration.setEagerTtl(false) for caches which don't need a TTL for its entries. 1) Do you see any issue with this config that impacts the described use-case? 2) Are there other threads I can get rid of as well? (currently there are still ~20 threads from Ignite on an average developer-machine.) I'm e.g. wondering about a) disco-event-worker b) exchange-worker c) grid-time-coordinator d) grid-time-server-reader e) ignite-clock f) nio-acceptor g) pub-* h) session-timeout-worker i) tcp-disco-msg-worker j) tcp-disco-srvr Any hint is appreciated, Peter
Re: Off-heap issue
Hi Val,
it's like:
public class LoaderThread extends Thread {
private static final Logger LOG = createProprietaryLogger();
private Ignite ignite;
private IgniteCache cache;
public LoaderThread(Ignite ignite) {
this.ignite = ignite;
this.cache = ignite.getOrCreateCache("userCache");
}
@Override
public void run() {
//WILL cause the issue: LOG.info("Import data into Ignite");
//WON'T cause the issue: createProprietaryLogger().info("Import
data into Ignite");
Map dataToCache = loadDataToCache();
try (IgniteDataStreamer stream =
ignite.dataStreamer(cache.getName())) {
stream.allowOverwrite(false);
stream.addData(dataToCache); //issue during this call --
happens just once
}
dataToCache = loadDataToCache();
try (IgniteDataStreamer stream =
ignite.dataStreamer(cache.getName())) {
stream.allowOverwrite(false);
stream.addData(dataToCache); //NO issue during this call
}
}
private Map loadDataToCache() {
//...
}
//...
}
User is not Serializable and there is no logger in the User class.
The loaded test-data is always the same.
The source of the logger is pretty complex and I'm not allowed to share it,
but what I can say is that it replaces JUL.
However, the first line in the run-method leads to a broken (see LOG.info)
run or a working (createProprietaryLogger().info) run.
I couldn't believe my eyes, however, I can reproduce it over and over again
just by changing this one line.
Kind regards,
Peter
2016-07-18 22:50 GMT+02:00 vkulichenko :
> Hi Peter,
>
> I don't see your code, so can hardly suggest anything else. According to
> your description, I'm pretty sure the logger instance is being serialized
> as
> a part of key or value object, but I have no idea why. I would start with
> running the app in debug and checking if my assumption is right or not.
>
> -Val
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Off-heap-issue-tp6327p6356.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
Re: Off-heap issue
Hi Val, the logger is only used in the class of the loader-thread and not in one of the keys/values. If I just remove the call in the class of the loader-thread, everything looks fine again (small size and no error-message). Moreover, once I change the logger from a static class-variable to a local-variable (the rest of the call is the same), the side-effect disappears as well (but I tested that constellation just twice). Kind regards, Peter 2016-07-16 2:04 GMT+02:00 vkulichenko : > Hi Peter, > > It seems to me that either key and value class has a non-transient > reference > to the logger. The serialization of the logger instance can cause both > difference in entry sizes and the warning you showed. Can this be the case? > > -Val > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/Off-heap-issue-tp6327p6329.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Off-heap issue
Hello Ignite-Community! I've to use a special (not open) logger in my project. It causes a strange side-effect in Ignite. Once I use it in a method which fills the Off-heap cache via IgniteDataStreamer, the memory consumption is different. Without using the logger the Off-heap-size is ~15MB for 1000 entries. Just adding the logger (it gets called before the work starts) and filling the cache with the same entries leads to an Off-heap size of more than 500MB for the same 1000 entries. I've no idea how Ignite and esp. the consumed size can be impacted by a logger. I reproduced it at least 20 times (adding the log-statement always caused the huge cache-size and removing it resulted in a small cache). Furthermore, I get a strange message in combination with the logger: "Class java.beans.PropertyChangeSupport cannot be written in binary format because it either implements Externalizable interface or have writeObject/readObject methods. Please ensure that all nodes have this class in classpath. To enable binary serialization either implement Binarylizable interface or set explicit serializer using BinaryTypeConfiguration.setSerializer() method." It just shows up once, but not at the first entry. Also with different data it shows up (just once) and usually not for the first entry. Any hint is appreciated, Peter
Re: Non-cluster mode
Thank you Denis for the hint! Kind regards Peter 2016-07-05 14:35 GMT+02:00 Denis Magda : > Peter, > > Measure it basing under your load. Sometimes it’s enough to have Java > heaps 8 GB in size to work under significant load with off-heap data in > hundreds of GBs in size. > > — > Denis > > On Jul 5, 2016, at 3:20 PM, Peter Schmitt > wrote: > > Hi Denis, > > we are trying to store a huge amount of data off-heap (more than 50 GB). > Therefore, we need to know the heap-size which is needed by Ignite to > handle such a huge off-heap cache (which we only need to keep the heap-size > as low as possible due to the GC overhead). > > Kind regards > Peter > > > > 2016-07-05 11:41 GMT+02:00 Denis Magda : > >> Hi Peter, >> >> Basically it depends on your use case. Sometimes it’s enough 2 GB, >> sometimes 5 GB or 10 GB. It depends on the workload. >> However you shouldn’t allocate too big Java heaps with size more than 20 >> GB because it can lead to long stop-the-world pauses at some time. >> >> — >> Denis >> >> On Jul 3, 2016, at 11:29 AM, Peter Schmitt >> wrote: >> >> Hi Val, >> >> after several tests I can confirm that it works with more heap-memory. >> However, I'm not sure how much heap-memory is needed for 50+ GB >> off-heap-data and I can't find hints for it in the docs. >> >> Kind regards >> Peter >> >> >> >> 2016-06-30 22:23 GMT+02:00 vkulichenko : >> >>> Hi Peter, >>> >>> It sound like you just don't give enough heap memory to a node. Heap >>> memory >>> is still required, even if you store all the data off heap. Can you try >>> to >>> your JVM at least 2GB and check if this helps? >>> >>> -Val >>> >>> >>> >>> -- >>> View this message in context: >>> http://apache-ignite-users.70518.x6.nabble.com/Non-cluster-mode-tp5959p6028.html >>> Sent from the Apache Ignite Users mailing list archive at Nabble.com >>> <http://nabble.com/>. >>> >> >> >> > >
Re: Non-cluster mode
Hi Denis, we are trying to store a huge amount of data off-heap (more than 50 GB). Therefore, we need to know the heap-size which is needed by Ignite to handle such a huge off-heap cache (which we only need to keep the heap-size as low as possible due to the GC overhead). Kind regards Peter 2016-07-05 11:41 GMT+02:00 Denis Magda : > Hi Peter, > > Basically it depends on your use case. Sometimes it’s enough 2 GB, > sometimes 5 GB or 10 GB. It depends on the workload. > However you shouldn’t allocate too big Java heaps with size more than 20 > GB because it can lead to long stop-the-world pauses at some time. > > — > Denis > > On Jul 3, 2016, at 11:29 AM, Peter Schmitt > wrote: > > Hi Val, > > after several tests I can confirm that it works with more heap-memory. > However, I'm not sure how much heap-memory is needed for 50+ GB > off-heap-data and I can't find hints for it in the docs. > > Kind regards > Peter > > > > 2016-06-30 22:23 GMT+02:00 vkulichenko : > >> Hi Peter, >> >> It sound like you just don't give enough heap memory to a node. Heap >> memory >> is still required, even if you store all the data off heap. Can you try to >> your JVM at least 2GB and check if this helps? >> >> -Val >> >> >> >> -- >> View this message in context: >> http://apache-ignite-users.70518.x6.nabble.com/Non-cluster-mode-tp5959p6028.html >> Sent from the Apache Ignite Users mailing list archive at Nabble.com >> <http://nabble.com>. >> > > >
Re: Non-cluster mode
Hi Val, after several tests I can confirm that it works with more heap-memory. However, I'm not sure how much heap-memory is needed for 50+ GB off-heap-data and I can't find hints for it in the docs. Kind regards Peter 2016-06-30 22:23 GMT+02:00 vkulichenko : > Hi Peter, > > It sound like you just don't give enough heap memory to a node. Heap memory > is still required, even if you store all the data off heap. Can you try to > your JVM at least 2GB and check if this helps? > > -Val > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/Non-cluster-mode-tp5959p6028.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Re: Non-cluster mode
Hi Val, I did further tests and it looks like OutOfMemoryError shows up in case the VM isn't fast enough with its GC. If you add e.g. cache.get in a loop for every key, it's possible to reproduce it. Doing System.gc() every thousand calls takes longer, but the VM has enough time for GC and it works. Nothing is referenced permanently, because a simple cache.get call is used. But I'm not sure how we can handle it in a high-load scenario. From my tests I can't see the coherency between size of Off-Heap-Memory and the required size of On-Heap-Memory to avoid a OutOfMemoryError. Kind regards Peter 2016-06-29 11:00 GMT+02:00 Peter Schmitt : > Hi Val, > > I've pushed a demo to https://github.com/ps4os/ignite_offheap_test > The issue is that I can't reproduce it consistently. As soon as I get the > OutOfMemoryError, I can reproduce it. And I can reproduce it with a restart > in between. > The demo contains a Readme as well as some TODOs and comments which > document the goals and observed issues. > > Kind regards > Peter > > > 2016-06-29 3:28 GMT+02:00 vkulichenko : > >> Peter, >> >> This doesn't make much sense to me. With OFFHEAP_TIERED eviction policy >> should not change anything at all, so it sounds like misconfiguration. Can >> you provide the whole test that I can run and investigate? >> >> -Val >> >> >> >> -- >> View this message in context: >> http://apache-ignite-users.70518.x6.nabble.com/Non-cluster-mode-tp5959p5982.html >> Sent from the Apache Ignite Users mailing list archive at Nabble.com. >> > >
Re: Non-cluster mode
Hi Val, I've pushed a demo to https://github.com/ps4os/ignite_offheap_test The issue is that I can't reproduce it consistently. As soon as I get the OutOfMemoryError, I can reproduce it. And I can reproduce it with a restart in between. The demo contains a Readme as well as some TODOs and comments which document the goals and observed issues. Kind regards Peter 2016-06-29 3:28 GMT+02:00 vkulichenko : > Peter, > > This doesn't make much sense to me. With OFFHEAP_TIERED eviction policy > should not change anything at all, so it sounds like misconfiguration. Can > you provide the whole test that I can run and investigate? > > -Val > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/Non-cluster-mode-tp5959p5982.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Re: Non-cluster mode
Hi Val, without the eviction policy, the setup breaks due to java.lang.OutOfMemoryError: GC overhead limit exceeded I'm not sure why the heap grows (+ it looks like GC can't free it), in case of the mentioned (off-heap) config. In the end almost everything should be stored off-heap. However, maybe it's a kind of index which needs heap-space. In that case it would be great to know how much heap-space is safe if the off-heap size should be ~50 GB. Kind regards Peter 2016-06-28 21:14 GMT+02:00 vkulichenko : > Peter, > > The only configuration that defines whether nodes join topology or not is > discovery SPI (the one you provided in the first message) > > All looks fine, expect that eviction policy will be ignored in your case. > It's used for entries that are stored in heap memory, while your cache is > OFFHEAP_TIERED and therefore stores everything offheap. > > -Val > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/Non-cluster-mode-tp5959p5978.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
Re: Non-cluster mode
Hi Val,
thank you for checking it!
I've switched to JDK8 and the issue disappeared.
I've to test it with the JDK version we need to use in production.
It would be great to hear whether there is a different approach to reach
the same or if it could be a side-effect due to the used config:
//IgniteConfiguration + start as listed in the first mail
CacheConfiguration offheapCacheConfig = new
CacheConfiguration()
.setName(cacheName)
.setCacheMode(CacheMode.LOCAL)
.setMemoryMode(CacheMemoryMode.OFFHEAP_TIERED)
.setSwapEnabled(false)
.setBackups(0);
offheapCacheConfig.setOffHeapMaxMemory(...); //max. value loaded from a
config
LruEvictionPolicy evictionPolicy = new LruEvictionPolicy();
evictionPolicy.setMaxMemorySize(new
BigDecimal(offheapCacheConfig.getOffHeapMaxMemory() * 0.9).longValue());
IgniteCache cache =
ignite.createCache(offheapCacheConfig);
cache = cache.withExpiryPolicy(new AccessedExpiryPolicy(new
Duration(/*configured value*/)));
And to fill the cache the following code is used:
try (IgniteDataStreamer stream =
ignite.dataStreamer(cache.getName())) {
stream.allowOverwrite(true);
//use stream#addData
}
I hope that config makes sense and can't lead to the effect I described
initially.
Kind regards
Peter
2016-06-28 19:23 GMT+02:00 vkulichenko :
> Hi Peter,
>
> Your code works fine for me. Can you please attach the log file?
>
> -Val
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Non-cluster-mode-tp5959p5971.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
Non-cluster mode
Hello Ignite-Community!
As a part of an evaluation of Ignite 1.6, I'm trying to use Ignite in a
cluster *without* cluster-mode.
It should be used as local cache (independent of the other nodes).
Therefore, the (Ignite-)nodes shouldn't try to discover other
(Ignite-)nodes.
I tried
TcpDiscoverySpi localNodeDiscovery = new TcpDiscoverySpi();
TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
ipFinder.setAddresses(Collections.singletonList("127.0.0.1"));
localNodeDiscovery.setIpFinder(ipFinder);
IgniteConfiguration configuration = new IgniteConfiguration()
.setDiscoverySpi(localNodeDiscovery)
.setDaemon(false);
Ignite ignite = Ignition.getOrStart(configuration);
to limit cluster-discovery to the local node.
In that case Ignite does nothing at all (the startup hangs).
I've read the docs about the different cluster-modes, but I couldn't find
the information I'm looking for (which works as expected).
Any hint is appreciated,
Peter
Reproducing the benchmark numbers
We (Hazelcast) would like to reproduce the benchmark numbers: https://ignite.apache.org/benchmarks/ignite-vs-hazelcast.html We have set up 3 separate environments, to reduce the change of configuration errors, according to the exact specifications on the website, but have failed to reproduced the numbers. There are a few points of confusion which might have caused the differences in the measurements: - which AMI was used? We are using the ami-fce3c696 Ubuntu 14.04 LTS (HVM) from us-east-1 - can we get the exact properties being used for Ignite and Hazelcast. We know the properties are in the github repo; but these can change and have changed.
