Diagnose and Fix Odoo Performance Bottlenecks

Odoo Performance Tuner guides investigation of slow page loads, timeouts, database bottlenecks and worker memory growth. It combines PostgreSQL query analysis, Odoo worker configuration and the built-in profiler. Given relevant logs or configuration, it provides a root cause analysis and proposed changes with explanations.

The workflow starts by describing the performance issue with @odoo-performance-tuner. Typical triggers include MemoryError or Worker timeout messages, an expensive database operation or a need to size odoo.conf for a particular server. Configuration examples are illustrative: worker counts and limits must fit the measured workload and the combined memory needs of HTTP workers, cron, the database and operating system.

Use it to investigate server-side Python and SQL behavior before changing indexes or caches. The profiler runs through debug mode and Settings > Technical > Profiling: enable a bounded capture, reproduce the slow action and inspect results. High query counts, long individual queries, repeated queries and high Python time are investigation hypotheses. Check query plans, locks, data volumes, cache validity and profiling overhead before deciding on a fix.

The built-in profiler does not diagnose JavaScript rendering; browser DevTools are needed there. Deep PostgreSQL memory tuning is server-specific, with PGTune suggested only as a starting baseline. Odoo.sh may restrict direct database and odoo.conf access. Redis session stores and Celery queue optimization are outside this skill's coverage.

Provide symptoms, relevant log lines, current configuration and server specifications. Outputs include diagnostic reasoning and configuration recommendations for workers, cron threads, memory limits, request recycling and CPU or wall-clock request limits.

A PostgreSQL example ranks queries by average execution time:

SELECT
    LEFT(query, 100) AS query_snippet,
    round(mean_exec_time::numeric, 2) AS avg_ms,
    calls,
    round(total_exec_time::numeric, 2) AS total_ms
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

Using pg_stat_statements requires extension setup. Preserve existing shared_preload_libraries entries and schedule a restart when adding the module. Physical-order correlation statistics alone do not prove that an index is missing.

Recommendations include batching recordsets, measuring actual SQL counts, considering B-tree indexes for frequently filtered columns and using static-asset HTTP caching with a CDN such as Cloudflare or AWS CloudFront. Repeated methods may benefit from @tools.ormcache when cache validity is understood.

Uncached field access through mapped(), filtered() or sorting can still read the database. Rely on automatic batch prefetching rather than modifying prefetch_ids. Preserve memory recycling safeguards and select a production deployment mode supported by the target OS and measured concurrency needs.