... a large hash.
You may simply be out of memory. Hashes use up a lot. You may be automatically OOM-killed. The slowness you mention is suggestive of a program driven into swap.
You could try all kinds of debugging tricks to track this down, but just checking process memory use as the hash is built should be enough to spot this. Perhaps you will need to change your algorithm.
| [reply] |
Anonymous Monk,
Certain types of signals can be trapped and hence ignored. On a *nix platform, signal 9 can not. Depending on how and why your script was killed, there are a handful of options.
- Perhaps you could post your code and we could help make it more run-time efficient
- Perhaps you could ask the administrator to exempt this particular script if it is an automated cleanup process
- Perhaps you could ask the administrator under what circumstances a kill happens and ask for help playing by the rules. Possibly you only run 20 minutes at a time and save your intermittent results to file for persistency.
Cheers - L~R | [reply] |
Yes maybe, or maybe a cron job set up by the administrator that automatically kills user processes for users who aren't currently logged in, or who haven't been active in awhile, etc.
Dave
"If I had my life to live over again, I'd be a plumber." -- Albert Einstein
| [reply] |
$ nohup script.pl &
As always YMMV
| [reply]
[d/l] |
Is it possible that you're running against the limits of your shell? Like for CPU time, memory usage, etc? Try seeing what your limits are set to by running ulimit -a.
| [reply] |
Thought in addition to what is above. Is your system running a backup at that time? It could be killing all non-essentials (through a cron or what ever) at the same time each night.
| [reply] |