Problem: SBMservice unresponsive

[hhh]

Good news!
No freezes since thursday using the new version!

thanks,

henrik

[mickyj]

Excellent news! Fingers crossed.

[hhh]

this morning the service had frozen and had to be restarted.

[mickyj]

That's very depressing news. We've already exhausted all possible avenues to resolve this issue so I really don't know where we go from here. Ultimately we my have to simply start again using a different technology.

[hhh]

It has been running for 6 days straight though, I restarted it this morning and we'll see whether it freezes again.

As described in my other post the service has regarded most incoming connections as coming from banned addresses, with up to four rejected connections per second, which may have caused this crash?
I'm currently running at least 60-70 profiles against the service.

[hhh]

looking through the status logs now, 28000 + rows of status logs the last 24 hours might have helped the crash

[hhh]

looks stable since yesterday, I'm guessing it was the huge amounts of rejected connections and corresponding log messages that caused the service to hang.

[hhh]

FYI - no freezes since last restart (25th of july)

[Dave Wilkins]

Thanks for letting us know (MickyJ is on holiday until later this week but sounds good to me!)

[hhh]

we're experiencing this problem once again every two-three days.
Right now we're running 120 accounts with 3-5 jobs each.

I'm using a monitoring tool to keep track of what's happening to the service and should be able to post some detailed info in a day or two on what happens when it becomes unresponsive.

[mickyj]

Thanks for reporting. This bug is driving us nuts. Any and all information will help.

[hhh]

I think I have some info that might lead you to solving the problem!

We started monitoring the service and the morning after the service had become unresponsive. This is what the monitoring gave us:

Date/ Time/ Working Set/ Pagefile use/ Threads/ Handles
09-14/ 09:00-10:00 /33 MByte /30081024 KByte /20 # /358 #
09-14/ 08:00-09:00 /33 MByte /30081024 KByte /20 # /358 #
09-14/ 06:00-07:00 /33 MByte /30081024 KByte /20 # /358 #
09-14/ 05:00-06:00 /33 MByte /30080399 KByte /20 # /359 #
09-14/ 04:00-05:00 /33 MByte /30073179 KByte /20 # /366 #
09-14/ 03:00-04:00 /33 MByte /30061585 KByte /20 # /371 #
09-14/ 02:00-03:00 /33 MByte /30051328 KByte /20 # /388 #

Somewhere between 06:00 and 07:00 the service froze; the Pagefile use became constant at 30081024Kbyte, and Handles became constant at 358#. Number of threads also remained constant at 20#, but the service seems to reach 20# after running a few hours and then stays there.

This gave us the idea to change some values in the Service Configuration window. We increased the "Threads" value from 10 (default) to 150 to see if that had any effect.

The service has now been running fine since we restarted it around noon on friday (14th) after changing the Threads value.

In the monitoring tool we can now see that the Working set is around 62MB, Pagefile use at 60 450 611 Kbyte (although this varies), Threads constant at 20#, and Handles value changes between 200-540.

It seems that we've found a workaround in changing the threads value, but you might find this information even more useful

[mickyj]

This is extremely helpful.

As you're using threads, you must be using the TCP connection?

What would be the maximum concurrent connections you may have at any one time? For example, do you have many client computers that all run a profile at the same time, e.g. 9am?

[hhh]

In Service Configuration, HTTP is selected.

I'm not entirely sure how many concurrent connections we would have, but all our 120 accounts have their profiles scheduled to start somewhere between 19:30 and 22:30 every night, so it might be 100 connections.

[mickyj]

Now I'm really confused The threads setting isn't used if you're using HTTP. It's only used for TCP connections, so changing it shouldn't make any difference at all.

EDIT: I think we've found the problem here. We've recently updated the component we use for the service & console network communication and I see they've made the thread setting available for HTTP as well. Previously it didn't apply. We'll upload a new beta soon.