Hope someone can help me out, I’m in the dark here…
Prob is, earlier this week the al_jobserver was consuming 100% cpu, bringing down the performance on our DI server.
After a reboot the issue was gone.
Problem solved, but now we want to find out why DI was doing this.
I checked the logs & events, but couldn’t find anything…
We do have this job running every night, but it didn’t igve us any probs earlier or later this week.
I am facing the same issue of al_jobserver utilizing maximum amount of CPU(fluctuating between 85 to 100).
I have seen entries for" Cleaning job server log files…" in server even logs
so its not logs nor the column mapping option in designer since it is unchecked as well.
The utilization is happening even when jobs are not running(Off peak hours). Also the jobs are not performing any resource consuming operations. Since we just upgraded from 3.2 to 4.2, I have never seen this much utilization in our legacy 3.2 version. We have designer and job server installed on same machine (VMware -2008 R2 with 2CPU* 3 Cores and 12GB RAM).
We are on DS 4.2 SP1.
I am trying to avoid rebooting the server because we have cyclic jobs which run every 30mins for 24*7.
If anyone had similar problem can you guide me where to start with?
I think it may be related to the background job that is supposed to clear out the older jobs and logs. Your job server CPU at 100% may indicate a different problem.
Check with your DBA to see if the AL_STATISTICS table in your repository is exceptionally large. If so, have the DBA truncate that table. Then, if your log retention period is the default of 30 days change it to 7 days.
Thank Jim. Retention period is left as 30 days, I can try changing it to 7 days though.
Does that mean that setting up of retention period to 7 days will take care of clearing AL_STATISTICS table prior to 7 days?
I will check with my DBA on table. When do you think we can say that table is exceptionally large?
Also Do you see any need of back up of AL_STATISTICS table or see any affect on application side if truncate on the table happens?
No, there is no need to backup the al_statistics table unless you are running reports off of that table.
I would truncate it before you set the log retention period to 7 days. Otherwise it will try to remove 23 days of data using a standard DELETE statement. The truncate will be much faster and in most cases won’t adversely affect your transaction log.
(BOB member since 2004-01-30)
(BOB member since 2004-12-17)