optimization of a big postgresql database

Оптимизация производительности большой унаследованной PostgreSQL

базы

Электропрохладительный кислотный тест

Александр Чистяков, главный инженер Git in Sky,

2014

Кто я?

§ Меня зовут Саша§ Я инженер, главный инженер§ В компании Git in Sky§ Я люблю оптимизировать производительность§ Потому что это как волшебная сказка!

Оптимизация производительности большой унаследованной PostgreSQL базы. 2014

Где я? Кто вы?

§ Любите волшебные сказки?§ Пришли послушать про базу данных?§ Пришли послушать про оптимизацию производительности?§ Разрабатываете проекты для веб?§ Поддерживаете проекты в веб?§ У вас уже есть PostgreSQL?


О чем речь?

§ Доклад в жанре “field report”§ Если угодно - “trip report” (см. подназвание доклада)§ Предыстория: http://www.slideshare.net/profyclub_ru/08-6§ Однажды ко мне в дверь постучал

добрый волшебник§ И все заверте...


http://www.slideshare.net/profyclub_ru/08-6

Краткое содержание предыдущих серий

§ Заказчик — конструктор сайтов http://setup.ru§ Пользовательский статический контент (файлы) хранится в

базе данных (PostgreSQL)§ Для больших файлов используются large objects§ Приложение на Perl, работает под Apache + mod_perl§ Переходим из 2012-го года в 2014-й, и...


http://setup.ru/

Наше время

§ Было 6 миллионов файлов в базе — стало 207 миллионов (с версиями)/85 миллионов (без версий)

§ Времена, когда индексы были 2Gb, давно прошли§ Синхронизация тоже не 100 файлов в секунду, а в лучшем

случае 80, обычно — от 20 до 50§ База данных занимает на дисках ~6Tb§ И объем будет только расти


Почему не ...?

§ Россия — страна советов! (Каждый суслик — агроном!)§ “Работает — не трогай” (на самом деле, нет, но)§ У решений могут быть бизнес-причины§ TIMTOWTDI! (Кстати, Perl же!)§ Один из путей — “долго и дорого”

(“никогда и дорого”?)§ Вывод очевиден?


Все же, почему не ...?

§ OpenStack Swif§ Elliptics§ Ceph, MogileFS, MooseFS, whatever§ Слово “кислотный” из подзаголовка (Atomicity, Consistency, etc)

§ Либо делать групповую транзакцию в бизнес-логике (переписать всё приложение)

§ Либо транзакции берет на себя хранилище^ Много ли мы знаем таких хранилищ?


Объекты предметной области и базы

§ Таблица domains — содержит имена доменов, пример — setup.ru

§ Таблица content — содержит метаинформацию о файле (время последнего изменения, на основании которого принимается решение об актуальности бинарных данных)

§ Таблица stat — содержит собственно сами бинарные данные и их sha1-хэш (дедупликация!)

§ Таблица deleted — содержит признак того, что файл был удален§ Итого, у нас есть четыре связанных между собой таблицы


Пользовательские сценарии

§ Публикация и синхронизация файлов:§ Публикуем изменения всегда на одну и ту же ноду§ Иначе пользователь будет видеть старый контент§ Кастомный синхронизатор не очень быстро

распространяет изменения на все узлы§ Отдача статического контента:

§ Нужно отдавать а) последнюю, б) неудаленную версию


Что не очень хорошо?

§ Отдача работает не очень быстро§ Публикация и синхронизация работают не очень быстро§ Существующее железо справляется не очень хорошо§ Пара слов о железе:


Полный Хетцнер!

§ Исходно — RAID0 на 2*3Tb SATA диска, 16G RAM, RAID1 на 2 SSD для pg_temp и временных файлов nginx — сортировка и объединение таблиц в PostgreSQL и буферизация в nginx работают быстро

§ Переезд на RAID10 4*4Tb SATA диска (стало не хватать места), 48G RAM

§ Несмотря на наличие технической возможности, поставить SSD под кэш или временные файлы больше нельзя — добро пожаловать в Хетцнер!

§ ^ Надо как-то жить с этим


Есть ли у вас план, мистер Фикс?

§ Как это делается обычно:§ slow queries log§ pgFouine или pgBadger§ Раз в сутки (или даже чаще) — красивый рейтинг «плохих»

запросов статистика с победителями§ Смотрим план (опять это слово!) запроса§ Кто знает, что такое “план запроса”?§ Кто не знает — тот тоже оптимизатор

(но поисковый)


За спичками

§ Дело не выглядит сложным, кстати:§ “Найти неудаленный файл” при отдаче - это запрос к

view§ “Найти данные для синхронизации” - это тоже запрос к

view§ Это самые распространенные запросы§ Их планы и надо смотреть и оптимизировать


And the Oscar goes to...

§ А вот и план, о котором мы так долго говорили:§

§

§

§

§

§ Что-то он какой-то большой


Чрезвычайные и срочные меры

§ Материализовать нематериализованный view!§ PostgreSQL 9.2 — нет “родной” поддержки materialized view§ ^ не беда§ В книге “Enterprise Rails” отлично описано, как эмулировать

materialized view при помощи триггеров§ BTW WTF is “Enterprise Rails”?§ У нас опять есть план — чего же мы ждем?


Кстати, как это работает?

