Quote:
Originally Posted by
Smiling Dragon
It's an interesting and valid point, as it's an interpreted script, you'd have the perl engine + any variables etc declared sitting about in memory wheras an 'at' invocation would clear out and leave the memory free until it's needed. I'm of the same school of thought that if we don't need to use RAM, we shouldn't.
But, there are some things to consider:
- Your average perl binary is pretty small as far as memory footprints go
- Modern unix systems typically don't have the kind of memory issues we used to have, physical chip ram is still precious but swap space on disk is usually rather copious.
- CPU time is still precious, to start a new perl interpreter up is considerably more expensive on CPU than just running a sleep (to all intents and purposes, 0% cpu used) for 30 mins.
- The operational risk _could_ be greater using 'at', this really depends on how the job works though. If you run this thing and it's waiting on some condition to complete before it carries on, could someone make the mistake of seeing it's finished running and thinking that means it's done? They might either run it again (resulting in two 'at' jobs scheduled) or assume it's fully complete.
Excellent.What you have explained is all perfectly correct and acceptable.
But in my case,am doing this operation in a development server(and is a temporary operation too).
This development server got a very little RAM and some cronjobs will take around 4-5 hrs to complete execution,but not doing big tasks.So issues with RAM is an important concern for me.
And two 'at' command execution is a possibility and the pass-through for this is already implemented in my program.The conditional block which holds this 'at' command execution statement will fire only if the program is invoked at a particular time,ie 23:45 for eg.
So after the first scheduling time in crontab (23:45),this conditional block will never fire the next time when it is executed with 'at' or manually.
Anyway, putting the ideas and suggestions like this is great because sometimes programmers never look into these areas,but only from a functional perspective.
Good and thanks a lot for a nice discussion.
With Regards
Dileep Pattayath