I have a timer clocking every one minute in C# window Service. And, This pc is running 24 hours and never shut down. My workflow is that user will set the time for my service to run some processes. eg. he set 14:20. So, When my timer hit 14:20, I run some sql functions. Will it be any impact on performance If i run the timer like that for 24 hours?
Is there any better way?
You could use something like Quartz.NET: http://quartznet.sourceforge.net/
Related
I'm currently running 2 scripts on a weekly schedule on a raspberry pi with the following configuration:
Cron executes a python script at a fixed time weekly. This python script waits between 0 and 50 hours then runs python script A. It waits about 16 hours and runs script A again 3 more times every 8 hours (The script takes about 4x longer to run the first time). 8 hours after the 4th run it runs script B.
I would like to move my scripts to Google Cloud VM for improved reliability but running the VM 24/7 just to run 30 hours worth of computations over a 100 hour period is inefficient and expensive.
I know I can use Google Scheduler as my cron to initiate the VM weekly but I still risk letting it run up to 50 hours waiting for script A to run. I understand cron supports adding a random sleep interval as listed in the example here:
30 8-21/* * * * sleep ${RANDOM:0:2}m ; /path/to/script.php
However, from what I've discovered, Google Cloud Scheduler is limited to 60 minutes and rightfully so. In this case what are my options? Does Google Cloud Task support delayed triggering of VM (up to 50 hours)? Is this something Pub Sub would support instead?
My scripts use a python library that I don't think is compatible with Google App Engine so I would further need to figure how to trigger a specific script in the VM on trigger.
You can use Cloud Scheduler and Pub/Sub to trigger a Cloud Function that will start your VM and execute your script. If you do not want your Compute Engine instances to be running 24/7, at the end of your script you can have your Cloud Function stop your VM.
You can find how to schedule compute instances with Cloud Scheduler here and how to use HTTP functions in Cloud Functions to start and stop your Compute Engine instance [1].
Most importantly, here is the documentation on how to use Cloud Scheduler and Pub/Sub to trigger a Cloud Function [2].
[1] https://cloud.google.com/scheduler/docs/start-and-stop-compute-engine-instances-on-a-schedule
[2] https://cloud.google.com/scheduler/docs/tut-pub-sub
[3] Cloud Functions: https://cloud.google.com/functions/docs/concepts/overview
I have a Node task that I run daily, it takes around 1 hour and I'd like to pay for just that hour, rather than having a server run 24/7.
Ideally, it would be something similar to lamda, although Lamda has a limit of 15 mins.
What services allow this?
I'd take a look at Heroku - a hobby dyno can cover your needs, you'd just need something to call your service to activate it for a short amount of time.
If you're up for containerizing your task, you could use a cron schedule on something like ECS: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/scheduling_tasks.html
Is it possible to run a cron every 86410 seconds or simply every 1 day and 10 seconds?
I have a service which takes 24 hours to process the data from the moment it is called! Now, I need to make sure that I am giving the service enough time to process the data so instead of calling the service every 24 hours, I need to call the service every 24 hours and few seconds!
Is it possible using a cron?
I think it is interesting to note that if you do want to restart the processing every 86410 seconds, then your service start times would drift over days, later and later every time - so if you originally scheduled your process to start at 08:00, after about a year it would be starting at 09:00, and after about 23.6 years, it would go around the clock to start again at 8am.
Cron was definitely not designed for that kind of thing :-)
But if you are running on a recent Linux OS, you can use SystemD timer units to do exactly that. You may be familiar with SystemD service units - as this is how you write services for modern Linuxes, but SystemD can do a lot more, and one of those things is scheduling things that require interesting schedules.
Supposed you run your processing job as a SystemD service, it may look something like this:
/etc/systemd/system/data-processing.service
[Unit]
Description=Process some data
[Service]
Type=simple # its the default, but I thought I'd be explicit
ExecStart=/usr/bin/my-data-processor
You can then set up a timer unit to launch this service every 86410 seconds very simply - create a timer unit file in /etc/systemd/system/data-processing.timer with this content:
[Unit]
Description=start processing every day and 10 seconds
[Timer]
OnBootSec=0 # Start immediately after bootup
# Start the next processing 86410 seconds after the last start
OnUnitActive=86410
AccuracySec=1 # change from the default of 60, otherwise
# the service might start 86460 after the last start
[Install]
WantedBy=timers.target
Then just enable and start the timer unit - but not the service. If the service is enabled, you probably want to disable it as well - the timer will take care of running it as needed.
systemctl daemon-reload
systemctl enable data-processing.timer
systemctl start data-processing.timer
Looking at it a bit more, you mentioned that you want to start the next run of the service after the previous run has completed. What happens if it doesn't take exactly 86400 seconds to finish processing? If we change the requirement to be "restart the data processing service after it finished running, but give it 10 seconds to cool down first" then you don't need a timer at all - you just need to have SystemD restart the service after a 10 seconds cooldown, whenever it is done.
We can change the service unit above to do exactly that:
[Unit]
Description=Process some data
[Service]
Type=simple
ExecStart=/usr/bin/my-data-processor
Restart=always
RestartSec=10
I am starting with Heroku and I have a webapp that has a part that needs to run once every week (Mondays preferably). I had been reading something about workers: here and here and here... But I still have many doubts:
1) This workers, runs on background without a strict control, can´t be scheduled to run once a week. or am I wrong? If I am wrong how can I schedule it?
2) To make them work, what exactly do I need to do? Type
web: node webApp.js
worker: node worker.js
in the Procfile (where worker.js is the part of the program that needs to run only once a week). And that is all?? nothing else?? so easy??
3) And the last one... but the most important. The "squamous matter of money"... One dyno is the same as one worker, so if you have a dyno running for the web you need to buy another for the worker... no? And on the list of prices a extra dyno cost 34.5$ (27.87€). It isn´t cheap... so I want to know if I am right, is it necessary buy a dyno if you want to run a worker?
You might find that the Heroku Scheduler add-on (https://devcenter.heroku.com/articles/scheduler) is a 'good enough' low cost option. You are charged for the hours that your scheduled tasks run for so if you have a regular job that only takes a short time to run it would work out much cheaper than a continuous worker process.
Its not as flexible with regard to scheduling as other options. It can be set up to run a task at a specific time every day or hourly. So if you need to have your task run say only on Mondays then you would need to have the scheduler run daily then check the day within your worker.js and exit immediately on other days.
I have an azure web job running continuously, but the logs indicated that over the weekend it's status changed to Aborted, then Stopped. Although I did not use the website for the weekend, I am not sure why this would happen as there are still a lot of messages on the queue that need to be processed.
What can cause a continuous web job to stop or abort?
Does it have a timeout period?
Can the occurrence of multiple errors also cause it to stop or abort?
The job itself doesn't have a timeout period but the website does. Unless you enable the Always On option, the website (and the jobs) will unload after some idle time.
Another reason why a continuous job could stop is if you are running on the free tier and the job uses too much CPU time (I think you have 2.5 minutes CPU time for every 5 minutes).