Ferdinando, the cache holds data previously accessed, in memory. This makes future access to the same data faster, as the computer does not have to re-read the source data from the hard drive. RAM is about 1000x faster then a hard disk drive, (nano sec access for RAM, millisec access times for hard drives).
Having data in the cache *is a good thing* and will increase the speed of your program. If your cache is set to be too large, you may not leave enough memory (RAM) for the OS or the rest of 4D, or other program(s) running on the same computer. This will have a compounding effect, as the OS will then start to use virtual memory (memory slices stored on the hard disk), which means EVEN MORE hard disk accessing slowing the machine further. if you are running a 32 bit OS (look under control panel -> system -> general (I think) ) you should see some information about the computer, the OS, and whether it is 32 or 64 bit. as I said in a previous message a 32 bit OS can NOT access more then ~3.5 gig of ram, REGARDLESS of actual RAM installed. If you are running a 32 bit OS, and have a cache setting of say 3gig (3000MB) you are not leaving enough for other operations. Similarly, if you have 32gig of RAM in a 64 bit OS, and allocate 31.5 gig of RAM to the cache, you are not allowing enough room for other operations. Others may have different opinions on this, if you are running nothing but server on the machine - I would suggest that you start by setting the cache to approximately 50% of available RAM (set it to 1.75gig under 32 bit OS, 1/2 of installed RAM under 64 bit). run the program for a while, see what happens. If things are good - leave it alone, if things are not try adjusting the size of the cache, again. larger if 4D is the only thing running, smaller if there are other programs/services running. Chip P.S. get your database running on an SSD - this increases 'hard rive' access speeds significantly (10x I believe). On Wed, 18 Dec 2019 16:58:34 +0100, stardata.info via 4D_Tech wrote: > Hi David, > > I come back to you to let you know that the problem that i had told > you about in the first post is persisting. > > Now i noticed that the cache that is occupied keep raising on every > interaction that the client make with the server or more specific > with the database. > > At this reguard i thought that closing the clients could have free > all the cache that was occupied but wasn't as i supposed, so even > closing all the clients i got still cache occupied. > > I can't find a way to free the cache and this leads me to having all > of it full making my software very slow. > > Hoping to hear you soon.. > > Best reguards, > > Ferdinando > > Il 18/12/19 13:29, stardata.info ha scritto: >> >> Hi David, >> >> Thanks for your indications. >> >> Ferdinando >> >> Il 18/12/19 13:03, David Samson ha scritto: >>> That is not such big data. Some places have 300GB of data. Maybe >>> your cache is set too small on 4D server. Attached is an old >>> document but it still explains the basics. >>> >>> David >>> >>> On Tue, 17 Dec 2019 at 18:28, stardata.info <http://stardata.info> >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> 10.385.729 Data file >>> >>> 2.466.497 Index file >>> >>> Window server 2016 64 Bit >>> >>> Xeon E5 2620 v3 >>> >>> 16 Gb ram >>> >>> >>> >>> Il 17/12/19 18:43, David Samson ha scritto: >>>> The suggestions on the NUG make sense. >>>> "After some hours of use the application slows down."this sounds >>>> like the memory is getting full. How much RAM is on the server >>>> and how big is your data file? >>>> >>>> On Tue, 17 Dec 2019 at 14:02, stardata.info >>>> <http://stardata.info> <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi David, >>>> >>>> I understand you observation, but i notice that if i restart >>>> the application, the problme is solved. After some hours of >>>> use the application slows down. >>>> >>>> Thanks >>>> >>>> Ferdinando >>>> >>>> Il 17/12/19 13:40, David Samson ha scritto: >>>>> This sounds like a network problem - not 4D. We had a >>>>> similar thing and when they restarted the network switch >>>>> all was OK. >>>>> >>>>> David >>>>> >>>>> >>>>> >>>>> >>>>> Message: 1 >>>>> Date: Fri, 13 Dec 2019 18:50:51 +0100 >>>>> From: "stardata.info <http://stardata.info>" >>>>> <[email protected] <mailto:[email protected]>> >>>>> To: Tom Benedict <[email protected] >>>>> <mailto:[email protected]>>, 4D iNug Technical >>>>> <[email protected] <mailto:[email protected]>> >>>>> Cc: [email protected] >>>>> <mailto:[email protected]> >>>>> Subject: Re: FLUSH BUFFER >>>>> Message-ID: >>>>> <[email protected] >>>>> <mailto:[email protected]>> >>>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>>> >>>>> I notice that in some casual circumstances, 4D client of my >>>>> application, >>>>> have latency in the front end operations. >>>>> >>>>> I click, but the client is not responsive. >>>>> >>>>> After some seconds or one minute, all restart normally. >>>>> >>>>> I've noticed that before the unlock, I have one peak of >>>>> traffic in the >>>>> network. Seem that the client is stopped to wait for the >>>>> server response. >>>>> >>>>> Does someone have a suggestion? >>>>> >>>>> Thanks >>>>> >>>>> Ferdinando >>>>> >>>>> -- D Samson >>>> >>>> >>>> >>>> -- D Samson >>> >>> >>> >>> -- >>> D Samson > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** We have done so much, with so little, for so long; We are now qualified to anything with nothing <sigh> - unknown ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
