Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id DB4A12009F4 for ; Thu, 26 May 2016 22:08:08 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id D9DE6160A18; Thu, 26 May 2016 20:08:08 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3A948160A17 for ; Thu, 26 May 2016 22:08:07 +0200 (CEST) Received: (qmail 32115 invoked by uid 500); 26 May 2016 20:08:06 -0000 Mailing-List: contact user-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ignite.apache.org Delivered-To: mailing list user@ignite.apache.org Received: (qmail 32105 invoked by uid 99); 26 May 2016 20:08:06 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 May 2016 20:08:06 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id E3FC2CEDA0 for ; Thu, 26 May 2016 20:08:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.279 X-Spam-Level: * X-Spam-Status: No, score=1.279 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gridgain-com.20150623.gappssmtp.com Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id yXWCQbtIKEDC for ; Thu, 26 May 2016 20:08:03 +0000 (UTC) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id DB5265F343 for ; Thu, 26 May 2016 20:08:02 +0000 (UTC) Received: by mail-lf0-f49.google.com with SMTP id b73so14762201lfb.3 for ; Thu, 26 May 2016 13:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gridgain-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=eXuvCA+LYL034kv8nM6uvdSqGGVedG8/fy1/H9Ox1rg=; b=a/+s8WGN+ZsjcNzylOP7BpyCovMNUseyPxQqamCiNl6ForlSZs21LWmQfpyVEm9f5o hnbgyQHR6QQvKrgGr2+Kz4U5bT6iSsAWgUEwq6vHFo21SbQU6LAd4cqeEpPxse85ikfT WzgBgAZ7rmTwTBP9gfVbxReUbgW3HJqvz9inRCUV9dGCfE5hO71mnHtlqhBRT9CT3EoZ ngnzaInqV4UAYq6k7LP//c3fEVQv1XxEiORMJ8hfUpGJ9lJz+SquPuM5a/lOi6VTP4Rn lbuJ/F+sFJpkuayx5ffUoNe1MXUcwXgql/66bzGkzT63moiPNnX4Af9gLa+OFDhXMGCB vOeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=eXuvCA+LYL034kv8nM6uvdSqGGVedG8/fy1/H9Ox1rg=; b=hzp+neThtXe/puFCMUG7Qp58fYYKkZx+ACirVA2EoJutyGUPbEVZAz+EJNUnADVxHL 6fsgWEPaFo02/5A5jq4GZcf39UEBaBbYOSgQyZe3bxQH7OysuTyAL80bQyISorVqLHTZ kNzN9Uz/dpPupcNthftzX9ILcEemm7609trcaK5XdNvpSDhsKCuGPDWMlHizuyLyt5vo GKRP4sVpBMTvXq6MysH2mL0eSoUOerUS1t9D0FW4KsupDfCZuxGBwKvgZS4lzpGMqlbb XpPi2PihQyV9ZZhH/1LvTLDo3Of44Pc99ReZfqJmrfonPBALizkqWRz31JLGldZmTKQO sAJw== X-Gm-Message-State: ALyK8tL7QtZpmBYJltHBNP5FuP31EIKk/Bc18MWxNDl5en/bYE2LVITDLeRJ0dgJZX71sIca X-Received: by 10.25.165.135 with SMTP id o129mr3445493lfe.105.1464293274742; Thu, 26 May 2016 13:07:54 -0700 (PDT) Received: from [172.16.204.211] ([185.62.194.139]) by smtp.gmail.com with ESMTPSA id h81sm2542753lfi.0.2016.05.26.13.07.53 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 13:07:53 -0700 (PDT) From: Denis Magda Content-Type: multipart/alternative; boundary="Apple-Mail=_D25FB3D5-075A-4797-B503-DF5F3AE78371" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: off heap indexes - setSqlOnheapRowCacheSize - how does it improve efficiency ? Date: Thu, 26 May 2016 23:07:52 +0300 References: <1463844691268-5070.post@n6.nabble.com> <1463998064601-5092.post@n6.nabble.com> <53451DF7-1C59-4AFD-A390-3A80F884949E@gridgain.com> To: user@ignite.apache.org In-Reply-To: X-Mailer: Apple Mail (2.3124) archived-at: Thu, 26 May 2016 20:08:09 -0000 --Apple-Mail=_D25FB3D5-075A-4797-B503-DF5F3AE78371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here is a link with rough estimation https://apacheignite.readme.io/docs/capacity-planning = =E2=80=94 Denis > On May 26, 2016, at 8:09 PM, Tomek W wrote: >=20 > | Make sure you have enough memory for your dataset. > How to check it ? >=20 > 2016-05-26 18:46 GMT+02:00 Alexei Scherbakov = >: > You should measure performance on the real-life cases and see if it's = enough for you. > Ignite performs good in both modes. > If you really want to use ONHEAP_TIERED, you must tune GC and heap = size, as described here [1] > Make sure you have enough memory for your dataset. > The goal is to avoid long GC pauses. >=20 > [1] https://apacheignite.readme.io/docs/jvm-and-system-tuning = >=20 > 2016-05-26 19:40 GMT+03:00 Tomek W >: > Ok, I will try it. However, Why OFF_HEAP_TIERED ? It seem to be not = fast as ON HEAP >=20 > 2016-05-26 18:32 GMT+02:00 Alexei Scherbakov = >: > We are talking about count(*) query performance, right ? > WriteBehind is for writing to CacheStore in the async mode. >=20 > If yes, do the following: >=20 > 1) Set OFFHEAP_TIERED mode and reduce max heap memory on example to = 4Gb. > 2) Update to Ignite 1.6 > 3) Measure query performance. Run the query several times and use = average value as the estimation. > 4) If it's not as expected, show me GC logs. >=20 >=20 >=20 > 2016-05-26 18:28 GMT+03:00 Tomek W >: > No, I am using ON_HEAP_TIERED. >=20 > Maybe WriteBehind should be turned on ? > My App do exactly one thing: initialize hot loading. >=20 > When it comes to JDBC client, I did show fragment of code in previous = post. >=20 > 2016-05-26 16:15 GMT+02:00 Alexei Scherbakov = >: > I see long pauses in your GC log (> 3 seconds) > This means your app have high pressure on the heap. > It's hard to tell why without knowing what your app is doing. >=20 > Are you using OFFHEAP_TIERED? > If yes, try to reduce sqlOnheapRowCacheSize value. >=20 >=20 >=20 >=20 > 2016-05-26 14:57 GMT+03:00 Tomek W >: > Ok, > i am going to add new machines to ignite cluster. Firstly, please look = at my gc file log - previous message. >=20 > 2016-05-26 13:39 GMT+02:00 Alexei Scherbakov = >: > Hi, >=20 > The initial question was about setSqlOnheapRowCacheSize and I think > now it is clear how to improve SQL performance using with parameter. >=20 > If you dissatisfied with the Ignite performance, I suggest you to = start a new thread on this, > providing detailed info about your performance test like > cluster configuration, server GC settings, and test sources. >=20 > As already mentioned, Ignite SQL engine(H2) has the same(or slightly) = less performance when Postresql. > Ignite really starts to shine when used as distributed data grid = having large amount of data in memory on several nodes. >=20 > SELECT count(*) from table is not very good test query. > Postgres may have the result cached, whereas Ignite always do the full = table traversal. > Recently I implemented an improvement for this case. > See https://issues.apache.org/jira/browse/IGNITE-2751 = for details. >=20 > I strongly recommend to test Ignite performance on the real case. > Dont' forget to configure GC properly [1] >=20 > [1] https://apacheignite.readme.io/docs/jvm-and-system-tuning = >=20 >=20 >=20 >=20 >=20 >=20 > 2016-05-26 2:09 GMT+03:00 Tomek W >: > | Also it would be interesting to see result of=20 > | SELECT count(*) from the query above in both cases. > (number of rows =3D 2 798 685) > SELECT count(*) FROM postgresTable; > 456 ms > SELECT count(*) FROM postgresTable; > 314 ms >=20 > SELECT count(*) FROM igniteTable; > 9746 ms > SELECT count(*) FROM igniteTable; > 9664 ms >=20 >=20 > Code of Jdbc Drvier (the same code for Ignite and postgresql - url = connection is given from command line): > http://pastebin.com/mYDSjziN > My start sh file: > http://pastebin.com/VmRM2sPQ >=20 > My gc log file (following hint Magda): > (file generated during hot loading and query via JDBC). > http://pastebin.com/XicnNczV >=20 >=20 > If you would like to see something else let me know. >=20 > PS How to launch H2 debug console ? I followed docs, but it doesn't = help. =20 > I set enviroment variable: > echo $IGNITE_H2_DEBUG_CONSOLE > true > now, ./ignite.sh conf.xml >=20 > sudo netstat -tulpn | grep 61214 > No opened ports. >=20 > BTW, during starting ignite it give me information:=20 > [01:03:02] Performance suggestions for grid 'turbines_table_cluster' = (fix if possible) > [01:03:02] To disable, set = -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=3Dtrue > [01:03:02] ^-- Disable grid events (remove 'includeEventTypes' from = configuration) > [01:03:02] ^-- Enable ATOMIC mode if not using transactions (set = 'atomicityMode' to ATOMIC) > [01:03:02] ^-- Enable write-behind to persistent store (set = 'writeBehindEnabled' to true) >=20 >=20 > 2016-05-25 12:23 GMT+02:00 Alexei Scherbakov = >: > For postgres test I mean initial jdbc query and result set traversal. > For Ignite I mean sql query and iterator traversal. > Also it would be interesting to see result of=20 > SELECT count(*) from the query above in both cases. >=20 > 2016-05-25 12:00 GMT+03:00 Tomek W >: > >=20 > What code do you mean ? JDBC client ? >=20 > 2016-05-25 10:25 GMT+02:00 Alexei Scherbakov = >: > What's the batch size for postgresql ? > What's the size of one entry ? > Could you provide the test code for both postgres and Ignite (just the = query + read with the time estimation) ? >=20 > 2016-05-25 11:13 GMT+03:00 Tomek W >: > | How many entries are downloaded to the client in both cases? > 3000 000 >=20 > | Do the both queries involve network I/O ? > No, I have only local one server (for testing purpose). >=20 >=20 > 2016-05-25 9:59 GMT+02:00 Alexei Scherbakov = >: > SELECT * is not really a good test query. > It's result can be affected not only by engine performance. >=20 > How many entries are downloaded to the client in both cases? > Do the both queries involve network I/O ? >=20 > 2016-05-25 7:58 GMT+03:00 Denis Magda >: > In general Ignite is designed to be used in a distributed environment = when gigabytes or terabytes of dataset is spread across many cluster = nodes and SQL queries executed across the cluster should be faster since = resources of all the machines will be used and as a result a query = should be completed quicker. In your scenario you just have only a = single cluster node and in fact comparing performance of PostgreSQL and = H2 (engine that is used by Ignite SQL) and I can consider that Ignite = SQL can work slightly slowly but this in is not Ignite usage scenario. >=20 > However if you try to create a cluster of several nodes running on = different physical machines, pre-load gigabytes of data there and = compare Ignite SQL and PostgresSQL you should see performance = improvements on Ignite side. >=20 > In any case taking into account the advise above do the following: > - execute =E2=80=9CEXPLAIN=E2=80=9D query to see that the index is = chose properly [1]; > - H2 console will allow you to see how fast a query is presently = executed on a single node removing several Ignite layers [2]; > - check if you have any GC pauses during query execution since it can = affect execution time [3] >=20 > Also share the objects you use as keys and values. >=20 > [1] https://apacheignite.readme.io/docs/sql-queries#using-explain = > [2] = https://apacheignite.readme.io/docs/sql-queries#using-h2-debug-console = > [3] = https://apacheignite.readme.io/v1.6/docs/jvm-and-system-tuning#section-det= ailed-garbage-collection-stats = >=20 > =E2=80=94 > Denis >=20 >> On May 25, 2016, at 3:23 AM, Tomek W > wrote: >>=20 >> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time = | Size | Hi/Mi/Rd/Wr | >> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> | 0F0AAF99(@n0), 127.0.0.1 | 8 | 54.50 % | 3.23 % | = 00:13:13:49 | 3000000 | Hi: 0 | >> | | | | | = | | Mi: 0 | >> | | | | | = | | Rd: 0 | >> | | | | | = | | Wr: 0 | >> = +-------------------------------------------------------------------------= ---------------------+ >>=20 >>=20 >> I followed your hints. Actually, client doesn't require such many = memory as before - thanks for it. >>=20 >>=20 >> When it comes to configuration of server, I also followed your hints, = results: >>=20 >> Querying is done by JDBC Client. In ignite and postgresql I have = single index on column A. >>=20 >> Ignite: SELECT * FROM table WHERE A > 1345 takes 6s. >> Postgres: SELECT * FROM table WHERE A > 1345 takes 4s. >>=20 >> As you can see, postgres is still bettter than Ignite. I show you = significant fragments of my configuration: >> http://pastebin.com/EQC4JPWR >>=20 >> And xml for server file: >> http://pastebin.com/enR9h5J4 >>=20 >>=20 >> Try to consider why postgresql is still better, please. >>=20 >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Alexei Scherbakov >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Alexei Scherbakov >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Alexei Scherbakov >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Alexei Scherbakov >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Alexei Scherbakov >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Alexei Scherbakov >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Alexei Scherbakov >=20 --Apple-Mail=_D25FB3D5-075A-4797-B503-DF5F3AE78371 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Here is a link with rough estimation
https://apacheignite.readme.io/docs/capacity-planning
=

