Guys, I created a ticket [1] summing up results of our discussion. Please review and leave comments if something is still unclear there.
Thanks, Sergey [1] https://issues.apache.org/jira/browse/IGNITE-5375 On Wed, May 31, 2017 at 11:56 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > Denis, I do agree, the concept of virtual memory may work. I will start > another discussion thread on that. > > We should extensively javadoc all these interfaces. The current one-liner > javadoc documentation is not enough. > > Also, I would like to make a small correction to the MemoryMetrics > interface, see below... > > > On Wed, May 31, 2017 at 1:35 PM, Denis Magda <dma...@apache.org> wrote: > > > Guys, > > If to assume that the *page memory* is a sort of *virtual* memory that > > maps a page to RAM or disk then MemoryMetrics interface makes sense if we > > think of it as {Virtual}MemoryMetrics. It’s late to rename the interface > > but this design flaw can be handled with a proper documentation. > > At all, let’s gather all the page memory related metrics (both RAM and > > disk) in MemoryMetrics interface. Here is it’s final version: > > public interface MemoryMetrics { > > public String getName(); > > > > public long getTotalAllocatedPages(); > > > I think this method currently returns only the pages allocated in memory. > To behave correctly, it now should return the total pages allocated within > the virtual memory, which should be equal to the total pages on disk. > > > > public long getPagesOnDisk(); > > > > This method should be removed as it represents the same value as > "getTotalAllocatedPages()" method. Instead, we should add the following > method: > > // Returns the number of pages allocated in physical off-heap memory. > getPhysicalMemoryPages(); > > > > > > public long getDirtyPages(); > > > > public float getAllocationRate(); > > > > public float getEvictionRate(); > > > > public float getPagesFillFactor(); > > > > public double getPagesMissRate(); > > > > public float getLargeEntriesPagesPercentage(); > > } > > I would rename getAllocationRate and getEvitionRate to > > getPagesAllocationRate and getEvictionRates respectively but then we need > > to deprecate the existing methods which is not good. > > > > As for the persistence metrics related to WAL and checkpointing let’s > > store them here: > > > > public interface PersistentStoreMetrics { > > public double getWalLoggingRate(); > > > > public int getWalArchiveSegments(); > > > > public double getWalFsyncTime(); > > > > public double getCheckpointingTime(); > > > > public double getCheckpointingFsyncTime(); > > > > public long getCheckpointingTotalPagesNumber(); > > > > public long[] getCheckpointingPagesByTypeNumber(); > > > > public long getCheckpointingCopiedOnWritePagesNumber(); > > } > > > > Comments on the name of non released methods are welcomed. > > > > — > > Denis > > > > > On May 30, 2017, at 2:59 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > > wrote: > > > > > > On Tue, May 30, 2017 at 2:46 PM, Denis Magda <dma...@apache.org> > wrote: > > > > > >> I don’t have any extra metrics in mind for now. All I want to say that > > >> presently the Store metrics interface aggregates WAL and checkpointing > > >> metrics and in the future we might add additional Store related > metrics > > >> there (that has nothing to do with WAL). So, this is why > > IgniteWalMetrics > > >> doesn’t sound like a generic interface. > > >> > > > > > > I think it is getting more and more confusing. I, for instance, do not > > > understand where memory metrics end and storage begins, neither I think > > it > > > is important to separate memory policy related metrics from the WAL or > > > Checkpoint related metrics. > > > > > > How about we put them all together and have clear method names? > > > > > > > > >> > > >> — > > >> Denis > > >> > > >>> On May 30, 2017, at 2:39 PM, Dmitriy Setrakyan < > dsetrak...@apache.org> > > >> wrote: > > >>> > > >>> On Tue, May 30, 2017 at 1:22 PM, Denis Magda <dma...@apache.org> > > wrote: > > >>> > > >>>> I’m afraid that in the future we might need to add non WAL related > > >> metrics > > >>>> under this interface. This is why it might make sense to keep the > name > > >>>> generic. > > >>>> > > >>> > > >>> Hm... I am not sure we are going to have any other components in > > addition > > >>> to WAL and Store here. What do you have in mind? > > >> > > >> > > > > >
