Re: Defrag?

2021-07-03 Thread Ryan Trollip
A rebuild of the cash reduced the size of the data dramatically.
Apparently ignite is not doing anything to rebalance or clean up pages.
I can't see how anyone using ignite native seriously will not have this
problem.

I wonder if this impacts the indexing also? And could be part of the lousy
performance we are having with ignite native.


On Wed, Jun 30, 2021, 8:27 AM Ryan Trollip  wrote:

> Hey Ilya
>
> It's the data tables that keep growing not the WAL.
> We will try to rebuild the cache and see if that fixes the issue
>
> On Mon, Jun 28, 2021 at 8:46 AM Ilya Kasnacheev 
> wrote:
>
>> Hello!
>>
>> Is it WAL (wal/) that is growing or checkpoint space (db/)? If latter,
>> any specific caches that are growing unbound?
>>
>> If letter, you can try creating a new cache, moving the relevant data to
>> this new cache, switch to using it, and then drop the old cache - should
>> reclaim the space.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пн, 28 июн. 2021 г. в 17:34, Ryan Trollip :
>>
>>> Is this why the native disk storage just keeps growing and does not
>>> reduce after we delete from ignite using SQL?
>>> We are up to 80GB on disk now on some instances. We implemented a custom
>>> archiving feature to move older data out of ignite cache to a PostgresSQL
>>> database but when we delete that data from ignite instance, the disk data
>>> size ignite is using stays the same, and then keeps growing, and
>>> growing
>>>
>>> On Thu, Jun 24, 2021 at 7:10 PM Denis Magda  wrote:
>>>
 Ignite fellows,

 I remember some of us worked on the persistence defragmentation
 features. Has it been merged?

 @Valentin Kulichenko  probably you know
 the latest state.

 -
 Denis

 On Thu, Jun 24, 2021 at 11:59 AM Ilya Kasnacheev <
 ilya.kasnach...@gmail.com> wrote:

> Hello!
>
> You can probably drop the entire cache and then re-populate it via
> loadCache(), etc.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 23 июн. 2021 г. в 21:47, Ryan Trollip :
>
>> Thanks, Ilya, we may have to consider moving back to non-native
>> storage and caching more selectively as the performance degrades when 
>> there
>> is a lot of write/delete activity or tables with large amounts of rows.
>> This is with SQL with indexes and the use of query plans etc.
>>
>> Is there any easy way to rebuild the entire native database after
>> hours? e.g. with a batch run on the weeknds?
>>
>> On Wed, Jun 23, 2021 at 7:39 AM Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com> wrote:
>>
>>> Hello!
>>>
>>> I don't think there's anything ready to use, but "killing
>>> performance" from fragmentation is also not something reported too 
>>> often.
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> ср, 16 июн. 2021 г. в 04:39, Ryan Trollip >> >:
>>>
 We see continual very large growth to data with ignite native. We
 have a very chatty use case that's creating and deleting stuff often. 
 The
 data on disk just keeps growing at an explosive rate. So much so we 
 ported
 this to a DB to see the difference and the DB is much smaller. I was
 searching to see if someone has the same issue. This is also killing
 performance.

 Founds this:

 https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation

 Apparently, there is no auto-rebalancing of pages? or cleanup of
 pages?

 Has anyone implemented a workaround to rebuild the cache and
 indexes say on a weekly basis to get it to behave reasonably?

 Thanks

>>>


Re: Server stuck while joining cluster

2021-07-03 Thread Alexey Kukushkin
Check if you have active transactions running on your Server3 at the time
when Servers 1 and 2 are trying to join. Servers wait for active
transactions to complete before joining the cluster and if a transaction
takes longer than the join timeout (10 seconds by default) the joining node
would be segmented out and never join the cluster again until restarted.
You can use the control script to check active transactions:
https://ignite.apache.org/docs/latest/tools/control-script#transaction-management


чт, 1 июл. 2021 г. в 18:20, Joan Pujol :

> Hi,
>
> I've three servers running tomcat with Ignite 2.10 embedded. If I start
> all the nodes from a cold start (all servers stopped) it works well.
> But if I stop one of the server nodes and restart it again it gets stuck
> joining to the cluster and retrying infinitely with
> WARN  [main] o.a.i.s.d.t.TcpDiscoverySpi - Timed out waiting for message
> delivery receipt and other timeout messages.
>
> Details:
> Server1 (10.114.0.8): Two wars with  Ignite server embedded
> Server2: (10.114.0.13): A war with ignite server embedded
> Server3: (10.114.0.9): A war with Ignite client
>
> The problematic server, is Server1, which gets stuck if it's started while
> the Server3 it's also started.
> If server3 it's stopped then Server1 starts correctly without getting
> stuck.
>
> I attach server log from Server1:
> https://www.dropbox.com/s/2xc4as3qqorq21q/server1.log?dl=0
> And server2: https://www.dropbox.com/s/vtxhhg690aorbvo/server2.log?dl=0
>
> And stacktrace of where the Serv1 gets stuck:
> wait:-1, Object (java.lang)
>
> joinTopology:1179, ServerImpl (org.apache.ignite.spi.discovery.tcp)
> spiStart:472, ServerImpl (org.apache.ignite.spi.discovery.tcp)
> spiStart:2154, TcpDiscoverySpi (org.apache.ignite.spi.discovery.tcp)
> startSpi:278, GridManagerAdapter (org.apache.ignite.internal.managers)
> start:981, GridDiscoveryManager 
> (org.apache.ignite.internal.managers.discovery)
> startManager:1968, IgniteKernal (org.apache.ignite.internal)
> start:1324, IgniteKernal (org.apache.ignite.internal)
> start0:2112, IgnitionEx$IgniteNamedInstance (org.apache.ignite.internal)
> start:1758, IgnitionEx$IgniteNamedInstance (org.apache.ignite.internal)
> start0:1143, IgnitionEx (org.apache.ignite.internal)
> start:663, IgnitionEx (org.apache.ignite.internal)
> start:589, IgnitionEx (org.apache.ignite.internal)
> start:328, Ignition (org.apache.ignite)
>
>
> Configuration can be seen in server1 log but basically nodes are
> configured with multicast but with giving ips of the two server nodes.
>
> Any help or guidance to find the problem will be heavily appreciated.
>
> Cheers,
>
> --
> Joan Jesús Pujol Espinar
>


-- 
Best regards,
Alexey