https://www.ejabberd.im/node/4110 en https://www.ejabberd.im/node/4110#comment-56054 <p>Hmm, 32768 is 2^15 so it sounds like your running into an issue with a with a 16 bit (possibly unsigned) integer somewhere.</p> <p>I've never used FreeBSD before but I do see a few numbers of interest purely from a mathematical sense:</p> <p>net.inet.tcp.recvspace=16384<br /> net.inet.tcp.sendspace=16384</p> <p>net.inet.ip.portrange.last=65535</p> <p>16384 is 1/2 of 32768, while 65535 is double it, minus 1, so either of those may be causing a limit somehow.</p> <p>My other suggestion would be to check is the number of open file descriptors allowed per process, which it looks like you've already done. On Linux and Solaris, this is done with:</p> <p>ulimit -n</p> <p>My experience has been that you typically want this number to be at least double the users you are trying to login because I think ejabberd consumes two file descriptors per connected client (though I'm not sure why). I always make it a bit more then double just to be safe.</p> <p>For example, if your ulimit -n value is 65536, then ejabberd will be unable to login new clients after you've consumed all of these file descriptors. If it does consume two per login as I suspect, a limit of 65536 would cause it to start failing after 32768. If it only consumes one, then a limit of 32768 would cause similar issues. FreeBSD may have decided to set this to 2^16 by default.</p> <p>However, since you've already got this set to 200000, that may be moot, and it may have more to do with the FreeBSD values I mentioned above. Or, for some reason, the ulimit erlang is reporting isn't the same as the one actually configured in the system?</p> Wed, 16 Jun 2010 15:33:06 +0000 Tronman comment 56054 at https://www.ejabberd.im