=E2=80=94
Denis

On May 26, 2016, at 8:09 PM, = Tomek W <rrrtomtomrrr@gmail.com> wrote:

| Make sure you have enough memory for your = dataset.
How to check it  ?

2016-05-26 18:46 GMT+02:00 Alexei Scherbakov <alexey.scherbakoff@gmail.com>:
You should measure performance on the real-life cases and see = if it's enough for you.
Ignite performs good in both = modes.
If you really want to use ONHEAP_TIERED, you = must tune GC and heap size, as described here [1]
Make sure you have enough memory for your dataset.
The goal is to avoid long GC pauses.

[1] https://apacheignite.readme.io/docs/jvm-and-system-tuning

2016-05-26= 19:40 GMT+03:00 Tomek W <rrrtomtomrrr@gmail.com>:
Ok, I will try it. However, Why OFF_HEAP_TIERED ?  It = seem to be not fast as ON HEAP

2016-05-26 18:32 GMT+02:00 Alexei Scherbakov <alexey.scherbakoff@gmail.com>:
We are talking about count(*) query = performance, right ?
WriteBehind is for writing to = CacheStore in the async mode.

If yes, do the following:

1) Set OFFHEAP_TIERED = mode and reduce max heap memory on example to 4Gb.
2) Update to Ignite 1.6
3) Measure query performance. Run the query several times and = use average value as the estimation.
4) If it's not = as expected, show me GC logs.



