S, Sven Van Caekenberghe piše:
Janko Mivšek wrote:
If I recall others have also problems with sockets in Pharo, so here is the my current image, which:
- has 105 Sockets open, mostly waiting - has also >105 processes open - consumes 100% cpu - on aSocket close responds with primitive failure - image is workable, I can browse etc.
- Pharo1.2.2a on Linux
Sockets are waiting on Socket>>waitForConnectionFor:ifTimeOut:
Is that number of open sockets and processes by design or not ? If they keep coming back, you must be creating them. Your application has to keep these (expensive) resources under control to start with.
This is Swazoo accepting the connections, probably from web spiders. But also promptly closing them, because there are no instances of HTTPConnection hanging around.
Long running Seaside images seem to be fine and they are using sockets and processes a lot.
Socket have #close and #destroy, there might be a difference.
Swazoo uses Sport portability layer and its SpSocket actually call #closeAndDestroy on underlying Socket. Obviously this method don't manage to actually close nor destroy the socket.
I think that part of the cleanup of sockets is delayed (using finalization) and needs some GC work to complete. GC policies might be involved as well as weak datastructures.
This could be a way to proceed. How to diagnose that?
I am also interested in knowning the practical upper bound for open sockets and number of processes.
From Henrik pointer it seems that in 1.2 one-click there can be up to 512 semaphores by default. Every socket need three, so up to 170 sockets can be open at once. Semaphore limit can be increased , to say 1024*3 for 1024 sockets by:
Smalltalk vmParameterAt: 49 put: 1024*3 Another limit on Linux is namely a default 1024 limit of sockets per a whole machine. This one can also be increased Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si