Converse agora com nosso suporte
Chat com o suporte

Foglight Evolve 6.3.0 - Performance Tuning Field Guide

Overview Hardware and Operating System Tuning Management Server Tuning Java Virtual Machine Tuning Backend Database Tuning High Availability (HA) Tuning Agent Tuning Store and Forward Processing Appendix: Performance Health Check Appendix: Analyzing a Support Bundle

Sample init.ora:

db_file_multiblock_read_count = 16
dispatchers = ‘(protocol=TCP)(disp=4)(con=50)’
job_queue_processes = 10
sga_max_size = 6544M
undo_retention = 3
db_block_size = 8192
open_cursors = 300
pga_aggregate_target = 1599M
processes = 150
sga_target = 4544M

Database Maintenance Recommendations

For database maintenance recommendations, see the appropriate sections below.

MySQL Tuning

 
Table 1. MySQL Tuning
Motivation

MySQL caches data pages in the memory buffer pool. It is important that you have a large enough memory buffer pool for MySQL to have a high cache hit ratio.

Symptom

The browser interface performance is poor (that is, it responds slowly).

Diagnosis / Verification

The diagnostic snapshot for the Management Server shows that it is overloaded.

Tuning

Increase the innodb_buffer_pool_size to 1 GB or more (up to 80 percent of the free memory). The default is 512 MB.

For more information on MySQL performance, you can try
http://www.mysqlperformanceblog.com and http://www.oracle.com/technetwork/index.html.

Case

Exception: com.quest.nitro.service.topology.LockTimeoutException: Error obtaining cache lock for object

Cause: This exception is thrown when a thread that is trying to update a topology object from a Canonical Data Transformation (CDT), times out waiting for a write lock on the object. If it takes a long time for the object to be updated, it is probably because the database is dealing with a heavy load.

If you run your server in debug mode, the server logs thread and lock information, and therefore reports when it encounters such an error. For example, in one case where this exception was thrown, a thread dump was logged approximately a minute later. That thread dump showed that a few threads were inserting topology objects, and that several threads were waiting for an alarms query to finish. It seemed that the database had been allocated a lot of memory, but it was difficult to tell the status of the I/O. Some configurations are configured to flush the transaction logs to disk at the end of every transaction. The standard, or typical, configuration is more relaxed about this. It sets the following in the my.cnf file:

innodb_flush_log_at_trx_commit=2

That setting is beneficial in cases like the one described above.

Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação