On Thu, Sep 16, 2010 at 12:46 PM, Louis Munro <l...@louismunro.com> wrote: > Hi, > I'm trying to understand the relationship between semaphores, semaphore sets > and the relevant resource controls in solaris 10. > > My current understanding is that the total number of semaphores available to > a project is the product of > project.max-sem-ids * process.max-sem-nsems (number of sets * number of > semaphores per set). > Is that correct?
That is my understanding. > I also understand that when a set is full a request for an aditional > semaphore will be allocated form another set if there is one available. > Again, is that right? Not sure, but seems likely. I suspect it's probably sequential through each set. > Last, if that is the case, why do we have sets to begin with? I'm not familiar enough with the history of them wrt implementation, however on Solaris there is some housekeeping within the kernel associated with each set (since they are visible to potentially any process), and with that comes locks on the data structures used to house them in the kernel, which IIRC are one lock per set. > Why not use a single big pool of semaphores? Due to the above, a single set of semaphores means that all semaphore operations will be serialized. > There must be some use to the sets or else I don't see why they would still > be around but I can't figure out a case where a large number of small sets > would be better than a small number of large sets. > Does anyone know? Increased parallelism on semaphore operations (at least on Solaris, other platforms may differ). Probably the most well known user of SysV semaphores is Oracle's RDBMS (which provides a good example). I know places have encountered arguably a misconfiguration around this that caused performance (especially on larger machines) to be terrible. The resource limits were set such that Oracle allocated all it's semaphores in a single set (causing the serialization I mentioned). By lowering the amount of semaphores per set, and allowing multiple sets, it fixed the problem. Of course the question 'how many sets' is probably best done by experiment. If I were to hazard a guess, using #sets = #cpus would probably be a reasonable starting point, probably up to sqrt(# semaphores needed) if > #cpus. In the case of Oracle, there is documentation that will tell you how many semaphores it wants based on various parameters (I believe in the init file). IIRC, Oracle will allocate as many sets as needed to get the needed # of semaphores. > > Thank you for your advice, > > Louis > -- > This message posted from opensolaris.org > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
