Вы находитесь на странице: 1из 30

Производительность

PostgreSQL
Николай Самохвалов
http://postgresmen.ru
PostgreSQL
• открытый исходный код;
• BSD-лицензия;
• надёжность, предсказуемость, ACID — главное;
• высокое качество кода;

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
PostgreSQL
• хорошая поддержка: email: pgsql­ru­general@postgresql.org
• сообщество, xmpp: postgresmen@conference.jabber.org
web: http://postgresmen.ru
• коммерческая;
• прозрачность процесса разработки:
• http://wiki.postgresql.org/wiki/Development_information;
• большое количество проектов-спутников:
• http://wiki.postgresmen.ru/index.php/Проекты-спутники_PostgreSQL;

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
PostgreSQL
• богатые возможности:
• сравнение в wikipedia (англ.);
• производительность:
• индексы,
• «фичи», параметры настройки,
• надёжная производительность;

Фото: tika­online.de
http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
PostgreSQL
• масштабируемость:
• партицирование таблиц,
• M-S, M-M репликация,
• «шардинг», кластеризация
• PL/Proxy, GridSQL.

Фото: tika­online.de

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Производительность

1. Настройка
2. Разработка

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Настройка
Диски, RAID, ОС, ФС, postgresql.conf

С чего начать? (Совет №0)

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Настройка
С чего начать?

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Мониторинг, анализ
Все на анализы! (Без исключения)

Непрерывное слежение

Оповещение о проблемах


железо: contrib/pgbench, bonnie++

ОС, СУБД, web-сервер:

ZABBIX,

Cacti/Nagios, + расширения

Staplr by Gavin Roy

SQL-запросы: pgFouine;

pg_stat_*, reads/hits, phpPgAdmin
Где жмёт?
http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Работа с памятью
Если не понимаете этого – 
ничего не выйдет!

PostgreSQL Hardware Performance Tuning
by Bruce Momjian (англ.), 
мастер­класс на Highload­2007

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Мониторинг — главный друг DBA

Переход 8.2 → 8.3

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Мониторинг — главный друг DBA

Начинаем использовать 
pgBouncer (разные проекты)

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Мониторинг — главный друг DBA

БД «сидит» в RAM: 
наблюдаем только запись на диск

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Мониторинг — главный друг DBA

«Тревожный звонок»: 
уменьшение объёма кэша ОС
→ скачок LA

* FreeBSD node
http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Настройка: о чём помнить
Совет №1: не оставляйте настройки «по умолчанию»!

 shared_buffers

work_mem

max_connections

 effective_cache_size

рутинные задачи
VACUUM, FSM, сбор статистики, checkpoints

Все 187 параметров в 3-часовой экскурсии от
Джоша Беркуса (Josh Berkus)

Почитать на русском: коротко, подробнее


http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Настройка: о чём помнить
Совет №2: используйте PgBouncer

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Настройка: о чём помнить
Совет №3 (может быть «вредным»):

statement_timeout = 90s

Для «важных» транзакций и для задач обслуживания:

SET statement_timeout TO 0;
или
ALTER USER maintanance_user SET statement_timeout TO 0;

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Настройка: о чём помнить
Совет №3: следим за «здоровьем»
SELECT
SELECT
indexrelname,
datname,
idx_tup_read,
CASE
idx_tup_fetch,
WHEN blks_read = 0 THEN 0
(idx_tup_read - idx_tup_fetch),
ELSE blks_hit / blks_read
CASE WHEN idx_tup_read = 0 THEN 0 ELSE
END AS ratio
FROM (idx_tup_read::float4 -
pg_stat_database; idx_tup_fetch) / idx_tup_read END as r
FROM
pg_stat_user_indexes
... и т.д. ORDER BY r desc;

Настраиваем предупреждения в системе мониторинга 
и когда надо – реагируем
(перенастройка, чистка, пересоздание индексов и т.д.)
Фото: tika­online.de
http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Разработка
Схема БД, SQL-запросы, индексы, триггеры,
масштабирование, асинхронность

С чего начать? (Совет №0)

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Разработка
С чего начать?

Точно!
http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Разработка: анализ
1. Понимаем, что происходит «внутри»:

размеры БД, таблиц, индексов,

статистика использования (индексов, hit/read),

EXPLAIN ANALYZE;
2. PgFouine

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
PgFouine

выявляет самые медленные
[обобщённые] запросы:

см. вкладку Queries that took
up the most time (N),

показывает распределение
по часам,

если > 1h — нужна
оптимизация!

определяет, на что
потрачено время СУБД и когда;

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
PgFouine

показывает профиль нагрузки

у вас тоже 80-90% —чтение? ;-)

агрегирует и SQL-ошибки;

рисует TPS-графики

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
PgFouine

анализ VACUUM VERBOSE

FSM

статистика по базам/схемам, таблицам

Tsung: симуляция нагрузки

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
PgFouine
postgresql.conf:
log_min_duration_statement = 100ms

Важно: изменяем значение — меняется картина!

Начинаем с 1s,
постепенно спускаемся до 100ms

pgFouine— на PHP (sic!). Осторожно, «любит» RAM.


http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Разработка: о чём помнить
Совет №1: обязательно изучите все возможности
индексов в PostgreSQL

B-Tree, GiST, R-Tree, GIN;

Многоколоночные:

btree по 2 и более столбцам,

экзотика: btree_gist+rtree, rtree+
btree_gist+GiST(полнотекст.поиск) и т.п. в 1 (!) индексе

Функциональные:
CREATE INDEX idx ON t1 (substr(name, 6));

Частичные
CREATE INDEX ids ON t1 WHERE status=1;
http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Разработка: о чём помнить
Совет №2: избегайте заведомо медленных операций

OUTER (LEFT/RIGHT) JOIN

GROUP BY, DISTINCT, DISTINCT ON, UNION (без ALL)

... OFFSET 100000;

SELECT COUNT(1) FROM t1 WHERE ... AND ... AND ...;

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Разработка: о чём помнить
Совет №2: избегайте заведомо медленных операций.

Подробнее о списках (постраничный вывод информации):



Зло №1: медленный count() («всего найдено: 1000000
человек»):
— используем приближённые значения (парсим вывод
EXPLAIN SELECT ...);

Зло №2: большие значения OFFSET:
— меньше сортировок, больше фильтров (учимся у
GMail),
— возможно, ограничиваем максимальный номер
страницы.
http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
Разработка: о чём помнить
Совет №3: подумайте о масштабировании раньше


избегайте чрезмерно сложных SQL-запросов;

«Разделяй и властвуй»;

изучите решения для масштабирования:

Slony-I (масштабируем чтение),

SkyTools, PL/Proxy,

GridSQL.

Завтра: посетите доклады!



Аско Оя — о решениях Skype;

Гевин Рой — об опыте myYearbook.com.
http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf
30 минут — это очень мало.

вопросы?
а) прямо сейчас;
б) сегодня вечером в 19:00 на встрече PostgreSQL-сообщества;
в) в любое время. email: pgsql­ru­general@postgresql.org
xmpp: postgresmen@conference.jabber.org
web: http://postgresmen.ru

http://samokhvalov.com/files/20081006_highload2008_postgresql.pdf

Оценить