Hi
A customer of us has a 8.03 application with a WebService frontend. During a WebService call, a number of DLL calls are made to DLL's managing their memory using the malloc/free scheme.
In certain testcases the application is getting error messages implying that the malloc failed.
How can I increase the heap(?) of the Smalltalk executable in order to provide more memory for the backend application?
Regards
Thomas
-- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/sFQQoprhWiwJ. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en. |
Thomas -
Windows normally provides 2GB of memory for applications (this can be increased to 3MB if needed). The heap used by VA Smalltalk (or any other application) is not limited other than by the total size of available memory. If you seem to be running out of memory, I have found the Sysinternals Process Explorer and VMMap tools (download from www.sysinternals.com or run directly from the web) to be of great help in understanding what is going on with memory -- particularly in determining whether all available memory is really being used or the error return is bogus (caused by something other than being out of momory -- the VM is famous for dong this). |
Hi John
The problem happened (notice the past tense ;-)) in a 100% load test environment. The server application got WebService (SOAP XML) calls and ended up calling some DLL's for financial calculations. The memory for the DLL structure is being freed during garbage collection and scavenge. Now - the system is bombarded with calls and the method SstSockettransport>>findReadyConnection was trying to allocate memory for the next socket (as no other were available). However, the implementation with the "whileTrue:" loop at the top didn't allow the other threads to free the memory. So, what we did to resolve the issue was to add a [Processor finalizeCycle] whileTrue: []. Processor yield in the loop just before the "This should never happen ;-) The method looks now like this findReadyConnection "--- Answer a connection which is ready-for-read. Answer nil to indicate a new connection request on our listening socket. Answer an SstError on error. " | socket conn nread| [conn isNil] whileTrue: [ self isShutDown ifTrue: [^SstError for: SstTransportShutDownError]. [conn := knownReadyConnections isEmpty ifFalse: [knownReadyConnections remove]] critical. conn isNil ifTrue: [ (socket := socketSieve next) == listeningSocket ifTrue: [^nil]. socket isNil ifTrue: ["-- notification read --"] ifFalse: [ socket isSstError ifTrue: [ socket errorCode = SstReceiveError ifTrue: [self handleDeadSocketsError: socket in: 'findReadyConnection'] ifFalse: [^socket]] ifFalse: [ conn := self connectionManager lookupConnectionForHandle: socket ifAbsent: [^SstError for: SstInternalTransportError with: (NlsCatSSTG indexedMsg: 112)]]]]. [Processor finalizeCycle] whileTrue: []. Processor yield. ]. "$NLS$ This should never happen." (nread := conn handle ioctl: FIONREAD parameter: nil) isSciError ifTrue: [ ((Array with: ENOTSOCK with: ECONNRESET with: EBADF) includes: nread errorCode) ifTrue: [ self logWarning: ('%1>>findReadyConnection ... discarding dead socket (%2) for connection to peer @ %3.' bindWith: self class name with: conn handle platformHandle printString with: conn peer address printString)] ifFalse: [ On Aug 8, 7:44 pm, John O'Keefe <[hidden email]> wrote: > Thomas - > > Windows normally provides 2GB of memory for applications (this can be > increased to 3MB if needed). The heap used by VA Smalltalk (or any other > application) is not limited other than by the total size of available > memory. > > If you seem to be running out of memory, I have found the Sysinternals > Process Explorer and VMMap tools (download fromwww.sysinternals.comor run > directly from the web) to be of great help in understanding what is going on > with memory -- particularly in determining whether all available memory is > really being used or the error return is bogus (caused by something other > than being out of momory -- the VM is famous for dong this). > > -- > View this message in context:http://forum.world.st/malloc-in-a-DLL-call-out-of-memory-tp3711956p37... > Sent from the Instantiations mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en. |
Thomas -
I've opened Case 48631: SstSocketTransport>>findReadyConnection can starve other Processes on your behalf for this problem. We will report back here, as well as directly to you, after we have analyzed the problem. John |
Hi John,
-- Any news about Case 48631? Thanks, JP On Thursday, August 11, 2011 5:49:08 AM UTC-3, John O'Keefe wrote: Thomas - You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk. For more options, visit https://groups.google.com/d/optout. |
Free forum by Nabble | Edit this page |