Christian Kruse: "Too many open files" ?

Beitrag lesen

Hoi Christoph,

Naja, so leider finde ich das gar nicht. Es erfordert halt
einfach eine Konsequent saubere Programmierung -- nichts
anderes als Threadsafeness (geiles Wort, leider bestimmt
falsch ;-)

Ich kenne auch nichts anderes als "threadsafe" (Man könnte es
auch übersetzen, aber "einfädelsicher"? ;-)

Naja, aber threadsafeness? Ich bin fast sicher, es muss threadsafety
heissen ;-)

Das erste ist mehr "Zuverlässigkeit" das zweite mehr dem deutschem
"Sicherheit" zuzuordnen.
Mmh...
Ach, nimm "reentrant" ;-)

Ok ;-) Wobei ich Threadsafety als richtig empfinde ;-)

  • Dann gilt: Scripte, die auf mod_perl laufen sollen, grundsaetzlich
      *sehr* gut durchtesten. Es kann sehr gut sein, dass ein
      Fehlerverhalten erst nach einer gewissen Zeit auftritt. Das liegt
      daran, dass der Apache forked: in jedem Apache-Prozess wird das
      Script neu geladen. Und weil der Apache den Child, der den Request
      bearbeiten soll, nach dem Round-Robin-Verfahren

Round-Robin:
http://choices.cs.uiuc.edu/f-kon/RoundRobin/node1.html

Netter Link ;-)

aussucht, kann es
  durchaus sein, dass ein Fehlverhalten erst nach 40 oder 50
  Testlaeufen zum Vorschein kommt. Ich wuerde empfehlen, bei dem
  eigenen Testserver die Anzahl der Childs auf nur sehr wenige
  einzuschraenken. Die Alternative ist natuerlich, dem Apachen
  komplett zu verbieten zu forken. Das erreicht man, indem man ihn
  mit 'httpd -x' aufruft.

Das ist aber wenig zu empfehlen bei "gleichzeitigen" Lese/Schreibzugriffen
auf gemeinsame Dateien. (Datenbank etc)
Also Vorsicht bei scheinbar simplen Lösungen ;-)

Diese 'Loesung' war nur fuer den Developement-Prozess gedacht ;-)

  • Ich kann es nie oft genug wiederholen: vorsicht mit globalen
      Variablen! Globale Variablen erhalten ihren Wert fuer die gesamte
      Lebensdauer des Apache-Kind-Prozesses!

Globale Variablen sind selten threadsafe. Das gilt für alle Sprachen.

Stimmt ;-) Dafuer muss man Mutexes oder aehnliche Locking-Mechanismen
einrichten.

  • Module werde nicht neu geladen. Das heisst, wenn das Script das
      erste mal laeuft, wird das Modul frisch geladen. Beim zweiten mal
      nicht mehr. Um das zu erreichen, muss man...

- den Server neu starten.

Naja ;-)

Eine simple Loesung ist auch eine Loesung ;-)

  • Man sollte mit den Modulen aufpassen.

Gibt es da noch keine Unterscheidung bezüglich reentrance?

Was meinst du?

  • Die SheBang-Zeile hat keinen Einfluss mehr.

Erklärung(?):
Da alles in ein sub{} gesetzt wird, steht diese Zeile nicht mehr am Anfang
und ist somit ein simpler Kommentar.

Nein :-)
Die SheBang wird nicht von Perl benutzt, sondern von der Shell. Mal ganz
abgesehen davon, dass Perl zu dem Zeitpunkt schon laeuft, wo das Script ausgefuehrt wird...

Und da wundern sich die Leute, wenn ich CGI als zweifelhaften Workaround
ansehe ;-)
Ist doch wirklich nicht so schwer ein Modul zu bauen, geschweige denn an
den Apachen anzuhängen, oder?

Nein, das sicher nicht. Probleme macht mod_perl nur mit der
Speicherverwaltung... so 80MB-Apache-Prozesse sind nicht so das dollste ;-)

Hatte nicht letzte Tage hier mal jemand Teilhaber gesucht? ;-)))

Hehe ;-)
Nene. Ich hab mir vorgenommen, jetzt mache ich das richtig. Ich spare auf das
noch fehlende 19"-Gehaeuse und stelle mir dann meinen eigenen Server auf. Mir
geht das dauernde Provider-wechseln einfach nur auf den Geist.

bezahle ich auch noch einen ziemlich teuren Preis dafuer. Der
ISP ist all- -- den Rest musst du dir selber suchen ;-))

"all-exclusive" ? >;->

*hehe* fast ;-))

Kenne mich da nicht aus. (Und zu faul Google zu bemühen ;-)

Kannst es mir ja heimlich stecken.

Tausch mal das 'ex' gegen 'in' und setz ein '.com' dahinter *g*

Gruesse,
 CK