I had a problem where my image became unusable a few seconds after starting up. I got help on the database discord channel, and got my image back to usable. Here’s a summary. [MacOS, Pharo9, MongoTalk 1.24, the image runs a Seaside,Voyage,Mongo app]. 1. I got the stack trace (see attached) a few seconds after image startup, then the image became unusable and had to be terminated from the OS. 2. I eventually figured out that I needed to re-establish the ssh tunnel to my mongo database. After that, I was able to start the image without problem. 3. A potential fix may have been in MongoTalk 1.25, where connections were being leaked due to non-local returns. The fix (see attached) would add an ensure: block. I filed-in the fix, which I was able to do, with the ssh tunnel on. 4. I turned off the ssh tunnel, then tried to start the image with the MongoTalk change installed and saved. But I still got the debugger after a few seconds. I eventually noticed that the image was still usable, if I just closed the debugger (actually, closed it two times, because it came up again). In the Transcript was: WARNING: Had to GC to make room for more external objects. If this happens often, it would be a good idea to either: - Raise the maxExternalSemaphores size. - Write your code to explicitly release them rather than wait for finalization. WARNING: Had to increase size of semaphore signal handling table due to many external objects concurrently in use You should increase this size at startup using #maxExternalSemaphoresSilently: Current table size: 1024 WARNING: Had to increase size of semaphore signal handling table due to many external objects concurrently in use You should increase this size at startup using #maxExternalSemaphoresSilently: Current table size: 2048 So the MongoTalk fix would have salvaged the image too. 5. Digging around, I found the following would clean things up: MongoMonitor allInstances. "size: 95" MongoMonitor allInstancesDo: [ :each | each stop; tearDown ]. Smalltalk garbageCollect. MongoMonitor allInstances. "size: 6” After that, the pharo CPU usage went down from 23% to 5% Cheers, Yanni Chiu