Jump to content

Recommended Posts

Posted

Hi Edugeekers,

 

We've got a nice issue where eportal decides to top itself for what seemed to be no reason.

 

I looked back over the times that it was doing it and found that there was a warning from Time-Service stating the following...

 

The time service detected a time difference of greater than 5000 milliseconds for 900 seconds. The time difference might be caused by synchronization with low-accuracy time sources or by suboptimal network conditions. The time service is no longer synchronized and cannot provide the time to other clients or update the system clock. When a valid time stamp is received from a time service provider, the time service will correct itself.

 

Have any of you guys come across this before? Am I barking up the wrong tree? I've set a scheduled job to run every hour to sync the time to see if it makes a difference.

 

Any input would be amazing!

 

Thanks all!

Posted
Try setting up a scheduled to restart eportal at break (if possible) lunchtime and during the night. The way the data sets are structures in Facility eportal slows down the further through the academic year you go, and the more datasets you have live (and not archived)
  • Thanks 1
Posted
is it running as a VM? I've seen issues with time sensitive services if the hypervisor time is creeping (solved by setting an NTP source on the hypervisor) even if the VM is correct
  • Thanks 1
Posted (edited)

I have an issue on a VM which normally keeps good time when something like Symantec does a scan it cripples the CPU and it loses time. I'm pretty sure it happens on physical boxes as well.

It does recover itself but SQL does not like sharing the CPU at all and even a slight time mismatch causes it to fallover.

I did the same and whacked a manual batch file on a schedule to sync time.

Edited by vikpaw
  • Thanks 1
Posted

Hey guys and gals,

 

Yes it's a VM, but it had been running really nicely for a good while, but interestingly, it's been worse since September and obviously the dataset roll over. I've also seen the issue about the VM time/DC time crop up a couple of times.

 

Rebooting at break/lunch isn't really a feasibility for us as our teaching staff need access at those times, pretty sure they need it 24/7 as teachers don't sleep... O_o We do, however, reboot both services between 0300 and 0330 as recommended by ACS. Maybe that's when teachers sleep...

 

Thank you all for your input, I'll let you know if it plays nice for longer than normal. :-)

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...