r24 - 2015-05-26 - 18:04:11 - StephanieBagotYou are here: TWiki >  Deployment Web > DeploymentTroubleshooting > PerformanceTroubleshooting > WhyIsMyDatabaseConsumingSoManyResources

Why is my database consuming so many resources?

Authors: MikeDelargy
Build basis: CLM 4.x and later

Initial assessment

Symptoms

  • When I monitor my database server resources, I see high CPU or memory usage, or both.

Impact or scope

  • Does it affect one CLM application or multiple applications?
  • Are you noticing a negative performance impact when CPU usage is high?

Timing (When?)

  • When did the problem start to occur? (Has this always been the case, or is it a relatively new observation?)
  • Does this happen at any particular time of the day?
  • Do you have a separate data warehouse database and is the data warehouse on a separate database server?
  • Are builds being run when you see the spikes.

Environmental changes (Where?)

  • Has anything changed in the environment (outside the products) that could cause the problem?
  • Has the hardware, software, network, or client changed?
  • Are other applications using the same database server?
  • Is other software running on the database server?

Recommended data gathering and subsequent analysis steps

  • There are many commands the database administrator (DBA) can use to monitor the performance of your database. Keep in mind that excessive monitoring can lead to performance degradation of the database software. Limit monitoring initially to the amount of data (inbound and outbound), the number of queries over time, and some measure of the amount of time from the receipt of a SQL request to the time a response is generated.

Database tuning is typically out of scope for Jazz administrators.

Monitoring DB2

For more information on configuring and tuning the DB2 database, see Configuring and tuning DB2.

For more information on optimizing table space performance when data is on RAID devices for DB2 9.7, see Optimizing DB2 on RAID devices.

Monitoring Oracle

For more information on monitoring and tuning the Oracle database, see Configuring and tuning Oracle.

Monitoring SQL Server

For more information on monitoring and tuning the SQL Server database, see Configuring and tuning SQL Server.

Possible causes

  • Make sure that your database has sufficient physical memory and enough allocated memory to perform a lot of data transfers. All of the REST-based objects need to be stored and retrieved here, and the rest of the solution architecture depends on the repository. Do not try to cut costs; make sure that the foundation for your solution is solid.

  • Your database should be on a dedicated server. While it is technically possible to install the database software onto the same machine as other software, the load on the database is heavy because almost every user action implies multiple database events (like queries, inserts, or modifications). Deploy the database on a dedicated database server.

  • If you are running reports and have not configured a data warehouse, consider creating a separate data warehouse and locating it on a separate database server.

  • If you have been able to correlate reports running (ETLs) at the time of the spikes, consider moving your data warehouse to another database server.

  • Builds have several phases. During the first phase, data is being requested from the database as the source files are returned and populated into the build workspace. During this phase, there is a large load of communications and database traffic. A caching proxy placed between the build machine and the Jazz repository will cache copies of the source files that do not change often, thus eliminating the need to retrieve these files from the repository. Consider using a content caching proxy server to minimize the load on the database. For more information on content caching proxy servers, see Using content caching proxies for Jazz source control.

  • Your database administrator should be able to run an analysis on the database to help identify issues and provide steps to help optimize the database. These might include poorly formed queries, missing indexes, table locks, and even calls being made to the database outside of the application server. Use the above links to specific database vendor tools to help identify some of these issues.

Related topics: None

External links:

  • None

Additional contributors: None

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r24 < r23 < r22 < r21 < r20 | More topic actions
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Ideas, requests, problems regarding the Deployment wiki? Create a new task in the RTC Deployment wiki project