NFSv3 über TCP oder UDP?

Irgendwann wurde bei NFS heimlich TCP zum default RPC transport, so dass der geneigte Admin es nach dem Update benutzte, ohne es zu wissen. Es lief im LAN so gut wie UDP, also warum ändern, nachdem man es dann entdeckte?

Solange der Server nett ist, ist der Tux es auch. Sollte der Server aber auf die Idee kommen, manche Calls nur sehr zögerlich zu beantworten, fällt der Tux stumm auf den fetten Bauch. Bei UDP ist die Sache klar: Nach dem Timeout gibt es ein Retransmit und der Counter geht hoch. Nicht gut für den Server, weil sich die lahm beantworteten Calls nun vermehren, aber immerhin sieht der Admin, dass es ein Problem gibt. Load steigt mit den blockierten Prozessen und das System läuft normal weiter.

Bei TCP gibt es kein Retransmit – der Call ging ja nachweisbar nicht verloren. Theoretisch besser, aber real stauen sich die Calls, was man nicht sehen kann und irgendwann passiert es dann: Der Tux plumpst hin und blockiert auch I/O zu lokalem Storage – keine Fehlermeldung, teilweise wird selbst auf Eingaben an der Konsole nur noch verzögert oder gar nicht mehr reagiert. Zeit für Alt-SysRq, Reboot tut gut.

Für den Admin sieht das so aus: Auf einmal hängt das System ohne Fehlermeldungen. Soll der Depp mal drüber nachdenken, wie das kommen könnte.

Also zurück zu UDP, dann schaukelt sich die Last kurz massiv hoch und danach geht nichts mehr. Immerhin gibt’s eine Meldung, wer den Streit anfing, und wenn der gehbehinderte Server überlebt, dass der Tux ihn bis dahin regelmäßig gegen das Schienbein tritt, geht es irgendwann ohne Reboot weiter. (wenigstens seit Kernel 2.6.32.* und bei 2.6.34.7 immer noch so)

One Comments

  1. Der Tux friert bei TCP und Performanceproblemen im NFS ein, das ist war. Dabei sollte ein Pinguin Kälte vertragen. Das tut er sogar. Er braucht halt nur um die 8 Stunden, um wieder auf die Beine zu kommen. Hat mir ein Techniker erzählt, der sich damit auskennt.

    OK, den Anwendungen wird das gar nicht gefallen, für 8 Stunden auf den fsync() warten zu müssen. Insofern ist der Unterschied zwischen „hat sich auf die Fresse gelegt und bleibt liegen“ und „steht wieder auf“ eher theoretischer Art, denn den Tux muss man gleich zum Reinkarnator schicken.

    Das Dumme ist nur, daß Tux mit UDP auch nicht so viel robuster daherwatschelt. Irgendwelche Datenstrukturen füllen sich nämlich auch da, und selbst wenn der Tux sich von allein bekrabbelt hat und die Anwendungen das Lagging überlebt haben, so kann es beim fsync() oder bei einem geplanten Shutdown trotzdem zum grossen Tux-Hängen kommen. Oder der Kernel-Speicher ist „nur“ total fragmentiert und der OOM-Killer läuft gegen harmlose Anwendungen Amok.

    Der NFS-Client ist einfach mächtig kaputt, und das schon lange.

Leave a Reply

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen