Event cache for YFN 7.1
Answered
Hi,
Is the following article applicable to YFN 7.1?
The reason I'm asking is the info_cache.jsp page doesn't show any info on the event cache.
Regards,
Nick
Hi,
Is the following article applicable to YFN 7.1?
The reason I'm asking is the info_cache.jsp page doesn't show any info on the event cache.
Regards,
Nick
Hi Nick,
This actually does not relate to 7.1. I believe the earliest version this was introduced was 7.2.
Regards,
Paul
Hi Nick,
This actually does not relate to 7.1. I believe the earliest version this was introduced was 7.2.
Regards,
Paul
Thanks Paul.
I have an issue where broadcast schedules run on every 1st of each month, and on that day, SR crashes when users access SR and broadcast schedules kick off. To me, it sounds like a resourcing issue.
I've checked the Tomcat JVM Max memory, which is currently set to 4.5 GB and there's 2.2 GB free mem according from info.jsp. I haven't tried allocating more at this stage, but is there anything else I can look at since event cache is not an option in 7.1?
Please let me know if needs to be raised via a support ticket
Regards,
Nick
Thanks Paul.
I have an issue where broadcast schedules run on every 1st of each month, and on that day, SR crashes when users access SR and broadcast schedules kick off. To me, it sounds like a resourcing issue.
I've checked the Tomcat JVM Max memory, which is currently set to 4.5 GB and there's 2.2 GB free mem according from info.jsp. I haven't tried allocating more at this stage, but is there anything else I can look at since event cache is not an option in 7.1?
Please let me know if needs to be raised via a support ticket
Regards,
Nick
Hi Nick,
It could be a resourcing issue. Even though you have quite a bit of memory allocated, if you are kicking of a lot of report all at the same time on the same day and they are intensive based reports, you may need more. Although what we normally suggest is to go through the reports and change the times that they run at on the 1st of the month. This way you are spreading the load across the morning.
i.e.
Via the Report.
Via the Admin interface.
In almost every case when this is done, the problem is fixed. You may still need to increase memory, but I would look at this as the first option.
Thanks,
Paul
Hi Nick,
It could be a resourcing issue. Even though you have quite a bit of memory allocated, if you are kicking of a lot of report all at the same time on the same day and they are intensive based reports, you may need more. Although what we normally suggest is to go through the reports and change the times that they run at on the 1st of the month. This way you are spreading the load across the morning.
i.e.
Via the Report.
Via the Admin interface.
In almost every case when this is done, the problem is fixed. You may still need to increase memory, but I would look at this as the first option.
Thanks,
Paul
That is another option. Thanks for the suggestion, Paul.
If for any reason, the customer is unable to do this i.e stagger broadcast schedules, or allocating more JVM memory doesn't resolve the issue.
Is there anything else from a YFN perspective that we can look at?
Server specs look more than enough (CPU/MEM).
Regards,
Nick
That is another option. Thanks for the suggestion, Paul.
If for any reason, the customer is unable to do this i.e stagger broadcast schedules, or allocating more JVM memory doesn't resolve the issue.
Is there anything else from a YFN perspective that we can look at?
Server specs look more than enough (CPU/MEM).
Regards,
Nick
Hi Nick,
We do have various performance improvements, but the next one to check from here would probably be the way the reports are built and starting to analyse them in more detail. We could also look at making sure there are enough Database connections available in-case you are running out.
To be honest, this should fix the issue (Staggering the schedules and typically this should be okay to do), but if not we could look at some profiling tools or even the logs to see what errors are being seen.
Regards,
Paul
Hi Nick,
We do have various performance improvements, but the next one to check from here would probably be the way the reports are built and starting to analyse them in more detail. We could also look at making sure there are enough Database connections available in-case you are running out.
To be honest, this should fix the issue (Staggering the schedules and typically this should be okay to do), but if not we could look at some profiling tools or even the logs to see what errors are being seen.
Regards,
Paul
Hi Paul,
We've tried stagger the report schedules, and monitoring at this point.
I'll let you know as soon as I have an update.
Regards,
Nick
Hi Paul,
We've tried stagger the report schedules, and monitoring at this point.
I'll let you know as soon as I have an update.
Regards,
Nick
Hi Nick,
Great. Thanks for the update.
Cheers,
Paul
Hi Nick,
Great. Thanks for the update.
Cheers,
Paul
Hey Nick,
Just checking in on this ticket to see how it's going and if you need any more help?
Thank you,
Paul
Hey Nick,
Just checking in on this ticket to see how it's going and if you need any more help?
Thank you,
Paul
Hey Paul,
No further assistance needed on this one.
Thanks,
Nick
Hey Paul,
No further assistance needed on this one.
Thanks,
Nick
Thanks Nick.
Thanks Nick.
Replies have been locked on this page!