Slashdot Mirror
Worlds Slowest NT Server
Thom writes "NerdPerfect is holding a contest to find the NT server with the slowest reboot time. The best (worst?) time so far is 49 minutes, 13 seconds. Go check it out."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
...something an NT server will be good at! ;)
"Total destruction the only solution" - Bob Marley
One could easily have the login authenticated accross an artifically slow link creating very long login times. I think they should take this out of the contest.
Then again, this isn't scientific, and is good clean FUD, so sure, whatever!
-AP
There is a known problem with Microsoft Exchange 5.0 (and 5.5) that in certain circumstances can cause an NT machine to take a LONG time to reboot (approx. 1-2 hours). I believe that a machine with Exchange will be the winner because of this problem (which I spent days with MS trying to track down this problem).
This problem is apparently due to a service deadlock (i.e. the service does not respond to the kill command). There is a registry entry (what a shock!) that dictates how long NT will wait for a service to shutdown. Of course, this is a PER service command. If you have a deadlocked service subsystem (as can occur in certain circumstances with Exchange), it will take approximately * to bring the system down. I believe the default is 5 minutes. Changing it to ten or twenty seconds does a lot of good. =)
Looking at the website, the leader with 49 min has Exchange running on it. Maybe we should notify him of this registry entry... Nah...
Later,
Justin
Mu. P.S. The address you see is real. =)
What's the point of this? To show that NT takes a long time to boot up? To make NT look bad?
It doesn't do either. The organisers come across as being incredibly immature, and the existence of such a lame contest is hardly a credit to the Linux community.
He probably didn't shut the exchange services down in the correct order before shutting down exchange.
:-)
I have a pair of scripts on all three of our exchange servers, and use one of them to shut them down first before rebooting the server (the other one is for restarting the services, but is rarely used).
Here's the shutdown script:
@echo off
rem batch file to stop Microsoft exchange
echo Stopping services
net stop MSExchangeIMC
net stop MSExchangeMTA
net stop MSExchangeES
net stop MSExchangeIS
net stop MSExchangeDS
net stop MSExchangeSA
echo system down
As for longest shutdown, I did have once where one person here decided to reboot the server at the end of the day (and didn't know about the scripts), and it was still trying to stop the services at 8am (15 hours later!).
-- trust me, I'm a Viking
Java gaming nut - http://www.retep.org/ or for the rail http://uktra.in/
You'd be surprised.. I have a system that fsck's 6 8.5 gig drives in parallel in under 60 seconds. (I think it is about that timeframe, it has been 65 days of uptime since it last booted.) Running a single fsck, on one drive (95% full) takes 35 seconds real time (as just measured)
:)
But lets put it this way, that system takes less time to boot up with an fsck than my personal machine which has one 90% full 5gb partitian formatted with the defaults among its drives.
Those 6 drives are intended for big datafiles, so I make the blocksize 4kb as compared to the default 1kb. This means 1/4 the number if indirect blocks. Also, since its big files, there aren't a lot of directories so it doesn't have to scan through them. Those directories that there are only require 1/4 the time to read because they are 1/4 the number of blocks. (I assume that sequential reads are relatively free because seek time should be the main cost.)
Then, I formatted it at one inode per 128kb, as compared to the default of one inode for every 4kb. This drops the number of inodes fsck has to read off the disk by a factor of 30 to only 69632 (compared to >2 million in the default format). (FSCK *has* to read off each inode, to check if the file is orphaned.) I think that this here is the main speed improvement. It also frees an extra 120mb of drivespace. (drivespace that an fsck would have to read in.)
Remember, since you can never create new inodes, so the default format always starts you with a large amount of them, usually an insane number of extra ones.
What I'm saying is to format your drives appropriately for their planned usage. FSCK's don't always have to be that painful.
If you need that huge quantity of extra inodes and also have to save the data, than you are screwed. If you don't need all the inodes, then formatting a filesystem without them is a lot more effecient. And if you don't need to save the data (say, a cache server), then it may be faster to just reformat it upon each boot.
If none of the above apply, then yes, with the current version of ext2, it is very painful to fsck a 20gb filesystem that has 3 million files on it.
...it's been going on for many years. The fastest boot sequence of any reasonably general purpose OS I've encountered was on Univac 494/Omega that I worked on back in the early 70s (when it was already nearing the end of its lifetime): given suitable peripherals it could boot and have the online workload running again in under 10 seconds - because it had been designed for a target market which could not tolerate extended outages. And because the machine had a maximum of 262Kwords of memory, and ran at only about 1.2Mips, there was a premium on careful programming that used resources efficiently. Even then, though, it was clear that the trend was towards the cost of implementation and maintainance of application software exceeding that of the raw processing power, so that it became increasingly cost-effective to use less expert implementors and to provide them with tools that traded implementation time against run-time performance. And that is a perfectly reasonable and defensible way of proceeding, provided that the various costs are taken fully into account.
:-(
However, there's a big difference between making a considered guestimate of the price of processing power over the likely lifecyle of a project and using these resources accordingly, and making the mistake of thinking that "cheap" resources are "free", and placing no constraints on their use (or, equivalently, blindly assuming that available systems will be fast enough to run the product by the time it is released). In the old days, if you did this you were liable to fail to meet contractual performance criteria, so there was a fairly direct feedback mechanism that kept product performance reasonably compatible with the capabilities of the platforms on which the products ran. More recently, with commodity pricing for software products, this feedback loop has been broken, and the costs of poor implementation practices are now born disproportionally by the customers - whether by being forced to replace systems more frequently, or with outages after major software failures becoming longer, or by finding that the newest products increasingly manifest inconsistent and unpredictable failure modes.
It's interesting, in this regard, that there have been rumours that MS may be considering leasing of its products rather than (or more likely in addition to) the customary "shrink-wrapped" sales. Major corporate users might just be interested in this approach, if it gave them some contractual leverage when the fitness for use of a particular product was less than satisfactory.
Just don't hold your breath