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 <[email protected]> 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 <[email protected]> wrote:
>>
>>
>>> On Oct 8, 2017, at 5:53 PM, David Adams via 4D_Tech <[email protected]>
>>> 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
>> [email protected]
>>
>>
>>
>>
>>
>
> John Baughman
> Kailua, Hawaii
> (808) 262-0328
> [email protected]
John Baughman
Kailua, Hawaii
(808) 262-0328
[email protected]
**********************************************************************
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:[email protected]
**********************************************************************
