2011/10/20 Janko Mivšek <[email protected]>: > Hi guys, > > I'm measuring how my image is breathing through the time and what is > interesting is how nr. of Semaphore instances is variating through the > time. Every hour just before snapshot I report nr of instances, see last > 10 hours: > > ** image state: > 0 HTTPCommections > 4 Sockets > 22 Processes > 259 Semaphores > > ** image state: > 0 HTTPCommections > 4 Sockets > 22 Processes > 274 Semaphores > > ** image state: > 0 HTTPCommections > 4 Sockets > 22 Processes > 312 Semaphores > > ** image state: > 0 HTTPCommections > 4 Sockets > 22 Processes > 356 Semaphores > > ** image state: > 0 HTTPCommections > 4 Sockets > 22 Processes > 346 Semaphores > > ** image state: > 0 HTTPCommections > 4 Sockets > 22 Processes > 141 Semaphores > > ** image state: > 0 HTTPCommections > 4 Sockets > 22 Processes > 310 Semaphores > > ** image state: > 0 HTTPCommections > 4 Sockets > 26 Processes > 79 Semaphores > > ** image state: > 0 HTTPCommections > 4 Sockets > 20 Processes > 300 Semaphores > > Well, the number of semaphores tells nothing because not all of them serve for sockets.
There are 3 semaphores per socket. So, if you have 4 sockets, there should be 12 external objects. Of course not counting others, which is there for other purposes. Could you add following to report: Socket registry size StandardFileStream registry size (ExternalSemaphoreTable unprotectedExternalObjects reject: #isNil) size > Janko > > > > S, Eliot Miranda piše: >> >> >> On Sat, Oct 8, 2011 at 12:13 PM, Igor Stasenko <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 7 October 2011 23:38, Eliot Miranda <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > >> > On Fri, Oct 7, 2011 at 1:30 PM, Igor Stasenko <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> I don't understand why this problem appear only recently, and if i >> >> remember before i never heard that people >> >> had a problems with too many open sockets (and consequently exceeding >> >> a semaphore table space). >> >> >> >> Is there something we changed in language? in VM? or is it purely >> >> because we are lagging behind the scale of >> >> projects which today running on pharo? :) >> > >> > In the VM. In Cog I implemented a thread-safe non-blocking signal >> external >> > semaphore facility but I was too lazy to implement a thread-safe >> > non-blocking growing facility. It seems simple to set the size at >> start-up. >> > You choose a value large enough for your application, set it, >> save the >> > image and you're done. Whereas implementing a non-blocking >> growing facility >> > is tricky. >> >> >> Hmm, that confuses me even more. >> >> In Squeak VM there is a single hard limit for SemaphoresToSignalA, and >> SemaphoresToSignalB >> tables - 500 (i dont remember correct name of these tables). >> >> In these tables, upon receiving a signal, it storing the index of >> semaphore to signal, when you using signalSemaphore() function. >> Then at interrupt time, these tables are flushed by signaling >> corresponding semaphores which are stored in external semaphore table >> under corresponding index. >> This means that between two interrupts you cannot signal more than 500 >> semaphores. And given that time between interrupts are pretty small >> (about 1 ms) i hardly beleive that you can put such high load on >> server to receive more than 500 signals in 1 ms time period. >> >> >> That's not quite how it works. Each location in the VM's table maps to >> one semaphore in the image (each location remembers the number of >> signals to send to each external semaphore). So it's not the number of >> signals, it's the number of external semaphores in use. >> >> >> So the problem is not here, apparently, the problem is in size of >> external semaphore table , where semaphore objects are stored, >> which growth can be controlled completely by image size (this is a >> simple array), because signaling machinery operating only with indexes >> in this table but not with actual semaphores. >> >> Now, since i don't know well how much changes you did in signaling >> code in Cog. I only suspect that your conclusion that your changes >> might >> cause the problems are wrong. >> >> >> Could be. In any case, a command-line parameter does not harm :) >> >> >> >> > >> > -- >> > best, >> > Eliot >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> -- >> best, >> Eliot >> > > -- > Janko Mivšek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > -- Best regards, Igor Stasenko.