§ Буквально в двух словах (explain to me like I'm five years old):§ “Поверх” нематериализованного view делается таблица

с такими же полями§ Она работает как кэш — записи в ней создаются по

запросу§ Сначала идем в эту таблицу, потом во view, если там не

нашлось§ Записи инвалидируется при помощи триггеров на всех

таблицах-участниках исходного view


Все сделал как в книге!

§ Надо как-то проверить, что все удалось?§ Честно скажу, pgBadger и pgFouine я не трогал вообще§ Потому что slow log нерепрезентативен и не отражает динамику§ Расширение pg_stat_statements§ ^ должно быть включено у всех без исключения

на планете Земля§ Позволяет смотреть статистику в реальном времени


pg_stat_statements

§ SELECT

(total_time / 1000 / 60) as total_minutes,

(total_time/calls) as average_time,

calls, query

FROM pg_stat_statements

ORDER BY total_minutes/average_time desc;


pg_stat_statements


Вскрытие показало

§ Кэширующая таблица действительно работает§ Примерно 30-40% запросов не попадает в кэш§ ^ Хорошо, надо подождать§ На второй день ожидания ситуация не изменилась


Знай и люби бизнес-логику!

§ Алгоритм:§ Посмотреть в таблице§ Посмотреть в исходном view (долго)

§ А что, если такого файла вообще нет?§ 30-40 процентов запросов — к файлам, которых вообще

нет§ Зачем ходить во view за ними?


Наступило утро, проснулся комиссар

§ Ночью — 15 миллисекунд в среднем§ Днем — 40-50 миллисекунд в среднем§ Вносить изменения лучше ночью§ Но результат будет известен только в середине дня!


Возвращение целесообразности

§ Наша главная метрика — время отдачи контента пользователю!

§ При чем тут pg_stat_statements?§ Zabbix§ Graphite/StatsD§ https://github.com/alexclear/ansible-graphite-playbook


https://github.com/alexclear/ansible-graphite-playbook

Мониторинг/графики

Мониторинг нормального человека Мониторинг курильщика

Zabbix Cacti, Munin+NAGIOS

StatsD/Graphite Riemann+Collectd

NAGIOS passive checks

Мониторинг алкоголика Мониторинг наркомана


Еще пара слов про Zabbix

§ ВоронКаркнул:НИКОГДА!


Ogres have layers

§ Graphite/StatsD stack:§ Dashboard (тысячи их, я просто взял стандартный, он

плох)§ Веб-интерфейс отдачи графиков (на Django)§ Collector w/RRD-like storage (Carbon)§ Aggregator/preprocessor w/UDP interface (StatsD)


StatsD implementation

§ На Go, Node.JS, Python, Perl, C, ... (тысячи их)§ Сначала я взял Python:

§ ^ Автобус не придет§ Старый добрый Perl!


Покой нам только снится

§ Снится не покой, а те самые 40-50 миллисекунд, которые не хотят уменьшаться

§ Что делать?§ Как обычно, построить более подходящие индексы


Момент истины

§ Для самого частого запроса построен хороший индекс на три столбца (до того был — на два столбца, а исходно был на один столбец)

§ В этот момент все стало еще хуже :)§ Размер индекса — 18 гигабайт§ Все предыдущие докладчики, наверняка, говорили, что

маленький индекс лучше, чем большой


One size does not fit all

§ Один из столбцов, по которому построен индекс — varchar§ Превращаем varchar в int:§ http://stackoverflow.com/a/9812029/601572§ create function h_int(text) returns int as $$

select ('x'||substr(md5($1),1,8))::bit(32)::int;

$$ language sql;§ Забыл сказать — я не боюсь хранимых процедур и триггеров


http://stackoverflow.com/a/9812029/601572

После шлифовки отполировать

§ SET enable_bitmapscan=false; <= старые добрые nested loops

SELECT something

FROM stat s JOIN domains d ON d.id = s.domain JOIN content c ON c.id = s.content

LEFT JOIN deleted e ON e.id = s.id

WHERE d.name = domname

AND h_int(s.name) = h_int(filename <= работает новый маленький индекс

AND s.name = filename

AND date_part('epoch'::text, s.ptime) = filerev


Начинаем спать по ночам

§ Индекс занимал 18 гигабайт, стал занимать 8 гигабайт§ Среднее время выполнения запроса днем в моменты

пиковой нагрузки было 40-50 миллисекунд, стало 20-25 миллисекунд

§ 90% запросов обслуживаются за 100 миллисекунд (время от момента начала обработки запроса Perl-приложением до момента конца обработки, включает все SQL-запросы)

§ В среднем запрос обслуживается приложением за 50 мс


Мы строили-строили, и, наконец...

§ ...и, наконец:


Zabbix strikes back

§ ...и, наконец:


Выводы:

§ «Теория малых дел», внезапно, работает^ несмотря на свой почтенный возраст

§ Ломать — не строить!§ Знание — сила!§ Учение Маркса всесильно, потому что оно

верно!§ Кажется, я не туда пишу...§ В планах — шардинг, да


С вами был Александр Чистяков,главный инженер Git in Sky

[email protected]://gitinsky.com

http://meetup.com/DevOps-40

Пожалуйста, ваши вопросы.

Спасибо за понимание!

mailto:[email protected]

mailto:[email protected]

http://gitinsky.com/



http://meetup.com/DevOps-40

optimization of a big postgresql database

Technology

statements postgresql

tb postgresql

view view postgresql

playbook postgresql

time desc postgresql

language sql postgresql

postgresql large objects

materialized view