Community  »  Perl: Allgemeines Forum

alarm Problem	Seitenanfang
Hi zusammen, ich hab hier ein ziemlich merkwürdiges Problem mit alarm. Ich hab ein Script entwickelt, welches umfangreiche Dateiarbeiten durchführt und dabei aufs Internet zugreift. In regelmäßigen Abständen (7200 Sekunden) sollen die erstellten Dateien mit gzip gepackt werden. Solange nur eine Instanz des Scriptes läuft klappt das wunderbar. Aus Effizienzgründen laufen jedoch meistens so ca. 50 Prozesse des Scriptes. Dabei wird jedoch kein SIGALRM mehr verschickt (bzw. höchst selten, und nicht im Abstand von 7200 Sekunden). Ist das einstellen eines Alarms nur systemweit möglich? Laut Docu müßte sich das doch auf einen Prozeß beschränken? Ansonsten hab ich nur die Erklärung, daß bei einem Load von im Schnitt ca. 30 der Rechner überlastet ist. Der Alarm-Handler macht nichts weiter außer eine globale Variable setzen, welche dann im Hauptprogramm ausgewertet wird und danach wird der Alarm neu eingestellt. Hat jemand eine Erklärung für dieses Phänomen? cu Aiko Datum: 19.11.2005-02:28
re: alarm Problem	Seitenanfang
Hi, Du meinst, dass der Rechner (Linux?) eine Load von 30 hat? Soweit ich weiss, bedeutet eine konstante Load von 1, dass ein Rechner mit 1 CPU optimal augelastet ist. (Bei 2 CPUs also bis 2 und wenn die noch Hypedrthreading haben, dann 4 usw.). 30 wäre also verdammt viel. Wie kommst Du zu den 50 Prozessen? Mit fork? Hast Du denn etwas Beispielcode, den man mal kopieren und testen könnte? Gruss, svenXY Datum: 20.11.2005-12:45
re: alarm Problem	Seitenanfang
Load von 30 heißt, das im Schnitt 30 Prozesse Rechenzeit verwenden (ganz einfach ausgedrückt). Ich starte das Perlscript mehrfach, keine Threads. cu Aiko Datum: 20.11.2005-17:16
re: alarm Problem	Seitenanfang
Hi, OK, ich verstehe. Die Doku zu alarm() meint dazu: alarm SECONDS alarm Arranges to have a SIGALRM delivered to this process after the specified number of wallclock seconds have elapsed. If SECONDS is not specified, the value stored in $_ is used. (On some machines, unfortunately, the elapsed time may be up to one second less or more than you specified because of how seconds are counted, and process scheduling may delay the delivery of the signal even further.) Only one timer may be counting at once. Each call disables the previous timer, and an argument of 0 may be supplied to cancel the previ- ous timer without starting a new one. The returned value is the amount of time remaining on the previous timer. For delays of finer granularity than one second, you may use Perl's four-argument version of select() leaving the first three arguments undefined, or you might be able to use the "syscall" interface to access setitimer(2) if your system supports it. The Time::HiRes module (from CPAN, and starting from Perl 5.8 part of the standard distribution) may also prove useful. It is usually a mistake to intermix "alarm" and "sleep" calls. ("sleep" may be internally implemented in your system with "alarm") If you want to use "alarm" to time out a system call you need to use an "eval"/"die" pair. You can't rely on the alarm causing the system call to fail with $! set to "EINTR" because Perl sets up signal handlers to restart system calls on some systems. Using "eval"/"die" always works, modulo the caveats given in "Signals" in perlipc. eval { local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required alarm $timeout; $nread = sysread SOCKET, $buffer, $size; alarm 0; }; if ($@) { die unless $@ eq "alarm\n"; # propagate unexpected errors # timed out } else { # didn't } For more information see perlipc. Könnte es sein, dass Du extrem viele system calls machst und der Handler deswegwen nicht funktioniert (s.o.)? Kannst Du das wie vorgeschlagen mit eval probieren? Gruss, svenXY Datum: 21.11.2005-09:15