One thing I forgot to mention/ask… David’s test routine runs significantly faster with 32-bit 4D than it does with 64-bit 4D. Any ideas as to why this might be the case?
To refresh memories as to what the test is doing… For ($1;1;10) $prsNum:=New Process(“TestProcess”.0;”TestProcess”) end for //TestProcess method For ($1;1;1000000) CALL WORKER(“LogWorker”;“LogWorker_Write”;$i) end for //LogWorker SEND PACKET(Log_DocRef;$1+Char(Carriage return)) So the test is calling the worker 10 million times. Since nearly all of the calls are going into the worker queue, I believe it is the for loops that are executing more slowly with 64-bit 4D. The interaction with the file, SEND PACKET, appears to be plodding along at the same pace. > On Oct 11, 2017, at 6:46 AM, John Baughman <john...@hawaii.rr.com> wrote: > > Got an email from Timothy Penner yesterday pointing out that in his testing > of this issue he has concluded that the crash occurs because 4D is being > pushed past it’s memory limits. That is if run using the 32bit version of 4D. > Tim suggested that we run the test using the 64 bit version of 4D. > > Running the test using 64-bit 4D v16 R4, the test does not crash. Thanks Tim! > > I think this explains everything. Running with 32 bit 4D in a 64 bit OS I > think we have a 4 GB memory limit which I think would be easily reached as > the worker queue goes over 2.1 million calls. > > With 4D 64-bit I think we have a 16 TB memory limit… no problem running the > test up to 100 million calls in the queue. > > My conclusion: > > 1. There is no queue limit that we know of except those dictated by memory > constraints. > 2. There is no bug or memory leak. > 3. We still need a way to monitor the queue size especially if a worker is > expected to be flooded with calls. > > It was interesting watching the test run to it’s end, as the test completes > in a relatively short period of time, but the text file continues to build > for several hours as the worker continues to consume it’s queue. > > John > >> On Oct 8, 2017, at 8:42 PM, John Baughman <john...@hawaii.rr.com> wrote: >> >> >>> On Oct 8, 2017, at 5:53 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> >>> wrote: >>> >>> Oh, I forgot to say earlier about John's finding of ~2.1M messages being a >>> kind of breaking point...that number may not be replicable in other tests. >>> You might find a different number. The payloads in my scratch database are >>> quite small. For all I know, if you made the payloads 10x bigger, you would >>> crash with ~210K messages. I won't be testing this myself. >> >> Why not test this. I added a bit of text to the log entry with the 2 million >> calls set to run... >> >> $text:=“” No crash. Only an index number is being logged, ie, 1, 2, 3, etc. >> $text:=“j”*16 No problem >> $text:=“j”*32 Crashes near the end >> >> Here is the kicker. If I am running interpreted with the Runtime Explorer >> open it crashes very early and the Runtime Explorer throws an array range >> error on occasion before 4D crashes. Sometimes with $text:=“j”*32 set it >> actually completes, but if I try to open the Runtime Explorer, 4D crashes. >> >> Now I ‘m thinking maybe it’s not the worker queue limit per say but a memory >> leak associated with the worker and/or it’s queue. >> >> John >> >> >> >> >> John Baughman >> Kailua, Hawaii >> (808) 262-0328 >> john...@hawaii.rr.com >> >> >> >> >> > > John Baughman > Kailua, Hawaii > (808) 262-0328 > john...@hawaii.rr.com John Baughman Kailua, Hawaii (808) 262-0328 john...@hawaii.rr.com ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************