2016-05-26 18:28 GMT+03:00 Tomek W <rrrtomtomrrr@gmail.com>:
No, I am = using ON_HEAP_TIERED.

Maybe = WriteBehind should be turned on ?
My App do exactly = one thing:  initialize hot loading.

When it comes to JDBC client, I did show fragment of = code in previous post.

2016-05-26 16:15 GMT+02:00 Alexei Scherbakov <alexey.scherbakoff@gmail.com>:
I see long pauses in your GC log (> 3 seconds)
This means your app have high pressure on the heap.
It's hard to tell why without knowing what your app is = doing.

Are you = using OFFHEAP_TIERED?
If yes, try to reduce = sqlOnheapRowCacheSize value.




2016-05-26= 14:57 GMT+03:00 Tomek W <rrrtomtomrrr@gmail.com>:
Ok,
i am going to add new = machines to ignite cluster. Firstly, please look at my gc file log - = previous message.

2016-05-26 13:39 GMT+02:00 Alexei Scherbakov <alexey.scherbakoff@gmail.com>:
Hi,

The = initial question was about setSqlOnheapRowCacheSize and I = think
now it is clear how to improve SQL = performance using with parameter.

If you dissatisfied with the Ignite = performance, I suggest you to start a new thread on this,
providing detailed info about your performance test = like
cluster configuration, server GC settings, and = test sources.

