Тест упал на пятом часу, на переходе с 16 800 до 21 000 ВРМ. Потом запрос, который выполнялся меньше секунды, вдруг стал занимать десятки секунд. После этого отчёт вместо 5 секунд начал строиться 800. Во второй части мы разбираем, как с этим справились: от LWLock:PgStatsHash и сбежавшего плана запроса до гигабитной сетевой карты и 3 миллионов файлов временных таблиц. В итоге на 21 000 ВРМ получили APDEX = 0,975. Читать далее
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Как мы довели Postgres Pro до APDEX 0,986 на 30 000 пользователей 1С:ERP. Часть 1/3 | 0 | 19.71 | 12-10-2026 |
| 2 | Как мы довели Postgres Pro до APDEX 0,986 на 30 000 пользователей 1С:ERP. Часть 3/3 | 0 | 16.75 | 14-10-2026 |
| 3 | В погоне за APDEX-ом, или как создать HighLoad на недорогом серверном железе | 1 | 16.37 | 20-05-2026 |
| 4 | [Перевод] Статистика PostgreSQL: почему запросы выполняются медленно | 0 | 7.74 | 19-08-2026 |
| 5 | Если ваш админ — самурай, или История восстановления очень нужных данных | 0 | 8.87 | 04-09-2026 |
| 6 | PostgreSQL и временные таблицы. Часть 2: почему 1024 счётчиков бывает мало | 0 | 10.98 | 09-09-2026 |
| 7 | Кэш результатов запросов в Postgres Pro: как ускорить часто выполняющиеся запросы и разгрузить базу | 0 | 7.15 | 15-05-2026 |
| 8 | Если ваш админ — самурай, или История восстановления очень нужных данных | 0 | 8.87 | 04-09-2026 |
| 9 | Кто выгрузил платежи, или Пример расследования инцидента на аудите в Postgres Pro Enterprise | 0 | 8.37 | 10-07-2026 |
| 10 | Два параметра PostgreSQL утонули в разбросе теста 1С | 0 | 8.26 | 20-10-2026 |