The Midnight Problem

Somewhere, at this very moment, in an IT department or team of programmers, someone is planning a scheduled task. That task should run in "off" hours, when no one is around. The immediate suggestion that pops up is MIDNIGHT. There is no debate, no questioning of it and the task is scheduled for midnight.

Unfortunately, in many environments, this scenario is repeated a couple of times a month. I say unfortunate because the original reason for running these kinds of jobs overnight in the first place is that batch jobs that consume computing resources shouldn't interfere with regular daytime work activities. However, when *everything* gets scheduled at midnight (and in many shops, that actually ends up happening), all you've done is shift the bottleneck to the middle of the night.

I've worked in environments where the bunched up batch jobs all scheduled at midnight thrashed the hard drive and CPU all night and are often still running at 9 or 10am the next day.

When we changed the scheduling to stagger them out a bit, from 10pm through 6am, the total burden on the server dropped dramatically and we actually dropped the overall time spent running these jobs just by being more careful about scheduling.

So, if you happen to be in that meeting today and someone says "midnight", please, just check to see what else is running at midnight and consider a different time slot.