Re: FLUSH BUFFER
On Dec 18, 2019, at 10:02 AM, David Samson wrote: > 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. FLUSH CACHE(*) is what you are looking for. Check the documentation. https://doc.4d.com/4Dv17/4D/17.3/FLUSH-CACHE.301-4621758.en.html Tim Sent from my iPhone ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
no he is running v13.4 - I and others have suggested updating to v13.6 as well. On Wed, 18 Dec 2019 12:17:15 -0500, Chuck Miller via 4D_Tech wrote: > I think he said he was running 2003.x If so I would make cache much > smaller. I would make it 1.5 gig and I would set auto flush on server > to 1 minute > > Regards > > Chuck > > Chuck Miller Voice: (617) 739-0306 > Informed Solutions, Inc. Fax: (617) 232-1064 > mailto:cjmillerinformed-solutions.com > Brookline, MA 02446 USA Registered 4D Developer >Providers of 4D and Sybase connectivity > http://www.informed-solutions.com > > This message and any attached documents contain information which may > be confidential, subject to privilege or exempt from disclosure under > applicable law. These materials are intended only for the use of the > intended recipient. If you are not the intended recipient of this > transmission, you are hereby notified that any distribution, > disclosure, printing, copying, storage, modification or the taking of > any action in reliance upon this transmission is strictly > prohibited. Delivery of this message to any person other than the > intended recipient shall not compromise or waive such > confidentiality, privilege or exemption from disclosure as to this > communication. > >> On Dec 18, 2019, at 11:42 AM, Chip Scheide via 4D_Tech >> <4d_tech@lists.4d.com> wrote: >> >> Ferdinando, >> try setting the cache to 8gig (8000MB) that is 50% of installed RAM. >> >> run it for a bit, see if this helps. >> >> Chip > > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** We have done so much, with so little, for so long; We are now qualified to anything with nothing - 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:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
I think he said he was running 2003.x If so I would make cache much smaller. I would make it 1.5 gig and I would set auto flush on server to 1 minute Regards Chuck Chuck Miller Voice: (617) 739-0306 Informed Solutions, Inc. Fax: (617) 232-1064 mailto:cjmillerinformed-solutions.com Brookline, MA 02446 USA Registered 4D Developer Providers of 4D and Sybase connectivity http://www.informed-solutions.com This message and any attached documents contain information which may be confidential, subject to privilege or exempt from disclosure under applicable law. These materials are intended only for the use of the intended recipient. If you are not the intended recipient of this transmission, you are hereby notified that any distribution, disclosure, printing, copying, storage, modification or the taking of any action in reliance upon this transmission is strictly prohibited. Delivery of this message to any person other than the intended recipient shall not compromise or waive such confidentiality, privilege or exemption from disclosure as to this communication. > On Dec 18, 2019, at 11:42 AM, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Ferdinando, > try setting the cache to 8gig (8000MB) that is 50% of installed RAM. > > run it for a bit, see if this helps. > > Chip ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
7/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> >>>>> <mailto:stard...@stardata.info>> 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>" >>>>>>> mailto:stard...@stardata.info>> >>>>>>> To: Tom Benedict >>>>>> <mailto:benedic...@comcast.net>>, 4D iNug Technical >>>>>>> <4d_tech@lists.4d.com <mailto:4d_tech@lists.4d.com>> >>>>>>> Cc: 4d_tech-requ...@lists.4d.com >>>>>>> <mailto:4d_tech-requ...@lists.4d.com> >>>>>>> Subject: Re: FLUSH BUFFER >>>>>>> Message-ID: >>>>>>> <3b8782ae-5799-815c-b6ff-460530ddf...@stardata.info >>>>>>> <mailto:3b8782ae-5799-815c-b6ff-460530ddf...@stardata.info>> >>>>>>> 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:4d_tech-unsubscr...@lists.4d.com >>> ** >> We have done so much, with so little, for so long; >> We are now qualified to anything with nothing >>- unknown >> We have done so much, with so little, for so long; We are now qualified to anything with nothing - 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:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
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> >>> mailto:stard...@stardata.info>> 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> >>> <mailto:stard...@stardata.info>> 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. >>>>>
Re: FLUSH BUFFER
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>
mailto:stard...@stardata.info>> 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> mailto:stard...@stardata.info>> 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>"
mailto:stard...@stardata.info>>
To: Tom Benedict mailto:benedic...@comcast.net>>, 4D iNug Technical
<4d_tech@lists.4d.com <mailto:4d_tech@lists.4d.com>>
Cc: 4d_tech-requ...@lists.4d.com
<mailto:4d_tech-requ...@lists.4d.com>
Subject: Re: FLUSH BUFFER
Message-ID:
<3b8782ae-5799-815c-b6ff-460530ddf...@stardata.info
<mailto:3b8782ae-5799-815c-b6ff-460530ddf...@stardata.info>>
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:4d_tech-unsubscr...@lists.4d.com
**
AW: FLUSH BUFFER
Please use 0 as the value of the stack size. In most circumstances it is the
best idea to leave the memory management to 4D.
There was recently a thread about this topic on this mailing list or the
forums. I can't find it just now.
Regards
Lutz
-Ursprüngliche Nachricht-
Von: 4D_Tech [mailto:4d_tech-boun...@lists.4d.com] Im Auftrag von stardata.info
via 4D_Tech
Betreff: Re: FLUSH BUFFER
New
process("Wait_Lis";128*1024;[TABELLE]Descrizione;[TABELLE]Num_Ip;[TABELLE]Porta_Ip;[TABELLE]Codice;*)
The stack value is correct? or is better use 0 ?
**
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**
Re: FLUSH BUFFER
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 Il 13/12/19 18:19, Tom Benedict ha scritto: As Chuck pointed out, you may need to increase the size of your cache. The Info Report will make this evident. Tom On Dec 13, 2019, at 09:13, Tom Benedict via 4D_Tech <4d_tech@lists.4d.com> wrote: Contact 4D Tech Support. Tom On Dec 13, 2019, at 09:08, stardata.info wrote: Hi Tom, How I can find this component? Thanks Ferdinando Il 13/12/19 18:06, Tom Benedict ha scritto: That is the default and should work pretty well. You may be suffering from a related condition informally known as “cache thrashing” which was not uncommon in 4D v13 (as well as some later versions, but I haven’t kept up on what progress has been made). If you aren’t already using it, you can monitor cache performance with the 4D Info Report component, available from 4D Tech Support. It can show you graphically where the long cache flushing occurs. HTH, Tom Benedict On Dec 13, 2019, at 08:42, stardata.info wrote: 20 Seconds Thanks Ferdinando Il 13/12/19 17:00, Tom Benedict ha scritto: What is the “Flush Cache every..” value in Database Settings>Memory? If there are ‘lots’ of records being flushed, sometimes that can take a while. Setting the value smaller causes it to happen more frequently, but fewer records, which can be more efficient. HTH, Tom Benedict On Dec 13, 2019, at 07:39, stardata.info via 4D_Tech <4d_tech@lists.4d.com> wrote: Hi All, In one my application in 4D V13.4 on Windows, in some circumstances 4D client freezes, seems when in one process he must to write more records. During these freezes periods, the 3/4 processes launched from my applications work, but the front end interface is locked and is not responsive. After some seconds or minutes, 4D client work normally. Is possibile that this is because he must to write more records ( i think around 100 - 300 records )? Is necessary to use FLUSH BUFFER commands? Thanks Ferdinando ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com ** ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com ** ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
As Chuck pointed out, you may need to increase the size of your cache. The Info Report will make this evident. Tom > On Dec 13, 2019, at 09:13, Tom Benedict via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Contact 4D Tech Support. > > Tom > >> On Dec 13, 2019, at 09:08, stardata.info wrote: >> >> Hi Tom, >> >> >> How I can find this component? >> >> Thanks >> >> Ferdinando >> >> Il 13/12/19 18:06, Tom Benedict ha scritto: >>> That is the default and should work pretty well. You may be suffering from >>> a related condition informally known as “cache thrashing” which was not >>> uncommon in 4D v13 (as well as some later versions, but I haven’t kept up >>> on what progress has been made). >>> >>> If you aren’t already using it, you can monitor cache performance with the >>> 4D Info Report component, available from 4D Tech Support. It can show you >>> graphically where the long cache flushing occurs. >>> >>> HTH, >>> >>> Tom Benedict >>> >>>> On Dec 13, 2019, at 08:42, stardata.info wrote: >>>> >>>> 20 Seconds >>>> >>>> Thanks >>>> >>>> Ferdinando >>>> >>>> Il 13/12/19 17:00, Tom Benedict ha scritto: >>>>> What is the “Flush Cache every..” value in Database Settings>Memory? If >>>>> there are ‘lots’ of records being flushed, sometimes that can take a >>>>> while. Setting the value smaller causes it to happen more frequently, but >>>>> fewer records, which can be more efficient. >>>>> >>>>> HTH, >>>>> >>>>> Tom Benedict >>>>> >>>>>> On Dec 13, 2019, at 07:39, stardata.info via 4D_Tech >>>>>> <4d_tech@lists.4d.com> wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> In one my application in 4D V13.4 on Windows, in some circumstances 4D >>>>>> client freezes, seems when in one process he must to write more records. >>>>>> >>>>>> During these freezes periods, the 3/4 processes launched from my >>>>>> applications work, but the front end interface is locked and is not >>>>>> responsive. >>>>>> >>>>>> After some seconds or minutes, 4D client work normally. Is possibile >>>>>> that this is because he must to write more records ( i think around 100 >>>>>> - 300 records )? >>>>>> >>>>>> Is necessary to use FLUSH BUFFER commands? >>>>>> >>>>>> >>>>>> Thanks >>>>>> Ferdinando >>>>>> ** >>>>>> 4D Internet Users Group (4D iNUG) >>>>>> Archive: http://lists.4d.com/archives.html >>>>>> Options: https://lists.4d.com/mailman/options/4d_tech >>>>>> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com >>>>>> ** >>> > > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
Contact 4D Tech Support. Tom > On Dec 13, 2019, at 09:08, stardata.info wrote: > > Hi Tom, > > > How I can find this component? > > Thanks > > Ferdinando > > Il 13/12/19 18:06, Tom Benedict ha scritto: >> That is the default and should work pretty well. You may be suffering from a >> related condition informally known as “cache thrashing” which was not >> uncommon in 4D v13 (as well as some later versions, but I haven’t kept up on >> what progress has been made). >> >> If you aren’t already using it, you can monitor cache performance with the >> 4D Info Report component, available from 4D Tech Support. It can show you >> graphically where the long cache flushing occurs. >> >> HTH, >> >> Tom Benedict >> >>> On Dec 13, 2019, at 08:42, stardata.info wrote: >>> >>> 20 Seconds >>> >>> Thanks >>> >>> Ferdinando >>> >>> Il 13/12/19 17:00, Tom Benedict ha scritto: >>>> What is the “Flush Cache every..” value in Database Settings>Memory? If >>>> there are ‘lots’ of records being flushed, sometimes that can take a >>>> while. Setting the value smaller causes it to happen more frequently, but >>>> fewer records, which can be more efficient. >>>> >>>> HTH, >>>> >>>> Tom Benedict >>>> >>>>> On Dec 13, 2019, at 07:39, stardata.info via 4D_Tech >>>>> <4d_tech@lists.4d.com> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> In one my application in 4D V13.4 on Windows, in some circumstances 4D >>>>> client freezes, seems when in one process he must to write more records. >>>>> >>>>> During these freezes periods, the 3/4 processes launched from my >>>>> applications work, but the front end interface is locked and is not >>>>> responsive. >>>>> >>>>> After some seconds or minutes, 4D client work normally. Is possibile that >>>>> this is because he must to write more records ( i think around 100 - 300 >>>>> records )? >>>>> >>>>> Is necessary to use FLUSH BUFFER commands? >>>>> >>>>> >>>>> Thanks >>>>> Ferdinando >>>>> ** >>>>> 4D Internet Users Group (4D iNUG) >>>>> Archive: http://lists.4d.com/archives.html >>>>> Options: https://lists.4d.com/mailman/options/4d_tech >>>>> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com >>>>> ** >> ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
Hi Tom, How I can find this component? Thanks Ferdinando Il 13/12/19 18:06, Tom Benedict ha scritto: That is the default and should work pretty well. You may be suffering from a related condition informally known as “cache thrashing” which was not uncommon in 4D v13 (as well as some later versions, but I haven’t kept up on what progress has been made). If you aren’t already using it, you can monitor cache performance with the 4D Info Report component, available from 4D Tech Support. It can show you graphically where the long cache flushing occurs. HTH, Tom Benedict On Dec 13, 2019, at 08:42, stardata.info wrote: 20 Seconds Thanks Ferdinando Il 13/12/19 17:00, Tom Benedict ha scritto: What is the “Flush Cache every..” value in Database Settings>Memory? If there are ‘lots’ of records being flushed, sometimes that can take a while. Setting the value smaller causes it to happen more frequently, but fewer records, which can be more efficient. HTH, Tom Benedict On Dec 13, 2019, at 07:39, stardata.info via 4D_Tech <4d_tech@lists.4d.com> wrote: Hi All, In one my application in 4D V13.4 on Windows, in some circumstances 4D client freezes, seems when in one process he must to write more records. During these freezes periods, the 3/4 processes launched from my applications work, but the front end interface is locked and is not responsive. After some seconds or minutes, 4D client work normally. Is possibile that this is because he must to write more records ( i think around 100 - 300 records )? Is necessary to use FLUSH BUFFER commands? Thanks Ferdinando ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com ** ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
That is the default and should work pretty well. You may be suffering from a related condition informally known as “cache thrashing” which was not uncommon in 4D v13 (as well as some later versions, but I haven’t kept up on what progress has been made). If you aren’t already using it, you can monitor cache performance with the 4D Info Report component, available from 4D Tech Support. It can show you graphically where the long cache flushing occurs. HTH, Tom Benedict > On Dec 13, 2019, at 08:42, stardata.info wrote: > > 20 Seconds > > Thanks > > Ferdinando > > Il 13/12/19 17:00, Tom Benedict ha scritto: >> What is the “Flush Cache every..” value in Database Settings>Memory? If >> there are ‘lots’ of records being flushed, sometimes that can take a while. >> Setting the value smaller causes it to happen more frequently, but fewer >> records, which can be more efficient. >> >> HTH, >> >> Tom Benedict >> >>> On Dec 13, 2019, at 07:39, stardata.info via 4D_Tech <4d_tech@lists.4d.com> >>> wrote: >>> >>> Hi All, >>> >>> In one my application in 4D V13.4 on Windows, in some circumstances 4D >>> client freezes, seems when in one process he must to write more records. >>> >>> During these freezes periods, the 3/4 processes launched from my >>> applications work, but the front end interface is locked and is not >>> responsive. >>> >>> After some seconds or minutes, 4D client work normally. Is possibile that >>> this is because he must to write more records ( i think around 100 - 300 >>> records )? >>> >>> Is necessary to use FLUSH BUFFER commands? >>> >>> >>> Thanks >>> Ferdinando >>> ** >>> 4D Internet Users Group (4D iNUG) >>> Archive: http://lists.4d.com/archives.html >>> Options: https://lists.4d.com/mailman/options/4d_tech >>> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com >>> ** >> ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
It also depends on size of cache. How big is cache and how much me memory on machine On Fri, Dec 13, 2019 at 11:42 AM stardata.info via 4D_Tech < 4d_tech@lists.4d.com> wrote: > 20 Seconds > > Thanks > > Ferdinando > > Il 13/12/19 17:00, Tom Benedict ha scritto: > > What is the “Flush Cache every..” value in Database Settings>Memory? If > there are ‘lots’ of records being flushed, sometimes that can take a while. > Setting the value smaller causes it to happen more frequently, but fewer > records, which can be more efficient. > > > > HTH, > > > > Tom Benedict > > > >> On Dec 13, 2019, at 07:39, stardata.info via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > >> > >> Hi All, > >> > >> In one my application in 4D V13.4 on Windows, in some circumstances 4D > client freezes, seems when in one process he must to write more records. > >> > >> During these freezes periods, the 3/4 processes launched from my > applications work, but the front end interface is locked and is not > responsive. > >> > >> After some seconds or minutes, 4D client work normally. Is possibile > that this is because he must to write more records ( i think around 100 - > 300 records )? > >> > >> Is necessary to use FLUSH BUFFER commands? > >> > >> > >> Thanks > >> Ferdinando > >> ** > >> 4D Internet Users Group (4D iNUG) > >> Archive: http://lists.4d.com/archives.html > >> Options: https://lists.4d.com/mailman/options/4d_tech > >> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > >> ** > > > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** -- - Chuck Miller Voice: (617) 739-0306 Fax: (617) 232-1064 Informed Solutions, Inc. Brookline, MA 02446 USA Registered 4D Developer Providers of 4D, Sybase & SQL Server connectivity https://www.informed-solutions.com - This message and any attached documents contain information which may be confidential, subject to privilege or exempt from disclosure under applicable law. These materials are intended only for the use of the intended recipient. If you are not the intended recipient of this transmission, you are hereby notified that any distribution, disclosure, printing, copying, storage, modification or the taking of any action in reliance upon this transmission is strictly prohibited. Delivery of this message to any person other than the intended recipient shall not compromise or waive such confidentiality, privilege or exemption from disclosure as to this communication. ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
Hi Chip,
In database settings flush buffer is 20 seconds
The process that create the records use this command:
New
process("Wait_Lis";128*1024;[TABELLE]Descrizione;[TABELLE]Num_Ip;[TABELLE]Porta_Ip;[TABELLE]Codice;*)
The stack value is correct? or is better use 0 ?
Thanks
Ferdinando
Il 13/12/19 17:03, Chip Scheide ha scritto:
you can use the flush buffer command, or you can shorten the time
between automated flush buffers.
if this is writing into the very large table you mentioned in a
previous post, I would insure that you do as little as possible in the
trigger, and examine your indexes to determine if you use/need them.
*IF* you can remove an index, or reduce trigger execution time either
will help speed buffer flushing
Chip
On Fri, 13 Dec 2019 16:39:48 +0100, stardata.info via 4D_Tech wrote:
Hi All,
In one my application in 4D V13.4 on Windows, in some circumstances
4D client freezes, seems when in one process he must to write more
records.
During these freezes periods, the 3/4 processes launched from my
applications work, but the front end interface is locked and is not
responsive.
After some seconds or minutes, 4D client work normally. Is possibile
that this is because he must to write more records ( i think around
100 - 300 records )?
Is necessary to use FLUSH BUFFER commands?
Thanks
Ferdinando
**
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**
We have done so much, with so little, for so long;
We are now qualified to anything with nothing
- 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:4d_tech-unsubscr...@lists.4d.com
**
Re: FLUSH BUFFER
20 Seconds Thanks Ferdinando Il 13/12/19 17:00, Tom Benedict ha scritto: What is the “Flush Cache every..” value in Database Settings>Memory? If there are ‘lots’ of records being flushed, sometimes that can take a while. Setting the value smaller causes it to happen more frequently, but fewer records, which can be more efficient. HTH, Tom Benedict On Dec 13, 2019, at 07:39, stardata.info via 4D_Tech <4d_tech@lists.4d.com> wrote: Hi All, In one my application in 4D V13.4 on Windows, in some circumstances 4D client freezes, seems when in one process he must to write more records. During these freezes periods, the 3/4 processes launched from my applications work, but the front end interface is locked and is not responsive. After some seconds or minutes, 4D client work normally. Is possibile that this is because he must to write more records ( i think around 100 - 300 records )? Is necessary to use FLUSH BUFFER commands? Thanks Ferdinando ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com ** ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
you can use the flush buffer command, or you can shorten the time between automated flush buffers. if this is writing into the very large table you mentioned in a previous post, I would insure that you do as little as possible in the trigger, and examine your indexes to determine if you use/need them. *IF* you can remove an index, or reduce trigger execution time either will help speed buffer flushing Chip On Fri, 13 Dec 2019 16:39:48 +0100, stardata.info via 4D_Tech wrote: > Hi All, > > In one my application in 4D V13.4 on Windows, in some circumstances > 4D client freezes, seems when in one process he must to write more > records. > > During these freezes periods, the 3/4 processes launched from my > applications work, but the front end interface is locked and is not > responsive. > > After some seconds or minutes, 4D client work normally. Is possibile > that this is because he must to write more records ( i think around > 100 - 300 records )? > > Is necessary to use FLUSH BUFFER commands? > > > Thanks > Ferdinando > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** We have done so much, with so little, for so long; We are now qualified to anything with nothing - 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:4d_tech-unsubscr...@lists.4d.com **
Re: FLUSH BUFFER
What is the “Flush Cache every..” value in Database Settings>Memory? If there are ‘lots’ of records being flushed, sometimes that can take a while. Setting the value smaller causes it to happen more frequently, but fewer records, which can be more efficient. HTH, Tom Benedict > On Dec 13, 2019, at 07:39, stardata.info via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Hi All, > > In one my application in 4D V13.4 on Windows, in some circumstances 4D client > freezes, seems when in one process he must to write more records. > > During these freezes periods, the 3/4 processes launched from my applications > work, but the front end interface is locked and is not responsive. > > After some seconds or minutes, 4D client work normally. Is possibile that > this is because he must to write more records ( i think around 100 - 300 > records )? > > Is necessary to use FLUSH BUFFER commands? > > > Thanks > Ferdinando > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
FLUSH BUFFER
Hi All, In one my application in 4D V13.4 on Windows, in some circumstances 4D client freezes, seems when in one process he must to write more records. During these freezes periods, the 3/4 processes launched from my applications work, but the front end interface is locked and is not responsive. After some seconds or minutes, 4D client work normally. Is possibile that this is because he must to write more records ( i think around 100 - 300 records )? Is necessary to use FLUSH BUFFER commands? Thanks Ferdinando ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
