Question: I have many Linux servers (SUSE 9 &10) used to run web services that provide data to large calculation grids. Recently we have had some difficult to explain outages (i.e. hardware and software logs are not showing any obvious errors) and we are starting to wonder whether the long uptime (typically 200-300 days) is the issue. Given that these servers are heavily utilised, should I consider a regular reboot cycle?

Answer: 
Linux servers never need to be rebooted unless you **absolutely** need to change the running kernel version. Most problems can be solved by changing a configuration file and restarting a service with an init script.

You need to watch out for reboots... if you changed anything "on the fly" without reflecting your changes in a service's configuration file, those changes will not be applied after a reboot.

I usually reboot after scheduled system updates, though. It's generally not necessary, but I do them when nobody's in the office, so why not? There are often kernel upgrades when I get to doing the update, anyway.
My infrastructure has two data sites, the alpha (where operations takes place on a daily basis) and the beta (the backup site, in case things go horribly wrong at alpha). Although this is not currently the case, I am pushing to have scheduled downtime at the alpha site every 6 months, so that we can run all services from beta. 

This will accomplish two things. First, it will prove that our disaster recovery site is completely viable. Second, it will give me a week's worth of time to remove accumulated cruft at alpha. 

As it is, I don't reboot my servers as frequently as I should. I agree with the other posters who said that it's important to know that your servers will come back up when you need them to. You don't want to "think" that they will, only to find out that you've changed something and not done it correctly, or not documented it.