[jira] [Created] (IGNITE-14193) Initialize configuration tree with default values on first start
Ivan Bessonov created IGNITE-14193: -- Summary: Initialize configuration tree with default values on first start Key: IGNITE-14193 URL: https://issues.apache.org/jira/browse/IGNITE-14193 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov Conceptually we have the following picture: every possible configuration has non-null value. The problem is the exact moment when you save values not initialized by the user. This routine must be part of node lifecycle, of course, but implementation is not very trivial and used exclusively in lifecycle, which means that it can't be implemented as a part of other more abstract task. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: IGNITE-12508
Thank you! I have updated the PR per your comments. On Tue, Feb 16, 2021 at 9:29 PM Ilya Kasnacheev wrote: > > Hello! > > I have left some comments to the PR. > > Regards, > -- > Ilya Kasnacheev > > > пн, 15 февр. 2021 г. в 18:55, Atri Sharma : > > > Hi all, > > > > I have raised a PR for IGNITE-12508: > > > > https://github.com/apache/ignite/pull/8802 > > > > Requesting inputs and feedback on the same, please. > > > > Regards, > > > > Atri > > > > -- > > Regards, > > > > Atri > > Apache Concerted > > -- Regards, Atri Apache Concerted
[Community] First Ignite Summit: May 25, 2021. How can you help
Hi, Igniters! It’s time to shine the spotlight on Apache Ignite—time for all of us to offer our knowledge and expertise to the broader developer community! On May 25, the first Ignite Summit will be held online: https://ignite-summit.org The idea is to share architectural best practices from Ignite users' experience, meet Ignite developers, and develop expertise. How can you help? 1)Call for Papers is open. Share your Ignite stories and provide information that helps others to deploy and manage Apache Ignite. We need your support to make the first Summit a valuable learning experience and introduce people to Apache Ignite! To submit a proposal, go to https://sessionize.com/ignite-summit. 2)Help to spread the word about Ignite Summit. Repost https://twitter.com/ApacheIgnite/status/1361730371784695820 or respond to it and tell Program Committee which topics you want to be covered and whom you suggest inviting as the speakers (#ignitesummit). 3) Fill out the survey that can help to make the event more comfortable for attendees and promote Summit among developers: https://cutt.ly/RkAUHQS Thank you in advance! -- Cheers, Kseniya Devrel at GridGain Don't miss upcoming community events, join https://www.meetup.com/Apache-Ignite-Virtual-Meetup/
SpringOne 2021 - Call for papers open
Hi, The SpringOne 2021 annual conference is accepting call for papers. https://springone.io/ We have multiple modules contributed and maintained in Apache Ignite Extensions like Springboot Autoconfigure, Spring Data module. I was hoping we can propose a talk on the same. Regards, Saikat
Re: Ignite website css not loading in local dev
Denis, Ivan Thank you for your reply. I have not been able to troubleshoot further, I will look into it and share more details. My apologies for the late response. Regards, Saikat On Tue, Feb 2, 2021 at 9:27 AM Ivan Daschinsky wrote: > Ops, i'm very sorry. Really, nothing common with docs. > > пн, 1 февр. 2021 г. в 16:10, Denis Magda : > > > Ivan, > > > > Saikat is updating the page below which doesn’t not belong to the docs > and > > doesn’t not require a Jekyll setup: > > > > https://ignite.apache.org/features/streaming.html > > > > On Sunday, January 31, 2021, Ivan Daschinsky > wrote: > > > > > Saikat, have you tried build and run locally docs using docker? I just > > > tried latest master -- everything is working as expected. > > > Checked this in chrome incognito mode. I usually check docs locally > using > > > these steps: > > > 1 cd docs > > > 2. docker run -v "$PWD:/srv/jekyll" -p 4000:4000 jekyll/jekyll:latest > > > jekyll s > > > 3. Go to http://0.0.0.0:4000/docs/ in chrome incognito tab. > > > > > > пн, 1 февр. 2021 г. в 07:09, Denis Magda : > > > > > > > Saikat, > > > > > > > > Attach the screenshot with what you see. Please also check what > errors > > > the > > > > browser is printing out while rendering the page. > > > > > > > > You don't need to install Jekyll unless you build the docs locally. > So, > > > > skip this step. Also, you don't need to uncomment the "include > > virtual". > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Sun, Jan 31, 2021 at 1:35 PM Saikat Maitra < > saikat.mai...@gmail.com > > > > > > > wrote: > > > > > > > > > Hi Denis, Ivan > > > > > > > > > > Thank you for your email. I have verified the below lines in > > httpd.conf > > > > > > > > > > AddType text/html .html > > > > > AddOutputFilter INCLUDES .html > > > > > > > > > > I have also pull latest changes from master. > > > > > > > > > > I still see the issue in local, let me check if I need to make any > > > > > other changes. > > > > > > > > > > Also another change I did is I omitted the /trunk path from the > > > Document > > > > > root and used path till ignite-website since we are no longer using > > > svn. > > > > > > > > > > I have a question related to Jekyll, do I need to install Jekyll to > > run > > > > the > > > > > website in local? > > > > > > > > > > Also I have observed few additional lines commented in the > index.html > > > > like > > > > > below > > > > > > > > > > > > > > > > > > > > I will check if uncommenting them addresses the issue. > > > > > > > > > > Regards, > > > > > Saikat > > > > > > > > > > > > > > > > > > > > On Sun, Jan 31, 2021 at 12:08 PM Ivan Daschinsky < > > ivanda...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hi, Saikat. Do you have > > > > > https://issues.apache.org/jira/browse/IGNITE-13659 > > > > > > commit in yout local branch? > > > > > > In this patch, this issue was solved. Namely, > > > docs/assets/css/docs.scss > > > > > > and docs/assets/css/styles.scss are corrected. > > > > > > Jekyll required that in custom stiles, first two lines contains > > this > > > > char > > > > > > sequence `---` > > > > > > > > > > > > вс, 31 янв. 2021 г. в 03:09, Denis Magda : > > > > > > > > > > > > > Hi Saikat, > > > > > > > > > > > > > > Please double check that you configured the Apache server > > strictly > > > > > > > following steps 3-5. As far as I remember, I had the exact CSS > > > issue > > > > > > until > > > > > > > did this (step 5): > > > > > > > > > > > > > > AddType text/html .html > > > > > > > AddOutputFilter INCLUDES .html > > > > > > > > > > > > > > > > > > > > > - > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Sat, Jan 30, 2021 at 1:38 PM Saikat Maitra < > > > > saikat.mai...@gmail.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I was working on updating the ignite-website page[1] for > Ignite > > > > > > > Extensions > > > > > > > > and I observed that in local when we are running the > > > ignite-website > > > > > > then > > > > > > > it > > > > > > > > is not loading the css. > > > > > > > > > > > > > > > > I have followed the instructions as mentioned in confluence > > > > page[2] > > > > > > > > > > > > > > > > [1] https://ignite.apache.org/features/streaming.html > > > > > > > > [2] > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Website+Development > > > > > > > > > > > > > > > > Are there any additional steps that need to be done? > > > > > > > > > > > > > > > > I also noted that the source in live website pages vs the > local > > > is > > > > > > > > different in terms of js and css files. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Saikat > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Sincerely yours, Ivan Daschinskiy > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Sincerely yours, Ivan Daschinskiy > > > > > > > > > -- > > - > > Denis > > > > > -- > Sincerely yours, Ivan
Re: IGNITE-12508
Hello! I have left some comments to the PR. Regards, -- Ilya Kasnacheev пн, 15 февр. 2021 г. в 18:55, Atri Sharma : > Hi all, > > I have raised a PR for IGNITE-12508: > > https://github.com/apache/ignite/pull/8802 > > Requesting inputs and feedback on the same, please. > > Regards, > > Atri > > -- > Regards, > > Atri > Apache Concerted >
[jira] [Created] (IGNITE-14192) Add modules/ducktests/tests/certs/ to .gitignore
Sergei Ryzhov created IGNITE-14192: -- Summary: Add modules/ducktests/tests/certs/ to .gitignore Key: IGNITE-14192 URL: https://issues.apache.org/jira/browse/IGNITE-14192 Project: Ignite Issue Type: Task Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov Add modules/ducktests/tests/certs/ to .gitignore -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Adding metrics of using WAL archive
Hi, Zhenya! Users can also use it, I see nothing wrong with the presence of two metrics. 16.02.2021, 16:50, "Zhenya Stanilovsky" : > Kirill, is it good practice to have a metrics for internal use? Don`t think > so. > +1 witk Nikolay size is more readable than abstract segments count. > >> Hi, Nikolay! >> >> For internal use, leave the metric that I propose and also add the metric: >> Count of bytes logged in WAL. Why not "written" because for the mmap we >> cannot track when the physical writting will occur. >> >> 16.02.2021, 15:42, "Nikolay Izhikov" < nizhi...@apache.org >: >>> Kirill. >>> >>> «Count of segments» is a very internal thing for a regular user. >>> Regular user don’t want to know about such things. >>> >>> You suggest to calculate the number (space required to store WAL) with >>> some kind of rough calculation, and with the «Count of bytes written in >>> WAL» we can have exact number without any suggestions or calculations. >>> >>> Moreover, «Count of bytes written in WAL» is independent on internal WAL >>> implementation. >>> >>> So, I think exact number is always better to have then some approximation. >>> >>> What do you think? >>> 15 февр. 2021 г., в 20:45, ткаленко кирилл < tkalkir...@yandex.ru > написал(а): Hi, Nikolay! We set the number of segments in the working directory, we also delete by segment, it seems that this is a matter of usability. I prefer to dwell on my own version, this is a simple metric that does not hurt and you can add more as needed. 15.02.2021, 17:10, "Nikolay Izhikov" < nizhi...@apache.org >: > My suggestion that «count of files» is meaningless number. > And «count of bytes written to the files» is useful number to know and > use for capacity planning.. > >> 15 февр. 2021 г., в 15:59, ткаленко кирилл < tkalkir...@yandex.ru > >> написал(а): >> >> Hi, Nikolay! >> >> There may be a number (count of segments * segment size) or there may >> be a count of segments, whichever is more convenient for the user. >> >> 15.02.2021, 13:14, "Nikolay Izhikov" < nizhi...@apache.org >: >>> Hello, Kirill. >>> >>> Thanks for an answers. >>> Now, I understand your intentions. >>> t also seems that it will be more natural to operate not just bytes but multiples of a segment. >>> >>> Can’t agree here. >>> From my point of view - it’s better to know exact number, not just >>> «count of segments». >>> 15 февр. 2021 г., в 13:00, ткаленко кирилл < tkalkir...@yandex.ru > написал(а): Hello, Nikolay! The period of one day (24h) seems more natural, you can take more or less, I think that one day may not be enough, and it is worth getting the metric for several days (collect statistics) for example a week. Yes, the total size of the segments may not be DataStorageConfiguration#getMaxWalArchiveSize, but for capacity planning, accuracy is not so important to us, since the load can always change, it will hurt users more if we overflow the archive and it will not be able to start the node. So to say that more is better than less, it also seems that it will be more natural to operate not just bytes but multiples of a segment. In separate threads, you can discuss the metric that you propose about page memory and indexes estimates. 14.02.2021, 11:54, "Nikolay Izhikov" < nizhi...@apache.org >: > Hello, Kirill > > Your conclusions still not clear for me. > >> It is not possible for us to estimate how much space a user >> will need in the archive so as not to overflow it under its load >> We take the maximum 44 and multiply it by a >> DataStorageConfiguration#getWalSegmentSize > > Why you take a single day (24h) for a standard period? Is there > any rationale behind this? > > 1. We have `walAutoArchiveAfterInactivity` property. So WAL > segment can have a size less than the maximum. > 2. For CDC feature I want to introduce «WAL force rollover > timeout» to make data available for a consumer in a guaranteed period > [1]. > > Why does the user want to estimate those numbers in the first > place? > Are we talking about some kind of capacity planning? > > If yes, then maybe it will be better to have a metric for a count > of bytes written in the WAL? > With it, we will have an exact number of space we need for WAL. > > How user should estimate capacity for a page memory and indexes? > >
Re[2]: Adding metrics of using WAL archive
Kirill, is it good practice to have a metrics for internal use? Don`t think so. +1 witk Nikolay size is more readable than abstract segments count. >Hi, Nikolay! > >For internal use, leave the metric that I propose and also add the metric: >Count of bytes logged in WAL. Why not "written" because for the mmap we cannot >track when the physical writting will occur. > >16.02.2021, 15:42, "Nikolay Izhikov" < nizhi...@apache.org >: >> Kirill. >> >> «Count of segments» is a very internal thing for a regular user. >> Regular user don’t want to know about such things. >> >> You suggest to calculate the number (space required to store WAL) with some >> kind of rough calculation, and with the «Count of bytes written in WAL» we >> can have exact number without any suggestions or calculations. >> >> Moreover, «Count of bytes written in WAL» is independent on internal WAL >> implementation. >> >> So, I think exact number is always better to have then some approximation. >> >> What do you think? >> >>> 15 февр. 2021 г., в 20:45, ткаленко кирилл < tkalkir...@yandex.ru > >>> написал(а): >>> >>> Hi, Nikolay! >>> >>> We set the number of segments in the working directory, we also delete by >>> segment, it seems that this is a matter of usability. I prefer to dwell on >>> my own version, this is a simple metric that does not hurt and you can add >>> more as needed. >>> >>> 15.02.2021, 17:10, "Nikolay Izhikov" < nizhi...@apache.org >: My suggestion that «count of files» is meaningless number. And «count of bytes written to the files» is useful number to know and use for capacity planning.. > 15 февр. 2021 г., в 15:59, ткаленко кирилл < tkalkir...@yandex.ru > > написал(а): > > Hi, Nikolay! > > There may be a number (count of segments * segment size) or there may > be a count of segments, whichever is more convenient for the user. > > 15.02.2021, 13:14, "Nikolay Izhikov" < nizhi...@apache.org >: >> Hello, Kirill. >> >> Thanks for an answers. >> Now, I understand your intentions. >> >>> t also seems that it will be more natural to operate not just bytes >>> but multiples of a segment. >> >> Can’t agree here. >> From my point of view - it’s better to know exact number, not just >> «count of segments». >> >>> 15 февр. 2021 г., в 13:00, ткаленко кирилл < tkalkir...@yandex.ru > >>> написал(а): >>> >>> Hello, Nikolay! >>> >>> The period of one day (24h) seems more natural, you can take more or >>> less, I think that one day may not be enough, and it is worth getting >>> the metric for several days (collect statistics) for example a week. >>> Yes, the total size of the segments may not be >>> DataStorageConfiguration#getMaxWalArchiveSize, but for capacity >>> planning, accuracy is not so important to us, since the load can always >>> change, it will hurt users more if we overflow the archive and it will >>> not be able to start the node. So to say that more is better than less, >>> it also seems that it will be more natural to operate not just bytes >>> but multiples of a segment. >>> >>> In separate threads, you can discuss the metric that you propose >>> about page memory and indexes estimates. >>> >>> 14.02.2021, 11:54, "Nikolay Izhikov" < nizhi...@apache.org >: Hello, Kirill Your conclusions still not clear for me. > It is not possible for us to estimate how much space a user will > need in the archive so as not to overflow it under its load > We take the maximum 44 and multiply it by a > DataStorageConfiguration#getWalSegmentSize Why you take a single day (24h) for a standard period? Is there any rationale behind this? 1. We have `walAutoArchiveAfterInactivity` property. So WAL segment can have a size less than the maximum. 2. For CDC feature I want to introduce «WAL force rollover timeout» to make data available for a consumer in a guaranteed period [1]. Why does the user want to estimate those numbers in the first place? Are we talking about some kind of capacity planning? If yes, then maybe it will be better to have a metric for a count of bytes written in the WAL? With it, we will have an exact number of space we need for WAL. How user should estimate capacity for a page memory and indexes? [1] https://issues.apache.org/jira/browse/IGNITE-13582 > 14 февр. 2021 г., в 09:48, ткаленко кирилл < tkalkir...@yandex.ru > > написал(а): > > Hi, Nikolay! > > The user will be able to take the getLastArchivedSegmentIndex >
[jira] [Created] (IGNITE-14191) Add command to control.(sh|bin) to manage performance statistics
Amelchev Nikita created IGNITE-14191:
Summary: Add command to control.(sh|bin) to manage performance
statistics
Key: IGNITE-14191
URL: https://issues.apache.org/jira/browse/IGNITE-14191
Project: Ignite
Issue Type: New Feature
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
Fix For: 2.11
Add command to control.(sh|bin) to manage performance statistics:
{noformat}
--perf-stat [start|stop|started]
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Adding metrics of using WAL archive
Hi, Nikolay! For internal use, leave the metric that I propose and also add the metric: Count of bytes logged in WAL. Why not "written" because for the mmap we cannot track when the physical writting will occur. 16.02.2021, 15:42, "Nikolay Izhikov" : > Kirill. > > «Count of segments» is a very internal thing for a regular user. > Regular user don’t want to know about such things. > > You suggest to calculate the number (space required to store WAL) with some > kind of rough calculation, and with the «Count of bytes written in WAL» we > can have exact number without any suggestions or calculations. > > Moreover, «Count of bytes written in WAL» is independent on internal WAL > implementation. > > So, I think exact number is always better to have then some approximation. > > What do you think? > >> 15 февр. 2021 г., в 20:45, ткаленко кирилл >> написал(а): >> >> Hi, Nikolay! >> >> We set the number of segments in the working directory, we also delete by >> segment, it seems that this is a matter of usability. I prefer to dwell on >> my own version, this is a simple metric that does not hurt and you can add >> more as needed. >> >> 15.02.2021, 17:10, "Nikolay Izhikov" : >>> My suggestion that «count of files» is meaningless number. >>> And «count of bytes written to the files» is useful number to know and use >>> for capacity planning.. >>> 15 февр. 2021 г., в 15:59, ткаленко кирилл написал(а): Hi, Nikolay! There may be a number (count of segments * segment size) or there may be a count of segments, whichever is more convenient for the user. 15.02.2021, 13:14, "Nikolay Izhikov" : > Hello, Kirill. > > Thanks for an answers. > Now, I understand your intentions. > >> t also seems that it will be more natural to operate not just bytes >> but multiples of a segment. > > Can’t agree here. > From my point of view - it’s better to know exact number, not just > «count of segments». > >> 15 февр. 2021 г., в 13:00, ткаленко кирилл >> написал(а): >> >> Hello, Nikolay! >> >> The period of one day (24h) seems more natural, you can take more or >> less, I think that one day may not be enough, and it is worth getting >> the metric for several days (collect statistics) for example a week. >> Yes, the total size of the segments may not be >> DataStorageConfiguration#getMaxWalArchiveSize, but for capacity >> planning, accuracy is not so important to us, since the load can always >> change, it will hurt users more if we overflow the archive and it will >> not be able to start the node. So to say that more is better than less, >> it also seems that it will be more natural to operate not just bytes but >> multiples of a segment. >> >> In separate threads, you can discuss the metric that you propose >> about page memory and indexes estimates. >> >> 14.02.2021, 11:54, "Nikolay Izhikov" : >>> Hello, Kirill >>> >>> Your conclusions still not clear for me. >>> It is not possible for us to estimate how much space a user will need in the archive so as not to overflow it under its load We take the maximum 44 and multiply it by a DataStorageConfiguration#getWalSegmentSize >>> >>> Why you take a single day (24h) for a standard period? Is there any >>> rationale behind this? >>> >>> 1. We have `walAutoArchiveAfterInactivity` property. So WAL segment >>> can have a size less than the maximum. >>> 2. For CDC feature I want to introduce «WAL force rollover timeout» >>> to make data available for a consumer in a guaranteed period [1]. >>> >>> Why does the user want to estimate those numbers in the first place? >>> Are we talking about some kind of capacity planning? >>> >>> If yes, then maybe it will be better to have a metric for a count of >>> bytes written in the WAL? >>> With it, we will have an exact number of space we need for WAL. >>> >>> How user should estimate capacity for a page memory and indexes? >>> >>> [1] https://issues.apache.org/jira/browse/IGNITE-13582 >>> 14 февр. 2021 г., в 09:48, ткаленко кирилл написал(а): Hi, Nikolay! The user will be able to take the getLastArchivedSegmentIndex every day and remember it and do it, say, for several days. For example, when starting the application, the getLastArchivedSegmentIndex is 0, then at the end of the first day the value will be 30 at the end of the second 55 and at the end of the third 99. It turns out that 30 segments were used for the first day, 25 for the second and 44 for the third. We take the maximum 44 and
Re: Adding metrics of using WAL archive
Kirill. «Count of segments» is a very internal thing for a regular user. Regular user don’t want to know about such things. You suggest to calculate the number (space required to store WAL) with some kind of rough calculation, and with the «Count of bytes written in WAL» we can have exact number without any suggestions or calculations. Moreover, «Count of bytes written in WAL» is independent on internal WAL implementation. So, I think exact number is always better to have then some approximation. What do you think? > 15 февр. 2021 г., в 20:45, ткаленко кирилл написал(а): > > Hi, Nikolay! > > We set the number of segments in the working directory, we also delete by > segment, it seems that this is a matter of usability. I prefer to dwell on my > own version, this is a simple metric that does not hurt and you can add more > as needed. > > 15.02.2021, 17:10, "Nikolay Izhikov" : >> My suggestion that «count of files» is meaningless number. >> And «count of bytes written to the files» is useful number to know and use >> for capacity planning.. >> >>> 15 февр. 2021 г., в 15:59, ткаленко кирилл >>> написал(а): >>> >>> Hi, Nikolay! >>> >>> There may be a number (count of segments * segment size) or there may be a >>> count of segments, whichever is more convenient for the user. >>> >>> 15.02.2021, 13:14, "Nikolay Izhikov" : Hello, Kirill. Thanks for an answers. Now, I understand your intentions. > t also seems that it will be more natural to operate not just bytes but > multiples of a segment. Can’t agree here. From my point of view - it’s better to know exact number, not just «count of segments». > 15 февр. 2021 г., в 13:00, ткаленко кирилл > написал(а): > > Hello, Nikolay! > > The period of one day (24h) seems more natural, you can take more or > less, I think that one day may not be enough, and it is worth getting the > metric for several days (collect statistics) for example a week. Yes, the > total size of the segments may not be > DataStorageConfiguration#getMaxWalArchiveSize, but for capacity planning, > accuracy is not so important to us, since the load can always change, it > will hurt users more if we overflow the archive and it will not be able > to start the node. So to say that more is better than less, it also seems > that it will be more natural to operate not just bytes but multiples of a > segment. > > In separate threads, you can discuss the metric that you propose about > page memory and indexes estimates. > > 14.02.2021, 11:54, "Nikolay Izhikov" : >> Hello, Kirill >> >> Your conclusions still not clear for me. >> >>> It is not possible for us to estimate how much space a user will >>> need in the archive so as not to overflow it under its load >>> We take the maximum 44 and multiply it by a >>> DataStorageConfiguration#getWalSegmentSize >> >> Why you take a single day (24h) for a standard period? Is there any >> rationale behind this? >> >> 1. We have `walAutoArchiveAfterInactivity` property. So WAL segment >> can have a size less than the maximum. >> 2. For CDC feature I want to introduce «WAL force rollover timeout» to >> make data available for a consumer in a guaranteed period [1]. >> >> Why does the user want to estimate those numbers in the first place? >> Are we talking about some kind of capacity planning? >> >> If yes, then maybe it will be better to have a metric for a count of >> bytes written in the WAL? >> With it, we will have an exact number of space we need for WAL. >> >> How user should estimate capacity for a page memory and indexes? >> >> [1] https://issues.apache.org/jira/browse/IGNITE-13582 >> >>>14 февр. 2021 г., в 09:48, ткаленко кирилл >>> написал(а): >>> >>>Hi, Nikolay! >>> >>>The user will be able to take the getLastArchivedSegmentIndex every >>> day and remember it and do it, say, for several days. >>> >>>For example, when starting the application, the >>> getLastArchivedSegmentIndex is 0, then at the end of the first day the >>> value will be 30 at the end of the second 55 and at the end of the >>> third 99. >>>It turns out that 30 segments were used for the first day, 25 for >>> the second and 44 for the third. We take the maximum 44 and multiply it >>> by a DataStorageConfiguration#getWalSegmentSize, and we get the >>> possible maximum that the archive overflow was the least likely. If the >>> user uses compression, then it can be subtracted from the result >>> (result * getMaxSizeCompressedArchivedSegment). >>> >>>13.02.2021, 10:47, "Nikolay Izhikov" : Hello, Kirill.
[jira] [Created] (IGNITE-14190) control.sh --cache idle_verify --dump --host 'hostname' creates a dump file on a random host if param --host is the hostname
Sergei Ryzhov created IGNITE-14190: -- Summary: control.sh --cache idle_verify --dump --host 'hostname' creates a dump file on a random host if param --host is the hostname Key: IGNITE-14190 URL: https://issues.apache.org/jira/browse/IGNITE-14190 Project: Ignite Issue Type: Task Components: control.sh Reporter: Sergei Ryzhov control.sh --cache idle_verify --dump --host 'hostname' creates a dump file on a random host if param --host is the hostname if param --host is the ip-address, then the file will be on the node whose ip-address was transferred -- This message was sent by Atlassian Jira (v8.3.4#803005)
