The Statistics page displays a collection of data that you can use to monitor the performance of your YouTrack InCloud instance. When users report that YouTrack is slow, use these metrics to help diagnose the problem.
The YouTrack InCloud support team monitors the servers that support our hosted instances around the clock. We use a range of monitoring tools to identify events that can negatively impact performance and resolve them as quickly as possible.
That said, there are several factors that affect the responsiveness of your instance. When users complain that the instance is slow, use the metrics on this page to determine whether your instance is simply overloaded temporarily or requires the attention of the support team.
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 helps the support team determine which backups contain a valid database that they can use to restore your instance should you encounter this problem.
|Database Background Threads|
The number of dedicated threads that populate the database queries cache.
Our servers normally require only one or two threads to perform these tasks. The support team monitors these threads to ensure that your server has enough resources to process its work.
|Pending Async Jobs|
The number of tasks that are waiting to be executed, usually background tasks that populate the database queries cache.
On a hosted instance server, you should see that this queue of tasks is processed fairly quickly.
|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.
|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.
The number of database transactions that have been processed since the last service start time.
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 instance 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 your 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.
|Full Database Size||The total amount of space on the server that is currently occupied by your YouTrack database. Use this metric to determine whether you need to reduce the size of your database or upgrade your subscription plan to increase your storage limit.|
|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, see Text Index.
The number of users who are currently using the application.
If there numbers are relatively large, it indicates that the traffic in your instance 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 instance performance.
|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.
For instances that use a hosted SMTP server, the support team monitors the notification queue for you.
If you use your own mail service and this number is high, there could be a problem with your mail server. Check the logs for your mail server for rejected sendouts or other delivery-related issues.
|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.