As= already mentioned, Ignite SQL engine(H2) has the same(or slightly) less = performance when Postresql.
Ignite really starts to = shine when used as distributed data grid having large amount of data in = memory on several nodes.

SELECT count(*) from table is not very good test = query.
Postgres may have the result cached, = whereas Ignite always do the full table traversal.
Recently I implemented an improvement for this = case.
See https://issues.apache.org/jira/browse/IGNITE-2751 for = details.

I = strongly recommend to test Ignite performance on the real = case.
Dont' forget to configure GC properly = [1]

[1] https://apacheignite.readme.io/docs/jvm-and-system-tuning






2016-05-26 2:09 GMT+03:00 Tomek W <rrrtomtomrrr@gmail.com>:
| Also it would be interesting to see result of
| SELECT count(*) from the query above in both cases.
(number of rows =3D 2 798 685)
SELECT count(*) FROM postgresTable;
 456 = ms
SELECT count(*) FROM postgresTable;
314 = ms

SELECT count(*) FROM igniteTable;
9746 ms
SELECT count(*) FROM igniteTable;
9664 ms


Code of = Jdbc Drvier (the same code for Ignite and postgresql - url connection is = given from command line):
http://pastebin.com/mYDSjziN
My start sh = file:
http://pastebin.com/VmRM2sPQ

