Permalink
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
132 lines (94 sloc) 7.81 KB

docops

Как устроить хайлоад на ровном месте

Олег Бартунов, Федор Сигаев, Postgres Professional

Содержание

Что такое хайлоад

Что такое хайлоад на самом деле?

Производительные и масштабируемые системы высокой доступности.

Highload — чисто русское слово. Остальные используют high-volume.

Хайлоад — это ситуация в системе, грозящая отказом в обслуживании из-за недостатка ресурсов. Внештатная ситуация.

В идеале хайлоада не должно быть, но есть человеческие ошибки, которые ведут к недостатку ресурсов (железа, людей, денег), а он приводит к угрозе отказа в обслуживании.

Спешная починка костылями.

Костыль — решение задачи без серьёзного редизайна системы. Документированный костыль — полноценная фича системы.

Про что доклад:

  • действия, которые создают хайлоад на ровном месте
  • известные, но важные ошибки
  • в частности про PostgreSQL

Ошибки проектирования

  • Неэффективное использование ресурсов, блокирование спящим процессом. Процесс ждёт, пока клиент заберёт свой запрос.
  • База наружу — внешний трафик внутри сети.
  • Разные сервисы на одной машине дерутся за ресурсы.
  • Останов мастера при исчезновении единственной синхронной реплики. Используйте одну синхронную и одну асинхронную реплику.
  • Неправильное или недостаточное тестирование
  • Пиковые нагрузки — по времени, по событиям, таймзонам.
  • Разумный отлуп роботов

Ошибки проектирования БД

  • Пагинация. На страницу N+1 попадают 3% посетителей, и это скорее всего роботы. Не надо заранее выгружать вторую страницу с LIMIT/OFFSET. А если пользователь все-таки перешел на вторую, то далее выгружайте больше страниц сразу в кэш.

  • Узкие таблицы — оверхед постгресовых заголовков. Заголовок в постгресе всё равно займет не меньше чем 32 байта, даже если колонки — два bool.

    Пример: id-координата, 60 терабайт. Объединили 200 точек в 1 JSON, получилось 10 терабайт.

  • Широкие таблицы — тоже плохо.

  • NoSQL когда не надо. На больших данных джойны в клиенте приводят к аду.

  • JSON/XML когда не надо.

  • «Ненужная» точность вычислений

  • Виртуализация и докер

Graceful degradation

  • Мало кто думает
  • ПОС по нагрузке
  • Лучше обслужить кого-то, чем попытаться обслужить всех и упасть.
  • Поисковые системы лучше всего ищут в ночь с субботы на воскресенье. Когда нагрузки больше, они ограничивают задачу, чуть ухудшают качество, но зато не деградируют.

Нелепости

  • Забытая клавиатура на стойке блокирует отвод тепла, процы понижают частоту.

  • Скомпилировали с дебагом (--enable-cassert).

  • Не материализация настроек — настроили, но не сохранили нигде

  • Логирование (prepared statements & syslog).

  • foreign keys / triggers

  • бесконечные with recursive

  • зависшие транзакции — вакуум встаёт намертво

  • freeze и вообще автовакуум

  • неумеренное использование временных таблиц (bloat системного каталога)

  • ненужные и бесполезные индексы

  • много памяти без huge pages

  • ненужное шифрование

  • множественные savepoint (SubtransControlLock)

  • планируемые дедлоки

  • отключение генетического оптимизатора (geqo)

    Сложность оптимизации — факториал от количества таблиц индексов. Генетический оптимизатор избавляет от этой зависимости.

В PostgreSQL есть таймауты! Используйте их!

  • authentification_timeout
  • wal_sender_timeout
  • statement_timeout
  • lock_timeout
  • idle_in_transaction_session_timeout
  • deadlock_timeout
  • TCP keepalive (оба два!)

И еще много других!

Камни, под которые редко заглядывают:

  • Max_files_per_process
  • bgwriter_*
  • Effective_io_concurrency
  • Effective_cache_size
  • Параллелизм помогает только когда есть свободные ядра.
  • Wal_level
  • Random_page_cost
  • *_collapse_limit если скорость работы зависит от порядка джойнов — упёрлись в этот лимит.
  • default_transaction_read_only
  • max_connection (и на реплике!)
  • временные файлы постгреса — следить, чтобы постгрес создавал их меньше
  • отстающие реплики (гроханье таблиц по одной для освобождения диска)

Срочные костыли (не делайте так)

  • fsync = off (data_loss = on)
  • synchronous commit = on (лог и миримся с потерями)
  • unlogged table (кстати, и hash index тоже (до PG10))

Хайлоада не избежать!

  • Всегда нужен план Б:
    • жертвуем доступностью, чтобы избежать эффекта домино
    • сохраняем целостность данных
  • Обязательны полевые учения.