Главный принцип - подвергай всё сомнению. В IT особенно!⁠⁠

Меня всегда интересовало - откуда вообще пошла рекомендация 25% RAM для shared_buffers ?

Спросил у DeepSeek

Кто первый рекомендовал значение 25% от размера RAM для параметра shared_buffers для СУБД PostgreSQL ?

Рекомендация устанавливать параметр **`shared_buffers`** в размере **25% от объёма оперативной памяти (RAM)** в PostgreSQL впервые появилась в **официальной документации проекта** и стала результатом **коллективного опыта разработчиков и сообщества**, а не авторства одного конкретного человека. Вот ключевые аспекты её происхождения и распространения:

---

### 📜 1. **Источник рекомендации**
- **Документация PostgreSQL**: В ранних версиях документации (например, в версии 9.1 и более поздних) явно указано, что для серверов с RAM ≥1 ГБ "разумным начальным значением" является **25% от общего объёма памяти** . Например:
> *"Если вы используете выделенный сервер с объёмом ОЗУ 1 ГБ и более, разумным начальным значением `shared_buffers` будет 25% от объёма памяти"* .
- Эта рекомендация позже стала стандартом в руководствах по настройке производительности.

---

### ⚙️ 2. **Почему именно 25%?**
- **Компромисс между кэшем PostgreSQL и ОС**: PostgreSQL использует двойное кэширование:
- `shared_buffers` — внутренний кэш СУБД.
- Кэш файловой системы ОС.
При значении выше 25% возникает дублирование данных в памяти, снижающее эффективность. При этом выделение <25% ухудшает производительность чтения данных .
- **Эмпирические тесты**: Эксперименты показали, что 25% обеспечивают баланс для большинства рабочих нагрузок (OLTP, аналитика). Например, тесты EDB в 2022 году подтвердили, что превышение 25% даёт незначительный прирост производительности, но повышает риски нехватки памяти для других процессов .
⚠️⚠️⚠️
Я провел серию тестов для EDB в 2022 году, чтобы определить, как общие буферы влияют на производительность PostgreSQL. Анализ проводился на устаревшем оборудовании с жесткими дисками и на более современных системах на базе SSD. В итоге мы пришли к выводу, что рекомендация 25 % в целом достаточна
⚠️⚠️⚠️
"(Из ссылки на результаты тестов)
Вы серьезно ? Это называете тестом и рекомендацией !? Ни одной цифры , ни одного графика . Просто "мы пришли к выводу" . А почему я могу верить вашим выводам ? Выводы на чем основаны ?
Я кстати, помню как во времена публикации на Хабре, один кекс в качестве критического комментария к моей статье по анализу производительности СУБД приводил эту статью.
"
---

### 📣 3. **Распространение рекомендации**
- **Сообщество и эксперты**: Совет стал общепринятым благодаря статьям на Habr , Crunchy Data , EnterpriseDB и в инструментах вроде **pgTune**.
- **Реальные конфигурации**: В корпоративных решениях (например, для розничных сетей) параметр строго следует правилу 25%:
- Для сервера с 6 ГБ RAM → `shared_buffers = 1.5 ГБ` .
- Для 32 ГБ RAM → `shared_buffers = 8 ГБ` .

---

### ⚠️ 4. **Исключения**
- **Системы с малым RAM** (<1 ГБ): Рекомендуется снизить долю до 15% или ниже .
- **Специфические нагрузки**:
- Для OLAP-систем с большими запросами иногда эффективнее 15–20% .
- Для чисто записывающих (write-heavy) нагрузок избыток `shared_buffers` может замедлить работу из-за накладных расходов на запись WAL .

---

### 💎 **Заключение**
Рекомендация в 25% для `shared_buffers` **не имеет единственного автора** — она сформирована разработчиками PostgreSQL на основе многолетнего опыта оптимизации. Её первое официальное упоминание появилось в документации (версии 9.x и ранее) , а затем было подтверждено практикой сообщества. Для современных систем это значение остаётся отправной точкой, но требует адаптации под конкретную нагрузку и мониторинг (например, через `pg_buffercache` и анализ соотношения попаданий в кэш) .

В общем , всё как обычно - в стародавние времена просто взяли цифру с потолка и затем рекомендация стала передаваться от одного акына к другому .
При этом не особо и задумываясь над целесообразностью, обоснованностью и не проведя анализ и тесты.
Что , в общем то подтверждает давно известное - основная масса DBA - ремесленники , верящие алхимикам.
Подлинное научное и инженерное знание и опыт в DBA это исключение , чем правило.