Hi,
I have an application which needs to open a lost of TCP connections
at once. Up until now I have been telling this application to limit
itself to 1024 file descriptors at once, but today I thought I would
let it rip and increase it to 4096.
When I did this, I started noticing errors in other applications on
the same machine, such as postfix:
9905D27F28 4026 Tue May 18 23:53:55 mark@example.org
(connect to mail.example.com[67.15.16.50]: Can't assign requested
address)
kari@example.com
Also emulating a HTTP connection:
$ telnet babylon.otherwize.co.uk 80
Trying 212.13.198.54...
telnet: connect to address 212.13.198.54: Can't assign requested address
So I'm thinking, ah, file descriptor limit. I know the system's
FD limit can be queried with pstat -T, but:
$ pstat -T
4614/12328 files
45M/2047M swap space
seems like there is plenty of room there. The ulimit -a for the
user the application runs under shows that it has a hard limit of
some 11000 FDs as well.
So it's not FDs.
Could someone point me in the right direction as to what resource I
might be running out of here? If you could let me know how to list
the current usage of that resource, and how to increase it in
future, that would also be very useful, but any assistance would be
appreciated.
--
http://freebsdwiki.org/ - Encrypted mail welcome - keyid 0xBF15490B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20040519/ebb2f475/attachment.bin
On Wed, May 19, 2004 at 02:30:26AM +0000, Andy Smith wrote:> I have an application which needs to open a lost of TCP connections > at once. Up until now I have been telling this application to limit > itself to 1024 file descriptors at once, but today I thought I would > let it rip and increase it to 4096. > > When I did this, I started noticing errors in other applications on > the same machine, such as postfix: > > 9905D27F28 4026 Tue May 18 23:53:55 mark@example.org > (connect to mail.example.com[67.15.16.50]: Can't assign requested address) > kari@example.com > > Also emulating a HTTP connection: > > $ telnet babylon.otherwize.co.uk 80 > Trying 212.13.198.54... > telnet: connect to address 212.13.198.54: Can't assign requested addressI had some suggestions off-list. One said it might be mbufs, but netstat doesn't really confirm: $ netstat -m 139/688/26624 mbufs in use (current/peak/max): 135 mbufs allocated to data 2 mbufs allocated to ancillary data 2 mbufs allocated to socket names and addresses 86/370/6656 mbuf clusters in use (current/peak/max) 912 Kbytes allocated to network (4% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Another suggested I was running out of ephemeral ports: $ sysctl -a | grep portrange net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 1024 net.inet.ip.portrange.last: 5000 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.hilast: 65535 If my application is using first -> last then I can this would be quite likely: I'm opening over 4000 TCP connections at once. But I thought it used hifirst -> hilast. I also increased kern.ipc.somaxconn from 128 to 1024 but this did not appear to help. Are there any other resource limits which people think I should be changing? The connections are very short-lived, perhaps no more than 30 seconds each, and hardly any data goes over them. Okay, while writing this email I used lsof to see what TCP conections my app had. They do all seem to have source ports within the first -> last range. $ sudo sysctl net.inet.ip.portrange.last=20000 net.inet.ip.portrange.last: 5000 -> 20000 seem to have removed my problem. Thanks! -- http://freebsdwiki.org/ - Encrypted mail welcome - keyid 0xBF15490B -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20040519/c787376b/attachment.bin