~20081006 Highload2008 Postgresql самохвалов

Производительность
PostgreSQL
Николай Самохвалов
http://postgresmen.ru

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

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

PostgreSQL
• хорошая поддержка: email: pgsqlrugeneral@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;


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

Фото: tikaonline.de

PostgreSQL
• масштабируемость:
• партицирование таблиц,
• M-S, M-M репликация,
• «шардинг», кластеризация
• PL/Proxy, GridSQL.



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

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


Настройка
Диски, RAID, ОС, ФС, postgresql.conf

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


Настройка
С чего начать?


Мониторинг, анализ
Все на анализы! (Без исключения)
●
Непрерывное слежение
●
Оповещение о проблемах

●
железо: contrib/pgbench, bonnie++
●
ОС, СУБД, web-сервер:
●
ZABBIX,
●
Cacti/Nagios, + расширения
●
Staplr by Gavin Roy
●
SQL-запросы: pgFouine;
●
pg_stat_*, reads/hits, phpPgAdmin
Где жмёт?

Работа с памятью
Если не понимаете этого –
ничего не выйдет!

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


Мониторинг — главный друг DBA

Переход 8.2 → 8.3



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



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



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

* FreeBSD node

Настройка: о чём помнить
Совет №1: не оставляйте настройки «по умолчанию»!
●
shared_buffers
●
work_mem
●
max_connections
●
effective_cache_size
●
рутинные задачи
VACUUM, FSM, сбор статистики, checkpoints
●
Все 187 параметров в 3-часовой экскурсии от
Джоша Беркуса (Josh Berkus)

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

Совет №2: используйте PgBouncer


Совет №3 (может быть «вредным»):

statement_timeout = 90s

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

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


Совет №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;

Настраиваем предупреждения в системе мониторинга
и когда надо – реагируем
(перенастройка, чистка, пересоздание индексов и т.д.)

Разработка
Схема БД, SQL-запросы, индексы, триггеры,
масштабирование, асинхронность

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


Разработка
С чего начать?

Точно!

Разработка: анализ
1. Понимаем, что происходит «внутри»:
●
размеры БД, таблиц, индексов,
●
статистика использования (индексов, hit/read),
●
EXPLAIN ANALYZE;
2. PgFouine


PgFouine
●
выявляет самые медленные
[обобщённые] запросы:
●
см. вкладку Queries that took
up the most time (N),
●
показывает распределение
по часам,
●
если > 1h — нужна
оптимизация!
●
определяет, на что
потрачено время СУБД и когда;


PgFouine
●
показывает профиль нагрузки
●
у вас тоже 80-90% —чтение? ;-)
●
агрегирует и SQL-ошибки;
●
рисует TPS-графики


PgFouine
●
анализ VACUUM VERBOSE
●
FSM
●
статистика по базам/схемам, таблицам
●
Tsung: симуляция нагрузки


PgFouine
postgresql.conf:
log_min_duration_statement = 100ms

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

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

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

Разработка: о чём помнить
Совет №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;

Совет №2: избегайте заведомо медленных операций
●
OUTER (LEFT/RIGHT) JOIN
●
GROUP BY, DISTINCT, DISTINCT ON, UNION (без ALL)
●
... OFFSET 100000;
●
SELECT COUNT(1) FROM t1 WHERE ... AND ... AND ...;


Совет №2: избегайте заведомо медленных операций.

Подробнее о списках (постраничный вывод информации):
●
Зло №1: медленный count() («всего найдено: 1000000
человек»):
— используем приближённые значения (парсим вывод
EXPLAIN SELECT ...);
●
Зло №2: большие значения OFFSET:
— меньше сортировок, больше фильтров (учимся у
GMail),
— возможно, ограничиваем максимальный номер
страницы.

Совет №3: подумайте о масштабировании раньше

●
избегайте чрезмерно сложных SQL-запросов;
●
«Разделяй и властвуй»;
●
изучите решения для масштабирования:
●
Slony-I (масштабируем чтение),
●
SkyTools, PL/Proxy,
●
GridSQL.

Завтра: посетите доклады!
●
Аско Оя — о решениях Skype;
●
Гевин Рой — об опыте myYearbook.com.

30 минут — это очень мало.

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


~20081006 Highload2008 Postgresql самохвалов

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Viewers also liked

Viewers also liked (20)

More from Ontico

More from Ontico (20)

~20081006 Highload2008 Postgresql самохвалов