Hi Riccardo, Starting from 2.0-M3 the allocation of disk-cache based on available memory + used heap is smarter. In your case Level2 cache should always be off, and Level1 cache always be on.
file.mmap.bufferSize works only with "local" storage, so if (as I hope) you're using plocal has no effect. Lvc@ On 6 November 2014 17:28, Riccardo Tasso <riccardo.ta...@gmail.com> wrote: > Any help please? > > Riccardo > > 2014-10-30 8:56 GMT+01:00 Riccardo Tasso <riccardo.ta...@gmail.com>: > >> Just another question. In this moment my embedded database (1.7.8) is >> configured as: >> >> 2014-10-30 08:39:27,970 - INFO - [main] - config.StorageConfig :119 >> - CACHE LEVEL 1 >> 2014-10-30 08:39:27,973 - INFO - [main] - config.StorageConfig :120 >> - enabled: true >> 2014-10-30 08:39:27,973 - INFO - [main] - config.StorageConfig :121 >> - maxSize: 2147483647 >> 2014-10-30 08:39:27,973 - INFO - [main] - config.StorageConfig :123 >> - CACHE LEVEL 2 >> 2014-10-30 08:39:27,973 - INFO - [main] - config.StorageConfig :124 >> - enabled: false >> 2014-10-30 08:39:27,974 - INFO - [main] - config.StorageConfig :125 >> - maxSize: -1 >> >> It means that local cache will store at most 2147483647 records, is it >> right? If I know my records will always be less (for example 1,000,000), >> should I lower the max cache size? What about Cache Level 2? >> >> Let's say my database is 100MB. It's sufficient launch my application >> with the following parameter? >> -Dfile.mmap.bufferSize=100 >> Which is the relationship between CACHE LEVEL 1 and file.mmap.bufferSize? >> >> Thank you, >> Riccardo >> >> >> 2014-10-30 8:24 GMT+01:00 Riccardo Tasso <riccardo.ta...@gmail.com>: >> >>> Thanks Andrey, >>> and what do you suggest me to warm-up cache? >>> Could something like SELECT FROM V; SELECT FROM E will work? >>> >>> Another question: is there a way to print a line of log to see if the >>> results of a given query were in cache? i.e. some way to be sure that >>> everything was cached. >>> >>> Riccardo >>> >>> 2014-10-30 7:16 GMT+01:00 Andrey Lomakin <lomakin.and...@gmail.com>: >>> >>>> Hi, >>>> Just look at amount of space consumed by db files after close. >>>> >>>> On Wed, Oct 29, 2014 at 5:38 PM, Riccardo Tasso < >>>> riccardo.ta...@gmail.com> wrote: >>>> >>>>> >>>>> 2014-10-08 9:12 GMT+02:00 Luigi Dell'Aquila < >>>>> l.dellaqu...@orientechnologies.com>: >>>>> >>>>>> you can rely on a plocal (persistent) storage with enough memory >>>>>> allocated to disk cache to keep in memory all your database >>>>>> >>>>> >>>>> Hi, how can I estimate which is the disk cache required to store the >>>>> whole database in memory? >>>>> >>>>> Cheers, >>>>> Riccardo >>>>> >>>>> -- >>>>> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "OrientDB" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to orient-database+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Andrey Lomakin. >>>> >>>> Orient Technologies >>>> the Company behind OrientDB >>>> >>>> -- >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "OrientDB" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to orient-database+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to orient-database+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
