Найти в Дзене
Закреплено автором
Postgres DBA
Статистический анализ производительности СУБД PostgreSQL
6 месяцев назад
Postgres DBA
PG_EXPECTO: стратегия развития и исследовательские векторы
2 дня назад
Postgres DBA
PG_EXPECTO: Чек-лист проверки инфраструктуры Linux по результатам нагрузочного тестирования PostgreSQL
1 неделю назад
PG_EXPECTO 5.2 : OLTP - влияние vm.dirty_ratio/vm.dirty_background_ratio на производительность СУБД PostgreSQL.
В условиях, когда производительность СУБД упирается в пропускную способность дисковой подсистемы, каждая настройка ОС, влияющая на ввод-вывод, становится критичной. В статье исследуется, может ли агрессивная политика сброса «грязных» страниц памяти (vm.dirty*) смягчить узкое место, или же она лишь усиливает конкуренцию за ресурсы. Глоссарий терминов | Postgres DBA | Дзен GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL Проанализировать влияние уменьшения значения vm...
14 часов назад
PG_EXPECTO 5.2 : OLAP - влияние vm.dirty_ratio/vm.dirty_background_ratio на производительность СУБД PostgreSQL.
Уменьшение параметров грязной памяти — интуитивно понятный шаг для снижения IO-нагрузки. Но что, если он лишь меняет "симптомы", не затрагивая корень проблемы? Итоги нагрузочного тестирования бросают вызов упрощенным подходам к тюнингу. В статье представлены результаты сравнительного анализа производительности СУБД PostgreSQL под OLAP-нагрузкой. Исследование фокусируется на оценке влияния ключевых параметров виртуальной памяти ядра Linux — vm.dirty_ratio и vm.dirty_background_ratio — на поведение системы, паттерны ожиданий и итоговую эффективность...
17 часов назад
postgresql.auto.conf # Do not edit this file manually! # It will be overwritten by the ALTER SYSTEM command. track_io_timing = 'on' listen_addresses = '0.0.0.0' logging_collector = 'on' log_directory = '/log/pg_log' log_destination = 'stderr' log_rotation_size = '0' log_rotation_age = '1d' log_filename = '2sdba-s-tpg12.postgresql-%u.log' log_line_prefix = '%m| %d| %a| %u| %h| %p| %e| ' log_truncate_on_rotation = 'on' log_checkpoints = 'on' archive_mode = 'on' archive_command = 'true' archive_timeout = '30min' checkpoint_warning = '60' checkpoint_completion_target = '0.9' min_wal_size = '2GB' synchronous_commit = 'on' wal_compression = 'on' random_page_cost = '1.1' effective_io_concurrency = '300' wal_sender_timeout = '0' autovacuum_naptime = '1s' autovacuum_vacuum_scale_factor = '0.01' autovacuum_analyze_scale_factor = '0.005' autovacuum_vacuum_cost_delay = '2ms' autovacuum_max_workers = '4' autovacuum_work_mem = '256MB' vacuum_cost_limit = '4000' bgwriter_delay = '10ms' bgwriter_lru_multiplier = '4' bgwriter_lru_maxpages = '400' max_locks_per_transaction = '256' max_pred_locks_per_transaction = '256' temp_buffers = '14MB' idle_in_transaction_session_timeout = '1h' statement_timeout = '8h' pg_stat_statements.track_utility = 'off' max_parallel_maintenance_workers = '4' hash_mem_multiplier = '2' autovacuum_vacuum_insert_scale_factor = '0.01' shared_preload_libraries = 'pg_stat_statements , pg_wait_sampling' commit_delay = '1000' log_autovacuum_min_duration = '0' wipe_file_on_delete = 'on' wipe_heaptuple_on_delete = 'on' wipe_mem_on_free = 'on' wipe_memctx_on_free = 'on' wipe_xlog_on_free = 'on' log_connections = 'on' log_disconnections = 'on' pg_stat_statements.track = 'all' max_connections = '1000' max_parallel_workers_per_gather = '1' max_parallel_workers = '16' max_worker_processes = '16' effective_cache_size = '6GB' work_mem = '32MB' maintenance_work_mem = '512MB' max_wal_size = '32GB' checkpoint_timeout = '5min' shared_buffers = '4GB'
23 часа назад
Сравнительный анализ паттернов производительности PostgreSQL: OLAP vs OLTP под нагрузкой с использованием PG_EXPECTO.
Статья представляет собой глубокий сравнительный анализ паттернов производительности PostgreSQL 17 для двух принципиально разных типов нагрузки — аналитической (OLAP) и транзакционной (OLTP). Исследование проведено с помощью специализированного комплекса pg_expecto, предназначенного для статистического анализа и нагрузочного тестирования. Этот инструмент позволил не только имитировать сценарии, но и выявить тонкие корреляции между внутренними ожиданиями СУБД (DataFileRead, LWLock) и системными метриками (vmstat, iostat)...
1 день назад
-- OLTP -- scenario1.sql -- 5.2 CREATE OR REPLACE FUNCTION scenario1() RETURNS integer AS $$ DECLARE  test_rec record ;  current_aid bigint ; BEGIN -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -- ТОЛЬКО ДЛЯ scale = 685 -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! current_aid = floor(random() * (68500000 - 1 + 1)) + 1 ; select acc.abalance into test_rec from pgbench_accounts acc where acc.aid = current_aid ; return 0 ; END $$ LANGUAGE plpgsql;
1 день назад
PG_EXPECTO 5.2 : Иммитация OLAP нагрузки
Данный отчет представляет результаты комплексного анализа производительности СУБД PostgreSQL под нагрузкой, имитирующей OLAP. Глоссарий терминов | Postgres DBA | Дзен GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL Протестировать сценарий нагрузочного тестирования для имитации типа нагрузки "OLAP" scenario1 = 0.7 scenario2 = 0.2 scenario3 = 0.1 Проанализируй данные по метрикам производительности и ожиданий СУБД , метрикам инфраструктуры vmstat/iostat...
1 день назад
-- scenario3.sql -- UPDATE -- 5.2 CREATE OR REPLACE FUNCTION scenario3() RETURNS integer AS $$ DECLARE  current_aid bigint ;  current_delta bigint ; BEGIN -- Генерация случайного сдвига   current_delta := (ROUND(RANDOM())::BIGINT) * 10 + 1; -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -- ТОЛЬКО ДЛЯ scale = 685 -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!   -- Атомарный выбор и блокировка одной строки с пропуском заблокированных   -- FOR UPDATE SKIP LOCKED для выбора одной доступной строки current_aid = floor(random() * (68500000 - 1 + 1)) + 1 ;   SELECT aid INTO current_aid   FROM pgbench_accounts   WHERE aid = current_aid   FOR UPDATE SKIP LOCKED;   -- Если строка найдена — обновляем её   IF current_aid IS NOT NULL THEN    UPDATE pgbench_accounts    SET abalance = abalance + current_delta    WHERE aid = current_aid;   END IF;  return 0 ; END $$ LANGUAGE plpgsql;
1 день назад
-- scenario2.sql -- INSERT -- 5.2 CREATE OR REPLACE FUNCTION scenario2() RETURNS integer AS $$ BEGIN --------------------------------------------------- --СЦЕНАРИЙ 3 - INSERT ONLY -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -- ТОЛЬКО ДЛЯ scale = 685 -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! INSERT INTO pgbench_history ( tid, bid, aid, delta, mtime ) VALUES ( floor(random() * (6850 - 1 + 1)) + 1 , floor(random() * (685 - 1 + 1)) + 1 , floor(random() * (68500000 - 1 + 1)) + 1 , random() * 1000.0 , CURRENT_TIMESTAMP ) ON CONFLICT DO NOTHING ; --ССЦЕНАРИЙ 3 - INSERT ONLY ---------------------------------------------------  return 0 ; END $$ LANGUAGE plpgsql;
1 день назад
--OLAP -- scenario1.sql -- 5.2 CREATE OR REPLACE FUNCTION scenario1() RETURNS integer AS $$ DECLARE  test_rec record ; BEGIN WITH branch_summary AS (   SELECT    b.bid,    COUNT(a.aid) as account_count,    SUM(a.abalance) as total_balance,    AVG(a.abalance) as avg_balance   FROM pgbench_branches b   LEFT JOIN pgbench_accounts a ON b.bid = a.bid   GROUP BY b.bid ), transaction_summary AS (   SELECT    h.bid,    COUNT(*) as transaction_count,    SUM(h.delta) as net_flow,    COUNT(DISTINCT h.aid) as active_accounts,    MIN(h.mtime) as first_transaction,    MAX(h.mtime) as last_transaction   FROM pgbench_history h   WHERE h.mtime > CURRENT_TIMESTAMP - INTERVAL '7 days'   GROUP BY h.bid ) SELECT   bs.bid,   bs.account_count,   bs.total_balance,   bs.avg_balance,   COALESCE(ts.transaction_count, 0) as transaction_count,   COALESCE(ts.net_flow, 0) as net_flow,   COALESCE(ts.active_accounts, 0) as active_accounts,   EXTRACT(DAY FROM ts.last_transaction - ts.first_transaction) as activity_days,   CASE    WHEN ts.transaction_count > 0    THEN bs.total_balance / ts.transaction_count    ELSE 0   END as balance_per_transaction INTO test_rec FROM branch_summary bs LEFT JOIN transaction_summary ts ON bs.bid = ts.bid WHERE bs.total_balance > 0 ORDER BY bs.total_balance DESC LIMIT 100; return 0 ; END $$ LANGUAGE plpgsql;
1 день назад
Эмпирические ориентиры для соотношения (shared_blks_hit + shared_blks_read) / shared_blks_dirtied
Характеристика: интенсивные короткие транзакции с высокой конкуренцией за данные Паттерн: каждая транзакция читает немного данных (обычно по индексам) и часто изменяет записи Характеристика: сочетание оперативных транзакций и аналитических запросов Паттерн: чтений значительно больше, чем записей, но запись происходит регулярно Характеристика: доминирование сложных аналитических запросов Паттерн: массовое сканирование больших объёмов данных с редкой пакетной записью Характеристика: полное отсутствие...
1 день назад
PG_EXPECTO: стратегия развития и исследовательские векторы
В документе представлен план развития инструмента PG_EXPECTO для анализа производительности PostgreSQL, а также перечень исследовательских тем в области статистического анализа СУБД. Особое внимание уделено оценке трудоёмкости реализации каждого направления Глоссарий терминов | Postgres DBA | Дзен GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL PG_EXPECTO — это открытый комплекс для глубокого статистического анализа и нагрузочного...
2 дня назад
Забудьте о "стандартной" конфигурации. Реальная производительность PostgreSQL рождается в недрах ОС.
Когда PostgreSQL замедляется, первая мысль — апгрейд сервера. Однако реальный эксперимент показал, что прирост в 65% можно получить, просто правильно настроив Linux. Глоссарий терминов | Postgres DBA | Дзен GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL 📃Статья «Не апгрейд, а оптимизация» наглядно демонстрирует, что путь к максимальной производительности СУБД PostgreSQL лежит не только через тонкую настройку её внутренних механизмов, но и через оптимизацию операционной системы, на которой она работает...
3 дня назад