Hi, Ryan.
Current implementation doesn’t share free pages among cache partitions
when persistence is enabled. This happens because page is bound to
certain partition file and cannot be ‘moved’ and reused in another
partition. And there is no share of free pages among caches. Each
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
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
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.
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
Hello Ryan,
defragmentation is already implemented, your link was correct. The only
documentation that I know existing is located here: [1]
It's an offline process that you trigger on an online node. There's also a
"--defragmentation status" command to check the process for completion.
You
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
wrote:
> Hello!
>
> You can probably drop the entire cache and then
