What's the current recommendation on Bouncing the Servers? Should that be done periodically, I'm thinking: Yes? Or, what better way is there to maintain the clean functionality of the environments?

Case in point: We just had an issue where things were so slow that AppStudio timed out while accessing the environments. We restarted the associated services and things are working fine now.

This message has been edited. Last edited by: Doug,

Ideally never, there is a reason for something not responding anymore, that should be fixed first.

Negative effect of server restart: OS cache is gone and you have a new maintainance window.

I'd first check the agents running on the reporting server - there could be a runaway task slowing everything down. If there is, kill the agent.

Doug

When I was an SE a lot of my customers would recycle the reporting server on a weekly basis. The edatemp directory is re-created every time the server is recycled and it would also clear up any excess memory usage as well.

Francis post is also very valid for cleaning up an agent that may be causing an immediate issue and the server can't be bounced.

depends on your usage volume and your tomcat, if you use it. if your edaprint logs get gigantic, recycle more often. if you use tomcat, that sucker needs a recycle as well, renaming the current localhost and starting over with a fresh one when you restart.
I learned from techsupport to rename my tomcat localhosts as a.localhost, b.localhost, etc, after stopping the service and before restarting.
and as francis says, look for hung agents. I use an includable fex in every report that grabs the name of the fex, the user, some parms, and puts it into a .txt file in the agent, so when something crashes or hangs , I can always tell what broke and who ran it.

quote:

Originally posted by susannah:
If your edaprint logs get gigantic, recycle more often.

Just as a side note, you can minimize this by configuring a max line limit and edaprint history file count. You don't have to keep the default edaprint config. For example, you can max the size to 10k lines and 5 history files. It will rollover the edaprints and delete older history files automatically.

Thanks All,

I'll check the size of the edaprint logs. Do the restart delete those logs, I'm thinking: No?

There were no hung agents this time.

We'll look into this deeper (I don't have full admin rights here, yet)

Doug

There is a setting that keeps a number of edaprint logs by default it is 5 logs. They are saved in the \ibi\srv81\wfs directory.

Before you bounce the server, turn it off and disconnect all wires. Depending on the weight, you may require a second person doing the lifting.

On a more serious note, we recently had some serious slowness on both our DEV and production servers. Turned out there was a Windows Update going on...

Microsoft is getting more and more aggressive about pushing updates through our throats recently (is Trump's behaviour rubbing off perhaps?). I'll celebrate the day we get rid of it.

And just a little after posting that we ran into slowness on our DEV server caused by a new version of McCoffee anti-virus, that did not copy the excluded binaries (tscom3, jscom3, edapsomething, tomcat7) nor the excluded directories (not possible anymore?) from the previous version. As a result, it was interfering with the WebFOCUS binaries, severely degrading performance.

And OMG, what kind of user interface is THAT?!? They clearly focused more on pretty pictures than on usability...

On Linux, we rarely reboot the server(s). Slowness can be caused by any of the aforementioned issues plus several others. Temporary files (for example, using Excel output) are written to a specific directory which is designated in the Admin Console. We’ve had run-ins with Java memory issues. Just make sure to check your application server log files and you WF log files (client and reporting server) before restarting anything if you want to get to the root problem. I’ve had times where the log files showed nothing suspicious and a recycling of Tomcat fixed the slowness, so, there’s that, too.

Thanks again Everyone...

That's a lot to chew on for a relatively new installation of WebFOCUS and other IBI Items like DataMigrator.

I'll keep this open for a while...

Doug

This message has been edited. Last edited by: Doug,

Hey Doug

I finally decided to look into the forums for the first time in forever. Lo and behold - a post from Doug Lee

Here's the thing nobody's mentioned, the hanging behavior is very likely actually occurring at the WF client level. It's not necessarily the reporting server.

If you bounced both Tomcat and the WFRS services and things started working, it might have been a client issue.

Here's how to tell - next time it occurs, use something like Fiddler or turn on the AS communication layer trace. (essentially they both watch HTTP traffic which AS uses to connect to the environment)

I can help you with that if you need a hand. A hint when using the communication layer trace - leave the utility running and just toggle on or off. The tracing will start or stop instantly. No need to close that utility between starting and stopping tracing. Notice the path it shows for where the trace will land on your machine (wfscom.trc).

For more info see the user manual and or call me.

WebFOCUS App Studio User’s Manual
Release 8.2 Version 01
September 22, 2016

Page 760- App Studio Trace Utility


Good luck!
Toby

Toby,

Thanks for the great information and our phone conversation. This, along with all the other inputs, will help us resolve this issue and prevent it from any re-occurrences.

I'm going to dive into this deeply next week and update this post accordingly.