Re: Binary recovery for a very long time

2020-05-27 Thread Ilya Kasnacheev
Hello! We use H2 engine and we need to create tables within H2. We're not touching much data in the process. I'm not sure this is a factor of slowdown since it fits in 2s here. Regards, -- Ilya Kasnacheev ср, 27 мая 2020 г. в 04:20, 38797715 <38797...@qq.com>: > Hi, > > I enabled debug loggin

Re: Binary recovery for a very long time

2020-05-26 Thread 38797715
Hi, I enabled debug logging and found the following log output: [2020-05-23T21:43:58,397][DEBUG][nio-acceptor-tcp-comm-#28%ClusterName1%][TcpCommunicationSpi] Balancing data [min0=0, minIdx=0, max0=-1, maxIdx=-1] [2020-05-23T21:43:58,405][DEBUG][main][SchemaManager] Creating DB table with SQL:

Re: Binary recovery for a very long time

2020-05-21 Thread Ilya Kasnacheev
Hello! 1. I guess that WAL is read. 2. Unfortunately we do not have truly graceful exit as far as my understanding goes. Regards, -- Ilya Kasnacheev вт, 19 мая 2020 г. в 10:22, 38797715 <38797...@qq.com>: > Hi, > > the following log message: > > [2020-05-12T18:17:57,071][INFO ][main][GridCach

Re: Binary recovery for a very long time

2020-05-19 Thread 38797715
Hi, the following log message: [2020-05-12T18:17:57,071][INFO ][main][GridCacheProcessor] Started cache in recovery mode [name=CO_CO_LINE_NEW, id=1742991829, dataRegionName=default, mode=PARTITIONED, atomicity=ATOMIC, backups=1, mvcc=false] I have the following questions: 1.What has been d

Re: Binary recovery for a very long time

2020-05-18 Thread Ilya Kasnacheev
Hello! Direct IO module is experimental and should not be used unless performance is tested first, in your specific use case. Regards, -- Ilya Kasnacheev пн, 18 мая 2020 г. в 16:47, 38797715 <38797...@qq.com>: > Hi, > > If direct IO is disabled, the startup speed will be doubled, including >

Re: Binary recovery for a very long time

2020-05-18 Thread 38797715
Hi, If direct IO is disabled, the startup speed will be doubled, including some other tests. I find that direct IO has a great impact on the read performance. 在 2020/5/14 上午5:16, Evgenii Zhuravlev 写道: Can you share full logs from all nodes? вт, 12 мая 2020 г. в 18:24, 38797715 <38797...@qq.

Re: Binary recovery for a very long time

2020-05-13 Thread Evgenii Zhuravlev
Can you share full logs from all nodes? вт, 12 мая 2020 г. в 18:24, 38797715 <38797...@qq.com>: > Hi Evgenii, > > The storage used is not SSD. > > We will use different versions of ignite for further testing, such as > ignite2.8. > Ignite is configured as follows: > > http://www.springframework.

Re: Binary recovery for a very long time

2020-05-12 Thread 38797715
Hi Evgenii, The storage used is not SSD. We will use different versions of ignite for further testing, such as ignite2.8. Ignite is configured as follows: http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.springf

Re: Binary recovery for a very long time

2020-05-12 Thread Evgenii Zhuravlev
Hi, Can you share full logs and configuration? What disk so you use? Evgenii вт, 12 мая 2020 г. в 06:49, 38797715 <38797...@qq.com>: > Among them: > CO_CO_NEW: ~ 48 minutes(partitioned,backup=1,33M) > > Ignite sys cache: ~ 27 minutes > > PLM_ITEM:~3 minutes(repicated,1.9K) > > > 在 2020/5/12 下午9

Re: Binary recovery for a very long time

2020-05-12 Thread 38797715
Among them: CO_CO_NEW: ~ 48 minutes(partitioned,backup=1,33M) Ignite sys cache: ~ 27 minutes PLM_ITEM:~3 minutes(repicated,1.9K) 在 2020/5/12 下午9:08, 38797715 写道: Hi community, We have 5 servers, 16 cores, 256g memory, and 200g off-heap memory. We have 7 tables to test, and the data volume i

Binary recovery for a very long time

2020-05-12 Thread 38797715
Hi community, We have 5 servers, 16 cores, 256g memory, and 200g off-heap memory. We have 7 tables to test, and the data volume is respectively:31.8M,495.2M,552.3M,33M,873.3K,28M,1.9K(replicated),others are partitioned(backup = 1) VM args:-server -Xms20g -Xmx20g -XX:+AlwaysPreTouch -XX:+UseG1