2011/10/20 Janko Mivšek <janko.mivsek@eranova.si>:
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 <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote:
  On 7 October 2011 23:38, Eliot Miranda <eliot.miranda@gmail.com   <mailto:eliot.miranda@gmail.com>> wrote:   >   >   > On Fri, Oct 7, 2011 at 1:30 PM, Igor Stasenko <siguctua@gmail.com   <mailto:siguctua@gmail.com>> 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.