sorry no space netstat -na >c:\netstst.txt

Just mailed you the results:-)

That looks like a search query without a timestamp being passed to it. Do you have a custom active threads link? The search engine has changed a bit in 6.4 and if you don't use the format found in the new links for "Past 24 hours", "Past 48 hours", etc, then it's going to do a full table scan when doing the search and copy to a temp table. Essentialy it will lock the table until it's done so every other query must wait for it to be done.<br /><br />I've seen this on 2 other upgrades to 6.4, both having a custom link that points to recent posts that was not updated to the new 6.4 format.

why has this guy got so many connections? - 212.204.251.30 <br /> <br />You definetly have too many connections in TIME_WAIT state similer to a denial of service attack, you need to make sure these registry settings are set, you will need to reboot too. <br /> <br />Look at my attachment rename it to .reg and run it, I am sure I havnt missed anything but PLEASE check the technet site before appling it and make sure YOU are happy with the settings. <br />

BTW I think the TIME_WAIT connections is only compounding the main issue. Win2k will leave a connection like tis for 2 hours (7200000), I have mine set to 2.5 mins (150000)<br /><br />heres a good technet link look at appendix A<br /><br />http://www.microsoft.com/technet/treevie...ovg/tcpip2k.asp

212.204.251.30 is another (small) site running a phpbb on the same server (different database).<br />I do not have a custom link to recent posts. We do have a custon header and a custon unregisterednav.tmpl and a registerednav.tmpl. Would you mind having a closer look at my database Rick when I send you my phpmyadmin password via e-mail?<br />I have the feeling it must be database related. I have tried all other options with the help from Clint.<br />I am getting pretty desperate since all visitors are starting to complaint about the slow responce of the server.<br /><br />Regards,<br /><br />Ron.

Actually looking a bit closer on that. That looks like a general search. That's one thing that we are going to need to change is the fact that right now if a user does a generic search it pretty much does scan through all rows in the post table and that can create this issue. But, this is the way .threads has been from the beginning so it shouldn't be a new issue. We probably will need to start building a search index table in an upcoming version to improve the search speed.

Ok, but that is not dragging my server down is it?

Well I have filed a support ticket at infopop, because even with all the help I got here, the problem is not solved.<br />I think there is something wrong with the threads database since the other board runnng on the same server (phpbb) does not have the same problems.<br />I think it must be upgrade 6.3 -> 6.4 related.<br /><br />Regards,<br /><br />Ron

Infopop fixed the problem yesterday:-) <br />It turned out to be a problem with some sort of table wich was not converted properly when upgrading to 6.4. <br />This resulted in the search engine to do searches thrue the entire database (270MB) and that dragged the server down. <br /> <br />Ron