Article Details
Product: ServiceDeskPlus
Category :ServiceDeskPlus >> TroubleShooting
Performance Troubleshooting

When ServiceDesk Plus endures a performance issue, few first hand information collected from the application will help us to analyze the issue quick and with ease.

Few scenarios that you may experience.,

      1. ServiceDesk Plus is slow in general

      2. Unable to access a specific tab

      3. CPU usage peeks to 100% in the server due to ServiceDesk Plus

      4. ServiceDesk Plus crashes frequently

Regardless of the above mentioned scenarios, few general information has to be collected from the application and the server which hosts the application.

      1. Support File - As soon as the issue recur, Go to Support Tab in ServiceDesk Plus and click on Support File. Save the file which gets created in a new location.

      1. Thread Dump - When you face a performance degradation, at that particular instance, go to Support Tab in ServiceDesk Plus in a separate browser tab and click on Thread Dump. It will show the Thread Dump in a separate window, save the page as .htm file. If the web console of ServiceDesk Plus is inaccessible during the issue, access the URL, http://<SERVERNAME:PORT>/jsp/ThreadDump.jsp' in a new browser tab, it will create threaddump0.txt will be created in the location [servicedesk]\server\default\log.

      1. Server Configuration – Operating System, RAM available, free space in the installation drive and processor info.

      1. Go to [servicedesk]\bin directory, copy the file StartDB.bat also go to [server]\default\conf, copy the file wrapper.conf, compress these file (ZIP/RAR) and save it in a new location.

      1. Data Count in Tables – Go to Support Tab in ServiceDesk Plus, in the section ServiceDesk Plus application status check, click on 'Data Count In Table'. Save the results as a .htm file.

      1. Scheduled Activities – Go to Support Tab in ServiceDesk Plus, in the section ServiceDesk Plus application status check, click on 'Scheduled Activies'. Save the results as a .htm file.

For the initial phase of analysis, the above mentioned files and info are essential. Please collect them all and send it to .

Additional Info that is required for few issues in specific

No Managed Connections / Unable to access a specific tab

MS SQL Database

When the serverout*.txt files in the Support File is analyzed with the 'no managed connections' error trace or if accessing one of the tabs / feature freezes the application in a MS SQL environment, we need to find the MS SQL table lock at the instance when the issue recur or we have to reproduce the issue and get the lock query.

Open command prompt (administrator), [servicedesk]\bin>mssqlstatistics.bat

It will create the file sp_who2.html and Block.txt in the location [servicedesk]\server\default\log. Check if the file Block.txt contains the suspended query. This query is required to analyze the failure.If it doesn't have the query there, then open the file sp_who2 and check for the SUSPENDED entry against 'servicedesk' DB and make a note of the 'BlkBy'. You can also execute the 'sp_who2' directly it the query analyzer to get the below result.

In the above example we have found the 'BlkBy' as 58, now connect to the SQL Management Studio and execute a new query in the servicedesk DB. Query - 'dbcc inputbuffer (58)'

It will return the actual query which is getting blocked.

Copy the query, save it in a text file. This query has to be analyzed to find the root cause.

MySql Database

In the case of mysql database, we need to enable the slow query log to capture the query which causes this issue.

To enable it, go to [servicedesk]\bin folder, edit the file 'startDB.bat' file in a WordPad and add the below parameter at the end of the existing parameters.

--log-slow-queries --long-query-time=6

Restart the application once for it to take effect. Now you can find the '<machine-name>-slow.log' in the location [servicedesk]\mysql\data.

These information, the blocked query in case of MS SQL or the slow log in case of the MySql database along with the general info mentioned in this initial document will be helpful in analyzing this issue.

100% CPU Usage

In scenarios where the CPU usage in server peeks to 100% due to ServiceDesk Plus, the Performance Monitoring Tool will capture threaddump0.txt in the location [servicedesk]\server\default\log. However, the tool has to be enabled. Collect all the threaddump*.txt available in the logs, in addition to that take a screen-shot of the performance tab in the Task Manager and send it along with the other general info mentioned in the beginning.

ServiceDesk Plus crashes frequently / OutOfMemory

If the wrapper.log file is found to have OutOfMemory trace or if ServiceDesk Plus crashes frequently, collect all general info required for analyzing performance issues, along with it also capture the Java version. To capture the Java version in the application, go to [servicedesk]\jre\bin and execute 'java -version'.

General Solutions and Workarounds

To set the Java heap and MaxPermSize to the max values in wrapper.conf

Before allocating the max memory for Java heap and PermSize, we have to determine the available physical memory in the server. To determine the system's available memory, launch the Task Manger > Performance tab and check the 'Available' memory in the Physical Memory section.

In our server we have 8 GB of installed memory in which about 5 GB of memory is available.

Go to [servicedesk]\server\default\conf, edit the file in a WordPad and seach for the keyword 'heap' and set the 'java.initmemory' to 256, 'java.maxmemory' to 1024 and 'MaxPermSize' to 256m as show in the below image.

Restart ServiceDesk Plus for this configuration to take effect.

Configuring MySql to increase the memory usage

Increasing the memory allocation for MySql also depends upon the available physical memory. Go to [servicedesk]\bin and edit the file 'starDB.bat' in a WordPad and add the tuning parameters in addition to the existing parameters.

If available memory is 1 GB

--set-variable=query-cache-type=2 --read_buffer_size=128K --read_rnd_buffer_size=1M --sort_buffer_size=1M --myisam_sort_buffer_size=4M --tmp_table_size=32M --max_heap_table_size=32M --key_buffer_size=32M --innodb_buffer_pool_size=128M --bulk_insert_buffer_size=16M --table_cache=512 --thread_cache=32 --innodb_flush_log_at_trx_commit=0 --low-priority-updates

If available memory is 2 GB

--set-variable=query-cache-type=2 --read_buffer_size=128K --read_rnd_buffer_size=1M --sort_buffer_size=2M --myisam_sort_buffer_size=4M --tmp_table_size=32M --max_heap_table_size=32M --key_buffer_size=32M --innodb_buffer_pool_size=256M --bulk_insert_buffer_size=16M --table_cache=512 --thread_cache=32 --innodb_flush_log_at_trx_commit=0 --low-priority-updates

Restart the application once for this configuration to take effect.

Performance Guide:

Please refer the performance guide to enhance the general application performance when there are no memory issues or database query locks.