db free space and login timeout -strange

I saw something strange this morning that I can not work out in my head.

Customer contacted us saying that the login timeout for one of our web apps was timing out.

The login does a simple check of user name and password against a table and inserts the event into a tracking table. I traced the login routine and the query took zero seconds in the QA on the db server. Everything looked fine in the Task Manager and the Performance monitor except that the disk que spiked out when the login page was used. I pinged between the web and database server and that was fine. The disk had plenty of free space for the log and the mdf files. The db had about of 15mb of unallocated space. Nothing seemed to work until I allocated another 100 MB to the db on their test site. Suddenly no more time out. I tested the live site again and it was still happening (same db and web server). Bumped up the db size on the live site and boom no more problem.

The problem is "fixed" for the moment but I can not seem to reason why so I can actually fix the problem in the long run. I do not know why a simple little password routine would care about the difference between 15mb of unallocated space and 115 mb of unallocated space.From the explanation, it looks like the system tried to expand a file (whether data or log, I am not sure, but I would bet data), but could not do so in the timeout period. What is the growth increment of the file? If you did not change the size of the file, but increased the max-size of the file, did the file grow? Lastly, do you get the disk queue spike, now that the database has been expanded?|||10%, but they had free space. I neglected to check the log file and I neglected to check the perf mon after the symptoms subsided. If I get some time today (a big if) I will try to recreate.|||The log file would not have shown a file auto-grow event. Profiler can capture that, but the history is lost, if you are not watching specifically for that. Hopefully that's changed in 2005. I am a bit suspicious of the free space being available, since you need to run dbcc updateusage to get accurate numbers, but I figure you did that already.