The Server Metrics page displays a collection of metrics that you can use to monitor the performance of your YouTrack Server installation. When users report that YouTrack is slow, use these metrics to help diagnose the problem.
The path to the location where your YouTrack application files are installed. For ZIP and MSI installations, this is also referenced as the
Use this information to determine where these files are located when you need to upgrade or restore your installation.
The path to the current location of your YouTrack database.
Each installation package has a default location for storing database files. However, you or another administrator can change this location.
This information simply helps you find where YouTrack stores data files without having to search for the files on the server.
The path to the current location of your YouTrack log files.
As with the database, there is a default location for storing log files, but logs can also be stored in a custom location.
When you report a problem to our customer support team, they often ask you for copies of these files. This information helps you find these files quickly.
The number of cores that are capable of running YouTrack.
The number of processors that you need to run YouTrack varies based on the number of users and the number of transactions they perform on a regular basis. However, we don't generally recommend that you run YouTrack on a machine that has fewer than two cores.
The total amount of free JVM heap memory that is currently available to your YouTrack service.
For best performance, this number should always be larger than the Database Size without BLOBs. If your database is larger than the amount of heap memory that is available to the JVM, consider the following actions:
The peak amount of memory that has been allocated to the JVM that runs your YouTrack service.
In most cases, your YouTrack installation will have used as much memory as has been allocated to the JVM during peak use. However, if you have overallocated memory, this number can be significantly lower than the Available Memory.
Use this metric to determine whether you can safely reduce the amount of heap memory that is available to the JVM without going below the minimum requirement.
The amount of JVM heap memory currently being used by your YouTrack service.
Compare this value to the Allocated Memory to measure your current memory usage versus the peak amount of memory that has been allocated to the JVM.
You should also compare this value with the Available Memory. If you are consistently using most of the Available Memory, consider increasing the maximum Java heap size.
The total amount of running time since the last YouTrack service start.
Our support team uses this information to detect possible memory leaks. In this case, it is important to know how long the service was running before it ran out of memory.
The date and time of the last YouTrack service start.
There are certain database problems that can only be discovered on application restart. This information can help you determine which of your backups has a valid database that you can restore to should you encounter problems with your database.
Database Background Threads
The number of dedicated threads that populate the database queries cache.
A healthy server normally requires only one or two threads to perform these tasks. This number is calculated statically on server start and remains constant.
Pending Async Jobs
The number of tasks that are waiting to be executed, usually background tasks that populate the database queries cache.
On a powerful server, you should see that this queue of tasks is processed fairly quickly. If you see an abnormally high value that remains unchanged or grows in value, your server is experiencing problems.
To resolve this problem, you can switch the server to read-only mode until the queue returns to normal levels. For more information, see System.
Cached Results Count in Database Queries Cache
The number of records that are held in the cache for search query results. Cached results improve the performance of search queries against the database.
Database Queries Cache Hit Rate
The percentage of search queries that are satisfied by results that are stored in the cache.
A high percentage means that there are fewer queries that have to run against the database itself, which is good.
Check this metric when users complain about poor search performance. If this percentage is lower than 50%, it can indicate that there is insufficient storage space allocated to the cache. To investigate this issue, submit a support request.
BLOB Strings Cache Hit Rate
The percentage of text-based data that is served from the BLOB strings cache. This rate does not affect performance as significantly as the Database Queries Cache Hit Rate does, but can affect page load time.
The BLOB strings cache mainly stores issue descriptions and comments. When this percentage is high, YouTrack is able to load this information quickly. If the data is not served from the cache, users experience slow page loading times.
While the text index is being rebuilt, the percentage is expected to be low. This should return to a healthy percentage after the index is rebuilt.
If this percentage is consistently lower than 20%, it can indicate that there is insufficient storage space allocated to the cache. To investigate this issue, submit a support request.
The number of database transactions that have been processed since the last service start time.
You can compare this number to the Uptime to measure the average overall server load.
Transactions per Second
The average number of database transactions that are processed each second. Measures the immediate server load.
Check this metric when users experience general performance issues. It may be that your server is processing an unusually high number of transactions.
Requests per Second
The average number of requests that are processed each second.
This is also a load indicator. Each request can initiate multiple database transactions. For example, a single request to merge two user accounts can trigger a series of transactions that are required for this operation.
Database Size without BLOBs
The total size of the database, excluding binary large objects (BLOBs).
Images and other attachments are stored as BLOBs, as are large blocks of text in issue descriptions and comments. The amount of space that on the server that is occupied by these objects is excluded from this calculation.
Compare this metric with the Available Memory to determine whether you need to increase the amount of memory or reduce the size of your database.
Full Database Size
The total amount of space on the server that is currently occupied by your YouTrack database.
Text Index Size
The amount of space in the database that is used by the text index. The text index is used to find matching words and phrases in search queries.
A normal text index will be roughly 10% of the Database Size without BLOBs. If the ratio is higher than 50%, it can indicate that there is a lot of random text stored in the database.
Rebuilding the text index can improve performance. For instructions, seeText Index.
The number of users who are currently using the application.
If there numbers are relatively large, it indicates that the traffic on your server is very heavy. You may experience poor performance not because of any problem with the application itself, but because there is a large number of incoming requests that are generated by a large number of users. The following metrics are shown:
Report Calculation Threads
The number of threads that can be used to calculate reports. Basically, shows the number reports that can be calculated simultaneously.
Notification Analyzer Threads
Shows a number of threads that are allocated for processing events (updates in issues, saved searches, tags, and so on) and analysing the required notifications. The more threads allocated, the quicker the events queue is processed and calculated, and the quicker the notifications are sent.
Notification Analyzer Queue Size
The number of issue updates that are waiting to be processed by the notification analyzer.
The notification analyzer looks at all of the changes that have been applied to issues, finds all of the users that subscribe to these changes, and determines whether the notification contains a single update or a digest of concurrent changes. Notification analysis can be CPU-intensive, so a large number of unprocessed notifications can have a negative impact on general server performance.
On our YouTrack server, we monitor this metric and notify the administrators when the queue is larger than 50 for at least five minutes.
If this number is very large and increases in size, you can switch the server to read-only mode until the queue returns to normal levels. For more information, see System.
There are a number of factors that can slow down notification analysis. If you experience poor performance and you see that there is a persistent number of analyzer tasks in the queue, submit a support request. Our support team can help you determine the best solution for this problem.
Notification Sender Queue Size
The number of notification messages that have been analyzed and processed and are waiting to be transferred to the mail server for sendout.
If this number is high, it indicates that there could be a problem with your mail server. Here, it's worth checking both the YouTrack server logs for exceptions and the logs for your mail server for rejected sendouts.
User Action Job Processor Queue Size
The number of user-initiated transactions that are waiting for execution. This is an alternative technical metric that shows pending asynchronous jobs that were initiated by user actions.
This number can be unusually high when users initiate jobs that require significant resources, for example, merging sets of values for custom fields or deleting projects. Otherwise, the queue size should be close to zero.
Hub Events Queue Size
The number of events that have been processed in the Hub service that are waiting to be synchronized with the YouTrack database.
These events are polled by YouTrack on a set schedule. This number can be unusually high when a change is applied in the Hub service that requires significant resources, for example, merging user accounts.
If you have updates that are applied in the Hub service that do not appear immediately in YouTrack, you may observe that this events queue is very large. In most cases, you can simply wait until the queue returns to a normal size. The changes in Hub will be applied to YouTrack at a normal rate.