Appearance
性能优化
关注 Memos 部署过程中对实际性能影响最大的部分。
Memos 默认情况下是轻量级的，因此应该有针对性地分配性能。在着手进行底层调优之前，先从存储、数据库选择和部署形态等方面入手。
内置缓存
Memos为频繁访问的数据维护了一个内存缓存。该缓存完全在进程内运行，无需任何外部依赖：
| 缓存的资源 | TTL | 最大数量 |
|---|---|---|
| 实例配置 | 10 分钟 | — |
| 用户 | 10 分钟 | 总共 1000 个 |
| 用户配置 | 10 分钟 | — |
缓存条目在执行写操作时立即失效，并在达到其生存时间（TTL）后自动过期。
SQLite 优化
Memos 默认情况下使用以下 SQLite 指令：
| 指令 | 默认值 | 影响 |
|---|---|---|
journal_mode | WAL | 预写式日志记录；允许在写入期间进行并发读取 |
busy_timeout | 10000（10秒） | 最多为写锁等待十秒，过期则返回错误 |
foreign_keys | 0 | 禁用以提高灵活性 |
mmap_size | 0 | 为避免某些操作系统中的内存溢出，禁用内存映射 |
为了获得更高的写入负载，您可以通过DSN扩展默认设置：
bash
export MEMOS_DSN="/path/to/memos.db?_pragma=cache_size(-64000)&_pragma=synchronous(NORMAL)&_pragma=temp_store(MEMORY)"需牢记的SQLite局限性：
| 事项 | 推荐 |
|---|---|
| 并发写入 | 1 （通过 WAL 序列化） |
| 并发读 | 无限制 |
| 实际数据库大小 | 约 100 GB |
| 何时迁移 | 高并发写入或多服务器写入 |
首先需要决定的
- SQLite 对于多数单实例部署是很好用的
- 当有运维上的需要时，迁移到 MySQL 或 PostgreSQL
- 根据文件大小和备份需求选择附件的存储后端
- 生产环境下部署到反向代理上
入手点
- 数据库延迟和并发锁
- 慢速存储卷
- 超大附件的处理
- 容器或 Pod 资源配置不足
优化建议
- 先进行评估
- 确认性能瓶颈后再对数据库进行优化
- 除非是对数据的使用另有要求，否则应保持缓存和代理的简单性
- 优先考虑结构性修复，例如优化存储位置，而不是对运行时标志进行微调。