基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/thiagofernandes1987-create/APEX --skill odoo-performance-tuner命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Token-aware reasoning workflow with real tools: picks an operating mode to control cost, runs a structured pipeline (decompose → validate → verify → snapshot), and gives Claude Program-of-Thought, RK4/Euler, a code gate, and a safe skill router. Use when: multi-step or high-stakes tasks, real math, precise computation, audits, or the user mentions APEX, PoT, pipeline, or scientific mode.
**v00.33.0**: Ingested from antigravity-awesome-skills community repo
run multiple local CLI agents in parallel (separate tmux sessions)
| name | odoo-performance-tuner |
| description | "Odoo is slow in production (slow page loads, timeouts)." |
This skill helps diagnose and resolve Odoo performance problems — from slow page loads and database bottlenecks to worker misconfiguration and memory bloat. It covers PostgreSQL query tuning, Odoo worker settings, and built-in profiling tools.
MemoryError or Worker timeout errors in logs.odoo.conf for a specific server spec.@odoo-performance-tuner and describe your performance issue.# odoo.conf — tuned for a 4-core, 8GB RAM server
workers = 9 # (CPU_cores × 2) + 1 — never set to 0 in production
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: Also add to postgresql.conf and reload:
-- 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: Check for missing indexes causing full table scans
SELECT schemaname, tablename, attname, n_distinct, correlation
FROM pg_stats
WHERE tablename = 'sale_order_line'
AND correlation < 0.5 -- low correlation = poor index efficiency
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
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
mapped(), filtered(), and sorted() on in-memory recordsets — they don't trigger additional SQL.partner_id, state, date_order).@tools.ormcache decorator on methods pulled repeatedly with the same arguments.workers = 0 in production — single-threaded mode serializes all requests and blocks all users on any slow operation.limit_memory_soft — workers exceeding it are recycled between requests; without the limit they grow unbounded and crash.prefetch_ids on recordsets — rely on Odoo's automatic batch prefetching, which activates by default.shared_buffers, work_mem, effective_cache_size) is highly server-specific and not covered in depth here — use PGTune as a starting baseline.odoo.conf access — some tuning options are unavailable.Analyze —