perl problem

[mark05]

hi

ich hoffe das das hier die richtige rubrik ist anst kann es gerne an die richtige stelle verschoben werden.

ok ganz kurz das problem .

ich entwickele auf linux ein , unter perl , laufenden daemon der dateien ueberwacht.
unter linux laeuft das auch prima .

kopiere ich nun das script auf openbsd laeuft das script im nicht deamon mode einwandfrei , lasse ich das script jedoch als daemon laufen faegt er an zu schecken
und auf einmal verschwindet perl ganz aus dem speicher.

nach einigen test ist es ein speicher problem , vermutlich hervorgerufen
von den ulimits , schalte ich einige modul im script ab ( was bedeutet das es weniger files zum ueberwachen sind , funktioniert das ding auch als daemon unter openbsd einwandfrei.

hat jemand zufaellig eine idee welche ulimits fuer perl und desen hashes zustaendig sind bzw woran es noch liegen koennte ?

hier mal meine ulims von der obsd kiste

~ >ulimit -a
time(cpu-seconds)    unlimited
file(blocks)         unlimited
coredump(blocks)     unlimited
data(kbytes)         1048576
stack(kbytes)        8192
lockedmem(kbytes)    675246
memory(kbytes)       2024264
nofiles(descriptors) 128
processes            1044

holger

 

[Reks30]

ulimit ist bei so etwas unter OpenBSD oft nur ein Punkt unter mehreren, ich kenne solche Probleme von MySQL unter OpenBSD. Hast du auch mal in die login.conf gesehen, welche Restriktionen da drin sind? Oft liegt es daran. Es gibt in OpenBSD gleich mehrere Stellen an denen Ressourcenlimits greifen (Dafür ist OpenBSD auch das einzigste mir bekannte System bei denen Forkbombs schon in der Voreinstellung gestoppt werden).

Wieviele Dateien öffnet denn dein Script? Falls es sehr viele sind liegt es womöglich an openfiles-cur in der login.conf. Es gibt dann auch noch eine generelle Obergrenze die man per sysctl verstellen kann (sysctl kern.maxfiles), aber login.conf greift schon früher bei niedrigeren Werten. In Bezug auf die login.conf ist es natürlich auch entscheidend in welcher Loginklasse das Script arbeitet, es kann auch sein, das wenn du es nicht als Daemon startest, das es dann in der Loginklasse staff läuft (die weniger Beschränkungen hat) und wenn du es als Daemon startest in der Klasse daemon läuft.

Ich würde so vorgehen: Stelle erst mal fest unter welcher Loginklasse das Script ausgeführt wird und passe dann die login.conf an.

Gruß
Reks30

 

[mark05]

ulimit ist bei so etwas unter OpenBSD oft nur ein Punkt unter mehreren, ich kenne solche Probleme von MySQL unter OpenBSD. Hast du auch mal in die login.conf gesehen, welche Restriktionen da drin sind? Oft liegt es daran. Es gibt in OpenBSD gleich mehrere Stellen an denen Ressourcenlimits greifen (Dafür ist OpenBSD auch das einzigste mir bekannte System bei denen Forkbombs schon in der Voreinstellung gestoppt werden).

Wieviele Dateien öffnet denn dein Script? Falls es sehr viele sind liegt es womöglich an openfiles-cur in der login.conf. Es gibt dann auch noch eine generelle Obergrenze die man per sysctl verstellen kann (sysctl kern.maxfiles), aber login.conf greift schon früher bei niedrigeren Werten. In Bezug auf die login.conf ist es natürlich auch entscheidend in welcher Loginklasse das Script arbeitet, es kann auch sein, das wenn du es nicht als Daemon startest, das es dann in der Loginklasse staff läuft (die weniger Beschränkungen hat) und wenn du es als Daemon startest in der Klasse daemon läuft.

Ich würde so vorgehen: Stelle erst mal fest unter welcher Loginklasse das Script ausgeführt wird und passe dann die login.conf an.

Gruß
Reks30

hi
danke fuer deine antwort .. ich habe mit ulimt gespielt leider bekam ich denwert den ich brauche nicht hin.
nach etwas debuggen habe ich rausbekommen das das script ca 35 mb speiver brauchte.

32 MB habe ich hi bekommen aber mehr nicht vermutlich muss mandafuer am kernel parameter setzen.

was ich gemacht habe , nach einem document was ich bei ibm gefunden habe bezueglich codeoptimierung unter perl,

ich hatte sehr viel mit dem direkten hash werten gearbeitet die ich innerhalb des scripts
benutzt habe , 2 hashes 1x fuer configuration und einmal fuer die files zum monitoren ,
dies habe ich umestellt auf referenzen und siehe da jetzt funktioniert esauch unter
bsd einwandfrei.

holger