Hi, I have a group of programs running as NT services. One set built on VA Smalltalk V5.5.2 is running in production on one box and another test set built on VA Smalltalk V8.0.3 running on what is claimed to be an identical box. Both sets write a time stamp to the start up transcript log every two minutes. The V5.5.2 set (even under production load) seems to do this like clock work (sorry for the pun) every two minutes. The V8.0.3 set (with much less load) seems to have periods of 4 to 8 minutes with no log entry. This is very odd. One of the servers is querying the other servers as to their status. During the times of a server not logging its 2 minute entry, The server querying the status doesn't get an answer. This happens when there is almost nothing going on. The servers are not busy doing something else. Ans even if they had something to do, the every 2 minute logging is at a higher priority than the general work load. Has anyone seen anything like this or have any idea what I could look at? Thanks, Lou
-- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/zJ0-TOvvu_gJ. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en. |
I take it the 'stuck' service is using no CPU (if it was, that could be debugged). So I'm thinking the image is stuck waiting on a synchronous callout. How about putting in trace statements before and after them (flushing the log) and maybe you'll see one that takes minutes...
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/JeSpHbDPtPsJ. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en. |
Hi Wayne, Thanks for the ideas, I will give it some thought. Unfortunately, for me, I can't think of many if any. There could be some hidden synchronous callouts made by the VM but I would expect they would be made is a way that wouldn't block the whole VM. I'm careful to put anything that would take a while, synchronous callout or not, in its own fork. And nothing I do should take minutes. That's why I wonder if there isn't something interfering with the dispatching of the VM or the VM;s dispatching of forks? I have seen something like this in the past. On a system running under I think VMWare, when a VA Smalltalk GUI program of mine is set to run at above normal Windows priority, the whole system slowed to a crawl. Especially the GUI program that I was trying to get to run a little faster. Setting the Windows priority to normal, eliminated the problem (no other change what so ever). Now, my current problem isn't on a system running under VMWare but I'm sure the environment can have an effect. Also, as I said, the Smalltalk code (mine) is basically the same between the systems built with V5.5.2 and V8.0.3. Now the Smalltalk VMs are different, some DLLs are different and the load is different (the lighter the load the WORSE the problem, I'm not sure the problem even exists on the V5.5.2 system). Lou You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/WyTC1N2qTysJ. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en. |
Hi, This problem is now solved. First it really wasn't the problem I thought it was. Somehow, somewhere along the line I was under the mistaken idea that more than one of my Smalltalk forks was not running consistently. In reality, only one fork "seemed" like it wasn't running consistently. This was a fairly high priority fork that did a few things every minute like rolling up some statistical counts every minute. It also wrote a time stamp to the log file that the Smalltalk VM uses when it starts a headless image. Some history here may help. Many of these servers use ODBC to access MS/SQL. Some ODBC/MS/SQL errors get logged to this file without a time stamp. To help know about when these errors occurred, I added a test to write a time stamp to the log file every two minutes. I was using Time>asSeconds to see if I was in the next minute. The change in some version after VAST V5.5.2 that added milliseconds to Time and changed #asSeconds from answering the seconds from midnight to the rounded to seconds of milliseconds from midnight. This change made some values of time that were just shy of the next minute look like they were the next minute. My simple test of "Time now minutes even" would sometimes get fooled. This made some of the time stamps get skipped, making it look like the fork hadn't run. Anyway, this problem is fixed. Please see my other post: https://groups.google.com/forum/#!topic/va-smalltalk/wgnMcOSOtrA to see what might be done with Time>asSeconds. Lou
-- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/TuM8cnZaw30J. To post to this group, send email to [hidden email]. To unsubscribe from this group, send email to [hidden email]. For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en. |
Free forum by Nabble | Edit this page |