Web und SSH blockiert / max tcp connections?

[thorstenhirsch]

Ich hab' meine Netzwerkprobleme weiter analysiert und kann mir keinen Reim darauf machen, was die Ursache ist:

- Nach einiger Zeit kann ich keine neuen Webseiten öffnen. Weder in Firefox noch in Safari. In beiden Browsern läuft's auf Timeout.
- Manchmal tritt das Problem 5 Stunden lang nicht auf, dann aber vielleicht 2x in 10 Minuten, es ist sehr unregelmäßig.
- Betroffen ist nicht nur das Internet, ich kann auch keine Verbindung zur Web-GUI meines Routers herstellen. Auch nicht zu anderen Web-GUIs im lokalen Netz.
- Ebenfalls betroffen sind SSH-Verbindungen - wenn das Problem da ist, kann ich keine neuen SSH-Verbindungen eröffnen.
- Bestehende SSH-Verbindungen funktionieren weiterhin.
- ICMP und DNS funktioniert nach wie vor, ich kann alles anpingen (lokal und Internet).
- Es ist nur mein rMBP mit OS X 10.11.2 betroffen, alle anderen Clients in meinem Netz können nach wie vor Webseiten öffnen.

Was ich schon probiert habe:
- IPv6 in OS X deaktiviert
- die Thunderbolt-Bridge deaktiviert
- in /etc/sysctl.conf folgendes gesetzt:

kern.ipc.somaxconn=1024

- auch auf dem Router ein paar Grenzen erhöht (obwohl der Router ja eigentlich nicht die Ursache sein kann):

net.core.somaxconn=1024
net.ipv4.tcp_max_orphans=4096
net.ipv4.tcp_orphan_retries=1

Aber es hat alles nichts genutzt. Ich kann das Problem zwar beheben, indem ich WiFi aus/an schalte, aber es tritt immer wieder auf. Zumindest scheint es nicht (mehr) ursächlich am Netzwerkinterface awdl0 zu liegen, wie ich hier und hier vermutet hatte. Vielleicht hat ein aktives awdl0 das Problem nur öfter auftreten lassen. Ähnlich scheint es sich mit VPN-Verbindungen zu verhalten, das Problem tritt überdurchschnittlich oft auf, wenn ich eine VPN-Verbindung aufgebaut habe ...und die bricht dann (im Gegensatz zu SSH-Verbindungen) sogar ab, wenn das Problem auftritt. SSH-Verbindungen im VPN brechen dann natürlich auch ab. Es überlebt aber bspw. die SSH-Verbindung rMBP -> Router. Aber wie gesagt: auf die Web-GUI des Routers komme ich nicht mehr.

Gibt's vielleicht einen Max-Wert für die offenen TCP-Verbindungen? Das wäre die einzige halbwegs vernünftige Erklärung, die mir noch einfällt.

 

[thorstenhirsch]

Okay, ich denke ich hab' die Ursache gefunden: in OS X ist das Limit für open files standardmäßig viel zu niedrig gesetzt. Ich hab's in ulimit auf 8192 erhöht und in launchctl auf 16384 (soft) bzw. 65532 (hard):

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 8192
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 16384
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited

Unglaublich, wie schnell ein paar tausend offene file handles zustande kommen. Hier meine Top12, wenn ich auf meinem Rechner alles offen habe, was ich so zum Arbeiten benötige:

$ lsof | awk '{ print $1 }' | sort | uniq -c | sort -n
[...]
  62 mysqld
  62 ruby
  68 AppleSpel
  72 nsurlstor
  80 Terminal
113 Safari
115 UserEvent
128 Atom
146 Atom\x20H
280 Spotlight
311 firefox
1746 com.apple

Also jeweils rund 300 für den Atom-Editor, Firefox und Spotlight. Jedes dieser Programme liegt über 256, was standardmäßig das Limit in OS X ist, was unglaublich wenig ist. Vielleicht wird das Limit von ulimit auch gar nicht berücksichtig, keine Ahnung. Konzentrieren wir uns also auf das Limit von launchctl und wieviele offene file handles ich wirklich benötige. Der Spitzenreiter mit 1746 offenen file handles ist com.apple, wohinter sich nochmal Safari versteckt. Safari legt für jeden Tab einen neuen Prozess an, also kommt man bei 30 Tabs mit vielleicht 50 file handles pro Tab ruck-zuck auf 1500 file handles.
Ich hatte das Limit in launchctl schon mal auf 4096 gesetzt - dummerweise in launchctl auch das hard limit, was wahrscheinlich erst meine Probleme verursacht hat, denn das hard limit steht standardmäßig auf unlimited*. Jedenfalls scheint mir 4096 noch zu wenig zu sein, denn insgesamt sind bei meinem User nun so viele file handles offen:

$ lsof | wc -l
    5164

Manchmal auch über 6000, ein Kumpel hatte sogar über 11000 offene file handles, als ich ihn gerade fragte. Zusätzlich habe ich noch ein paar andere Parameter in der Systemkonfiguration hochgeschraubt.

/etc/sysctl.conf:
kern.ipc.somaxconn=1024
kern.maxproc=2048
kern.maxprocperuid=1024
kern.sysv.shmmax=134217728
kern.sysv.shmmin=1
kern.sysv.shmmni=256
kern.sysv.shmseg=64
kern.sysv.shmall=32768
net.inet.tcp.delayed_ack=0
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
net.inet.tcp.sendspace=1042560
net.inet.tcp.recvspace=1042560

/Library/LaunchAgents/th.launchctl.limit.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>th.launchctl.limit</string>
        <key>ProgramArguments</key>
        <array>
            <string>/bin/sh</string>
            <string>-c</string>
            <string>/bin/sh -c "launchctl limit maxfiles 16384 65532; launchctl limit maxproc 2048 2048"</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
    </dict>
</plist>

/etc/profile:
ulimit -u 1024
ulimit -n 8192
ulimit -s 16384

Und es lohnt sich, dem System so viel zu erlauben: Safari läuft flüssiger und die load ist geringer(!) - mein OS X ist nun weniger mit sich selbst beschäftigt. Aber das allerbeste: das Problem taucht nicht mehr auf. Endlich.

* = Hierzu muss man noch wissen, dass - nach allem, was ich jetzt gelesen habe - unlimited nicht wirklich unlimited bedeutet, sondern 10240. Also mit einem konkreten (höheren) Wert ist man meiner Meinung nach besser bedient als mit diesem falschen unlimited.

edit: Da /etc/launchd.conf nicht mehr interpretiert wird, habe ich den entsprechenden Abschnitt geändert zu einer plist-Datei, die beim Boot gestartet wird.