My gc log file (following hint Magda):
(file generated during hot loading and query via JDBC).
http://pastebin.com/XicnNczV


If you would like to see something else let me = know.

PS How to launch H2 = debug console ? I followed docs, but it doesn't help. 
I set enviroment variable:
echo = $IGNITE_H2_DEBUG_CONSOLE
true
now,= ./ignite.sh conf.xml

sudo netstat = -tulpn | grep 61214
No opened ports.
BTW, during starting ignite it give me information: =
[01:03:02]  Performance suggestions for grid = 'turbines_table_cluster' (fix if possible)
[01:03:02] To = disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=3Dtrue
[01:03:02]   ^-- Disable grid events (remove = 'includeEventTypes' from configuration)
[01:03:02]   ^-- Enable ATOMIC mode if not using = transactions (set 'atomicityMode' to ATOMIC)
[01:03:02]   ^-- Enable write-behind to persistent = store (set 'writeBehindEnabled' to true)


2016-05-25= 12:23 GMT+02:00 Alexei Scherbakov <alexey.scherbakoff@gmail.com>:
For postgres test I mean initial jdbc query and result = set traversal.
For Ignite I mean sql query and = iterator traversal.
Also it would be interesting to = see result of 
SELECT count(*) from the query above in both cases.

2016-05-25= 12:00 GMT+03:00 Tomek W <rrrtomtomrrr@gmail.com>:
<image.png>

What code do you mean ? JDBC client ?

2016-05-25= 10:25 GMT+02:00 Alexei Scherbakov <alexey.scherbakoff@gmail.com>:
What's the batch size for postgresql ?
What's = the size of one entry ?
Could you provide the test = code for both postgres and Ignite (just the query + read with the time = estimation) ?

