title

text

Aleksander Pavlov
Aleksander Pavlov Modulbank
13:00 05 February
45 мин

How to break your DBMS with arised-from-nothing high loads?

As any ordinary software developers, we just pursued a goal to develop a system robust for high loads, and even succeeded. The system architecture was fine, but the data volume was keeping increased and revealed the painful issues and errors that nobody had expected. We faced very strange queries seemed to be unbelievable. In my short talk I would like to share sad experience of arised-from-nothing high loads in DBMS and solving the challenge.

Слайды

Видео

Другие доклады

  • Dmitry Yuhtimovsky
    Dmitry Yuhtimovsky Gilev.ru
    22 мин

    Magic tricks followed by exposure (1C+PG)

    Magic tricks followed by exposure (1C+PG):

    • Focus number one. How to convince the accounting department to buy a new server.
    • Focus number two. How to show that MS SQL is faster than PostgreSQL.
    • Focus number three. How to show that PostgreSQL is faster than MS SQL Server.

  • T
    Tatsuro Yamada NTT Comware
    22 мин

    Auto plan tuning using feedback loop

    As is often seen in OLAP and batch processing workloads, the more complex a query (containing many joins, filters, aggregates), the more there is a possibility of row count estimation errors, which leads to planner choosing an inefficient execution plan.

    To address that problem, I developed a tool called pg_plan_advsr as a PostgreSQL extension, which corrects the estimation errors by repeatedly feeding back the information collected during query execution to the planner.

    The tool has three features:

    1. Automatic plan tuning by repeatedly feeding execution information to planner
    2. Preserve all plans generated during plan tuning in a history table
    3. Create and store optimizer hints to be able to reproduce plans generated during tuning process

    I verified the effectiveness of pg_plan_advsr by enabling it when running the join order benchmark (JOB) against PG 10.4 and observed its execution time shortening to 50% of the original. Therefore, it is useful for user who would like to do plan tuning for OLAP and batch processing.

    I will talk about the following things in this presentation:

    • Principles behind pg_plan_advsr and its architecture
    • Detailed information about the measurements done with JOB
    • Possible future enhancements
    • Using aqo and pg_plan_advsr together (experimental)

  • Alex Lustin
    Alex Lustin SilverBulleters, LLC
    22 мин

    Analysis of troublesome queries as a means of recurrent refactoring of 1C code

    1. Principles of searching for troublesome queries in PostgreSQL.
    2. Evaluation of hypothetical indexes and their impact on query plans.
    3. The most common errors in 1C-programming.
    4. Basic methods of code refactoring, taking into account the features of PostgreSQL.
    5. Storing analytical information from the PostgreSQL log to assess the quality of refactoring

  • Алексей Лесовский
    Алексей Лесовский PostgreSQL Consulting LLC
    45 мин

    Troubleshooting in Postgres with pgCenter

    Sometimes problems arise during Postgres operation, and the faster they are identified and resolved, the happier users eventually will be. pgCenter is a set of CLI powerful utilities for troubleshooting in the "here and now" mode. In the talk I will show how to use pgCenter for efficient troubleshooting, the directions in which to search, and how to respond to certain problems, in particular how to:

    • check if Postgres is in the normal state;
    • identify promptly the faulty clients and stop them;
    • reveal too heavy queries;
    • and other tips and tricks of pgCenter.