I’ve had a quick look, but can’t see any similiar threads, has anyone experienced poor performance from the Rhythmyx front end. We’re noticing that it’s getting progressively worse, and seems to be particularly acute in the past few weeks. Symptons we’re seeing are:
-Exceptionally slow when logging in, the java icon hangs for a good couple of minutes.
-Same again when changing communities, but not quite to the same extent.
-Slow loading of content items.
-A few browser crashes when creating a new content item.
-We have a file type, which permits us to upload files as content items. Previously files of any size were fine, but now Rhythmyx sometimes imposes a limit by throwing errors when saving the file.
We’re having to ask users to clear out their cache much more frequently, and likewise with bouncing the system.
We’re on version 6.5.2, the db is ms sql server. Our RhythmyxServer.ja file is current as follows (although I’m not sure if this would impact the above symptons):
%IF_EXISTS%(“INIT_JAVA_HEAP”, “@INIT_JAVA_HEAP@256m”)
%IF_EXISTS%(“MAX_JAVA_HEAP”, “@MAX_JAVA_HEAP@1550m”)
Are there any guidelines for alleviating this sort of behviour in any way, or where to look to find where the problem may lie? I’m seeing nothing in the log file by way of indication. Are there approaches to cleaning out the file system, or database that could help?
Performance issues are often difficult and time consuming to troubleshoot, but the following steps are a good place to start. If issues persist even after following these steps, it’s probably time to open a new ticket with TS.
General Performance Checklist:
Are there any errors in the <rxroot>RXROOT/console.log (5.x) or the <rxroot>RXROOT/AppServer/server/rx/log/server.log (6.x)?
A. If there are errors, correcting them should ALWAYS be the first priority. There are sometimes memory settings that can be changed to give better performance overall, but if you don’t fix the actual errors, these changes will only provide temporary or limited relief.
Are there any Java Heap errors in the logs from step 1?
Java Heap errors can be caused by a number of issues, but most often are the result of unresolved errors. Assuming you’ve already completed step 1, try creating a RhythmyxServer.ja file in your RXROOT <rxroot>directory.
Inside the RhythmyxServer.ja should be a single -Xmx parameter. We generally recommend starting with a value of 512mb (-Xmx512m) and increasing that value by increments of 256 up to 1536mb (-Xmx1536m). Java imposes a limitation on this parameter of just about 1.5GB (1.7 on Linux), so any value over 1536 will cause more issues than it’ll help. The server must be restarted for changes to take effect.
Are only certain client machines experiencing performance issues?
If so, </rxroot></rxroot></rxroot>turn on all java debutting features (Control panel > Java > Advanced > Java Console > enable all 3 Debugging options) and <rxroot><rxroot><rxroot>log into the Cx with the java console open (Control panel > Java > Advanced > Java Console > enable ‘Show Console’). While the Cx is loading, keep an eye on the java console for any java heap errors.
If you see a java heap error in this log, the local client JRE doesn’t have enough memory to log into whatever folder the user was last logged into. Often, this can be resolved by adding an -Xmx value to the local JRE (Control panel > Java > Java > click ‘View’ under Java Applet Runtime Settings > add an -Xmx parameter under Java Runtime Parameters). This parameter would usually be -Xmx246m or -Xmx512m. The limit here is the available memory on the client. The browser must be restarted for any changes to take effect.
We had similar issues and eventually tracked it back to extensive logging configured on our XML applications. This might help you figure out where to look http://forum.percussion.com/showthread.php?t=3819 .
Thanks for the suggestions, there’s nothing in the log file that looks too unusual. I’ll have a look into the logging configuration. Whatever I find, I’ll post up here.
There are some errors that occur in the log files during a publish, these have been there long term. I’ve spent the past day or two trying to sort them out; they were quite difficult to trace one is: Problem while generating a publishing location for variant null and contentid null. I’ve my fingers crossed that I’ve got rid of these now and will hopefully find in the next publishes.
Rhythmyx.ja
A cut’n’paste:
%IF_EXISTS%(“INIT_JAVA_HEAP”, “@INIT_JAVA_HEAP@512m”)
%IF_EXISTS%(“MAX_JAVA_HEAP”, “@MAX_JAVA_HEAP@1536m”)
I just want to make sure that this is the correct syntax.
One the advice of vtDarrell, I’ve checked the pslog and pslgdat tables, however ours contain only 158 rows, so I suspect that isn’t the problem.
Finally 4) A few of us have noticed that when logging in to the front end with the java console open and have found that it hangs at the step:
With a Java heap that large, we ran into issue with garbage collection. the default rmi garbage collector runs every 60 seconds, but it probably takes almost 30 seconds to crawl a heap that large looking for items to discard. JBoss heavily uses RMI.
There are a lot of articles out there about tuning java heap management. We had to tweak the options for a couple of weeks before we found the sweet spot.
Let me be clear, that I’m not saying you should use these, nor do I even know if your JRE on your OS supports all of these options.
Specifying an Xmx = Xms cuts down on the need for the JVM to repeatedly resize the heap; useful when you have a large Xmx. -XX options are not guaranteed across future versions of the Java, but these in particular work well for us.
Of course, I’m also open to suggestions anyone else may have towards heap tuning.