Drosselt Mac OS X die Rate der Socket-Erstellung?

3447
pbhogan

Dies mag auf die Programmierung bezogen scheinen, aber dies ist eine Frage des Betriebssystems.

Ich schreibe einen kleinen Hochleistungs-Daemon, der Tausende von Verbindungen pro Sekunde benötigt. Es funktioniert gut unter Linux (insbesondere Ubuntu 9.10 auf EC2). Wenn ich unter Mac OS X ein paar tausend Verbindungen (etwa 16350) in einem Benchmark wirke, der einfach eine Verbindung öffnet, seine Sache macht und die Verbindung schließt, dann bleibt das Benchmark-Programm einige Sekunden stehen und wartet, bis ein Socket verfügbar wird bevor Sie fortfahren (oder das Zeitlimit überschreiten).

Ich habe sowohl Apache Bench als auch Siege verwendet (um sicherzustellen, dass es nicht die Benchmark-Anwendung ist).

Warum / wie beschränkt Mac OS X die RATE, bei der Sockets verwendet werden können, und kann ich dies verhindern?

Oder ist noch etwas los?

Ich weiß, dass es eine Beschränkung für Dateideskriptoren gibt, aber das trifft nicht zu. Es gibt keinen Fehler beim Akzeptieren eines Sockets, er hängt einfach nach dem ersten (ungefähren) 16000 für eine Weile und wartet, ich gehe davon aus, dass das Betriebssystem einen Socket freigibt. Dies sollte nicht passieren, da alle Steckdosen vorher geschlossen sind. Sie sollen mit der Geschwindigkeit verfügbar sein, die sie geschlossen haben, und zwar unter Ubuntu, aber unter Mac OS X scheint es eine Verzögerung von mehreren Sekunden (5-10?) Zu geben.

Ich habe versucht, mit ulimit überall zu arbeiten. Nada

7
Nicht kreuzen - http://serverfault.com/questions/145907/does-mac-os-x-throttle-the-rate-of-socket-creation MDMarra vor 13 Jahren 0
Dies ist eine gute Frage und eine dieser grauen Bereiche, die für Super User * oder * Server Fault gleichermaßen akzeptabel sein könnten. Sie sollten jedoch nicht zuerst einen Crosspost erstellen und später Fragen stellen. Post auf der einen oder anderen Seite. Wenn nach einer angemessenen Zeit keine guten Antworten erzielt werden, können Sie die Aufmerksamkeit des Moderators auffordern, ihn auf die andere Site zu migrieren. quack quixote vor 13 Jahren 0
@MarkM Warum nicht? Es ist auf beide anwendbar und auch wenn es etwas relevanter für ServerFault ist. Ich habe die Antwort hier erhalten und die Antwort dem anderen zur Verfügung gestellt. Es ist sogar relevant für StackOverflow, obwohl ich mich dazu entschied, dort nicht zu posten, da ich ziemlich sicher war, dass das Problem nicht im Code lag. Crossposting ist nicht schlecht, wenn es für jede Community relevant ist, da es für beide einen Mehrwert bietet. Sie wissen nicht immer, aus welchem ​​Blickwinkel die Antwort kommt. pbhogan vor 13 Jahren 1
@ quack quixote Ich wusste nicht, dass es dafür ein Protokoll gab. Ich stimme dem nicht wirklich zu, werde aber in Zukunft versuchen, ihm zu folgen. pbhogan vor 13 Jahren 0
* generell * Crossposts sind schlecht (weil der Fragesteller nicht weiß, zu welcher Site eine Frage gehört; in der Regel führt dies zu Fragenmigrationen und Duplikationen). Das ist hier nicht der Fall - wie gesagt, ich denke, dass dieser auf beiden Seiten gleichermaßen akzeptabel ist. Ich denke jedoch, dass Crossposts vermieden werden sollten. post-on-one-dann-migrate-if-not erscheint mir als vernünftiges Protokoll. Vielen Dank! quack quixote vor 13 Jahren 1

1 Antwort auf die Frage

16
Spiff

Mac OS X starts opening ephemeral ports at 49152. Port numbers are 16-bit unsigned integers, so there are 65535 possible ports. 65535 - 49152 = 16383. I think you've got 16K ports in TIME_WAIT.

Update: You might want to look at the following sysctl(8) variables:

net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.hilast: 65535

I think if you set hifirst to something lower, you'll increase the number of ephemeral ports available on your system.

There might be a socket option or something to tell the stack to basically violate the TCP spec and use a nonstandard value for TIME_WAIT, but I'm not enough of a Mac OS X sockets programmer to know that.

Update 2: You probably want to use setsockopt(2) to set SO_REUSEADDR.

Du hast Recht. Netstat sagt mir, dass sie alle in TIME_WAIT sind. Ich verwende bereits SO_REUSEADDR auf dem Daemon, aber die Benchmark-Apps tun dies wahrscheinlich nicht, weshalb es umkippt. Natürlich ist es höchst unwahrscheinlich, dass ein einzelner Client ohnehin so viele gleichzeitige Verbindungen aufbaut (im Gegensatz zur Wiederverwendung einer oder einiger Verbindungen). pbhogan vor 13 Jahren 0
sudo sysctl -w net.inet.ip.portrange.first = 32768 half, das Problem zu lindern. Unter Mac OS X müssen Sie wahrscheinlich sowohl zuerst als auch zuerst festlegen, da sie gleich behandelt werden und Sie nicht wissen, welcher verwendet wird. Siehe auch: http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html#FreeBSD pbhogan vor 13 Jahren 0
Diese Antwort löste ein ähnliches Problem, das ich mit Java / JMeter hatte, mit 1000 Anfragen / Sekunde an einen schnellen Webservice (lokales Perfoming). StaxMan vor 10 Jahren 0

Verwandte Probleme