Рубрика «postgresql» - 20

Тюнинг производительности запросов в PostgreSQL - 1 Настройка производительности базы данных — разработчики обычно либо любят это, либо ненавидят. Я получаю удовольствие от этого и хочу поделиться некоторыми методами, которые я использовал в последнее время для настройки плохо выполняющихся запросов в PostgreSQL. Мои методы не является исчерпывающими, скорее учебником для тех, кто просто тащится от тюнинга.

Поиск медленных запросов

Первый очевидный способ начать тюнинг — это найти конкретные операторы, которые работают плохо.

pg_stats_statements

Модуль pg_stats_statements — отличное место для начала. Он просто отслеживает статистику выполнения операторов SQL и может быть простым способом поиска неэффективных запросов.

Как только вы установили этот модуль, системное представление с именем pg_stat_statements будет доступно со всеми своими свойствами. Как только у него будет возможность собрать достаточный объем данных, ищите запросы, которые имеют относительно высокое значение total_time. Сначала сфокусируйтесь на этих операторах.

SELECT *
FROM
  pg_stat_statements
ORDER BY
  total_time DESC;

user_id dbid queryid query calls total_time
16384 16385 2948 SELECT address_1 FROM addresses a INNER JOIN people p ON a.person_id = p.id WHERE a.state = @state_abbrev; 39483 15224.670
16384 16385 924 SELECT person_id FROM people WHERE name = name; 26483 12225.670
16384 16385 395 SELECT _ FROM orders WHERE EXISTS (select _ from products where is_featured = true) 18583 224.67

Читать полностью »

Три года автотестов: как повысить скорость и не только - 1

Привет, я Алексей, full-stack разработчик платформы Vimbox. Когда я пришел в Skyeng, здесь решали, стоит ли тратить время на систему автотестов и попросили меня поделиться опытом с предыдущей работы. А такой опыт у меня был: к моменту ухода с предыдущего места мы написали на php и крутили больше 3 тысяч тестов. В итоге я сделал небольшую внутреннюю презентацию, рассказывающую о граблях, на которые успел наступить за несколько лет разработки этих автотестов, борьбы за их скорость, читабельность кода и общую эффективность. Презентация показалась коллегам полезной, поэтому я переложил ее в текст, чтобы оказаться полезным также и более широкой аудитории.

Для начала – термины, о которых пойдет речь в статье:

  • Приемочный тест – end-to-end тест: здесь браузер или эмулятор браузера исполняет сценарий
  • Модульный тест (юнит тест) – тест метода
  • Функциональный тест – тест контроллера или компонента, если речь о фронтенде
  • Фикстура – состояние тестового окружения, необходимое для работы теста (глобальные переменные, данные в БД и прочие участники сценария теста)

Читать полностью »

Привет! Рассказываем о том, что мы сделали в DataGrip за четыре месяца. Если вы используете поддержку баз данных в других наших IDE, этот пост для вас тоже.

DataGrip 2019.2: Управление соединениями, поиск по данным, фильтрация в навигации - 1
Читать полностью »

Итак, мы познакомились с устройством буферного кеша и на его примере поняли, что когда при сбое пропадает содержимое оперативной памяти, для восстановления необходим журнал предзаписи. Размер необходимых файлов журнала и время восстановления ограничены благодаря периодически выполняемой контрольной точке.

В предыдущих статьях мы уже посмотрели на довольно большое число важных настроек, так или иначе относящихся к журналу. В этой статье (последней в этом цикле) мы рассмотрим те вопросы настройки, которые еще не обсуждались: уровни журнала и их назначение, а также надежность и производительность журналирования.

Уровни журнала

Основная задача журнала предзаписи — обеспечить возможность восстановления после сбоя. Но, если уж все равно приходится вести журнал, его можно приспособить и для других задач, добавив в него некоторое количество дополнительной информации. Есть несколько уровней журналирования. Они задаются параметром wal_level и организованы так, что журнал каждого следующего уровня включает в себя все, что попадает в журнал предыдущего уровня, плюс еще что-то новое.
Читать полностью »

Мы уже познакомились с устройством буферного кеша — одного из основных объектов в разделяемой памяти, — и поняли, что для восстановления после сбоя, когда содержимое оперативной памяти пропадает, нужно вести журнал предзаписи.

Нерешенная проблема, на которой мы остановились в прошлый раз, состоит в том, что неизвестно, с какого момента можно начинать проигрывание журнальных записей при восстановлении. Начать с начала, как советовал Король из Алисы, не получится: невозможно хранить все журнальные записи от старта сервера — это потенциально и огромный объем, и такое же огромное время восстановления. Нам нужна такая постепенно продвигающаяся вперед точка, с которой мы можем начинать восстановление (и, соответственно, можем безопасно удалять все предшествующие журнальные записи). Это и есть контрольная точка, о которой сегодня пойдет речь.

