sickn33/antigravity-awesome-skills/odoo-performance-tuner

# odoo.conf — illustrative values only; measure workload and total memory before use
 
workers = 4                   # illustrative; budget HTTP, cron, DB and OS memory together
max_cron_threads = 2          # background cron jobs; keep ≤ 2 to preserve user-facing capacity
limit_memory_soft = 1610612736  # 1.5 GB — worker is recycled gracefully after this
limit_memory_hard = 2147483648  # 2.0 GB — worker is killed immediately; prevents OOM crashes
limit_time_cpu = 600          # max CPU seconds per request
limit_time_real = 1200        # max wall-clock seconds per request
limit_request = 8192          # max requests before worker recycles (prevents memory leaks)

-- Step 1: Enable pg_stat_statements extension (run once as postgres superuser)
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
 
-- Step 2: Preserve existing preload entries and schedule a server restart when adding this module:
-- shared_preload_libraries = 'pg_stat_statements'
-- log_min_duration_statement = 1000   -- log queries taking > 1 second
 
-- Step 3: Find the top 10 slowest average queries
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;
 
-- Step 4: Inspect statistics as context; correlation alone does not identify missing indexes
SELECT schemaname, tablename, attname, n_distinct, correlation
FROM pg_stats
WHERE tablename = 'sale_order_line'
  AND correlation < 0.5   -- physical ordering statistic, not an index-quality verdict
ORDER BY n_distinct DESC;

Prerequisites: Run Odoo with ?debug=1 in the URL to enable debug mode.
 
Menu: Settings → Technical → Profiling
 
Steps:
  1. Click "Enable Profiling" — set a duration (e.g., 60 seconds)
  2. Navigate to and reproduce the slow action
  3. Return to Settings → Technical → Profiling → View Results
 
These are investigation hypotheses, not automatic diagnoses. Check query plans, locks, data volume, cache validity and profiler overhead before applying indexes or caches.
 
What to look for:
  - Total SQL queries > 100 on a single page  → N+1 query problem
  - Single queries taking > 100ms             → missing DB index
  - Same query repeated many times            → missing cache, use @ormcache
  - Python time high but SQL low             → compute field inefficiency