Tracer quickly hits 50,000 event limit
Tracer gets disabled after a certain number of entries even though the maximum limit is set to 50,000, and the user is unable use the Tracer to analyze the application.
Event file has reached the limit of 50000 events
Steps to Reproduce
The output of the Tracer to the runtime Tracer window is resource intensive and the process can slow down to the point where either the wait to see all 50,000 lines is unacceptably long or the Tracer process hangs before those 50,00 lines are reached.
As a result, it is not possible to debug the issue at hand.
Open the Tracer settings panel and change the "Max Trace Events to Display" to 0.
The setting will be displayed at the very bottom of the settings panel.
The Tracer will go much faster if the output of lines to the screen is disabled by setting this field to 0. The Tracer log will still exist and the user can save it to disk.
Since there is no output to the screen, the user cannot tell when the Tracer has finished recording all of the events.
However, since it is recording much faster than when the screen is displaying those events, it is usually safe to wait only an additional minute after your command completes before pausing the Tracer and then saving it to disk. If, after completing the following steps, the user discovers the Tracer was truncated before hitting the 50,000 event limit, just repeat the process and wait a bit longer before saving. In all cases, the Tracer will still stop when the 50,000 event limit is reached.
The TracerViewer tool is required to analyze the saved file. The TracerViewer tool can be downloaded from here:
However, now that the user has a more complete Trace, it should be easy to find the cause of the large number of events.
For this issue, there was a page list of 756 entries, and an n² algorithm was working through the page list. Since 756x756 = 571,000, and each iteration through the list produced 4 or 5 lines of output, the total number of events that might have been required to output the complete Tracer file was over two million.
The solution is to replace the n²-search algorithm with something more efficient. And, if it is not this loop that is the actual cause of the issue, then placing the rules which execute the algorithm into a separate ruleset and not tracing that ruleset will eliminate all of these two million events from the Tracer file.
If it is absolutely required, the user can increase the 50,000 limit by adding/modifying this prconfig entry to a larger number:
Published July 23, 2018 - Updated October 8, 2020
Was this useful?
0% found this useful
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.