Контрольная точка

Каким свойством должна обладать контрольная точка? Мы должны быть уверены, что все журнальные записи, начиная с контрольной точки, будут применяться к страницам, записанным на диск. Если бы это было не так, при восстановлении мы могли бы прочитать с диска слишком старую версию страницы и применить к ней журнальную запись, и тем самым безвозвратно повредили бы данные.
Читать полностью »

Здравствуйте, в эфире опять Радио SQL! Сегодня у нас решение задачи, которую мы передавали в нашем предыдущем эфире, и обещали разобрать в следующий раз. И вот этот следующий раз наступил.

Задача вызвала живой отклик у гуманоидов галактики Млечный путь (и неудивительно, с их-то трудовым рабством, которое они до сих пор почитают за благо цивилизации). К сожалению, на третьей планете отложили запуск космической обсерватории «Спектр-РГ» в конце июля 2019 года РХ (летоисчисление местное), с помощью которого планировалось транслировать эту передачу. Пришлось искать альтернативные пути передачи, что привело к небольшому опозданию сигнала. Но всё хорошо, что хорошо кончается.

SQL: решение задачи о рабочем времени - 1

Сразу скажу, что в разборе задачи не будет никакой магии, не надо искать тут откровений или ждать какой-то особо эффективной (или особо какой-нибудь в любом другом смысле) реализации. Это просто разбор задачи. В нём те, кто не знает, как подступаться к решению таких задач, смогут посмотреть, как же их решать. Тем более, что ничего страшного тут нет.

Читать полностью »

Главные вопросы работы с базой данных связаны с особенностями устройства операционной системы, на которой работает база. Сейчас Linux — основная операционная система для баз данных. Solaris, Microsoft и даже HPUX все еще применяются в энтерпрайзе, но первое место им больше никогда не занять, даже вместе взятым. Linux уверенно завоевывает позиции, потому что open source баз данных все больше. Поэтому вопрос взаимодействия БД с ОС, очевидно, о базах данных в Linux. На это накладывается вечная проблема БД — производительность IO. Хорошо, что в Linux последние годы идет капитальный ремонт IO-стека и есть надежда на просветление.

Илья Космодемьянский (hydrobiont) работает в компании Data Egret, которая занимается консалтингом и поддержкой PostgreSQL, и про взаимодействие ОС и баз данных знает многое. В докладе на HighLoad++ Илья рассказал о взаимодействии IO и БД на примере PostgreSQL, но и показал, как с IO работают другие БД. Рассмотрел стек Linux IO, что нового и хорошего в нем появилось и почему все не так, как было пару лет назад. В качестве полезной памятки — контрольный список настроек PostgreSQL и Linux для максимальной производительности подсистемы IO в новых ядрах.
Читать полностью »

GitLab: С выходом версии 12.1 мы прекращаем поддержку MySQL - 1

Сейчас мы расскажем, почему, начиная с версии 12.1, GitLab перестанет поддерживать MySQL.

В июле 2017 GitLab предупредил, что прекратит поддержку MySQL. Так вот, с выпуском 12.1 период подготовки к этому завершится, и больше мы MySQL поддерживать не будем. Решение непростое, и мы хотели бы поделиться доводами.

Читать полностью »

Настройка параметров PostgreSQL для оптимизации производительности - 1 По умолчанию конфигурация PostgreSQL не настроена для рабочей нагрузки. Значения по умолчанию установлены для обеспечения работоспособности PostgreSQL везде с наименьшим количеством ресурсов. Имеются настройки по умолчанию для всех параметров базы данных. Главной обязанностью администратора базы данных или разработчика является настройка PostgreSQL в соответствии с нагрузкой их системы. В этом блоге мы изложим основные рекомендации по настройке параметров базы данных PostgreSQL для повышения производительности базы данных в соответствии с рабочей нагрузкой.

Имейте в виду, что, хотя оптимизация конфигурации сервера PostgreSQL повышает производительность, разработчик базы данных также должен быть внимательным при написании запросов. Если запросы выполняют полное сканирование таблицы, где можно использовать индекс, или выполнют тяжелые объединения или дорогостоящие операции агрегирования, тогда система все равно может работать плохо, даже если параметры базы данных настроены корректно. При написании запросов к базе данных важно обращать внимание на производительность.

Тем не менее, параметры базы данных тоже очень важны, поэтому давайте посмотрим на восемь, которые имеют наибольший потенциал для повышения производительности

Читать полностью »

Для приготовления преобразования из HTML в PDF нам понадобится сам postgres и его расширение pg_html2pdf. (Я дал ссылки на свой форк postgres, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальный репозиторий. Можно также воспользоваться готовым образом.)
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js