2016-05-25 11:13 GMT+03:00 Tomek W <rrrtomtomrrr@gmail.com>:
| How many entries are downloaded to the = client in both cases?
3000 000

| Do the both queries involve = network I/O ?
No, I have only = local one server (for testing purpose).


2016-05-25= 9:59 GMT+02:00 Alexei Scherbakov <alexey.scherbakoff@gmail.com>:
SELECT * is not really a good test query.
It's = result can be affected not only by engine performance.

How many entries are = downloaded to the client in both cases?
Do the both = queries involve network I/O ?

2016-05-25 7:58 GMT+03:00 Denis Magda <dmagda@gridgain.com>:
In general Ignite is designed = to be used in a distributed environment when gigabytes or terabytes of = dataset is spread across many cluster nodes and SQL queries executed = across the cluster should be faster since resources of all the machines = will be used and as a result a query should be completed quicker. In = your scenario you just have only a single cluster node and in fact = comparing performance of PostgreSQL and H2 (engine that is used by = Ignite SQL) and I can consider that Ignite SQL can work slightly slowly = but this in is not Ignite usage scenario.

However if you try to create a cluster = of several nodes running on different physical machines, pre-load = gigabytes of data there and compare Ignite SQL and PostgresSQL you = should see performance improvements on Ignite side.

In any case taking into = account the advise above do the following:
- = execute =E2=80=9CEXPLAIN=E2=80=9D query to see that the index is chose = properly [1];
- H2 console will allow you to see = how fast a query is presently executed on a single node removing several = Ignite layers [2];
- check if you have any GC = pauses during query execution since it can affect execution time = [3]

Also share = the objects you use as keys and values.

[1] https://apacheignite.readme.io/docs/sql-queries#using-explain
[2] https://apacheignite.readme.io/docs/sql-queries#using-h2-debug-= console
[3] https://apacheignite.readme.io/v1.6/docs/jvm-and-system-tuning#= section-detailed-garbage-collection-stats

=E2=80=94
Denis

On May = 25, 2016, at 3:23 AM, Tomek W <rrrtomtomrrr@gmail.com> wrote:

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
|     Node ID8(@), = IP      | CPUs | Heap Used | CPU Load = |   Up Time   |  Size   | Hi/Mi/Rd/Wr = |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
| 0F0AAF99(@n0), 127.0.0.1 | 8    | 54.50 = %   | 3.23 %   | 00:13:13:49 | 3000000 | Hi: = 0       |
|          &n= bsp;           &nbs= p;   |      = |           = |          = |             = |         | Mi: = 0       |
|          &n= bsp;           &nbs= p;   |      = |           = |          = |             = |         | Rd: = 0       |
|          &n= bsp;           &nbs= p;   |      = |           = |          = |             = |         | Wr: = 0       |
+--------------------------------------------------------------= --------------------------------+


I followed your hints. Actually, client doesn't require such many = memory as before - thanks for it.


When it comes to configuration of server, I = also followed your hints, results:

Querying is done by JDBC Client.  In = ignite and postgresql I have single index on column A.

Ignite: SELECT * FROM table WHERE A > = 1345 takes 6s.
Postgres: SELECT * FROM table = WHERE A > 1345 takes 4s.

As you  can see, postgres is still = bettter than Ignite.  I show you significant fragments of my = configuration:
http://pastebin.com/EQC4JPWR

And xml for server file:
http://pastebin.com/enR9h5J4


Try to consider why postgresql = is still better, please.





--

Best regards,
Alexei Scherbakov




--

Best regards,
Alexei Scherbakov




--

Best regards,
Alexei Scherbakov




--

Best regards,
Alexei Scherbakov




--

Best regards,
Alexei Scherbakov




--

Best regards,
Alexei = Scherbakov




--

Best regards,
Alexei = Scherbakov


= --Apple-Mail=_D25FB3D5-075A-4797-B503-DF5F3AE78371--