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 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
