Практика к главе 1

Часть 1. Стандартный тест pgbench

Образ виртуальной машины к курсу: https://disk.yandex.ru/d/APErrktFq-Gamg

1) При выполнении практик будет много раз перезапускаться экземпляр. Создайте файл с коротким именем для того, чтобы удобно перезапускать экземпляр:

astra@tantor:~$ su -

Password: root

root@tantor:~# echo "systemctl restart tantor-se-server-16" > /usr/local/bin/restart

root@tantor:~#  chmod 755 /usr/local/bin/restart

root@tantor:~# <ctrl+d>

logout

astra@tantor:~$ sudo restart 

astra@tantor:~$

Вы создали командный файл и перезапустили с его помощью экземпляр.

2) Переключитесь в пользователя операционной системы postgres:

astra@tantor:~$ su - postgres

Password: postgres

postgres@tantor:~$

3) Утилита pgbench поставляется с постгрес и использует таблицы для встроенных тестов.

Создайте таблицы для тестов pgbench:

postgres@tantor:~$ pgbench -i

dropping old tables...

NOTICE:  table "pgbench_accounts" does not exist, skipping

NOTICE:  table "pgbench_branches" does not exist, skipping

NOTICE:  table "pgbench_history" does not exist, skipping

NOTICE:  table "pgbench_tellers" does not exist, skipping

creating tables...

generating data (client-side)...

100000 of 100000 tuples (100%) done (elapsed 0.10 s, remaining 0.00 s)

vacuuming...

creating primary keys...

done in 0.43 s (drop tables 0.00 s, create tables 0.02 s, client-side generate 0.28 s, vacuum 0.07 s, primary keys 0.07 s).

Было создано четыре таблицы. В таблице pgbench_accounts 100тыс. строк, в остальных  таблицах 1, 0 и 10 строк.

4) Запустите тест по умолчанию длительностью 30 секунд с выводом промежуточных результатов с интервалом в 5 секунд:

postgres@tantor:~$ pgbench -T 30 -P 5

starting vacuum...end.

progress: 5.0 s, 547.2 tps, lat 1.818 ms stddev 0.475, 0 failed

progress: 10.0 s, 551.6 tps, lat 1.805 ms stddev 0.230, 0 failed

progress: 15.0 s, 545.8 tps, lat 1.824 ms stddev 0.255, 0 failed

progress: 20.0 s, 554.2 tps, lat 1.797 ms stddev 0.204, 0 failed

progress: 25.0 s, 532.6 tps, lat 1.870 ms stddev 0.298, 0 failed

progress: 30.0 s, 502.6 tps, lat 1.982 ms stddev 2.024, 0 failed

transaction type: <builtin: TPC-B (sort of)>

scaling factor: 1

query mode: simple

number of clients: 1

number of threads: 1

maximum number of tries: 1

duration: 30 s

number of transactions actually processed: 16171

number of failed transactions: 0 (0.000%)

latency average = 1.847 ms

latency stddev = 0.849 ms

initial connection time = 3.973 ms

tps = 539.088500 (without initial connection time)

В примере получен результат: 539 транзакций в секунду (transactions per second, tps)

5) Проверьте, как влияет удержание горизонта базы данных на TPS стандартного теста.  Запустите тест, указав большой интервал времени:

postgres@tantor:~$ pgbench -T 10000 -P 15

6) Запустите второй терминал. В терминале запустите psl и начните транзакцию:

astra@tantor:~$ psql

postgres=# begin;

BEGIN

postgres=*#

7) В окне с запущенным тестом обратите внимание на показатель tps:

progress: 15.0 s, 541.5 tps, lat 1.838 ms stddev 0.242, 0 failed

progress: 30.0 s, 554.7 tps, lat 1.795 ms stddev 0.255, 0 failed

progress: 45.0 s, 545.9 tps, lat 1.824 ms stddev 0.279, 0 failed

8)  Откройте транзакцию вызвав функцию, выдающую номер транзакции:

postgres=*# select pg_current_xact_id();

 pg_current_xact_id

--------------------

             974640

(1 row)

postgres=*#

9) Проверьте, что в окне с тестом tps постепенно начнет снижаться:

progress: 60.0 s, 484.6 tps, lat 2.055 ms stddev 0.603, 0 failed

progress: 75.0 s, 395.7 tps, lat 2.517 ms stddev 0.751, 0 failed

progress: 90.0 s, 349.1 tps, lat 2.853 ms stddev 0.793, 0 failed

progress: 105.0 s, 319.5 tps, lat 3.118 ms stddev 0.912, 0 failed

progress: 120.0 s, 308.1 tps, lat 3.237 ms stddev 0.942, 0 failed

progress: 135.0 s, 339.8 tps, lat 2.935 ms stddev 0.507, 0 failed

progress: 150.0 s, 306.3 tps, lat 3.257 ms stddev 0.478, 0 failed

progress: 165.0 s, 277.6 tps, lat 3.595 ms stddev 0.706, 0 failed

progress: 180.0 s, 264.2 tps, lat 3.777 ms stddev 0.673, 0 failed

За три минуты tps снизится в 1.5-2 раза. За час tps снизится в 100 раз. Мы не будем ждать час, часовой тест можно запустить в обеденное время.

10) Выполните запрос, показывающий PID активных процессов и длительность их транзакций:

select age(backend_xmin), extract(epoch from (clock_timestamp()-xact_start)) secs, pid, datname database, state from pg_stat_activity where backend_xmin IS NOT NULL OR backend_xid IS NOT NULL order by greatest(age(backend_xmin), age(backend_xid)) desc;

  age   |    secs     |  pid   | database |        state        

--------+-------------+--------+----------+---------------------

 175455 | 1425.651346 | 255554 | postgres | idle in transaction

      1 |    0.001878 | 255547 | postgres | active

      1 |    0.001213 | 255626 | postgres | active

Это запрос, который позволяет наблюдать за горизонтом баз данных. Запрос выдаёт число транзакций, прошедших с момента запуска транзакции серверным процессом, к которому относится строка; длительность транзакции, в первой строке самая долгая транзакция и время удержания горизонта; pid процесса, название базы данных, в которой работает транзакция; состояние транзакции. Если состояние транзакции "idle in transaction" это означает, что транзакция простаивает и ждёт команды от клиента. Простаивающая открытая транзакция нежелательна и таких транзакций в хорошо написанном приложении не должно быть.

В примере прошло 1425 секунд и за это время время tps в окне с тестом снизился в 7 раз:

progress: 1425.0 s, 71.6 tps, lat 13.964 ms stddev 1.215, 0 failed

11) Завершите транзакцию, удерживающую горизонт во втором окне терминала:

postgres=*# rollback;

ROLLBACK

postgres=#

12) повторите запрос в третьем окне терминала:

postgres=# select age(backend_xmin), extract(epoch from (clock_timestamp()-xact_start)) secs, pid, datname database, state from pg_stat_activity where backend_xmin IS NOT NULL OR backend_xid IS NOT NULL order by greatest(age(backend_xmin), age(backend_xid)) desc;

 age |   secs   |  pid   | database | state  

-----+----------+--------+----------+--------

   1 | 0.001050 | 255547 | postgres | active

   1 | 0.001280 | 255626 | postgres | active

Две транзакции это транзакции теста pgbench. Их "возраст" в числе транзакций 1. Они не удерживают горизонт.

13) Посмотрите в первом окне терминала с тестом, что tps достаточно быстро вернутся к исходным:

progress: 1905.0 s, 61.3 tps, lat 16.302 ms stddev 1.201, 0 failed

progress: 1920.0 s, 60.4 tps, lat 16.549 ms stddev 1.762, 0 failed

progress: 1935.0 s, 159.5 tps, lat 6.266 ms stddev 6.035, 0 failed

progress: 1950.0 s, 389.1 tps, lat 2.561 ms stddev 0.586, 0 failed

progress: 1965.0 s, 535.5 tps, lat 1.860 ms stddev 0.347, 0 failed

progress: 1980.0 s, 522.1 tps, lat 1.908 ms stddev 0.327, 0 failed

Вы наблюдали, что удержание горизонта в базе данных существенно снижает число транзакций, которые может обслужить СУБД. Одиночный запрос удерживает горизонт на время своей работы. Долгие запросы стоит переносить на реплики.

На уровне изоляции транзакций по умолчанию (READ COMMITED) транзакция начинает удерживать горизонт, как только ей будет назначен реальный номер транзакции (xid). Для получения реального номера использовалась функция pg_current_xact_id(). Реальный номер будет назначен при выполнении любой команды, меняющей данные. Например: INSERT, UPDATE, DELETE, CREATE, ALTER, DROP. Транзакции на уровне изоляции repeatable read удерживают горизонт с момента выполнения любой команды, в том числе SELECT и удерживают горизонт до завершения транзакции:

postgres=# begin transaction isolation level repeatable read;

BEGIN

postgres=*# select 1;

?column?

----------

        1

(1 row)

Часть 2. Использование pgbench с собственным скриптом

1) Создайте таблицу для теста выполнив команды в psql:

postgres=# drop table if exists t;

create table t(pk bigserial, c1 text default 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');

insert into t select *, 'a' from generate_series(1, 100000);

alter table t add constraint pk primary key (pk);

DROP TABLE

CREATE TABLE

INSERT 0 100000

ALTER TABLE

2) Создайте три скрипта (командных файла):

postgres=# \q

postgres@tantor:~$ echo "select count(*) from t;" > count1.sql

echo "select count(1) from t;" > count2.sql

echo "select count(pk) from t;" > count3.sql

postgres@tantor:~$

3) Запустите по очереди три теста с созданными скриптами:

postgres@tantor:~$ pgbench -T 30 -P 5 -f count1.sql

pgbench (16.2)

starting vacuum...end.

progress: 5.0 s, 75.8 tps, lat 13.144 ms stddev 1.410, 0 failed

progress: 10.0 s, 74.2 tps, lat 13.495 ms stddev 1.454, 0 failed

progress: 15.0 s, 75.0 tps, lat 13.304 ms stddev 1.047, 0 failed

progress: 20.0 s, 75.2 tps, lat 13.313 ms stddev 1.267, 0 failed

progress: 25.0 s, 75.6 tps, lat 13.205 ms stddev 1.030, 0 failed

progress: 30.0 s, 76.2 tps, lat 13.125 ms stddev 0.896, 0 failed

transaction type: count1.sql

scaling factor: 1

query mode: simple

number of clients: 1

number of threads: 1

maximum number of tries: 1

duration: 30 s

number of transactions actually processed: 2261

number of failed transactions: 0 (0.000%)

latency average = 13.263 ms

latency stddev = 1.207 ms

initial connection time = 3.788 ms

tps = 75.339419 (without initial connection time)

postgres@tantor:~$ pgbench -T 30 -P 5 -f count2.sql

pgbench (16.2)

starting vacuum...end.

progress: 5.0 s, 69.4 tps, lat 14.386 ms stddev 0.891, 0 failed

progress: 10.0 s, 67.8 tps, lat 14.707 ms stddev 1.009, 0 failed

progress: 15.0 s, 68.4 tps, lat 14.633 ms stddev 1.208, 0 failed

progress: 20.0 s, 68.4 tps, lat 14.615 ms stddev 0.909, 0 failed

progress: 25.0 s, 68.4 tps, lat 14.596 ms stddev 1.010, 0 failed

progress: 30.0 s, 67.0 tps, lat 14.940 ms stddev 0.720, 0 failed

transaction type: count2.sql

scaling factor: 1

query mode: simple

number of clients: 1

number of threads: 1

maximum number of tries: 1

duration: 30 s

number of transactions actually processed: 2048

number of failed transactions: 0 (0.000%)

latency average = 14.645 ms

latency stddev = 0.983 ms

initial connection time = 4.314 ms

tps = 68.242454 (without initial connection time)

postgres@tantor:~$ pgbench -T 30 -P 5 -f count3.sql

pgbench (16.2)

starting vacuum...end.

progress: 5.0 s, 56.2 tps, lat 17.758 ms stddev 0.983, 0 failed

progress: 10.0 s, 55.2 tps, lat 18.095 ms stddev 0.698, 0 failed

progress: 15.0 s, 55.6 tps, lat 17.968 ms stddev 0.768, 0 failed

progress: 20.0 s, 55.4 tps, lat 18.016 ms stddev 0.765, 0 failed

progress: 25.0 s, 55.8 tps, lat 17.954 ms stddev 0.930, 0 failed

progress: 30.0 s, 55.0 tps, lat 18.125 ms stddev 1.161, 0 failed

transaction type: count3.sql

scaling factor: 1

query mode: simple

number of clients: 1

number of threads: 1

maximum number of tries: 1

duration: 30 s

number of transactions actually processed: 1667

number of failed transactions: 0 (0.000%)

latency average = 17.985 ms

latency stddev = 0.906 ms

initial connection time = 4.129 ms

tps = 55.572129 (without initial connection time)

postgres@tantor:~$

4) Проанализируйте результат теста: определите какая команда работает быстрее

5) Выполните команды в psql:

postgres=# \timing 

Timing is on.

postgres=# select count(pk) from t;

 count  

--------

 100000

(1 row)

Time: 18.249 ms

postgres=# select count(1) from t;

 count  

--------

 100000

(1 row)

Time: 15.223 ms

postgres=# select count(*) from t;

 count  

--------

 100000

(1 row)

Time: 14.535 ms

Соответствует ли время выполнения команд результатам pgbench? Да, соответствует.

Соответствует ли время выполнения команд значению latency? Да, соответствует.

latency average измерено тестом pgbench с точностью, соответствующей latency stddev.

6) отключите измерение времени:

postgres=# \timing

Timing is off.

7) Выполните команды:

postgres=# explain analyze select count(pk) from t;

                                                   QUERY PLAN

---------------------------------------------------------------------------------------------

 Aggregate  (cost=1791.00..1791.01 rows=1 width=8) (actual time=817.468..817.485 rows=1 loops=1)

   ->  Seq Scan on t  (cost=0.00..1541.00 rows=100000 width=8) (actual time=0.013..403.349 rows=100000 loops=>

 Planning Time: 0.047 ms

 Execution Time: 817.602 ms

(4 rows)

postgres=# explain analyze select count(1) from t;

                                                   QUERY PLAN

---------------------------------------------------------------------------------------------

 Aggregate  (cost=1791.00..1791.01 rows=1 width=8) (actual time=800.453..800.470 rows=1 loops=1)

   ->  Seq Scan on t  (cost=0.00..1541.00 rows=100000 width=0) (actual time=0.015..399.821 rows=100000 loops=>

 Planning Time: 0.053 ms

 Execution Time: 800.589 ms

(4 rows)

postgres=# explain analyze select count(*) from t;

                                                   QUERY PLAN

---------------------------------------------------------------------------------------------

 Aggregate  (cost=1791.00..1791.01 rows=1 width=8) (actual time=804.634..804.650 rows=1 loops=1)

   ->  Seq Scan on t  (cost=0.00..1541.00 rows=100000 width=0) (actual time=0.013..401.192 rows=100000 loops=>

 Planning Time: 0.047 ms

 Execution Time: 804.767 ms

(4 rows)

postgres=# explain analyze select count(*) from t;

                                                   QUERY PLAN

--------------------------------------------------------------------------------------------

 Aggregate  (cost=1791.00..1791.01 rows=1 width=8) (actual time=813.472..813.489 rows=1 loops=1)

   ->  Seq Scan on t  (cost=0.00..1541.00 rows=100000 width=0) (actual time=0.015..410.861 rows=100000 loops=>

 Planning Time: 0.054 ms

 Execution Time: 813.610 ms

(4 rows)

Соответствует ли время выполнения команд explain analyze времени выполнения команд без explain analyze? Нет, не соответствует. Время выполнения команд ~15ms, время выполнения команд с explain analyze в этом примере ~800ms или меньше ~300ms (зависит от типа источника времени).

explain analyze с опциями по умолчанию показало время выполнения count(*) дольше, чем count(1), что расходится с предыдущими тестами. Накладные расходы на замеры времени существенно превышают время выполнения команд.

Два последних результата одной и той же команды 804.767 ms и 813.610 ms различаются из-за задержек в доступе к буферам в буферном кэше 401.192 и 410.861.

Время выполнения узла Aggregate также расходится с результатами pgbench и выполнения команд без explain analyze:

817.485-403.349=414.136

800.470-399.821=400.649

804.650-401.192=403.458

813.489-410.861=402.628

Расхождение результатов в том, что count(*) медленнее, чем count(1).

8) Выполните команды, отключив в команде explain измерение времени:

postgres=# explain (analyze, buffers, timing off) select count(pk) from t;

                                         QUERY PLAN

------------------------------------------------------------------------

 Aggregate  (cost=1791.00..1791.01 rows=1 width=8) (actual rows=1 loops=1)

   Buffers: shared hit=541

   ->  Seq Scan on t  (cost=0.00..1541.00 rows=100000 width=8) (actual rows=100000 loops=1)

         Buffers: shared hit=541

 Planning:

   Buffers: shared hit=65

 Planning Time: 0.431 ms

 Execution Time: 21.388 ms

(8 rows)

postgres=# explain (analyze, buffers, timing off) select count(1) from t;

                                         QUERY PLAN

---------------------------------------------------------------------------

 Aggregate  (cost=1791.00..1791.01 rows=1 width=8) (actual rows=1 loops=1)

   Buffers: shared hit=541

   ->  Seq Scan on t  (cost=0.00..1541.00 rows=100000 width=0) (actual rows=100000 loops=1)

         Buffers: shared hit=541

 Planning Time: 0.059 ms

 Execution Time: 18.952 ms

(6 rows)

postgres=# explain (analyze, buffers, timing off) select count(*) from t;

                                         QUERY PLAN        

-------------------------------------------------------------------------

 Aggregate  (cost=1791.00..1791.01 rows=1 width=8) (actual rows=1 loops=1)

   Buffers: shared hit=541

   ->  Seq Scan on t  (cost=0.00..1541.00 rows=100000 width=0) (actual rows=100000 loops=1)

         Buffers: shared hit=541

 Planning:

   Buffers: shared hit=3

 Planning Time: 0.058 ms

 Execution Time: 16.357 ms

(8 rows)

С опцией timing off результаты команды explain соответствуют результатам тестов pgbench и выполнению запросов без explain.

Параметр buffers на результат не влияет, он иллюстрирует то, что все блоки таблицы находились в буферном кэше (shared hit=541) при выполнении всех трёх команд.

У команды explain есть опция settings, которая выдаст строку со значениями параметров, которые:

a) влияют на планировщик

b) имеют значения, отличные от значений по умолчанию.

Если такие параметры отсутствуют, то параметр settings не влияет на вывод команды explain.

Особенности измерения времени, настройки источника времени, измерения его скорости  будут рассмотрены в следующих главах курса.

Какие параметры &ldquo;влияют на планировщик&rdquo;? Это декларируется при добавлении параметра конфигурации разработчиками PostgreSQL или создателями библиотек расширений. Пример:

postgres=# select pg_settings_get_flags('work_mem');

 pg_settings_get_flags

-----------------------

 {EXPLAIN}

(1 row)

Если в результатах есть , то это означает, что параметр конфигурации задекларирован как &ldquo;влияющий на планировщик&rdquo;. Таких параметров около 60.

У параметров конфигурации могут быть следующие флаги:

EXPLAIN (примерно 60 параметров) параметры с этим флагом включаются в команды EXPLAIN (SETTINGS);

NO_SHOW_ALL (параметров с таким флагом нет) исключаются из команд SHOW ALL;

NO_RESET (3 параметра) не поддерживают команды RESET;

NO_RESET_ALL (3 параметра) исключаются из команд RESET ALL;

NOT_IN_SAMPLE (50 параметров) автоматически не включаются в файл postgresql.conf.sample, на основе которого утилитой initdb создаётся файл параметров кластера

RUNTIME_COMPUTED (5 параметров) значения параметра не устанавливаются, а вычисляются при запуске экземпляра.

Список параметров с флагами можно получить командой:

postgres=# select name, pg_settings_get_flags(name) from pg_settings where array_length(pg_settings_get_flags(name),1)>0;

Список вычисляемых параметров:

postgres=# select name, context, pg_settings_get_flags(name) from pg_settings where pg_settings_get_flags(name)::text like '%RUNTIME%';

               name               | context  |      pg_settings_get_flags      

----------------------------------+----------+--------------------------------

 data_checksums                   | internal | {NOT_IN_SAMPLE,RUNTIME_COMPUTED}

 data_directory_mode              | internal | {NOT_IN_SAMPLE,RUNTIME_COMPUTED}

 shared_memory_size               | internal | {NOT_IN_SAMPLE,RUNTIME_COMPUTED}

 shared_memory_size_in_huge_pages | internal | {NOT_IN_SAMPLE,RUNTIME_COMPUTED}

 wal_segment_size                 | internal | {NOT_IN_SAMPLE,RUNTIME_COMPUTED}

(5 rows)

Список параметров, не сбрасывающихся в исходное значение:

postgres=# select name, context, pg_settings_get_flags(name) from pg_settings where pg_settings_get_flags(name)::text like '%RESET%';

          name          | context |         pg_settings_get_flags        

------------------------+---------+---------------------------------------

 transaction_deferrable | user    | {NO_RESET,NO_RESET_ALL,NOT_IN_SAMPLE}

 transaction_isolation  | user    | {NO_RESET,NO_RESET_ALL,NOT_IN_SAMPLE}

 transaction_read_only  | user    | {NO_RESET,NO_RESET_ALL,NOT_IN_SAMPLE}

(3 rows)

9) Выполните команду, созданную на основе  теста на языке plpgsql: https://gist.github.com/lukaseder/2611212b23ba40d5f828c69b79214a0e/ 

используемого в статье https://blog.jooq.org/whats-faster-count-or-count1/ :

DO $$

DECLARE

  v_ts TIMESTAMP;

  v_repeat CONSTANT INT := 100;

  rec RECORD;

  run INT[];

  stmt INT[];

  elapsed DECIMAL[];

  min_elapsed DECIMAL;

  i INT := 1;

BEGIN

  FOR r IN 1..5 LOOP

    v_ts := clock_timestamp();

    FOR i IN 1..v_repeat LOOP

      FOR rec IN (

        select count(*) from t

      ) LOOP

        NULL;

      END LOOP;

    END LOOP;

    run[i] := r;

    stmt[i] := 1;

    elapsed[i] := (EXTRACT(EPOCH FROM CAST(clock_timestamp() AS TIMESTAMP)) - EXTRACT(EPOCH FROM v_ts));

    i := i + 1;

    v_ts := clock_timestamp();

    FOR i IN 1..v_repeat LOOP

      FOR rec IN (

        select count(1) from t

      ) LOOP

        NULL;

      END LOOP;

    END LOOP;

    run[i] := r;

    stmt[i] := 2;

    elapsed[i] := (EXTRACT(EPOCH FROM CAST(clock_timestamp() AS TIMESTAMP)) - EXTRACT(EPOCH FROM v_ts));

    i := i + 1;

    v_ts := clock_timestamp();

    FOR i IN 1..v_repeat LOOP

      FOR rec IN (

        select count(pk) from t

      ) LOOP

        NULL;

      END LOOP;

    END LOOP;

    run[i] := r;

    stmt[i] := 3;

    elapsed[i] := (EXTRACT(EPOCH FROM CAST(clock_timestamp() AS TIMESTAMP)) - EXTRACT(EPOCH FROM v_ts));

    i := i + 1;

  END LOOP;

  SELECT min(t.elapsed)

  INTO min_elapsed

  FROM unnest(elapsed) AS t(elapsed);

  FOR i IN 1..array_length(run, 1) LOOP

    RAISE INFO 'RUN %, Statement %: %', run[i], stmt[i], CAST(elapsed[i] / min_elapsed AS DECIMAL(10, 5));

  END LOOP;

END$$;

INFO:  RUN 1, Statement 1: 1.00764

INFO:  RUN 1, Statement 2: 1.12819

INFO:  RUN 1, Statement 3: 1.38278

INFO:  RUN 2, Statement 1: 1.01305

INFO:  RUN 2, Statement 2: 1.12725

INFO:  RUN 2, Statement 3: 1.37496

INFO:  RUN 3, Statement 1: 1.00552

INFO:  RUN 3, Statement 2: 1.13360

INFO:  RUN 3, Statement 3: 1.38406

INFO:  RUN 4, Statement 1: 1.00269

INFO:  RUN 4, Statement 2: 1.13924

INFO:  RUN 4, Statement 3: 1.38148

INFO:  RUN 5, Statement 1: 1.00000

INFO:  RUN 5, Statement 2: 1.14320

INFO:  RUN 5, Statement 3: 1.41113

DO

Результат соответствует результатам теста pgbench.

Это был пример использования программы на языке plpgsql для тестирования времени выполнения трёх команд. Использование pgbench более просто и даёт больше информации: времени выполнения команд (latency) и стандартного отклонения времени выполнения.

Часть 3. Использование утилиты sysbench

1) Создайте таблицы, которые использует sysbench выполнив команду:

postgres@tantor:~$ sysbench --db-driver=pgsql --pgsql-port=5432 --pgsql-db=postgres --pgsql-user=postgres --pgsql-password=postgres --tables=1 --table_size=100000 /usr/share/sysbench/oltp_read_only.lua prepare

sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Creating table 'sbtest1'...

Inserting 100000 records into 'sbtest1'

Creating a secondary index on 'sbtest1'...

Создана одна таблица sbtest1 со 100тыс. строк.

2) Файлы тестов sysbench пишутся на языке lua. В директории /usr/share/sysbench/ находятся стандартные тесты. Запустите тест только для чтения с названием oltp_read_only.lua:

postgres@tantor:~$ sysbench --db-driver=pgsql --pgsql-port=5432 --pgsql-db=postgres --pgsql-user=postgres --pgsql-password=postgres --threads=10 --time=15  --report-interval=5 /usr/share/sysbench/oltp_read_only.lua run

sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:

Number of threads: 10

Report intermediate results every 5 second(s)

Initializing random number generator from current time

Initializing worker threads...

Threads started!

[ 5s ] thds: 10 tps: 584.03 qps: 9364.62 (r/w/o: 8194.56/0.00/1170.05) lat (ms,95%): 28.67 err/s: 0.00 reconn/s: 0.00

[ 10s ] thds: 10 tps: 592.77 qps: 9480.12 (r/w/o: 8294.58/0.00/1185.54) lat (ms,95%): 28.16 err/s: 0.00 reconn/s: 0.00

[ 15s ] thds: 10 tps: 477.21 qps: 7632.70 (r/w/o: 6678.48/0.00/954.21) lat (ms,95%): 51.02 err/s: 0.00 reconn/s: 0.00

SQL statistics:

    queries performed:

        read:                            115934

        write:                           0

        other:                           16562

        total:                           132496

    transactions:                        8281   (550.22 per sec.)

    queries:                             132496 (8803.46 per sec.)

    ignored errors:                      0      (0.00 per sec.)

    reconnects:                          0      (0.00 per sec.)

General statistics:

    total time:                          15.0492s

    total number of events:              8281

Latency (ms):

         min:                                    3.70

         avg:                                   18.12

         max:                                  178.98

         95th percentile:                       30.81

         sum:                               150092.73

Threads fairness:

    events (avg/stddev):           828.1000/63.26

    execution time (avg/stddev):   15.0093/0.01

Число транзакций в секунду 550.22.

Остальные показатели не удобны. Число транзакций 8281 и events: зависят от длительности теста. Другие показатели с трудом поддаются анализу. Например, Latency 95th percentile более точно соответствует реальности, чем avg, который вряд ли имеет смысл, так как измерения сильно отклоняющиеся от среднего (178.98) стоило исключить из расчёта. Задержки могут быть связаны с планировщиком или активностью операционной системы. В примере использовалось 10 потоков, в виртуальной машине меньше ядер и задержки связаны с планировщиком операционной системы. Измерения, выполненные сразу после запуска утилиты, авторам утилиты стоило исключать из подсчета.

Часть 4. Использование HammerDB

1) Запустите терминал под пользователем astra и установите HammerDB:

astra@tantor:~$ wget https://github.com/TPC-Council/HammerDB/releases/download/v4.12/HammerDB-4.12-Linux-x64-installer.run

- &lsquo;HammerDB-4.12-Linux-x64-installer.run&rsquo; saved [12665959/12665959]

astra@tantor:~$ chmod +x HammerDB-4.12-Linux-x64-installer.run 

astra@tantor:~$ ./HammerDB-4.12-Linux-x64-installer.run

Установите в директорию по умолчанию /home/astra/HammerDB-4.12

После инсталляции утилита запустится. Утилиту можно запустить повторно командой:

astra@tantor:~$ cd /home/astra/HammerDB-4.12

astra@tantor:~/HammerDB-4.12$ ./hammerdb &

2) После запуска утилиты в её окне кликните на PostgreSQL. В появившемся окне "Benchmark Options" оставьте значения PostgreSQL и TPROC-C. Нажмите в окне кнопку OK. В окне подтверждения также нажмите кнопку OK.

3) Раскрыв меню PostgreSQL->TPROC-C->Schema и кликнув на Options перейдите в закладку Settings и установите Number of warehouses (число складов) = 2. По умолчанию установлено значение 1. Для 10 складов потребуется 1Гб. Установите число Virtual Users to build schema в двойное число ядер процессоров минус один, например 7 при числе ядер 4. Нажмите OK,  настройка сохранится. При реальном тестировании потребуется значительно большее число складов. Однако, небольшое число складов позволит симулировать конкуренцию за блокировки между сессиями.

4) Кликните в меню PostgreSQL->TPROC-C->Schema на Build. Появится окно с предупреждением, что будет создана база данных tpcc и в ней таблицы с данными для теста TPC-C.

 Время на создание несколько минут. Можно посмотреть нагрузку на процессора пока идёт создание таблиц командой top. Чтобы показывалась нагрузка по ядрам нужно нажать 1. Для выхода из утилиты top нужно нажать клавишу q.

astra@tantor:~/HammerDB-4.12$ top

В окне утилиты top видно, что нагрузка на четыре ядра близка к 100%. Пропорция USR/SYS: %Cpu0 89.9us + 7.7 sy.

На то, что таблицы созданы укажет сообщение TPCC SCHEMA COMPLETE в окне Virtual User 1.

5) Нажмите на красный квадрат на toolbar утилиты. Выберите в меню PostgreSQL->TPROC-C-> Driver Script -> Options. В открывшемся окне перейдите в закладку Settings и укажите Minutes of Rampup Time 0. Это время "разогрева", то есть постепенного увеличения нагрузки на СУБД. Мы установили небольшое число клиентов, которые не нагрузят СУБД и задержка не нужна. Minutes of Test Duration 5, это длительность теста, если тест не будет остановлен раньше.

6) В окне PostgreSQL->TPROC-C-> Virtual User -> Options установите User Delay(ms)=0, Repeat Delay(ms)=0. При реальном тестировании рекомендуют устанавливать число пользователей в 10 раз меньше, чем число складов.

7) Перед запуском теста для наблюдения за tpm нужно запустить Transaction Counter. Для этого кликните в меню на PostgreSQL->TPROC-C-> Transactions -> Counter. Запустится счетчик транзакций.

7) Кликните на PostgreSQL->TPROC-C-> Virtual User -> Create и затем на PostgreSQL->TPROC-C-> Virtual User -> Run

Кликните на закладку Transaction Counter. Появится окно с метрикой теста, называющейся tpm.

В примере tpm=113604. График метрики tpm колеблется, это не неточности, а следствие динамической нагрузки, соответствующей правилам теста. Уменьшение tpm на десятки процентов возникает из-за  удержания горизонта базы данных автоанализом. Через несколько минут после запуска теста tpm может снизиться на треть. Это происходит из-за запуска автоанализа по таблице order_line и продолжающегося до двух минут. На снижение tpm также влияет выполнение контрольной точки.

Это пример, когда периодический сбор статистики не то, что бесполезен, а вреден. Если данные статистики после пересборов не меняются, статистику бессмысленно "актуализировать".

postgres=# \c tpcc

You are now connected to database "tpcc" as user "postgres".

tpcc=# select extract(epoch from (clock_timestamp()-xact_start)) secs, pid, datname database, state, query from pg_stat_activity where backend_xmin IS NOT NULL OR backend_xid IS NOT NULL order by greatest(age(backend_xmin), age(backend_xid)) desc limit 1 \gx

-[ RECORD 1 ]------------------------------------------

secs     | 118.896428

pid      | 296618

database | tpcc

state    | active

query    | autovacuum: VACUUM ANALYZE public.order_line

В отсутствие нагрузки анализ таблицы длится (на СУБД с параметрами конфигурации по умолчанию) 27 секунд:

tpcc=# VACUUM (ANALYZE, verbose)  public.order_line;

INFO:  vacuuming "tpcc.public.order_line"

INFO:  finished vacuuming "tpcc.public.order_line": index scans: 1

pages: 0 removed, 186118 remain, 166506 scanned (89.46% of total)

tuples: 446332 removed, 15377120 remain, 0 are dead but not yet removable, oldest xmin: 10827114

removable cutoff: 10827114, which was 0 XIDs old when operation ended

frozen: 79603 pages from table (42.77% of total) had 1825159 tuples frozen

index scan needed: 51544 pages from table (27.69% of total) had 597993 dead item identifiers removed

index "order_line_i1": pages: 81640 in total, 0 newly deleted, 0 currently deleted, 0 reusable

avg read rate: 83.907 MB/s, avg write rate: 48.399 MB/s

buffer usage: 170193 hits, 296131 misses, 170812 dirtied

WAL usage: 384641 records, 164101 full page images, 1262224255 bytes

system usage: CPU: user: 6.17 s, system: 4.05 s, elapsed: 27.57 s

INFO:  analyzing "public.order_line"

INFO:  "order_line": scanned 30000 of 186118 pages, containing 2492677 live rows and 0 dead rows; 30000 rows in sample, 15464402 estimated total rows

VACUUM

tpm снизился от 101000 до 63588 из-за того, что автоанализ удерживал горизонт базы данных.

8) Ждать остановки теста по времени не нужно. Остановите тест, нажав на левый красный квадрат (Destroy Virtual users) на toolbar. На правый красный квадрат (Stop Transaction Counter) нажимать не нужно, иначе остановится счётчик транзакций. В окне PostgreSQL->TPROC-C-> Virtual User -> Options установите User Delay(ms)=500, Repeat Delay(ms)=500. Эти параметры не сильно влияют на tpm, они влияют на колебания графика tpm. На tpm влияет число клиентов (сессий с СУБД), называемых Virtual Users.

Меняя параметры в Virtual User -> Options, нажав на Virtual User -> Run и перейдя в закладку Transaction Counter можно наблюдать как изменится tpm. Максимальный tpm достигается при числе клиентов равному числу ядер процессоров.

9) После завершения тестирования закройте окно HammerDB и удалите базу данных tpcc, которая после недолгого тестирования разрастётся в несколько раз. В таблицы тест выставляет строки и они увеличиваются.

По завершении теста в окне Virtual User 1 будет показан результат теста:

В примере результат tpms (PostgreSQL TPM)=72606 и NOPM (New Orders per minute)=31648.

Со временем tpcm при повторных тестах будут уменьшаться. Из-за этого тест не подходит для использования при проверке того как повлияют изменения конфигурации кластера на производительность, так как tpm не только не стабилен, но и уменьшается со временем. Для стабильности результата придется удалять базу данных tpcc и создавать заново. Тест может использоваться для долговременного однократного тестирования в целях сравнения с другими СУБД того же или другого типа. При тестировании все параметры должны быть одинаковы, особенно размер базы данных (число складов), длительность теста, число клиентов.

Тест TPC-С удобен тем, что при его выполнении можно проводить анализ работы экземпляра доступными инструментами (расширениями, обращаясь к представлениям со статистиками) и выявляя наиболее эффективные инструменты и метрики. Это следствие более сложных команд, чем у простых нагрузочных тестов pgbench TPC-B.

Графическое приложение HammerDB удобно для таких целей.

postgres=# \c tpcc

You are now connected to database "tpcc" as user "postgres".

tpcc=# select pg_size_pretty(pg_database_size('tpcc'));

 pg_size_pretty

----------------

 2682 MB

(1 row)

После создания таблиц база данных занимала 1Гб.

tpcc=# vacuum full;

VACUUM

tpcc=# select pg_size_pretty(pg_database_size('tpcc'));

 pg_size_pretty

----------------

 2331 MB

(1 row)

postgres=# drop database tpcc;

DROP DATABASE

postgres=#

Часть 5. Использование приложения Go-TPC

1) Установите go-tpc:

postgres@tantor:~$ mkdir gotpc

mkdir: cannot create directory &lsquo;gotpc&rsquo;: File exists

postgres@tantor:~$ cd gotpc

postgres@tantor:~/gotpc$ wget https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh

- &lsquo;install.sh&rsquo; saved [2020/2020]

postgres@tantor:~/gotpc$ chmod +x install.sh

postgres@tantor:~/gotpc$ ./install.sh

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

100 4984k  100 4984k    0     0  4370k      0  0:00:01  0:00:01 --:--:-- 23.2M

Detected shell: bash

Shell profile:  /var/lib/postgresql/.bash_profile

/var/lib/postgresql/.bash_profile has been modified to to add go-tpc to PATH

open a new terminal or source /var/lib/postgresql/.bash_profile to use it

Installed path: /var/lib/postgresql/.go-tpc/bin/go-tpc

===============================================

Have a try:     go-tpc tpcc

===============================================

postgres@tantor:~/gotpc$

2) Перейдите в директорию утилиты и запустите утилиту с опцией tpcc prepare, которая создаст базу данных gotpcc и создаст в этой базе данных объекты для теста типа TPC-C:

postgres@tantor:~/gotpc$ cd $HOME/.go-tpc/bin

postgres@tantor:~/.go-tpc/bin$ ./go-tpc tpcc prepare -d postgres -U postgres -p 'postgres' -D gotpcc -H 127.0.0.1 -P 5432 --conn-params sslmode=disable

maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined

creating table warehouse

creating table district

creating table customer

creating index idx_customer

creating table history

creating index idx_h_w_id

creating index idx_h_c_w_id

creating table new_order

creating table orders

creating index idx_order

creating table order_line

creating table stock

creating table item

load to item

load to warehouse in warehouse 1

load to stock in warehouse 1

load to district in warehouse 1

load to warehouse in warehouse 2

load to stock in warehouse 2

load to district in warehouse 2

load to warehouse in warehouse 3

load to stock in warehouse 3

load to district in warehouse 3

load to warehouse in warehouse 4

load to stock in warehouse 4

load to district in warehouse 4

load to warehouse in warehouse 5

load to stock in warehouse 5

load to district in warehouse 5

load to warehouse in warehouse 6

load to stock in warehouse 6

load to district in warehouse 6

load to warehouse in warehouse 7

load to stock in warehouse 7

load to district in warehouse 7

load to warehouse in warehouse 8

load to stock in warehouse 8

load to district in warehouse 8

load to warehouse in warehouse 9

load to stock in warehouse 9

load to district in warehouse 9

load to warehouse in warehouse 10

load to stock in warehouse 10

load to district in warehouse 10

load to customer in warehouse 1 district 1

load to history in warehouse 1 district 1

..

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

По умолчанию утилита создаёт 10 warehouses. Они создаются в течение 4 минут. Число складов можно поменять, указав параметр --warehouses 4.

3) Примерно через 3-4 минуты вы увидите в логе утилиты строки "begin to check warehouse 1 at condition 3.3.2.4". Утилита начала проверять данные после загрузки. Проверка идёт долго и не имеет смысла. Она нужна для тех СУБД, которые теряют данные, PostgreSQL не теряет данные. Нажмите на клавиатуре <ctrl+c>, чтобы прервать проверку:

load to new_order in warehouse 10 district 10

load to order_line in warehouse 10 district 10

begin to check warehouse 1 at condition 3.3.2.4

begin to check warehouse 1 at condition 3.3.2.5

begin to check warehouse 1 at condition 3.3.2.6

begin to check warehouse 1 at condition 3.3.2.7

begin to check warehouse 1 at condition 3.3.2.8

begin to check warehouse 1 at condition 3.3.2.9

begin to check warehouse 1 at condition 3.3.2.10

begin to check warehouse 1 at condition 3.3.2.10

^C

Got signal [interrupt] to exit.

check prepare failed, err check warehouse 1 at condition 3.3.2.10 failed exec SELECT count(*)

      FROM (  SELECT  c.c_id, c.c_d_id, c.c_w_id, c.c_balance c1,

                    (SELECT sum(ol_amount) FROM orders, order_line

                        WHERE OL_W_ID=O_W_ID

                          AND OL_D_ID = O_D_ID

                          AND OL_O_ID = O_ID

                          AND OL_DELIVERY_D IS NOT NULL

                          AND O_W_ID=?

                          AND O_D_ID=c.C_D_ID

                          AND O_C_ID=c.C_ID) sm, (SELECT  sum(h_amount)  from  history

                                                     WHERE H_C_W_ID=?

                                                       AND H_C_D_ID=c.C_D_ID

                                                       AND H_C_ID=c.C_ID) smh

                   FROM customer c

                  WHERE  c.c_w_id = ? ) t

   WHERE c1<>sm-smh failed pq: canceling statement due to user request

Finished

Размер базы данных, которую создала утилита 1Гб:

postgres=# select pg_size_pretty(pg_database_size('gotpcc'));

 pg_size_pretty

----------------

 1028 MB

(1 row)

4) Запустите тест tpcc:

postgres@tantor:~/.go-tpc/bin$ ./go-tpc tpcc run -d postgres -U postgres -p 'postgres' -D gotpcc -H 127.0.0.1 -P 5432 --conn-params sslmode=disable 
maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined
[Current] DELIVERY - Takes(s): 9.9, Count: 61, TPM: 369.4, Sum(ms): 879.3, Avg(ms): 14.4, 50th(ms): 14.2, 90th(ms): 16.8, 95th(ms): 17.8, 99th(ms): 21.0,
99.9th(ms): 27.3, Max(ms): 27.3
[Current] NEW_ORDER - Takes(s): 9.9, Count: 714, TPM: 4310.5, Sum(ms): 5931.1, Avg(ms): 8.3, 50th(ms): 8.4, 90th(ms): 11.0, 95th(ms): 12.6, 99th(ms): 17.8
, 99.9th(ms): 26.2, Max(ms): 29.4
[Current] ORDER_STATUS - Takes(s): 9.9, Count: 61, TPM: 369.7, Sum(ms): 104.9, Avg(ms): 1.7, 50th(ms): 2.1, 90th(ms): 2.1, 95th(ms): 2.6, 99th(ms): 3.1, 9
9.9th(ms): 5.2, Max(ms): 5.2
[Current] PAYMENT - Takes(s): 10.0, Count: 697, TPM: 4197.6, Sum(ms): 2448.8, Avg(ms): 3.5, 50th(ms): 3.7, 90th(ms): 4.2, 95th(ms): 4.7, 99th(ms): 7.9, 99
.9th(ms): 8.4, Max(ms): 13.1
[Current] STOCK_LEVEL - Takes(s): 9.9, Count: 65, TPM: 395.9, Sum(ms): 277.1, Avg(ms): 4.3, 50th(ms): 3.7, 90th(ms): 4.7, 95th(ms): 5.8, 99th(ms): 24.1, 9
9.9th(ms): 41.9, Max(ms): 41.9

На консоль будет выводиться текущая статистика TPM.

5) Примерно через минуту нажмите на клавиатуре <ctrl+c>, чтобы прервать тест. Утилита выдаст статистику с результатом tpmC:

^C

Got signal [interrupt] to exit.

Finished

[Summary] DELIVERY - Takes(s): 182.8, Count: 1329, TPM: 436.3, Sum(ms): 17163.3, Avg(ms): 12.9, 50th(ms): 12.6, 90th(ms): 14.7, 95th(ms): 16.8, 99th(ms): 22.0, 99.9th(ms): 29.4, Max(ms): 30.4

[Summary] NEW_ORDER - Takes(s): 182.8, Count: 14194, TPM: 4659.0, Sum(ms): 106451.6, Avg(ms): 7.5, 50th(ms): 7.3, 90th(ms): 9.4, 95th(ms): 10.5, 99th(ms): 15.7, 99.9th(ms): 22.0, Max(ms): 41.9

[Summary] ORDER_STATUS - Takes(s): 182.8, Count: 1288, TPM: 422.9, Sum(ms): 2306.0, Avg(ms): 1.8, 50th(ms): 2.1, 90th(ms): 2.6, 95th(ms): 2.6, 99th(ms): 4.2, 99.9th(ms): 8.9, Max(ms): 10.0

[Summary] PAYMENT - Takes(s): 182.8, Count: 13431, TPM: 4407.9, Sum(ms): 46553.2, Avg(ms): 3.5, 50th(ms): 3.7, 90th(ms): 4.2, 95th(ms): 4.7, 99th(ms): 7.9, 99.9th(ms): 14.2, Max(ms): 19.9

[Summary] STOCK_LEVEL - Takes(s): 182.7, Count: 1262, TPM: 414.4, Sum(ms): 3707.7, Avg(ms): 2.9, 50th(ms): 3.1, 90th(ms): 3.7, 95th(ms): 4.2, 99th(ms): 8.9, 99.9th(ms): 24.1, Max(ms): 41.9

tpmC: 4659.0, tpmTotal: 10340.5, efficiency: 3622.8%

6) Удалите базу данных, созданную утилитой:

postgres@tantor:~/.go-tpc/bin$ psql -с "drop database gotpcc;"

DROP DATABASE

7) В отличие от HammerDB утилита go-tpc работает не на полной скорости, а выполняет правила теста TPC-C, работая с задержками и постепенно увеличивая нагрузку. В утилите есть ещё два теста: TPC-H и собственный тест утилиты tpc-ch (CH-benCHmark смешанная нагрузка из тестов TPC-C и TPC-H). Тест подходит для СУБД, которые используются в общих целях со смешанной нагрузкой. PostgreSQL редко используется со смешанной нагрузкой, так как для долгих(аналитических) запросов используют физические реплики.

Тест TPC-H для хранилищ данных и состоит только из читающих команд. Результат теста TPC-H более стабилен, позволяет проводить сравнение. Недостаток в том, что размер баз для официальных тестов довольно большой.

Создание базы данных занимает примерно 10 минут. Размер базы данных 1660Мб.

Выполнять следующие пункты этой практики не обязательно. Команды и их результаты приведены для ознакомления. Вы можете использовать эти команды как справочник или если хотите закрепить навыки использования утилиты.

postgres@tantor:~/.go-tpc/bin$ ./go-tpc tpch prepare -d postgres -U postgres -p 'postgres' -D gotpch -H 127.0.0.1 -P 5432 --conn-params sslmode=disable

 maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined

creating nation

creating region

creating part

creating supplier

creating partsupp

creating customer

creating orders

creating lineitem

generating nation table

generate nation table done

generating region table

generate region table done

generating customers table

generate customers table done

generating suppliers table

generate suppliers table done

generating part/partsupplier tables

generate part/partsupplier tables done

generating orders/lineitem tables

generate orders/lineitem tables done

Finished

Запуск теста TPC-H:

postgres@tantor:~/.go-tpc/bin$ ./go-tpc tpch run -d postgres -U postgres -p 'postgres' -D gotpch -H 127.0.0.1 -P 5432 --conn-params sslmode=disable

maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined

[Current] Q1: 6.21s

[Current] Q2: 0.91s

[Current] Q3: 1.31s

[Current] Q4: 0.44s

[Current] Q5: 0.44s

[Current] Q10: 1.24s

[Current] Q11: 0.30s

[Current] Q12: 1.17s

[Current] Q13: 1.04s

[Current] Q14: 1.17s

[Current] Q6: 0.77s

[Current] Q7: 0.64s

[Current] Q8: 0.97s

[Current] Q9: 3.05s

[Current] Q15: 0.84s

[Current] Q16: 0.57s

[Current] Q17: 1199.91s

[Current] Q18: 5.27s

[Current] Q19: 1.04s

Запрос Q17 в тесте долгий, он выполняется 3 часа(11999.91s). Утилита показывает максимальное значение 1199.91s для длинных запросов, в утилите программная ошибка.

Пример мониторинга запроса Q17:

postgres=# select extract(epoch from (clock_timestamp()-xact_start)) secs, pid, datname database, state, query from pg_stat_activity where backend_xmin IS NOT NULL OR backend_xid IS NOT NULL order by greatest(age(backend_xmin), age(backend_xid)) desc limit 1 \gx

-[ RECORD 1 ]----------------------------------------------

secs     | 6434.701066

pid      | 316066

database | gotpch

state    | active

query    |                                                 +

         | /*PLACEHOLDER*/ select                          +

         |         sum(l_extendedprice) / 7.0 as avg_yearly+

         | from                                            +

         |         lineitem,                               +

         |         part                                    +

         | where                                           +

         |         p_partkey = l_partkey                   +

         |         and p_brand = 'Brand#43'                +

         |         and p_container = 'LG PACK'             +

         |         and l_quantity < (                      +

         |                 select                          +

         |                         0.2 * avg(l_quantity)   +

         |                 from                            +

         |                         lineitem                +

         |                 where                           +

         |                         l_partkey = p_partkey   +

         |         );                                      +

         |

В запросе есть коррелированный подзапрос. Коррелированные подзапросы тяжелы для всех СУБД. Например, на специализированной под OLAP СУБД clickhouse запросы теста TPC-H Q17 и Q20 не работают "As of October 2024, the query does not work out-of-the box due to correlated subqueries. Corresponding issue: https://github.com/ClickHouse/ClickHouse/issues/6697" (https://clickhouse.com/docs/en/getting-started/example-datasets/tpch).

Запрос Q20 работает на PostgreSQL с параметрами по умолчанию 7,6 часов, запрос Q17 работет около 4 часов. Долгие запросы интересны для оптимизации выполнения запросов: выяснения причин долгого выполнения. К оптимизации запросов стоит переходить после настройки работы экземпляра PostgreSQL. План выполнения этого запроса:

postgres=# \c gotpch

You are now connected to database "gotpch" as user "postgres".

gotpch=# explain select sum(l_extendedprice) / 7.0 as avg_yearly from lineitem, part where p_partkey = l_partkey and p_brand = 'Brand#43' and p_container = 'LG PACK' and l_quantity < ( select 0.2 * avg(l_quantity) from lineitem where l_partkey = p_partkey);

                                 QUERY PLAN

-------------------------------------------------------------------------------------

Aggregate  (cost=2204613.84..2204613.86 rows=1 width=32)

 -> Hash Join  (cost=6625.16..2204608.92 rows=1970 width=8)

      Hash Cond: (lineitem.l_partkey = part.p_partkey)

      Join Filter: (lineitem.l_quantity < (SubPlan 1))

      ->  Seq Scan on lineitem  (cost=0.00..184745.33 rows=6001233 width=21)

      ->  Hash  (cost=6622.70..6622.70 rows=197 width=8)

          ->  Gather  (cost=1000.00..6622.70 rows=197 width=8)

                Workers Planned: 2

                ->  Parallel Seq Scan on part  (cost=0.00..5603.00 rows=82 width=8)

                      Filter:((p_brand = 'Brand#43'::bpchar) AND (p_container = 'LG PACK'::bpchar))

      SubPlan 1

        ->  Aggregate  (cost=199748.49..199748.51 rows=1 width=32)

              ->  Seq Scan on lineitem lineitem_1  (cost=0.00..199748.41 rows=31 width=5)

                    Filter: (l_partkey = part.p_partkey)

JIT:

  Functions: 24

  Options: Inlining true, Optimization true, Expressions true, Deforming true

(17 rows)

В таблицах 6млн. и 200т. строк, что не так много:

gotpch=# select count(*) from lineitem;

  count  

---------

 6001215

(1 row)

gotpch=# select count(*) from part;

 count  

--------

 200000

(1 row)

Долгий запрос нужно прервать, набрав на клавиатуре <ctrl+c> и затем удалить базу данных gotpch:

postgres@tantor:~/.go-tpc/bin$ psql -с "drop database gotpch;"

В составе приложения go-tpc есть три теста. Для создания базы данных для третьего теста (смешанного) используются параметр "ch", вместо "tpcc" и "tpch":

go-tpc ch prepare -d postgres -U postgres -p 'postgres' -D gotpcch -H 127.0.0.1 -P 5432 --conn-params sslmode=disable

Практика к главе 2

Часть 1. Запуск экземпляра с огромными страницами

1) Найдите список экземпляров PostgreSQL:

postgres@tantor:~$ ps -ef | grep /postgres

postgres    1423       1  0 Nov27 ? 00:00:06 /opt/tantor/db/16/bin/postgres -D /var/lib/postgresql/tantor-se-16/data

postgres    1432       1  0 Nov27 ? 00:00:03 /usr/lib/postgresql/15/bin/postgres -D /var/lib/postgresql/15/main -c config_file=/etc/postgresql/15/main/postgresql.conf

В примере два экземпляра: СУБД Тантор и PostgreSQL Astralinux.

2) Посмотрите, сколько памяти использует экземпляр PostgreSQL и какой размер у огромных страниц:

postgres@tantor:~$ cat /proc/1432/status | grep VmPeak

VmPeak:   222268 kB

postgres@tantor:~$ cat /proc/meminfo | grep Huge

AnonHugePages:      2048 kB

ShmemHugePages:        0 kB

FileHugePages:         0 kB

HugePages_Total:       0

HugePages_Free:        0

HugePages_Rsvd:        0

HugePages_Surp:        0

Hugepagesize:       2048 kB

Hugetlb:               0 kB

Максимальное потребление памяти экземпляром: 222268 kB / 2048 kB=109 страниц по 2Мб (2048). Огромные страницы могут использоваться разделяемым пулом (параметр shared_buffers) и параллельными процессами (параметр min_dynamic_shared_memory). Форки могут использовать и под другие структуры памяти. Пиковое потребление памяти на загруженном экземпляре показывает использование памяти всеми структурами.

Значение в строке AnonHugePages: отличное от нуля укажет на то, что какой-то процесс явно запросил использование THP системным вызовом madvise(). PostgreSQL не использует такой системный вызов.

Выполните команду free:

postgres@tantor:~$ free

               total        used        free      shared  buff/cache   available

Mem:         4020796     1137792      764984      158692     2556828     2883004

Swap:              0           0           0

3) Остановите экземпляр и проверьте сколько огромных страниц он может максимально выделить в соответсвии с его параметрами конфигурации:

postgres@tantor:~$ sudo systemctl stop postgresql

postgres@tantor:~$ /usr/lib/postgresql/15/bin/postgres -c config_file=/etc/postgresql/15/main/postgresql.conf -D /var/lib/postgresql/15/main -C shared_memory_size_in_huge_pages

70

4) Выделите память под 100 страниц и проверьте, что они выделены:

postgres@tantor:~$ sudo sysctl -w vm.nr_hugepages=100

vm.nr_hugepages = 100

postgres@tantor:~$ cat /proc/meminfo | grep Huge

AnonHugePages:         0 kB

ShmemHugePages:        0 kB

FileHugePages:         0 kB

HugePages_Total:     100

HugePages_Free:       27

HugePages_Rsvd:        1

HugePages_Surp:        0

Hugepagesize:       2048 kB

Hugetlb:          204800 kB

Значение HugePages_Free: = 27 указывает, что свободных страниц недостаточно под разделяемый пул размера 128Мб. Если у вас страниц больше 70, то такого количества достаточно. Если их меньше 80, то выделите память под 300 страниц и проверьте что свободных страниц больше 80:

 postgres@tantor:~$ sudo sysctl -w vm.nr_hugepages=300

vm.nr_hugepages = 300

postgres@tantor:~$ cat /proc/meminfo | grep Huge

AnonHugePages:         0 kB

ShmemHugePages:        0 kB

FileHugePages:         0 kB

HugePages_Total:     218

HugePages_Free:      145

HugePages_Rsvd:        1

HugePages_Surp:        0

Hugepagesize:       2048 kB

Hugetlb:          446464 kB

5) Выполните команду free:

postgres@tantor:~$ free

               total        used        free      shared  buff/cache   available

Mem:         4020796     1331220      571396      158696     2556992     2689576

Swap:              0           0           0

В выводе команды free показатели: used увеличился на 193428 байт, free уменьшился на 193 588 байт, available уменьшился на 193 428 байт.

6) Перезапустите службу postgresql:

postgres@tantor:~$ sudo systemctl restart postgresql

postgres@tantor:~$ cat /proc/meminfo | grep Huge

AnonHugePages:         0 kB

ShmemHugePages:        0 kB

FileHugePages:         0 kB

HugePages_Total:     218

HugePages_Free:      126

HugePages_Rsvd:       73

HugePages_Surp:        0

Hugepagesize:       2048 kB

Hugetlb:          446464 kB

7) Получите список процессов, которые используют огромные страницы размером 2Мб:

postgres@tantor:~$ sudo grep "KernelPageSize:     2048 kB" /proc/[[:digit:]]*/smaps | awk {'print $1'} | cut -d "/" -f3 | sort | uniq

112647

112649

112650

112652

112653

112654

8) Сравните с номерами (PID) процессов  экземпляра Astralinux PostgresSQL:

postgres@tantor:~$ ps -ef | grep 15/

postgres  112647       1  0 17:55 ?        00:00:00 /usr/lib/postgresql/15/bin/postgres -D /var/lib/postgresql/15/main -c config_file=/etc/postgresql/15/main/postgresql.conf

postgres  112648  112647  0 17:55 ?        00:00:00 postgres: 15/main: logger

postgres  112649  112647  0 17:55 ?        00:00:00 postgres: 15/main: checkpointer

postgres  112650  112647  0 17:55 ?        00:00:00 postgres: 15/main: background writer

postgres  112652  112647  0 17:55 ?        00:00:00 postgres: 15/main: walwriter

postgres  112653  112647  0 17:55 ?        00:00:00 postgres: 15/main: autovacuum launcher

postgres  112654  112647  0 17:55 ?        00:00:00 postgres: 15/main: logical replication launcher

Номера процессов совпадают. Экземпляр использует огромные страницы.

На то, что экземпляр стал использовать огромные страницы также укажет увеличение значения HugePages_Rsvd или уменьшение HugePages_Free. Из-за неудобства проверки по этим метрикам операционной системы то ли страницы зарезервированы экземпляром, то ли уже используются и экземпляром ли или другими процессами операционной системы, в 17 версии PostgreSQL добавили параметр huge_pages_status, который показывает, используются ли огромные страницы экземпляром или не используются.

Если хочется быть уверенным что экземпляр использует огромные страницы, можно установить значение параметра huge_pages=on. При таком значении параметра экземпляр не запустится, если не выделит огромные страницы.

Огромные страницы под использование параллельными процессами резервируются только при запуске экземпляра и только параметром min_dynamic_shared_memory. Если огромные страницы не зарезервированы или их будет недостаточно, то параллельные процессы станут выделять и использовать обычные страницы.

9) Посмотрите размер и тип огромных страниц, которые использует процесс postgres:

postgres@tantor:~$ cat /proc/112647/smaps_rollup | grep tlb

Shared_Hugetlb:    12288 kB

Private_Hugetlb:       0 kB

Процесс postgres использует разделяемые огромные страницы.

Часть 2. Изменение значения oom_score 

1) Выполните команду:

postgres@tantor:~$ for PID in $(pgrep "postgres"); do awk '/Pss/ {PSS+=$2} END { getline cmd < "/proc/'$PID'/cmdline"; sub("\0", " ", cmd); getline oom < "/proc/'$PID'/oom_score"; printf "%.0f -%s-> %s (PID %s) \n", PSS, oom, cmd, '$PID'}' /proc/$PID/smaps; done|sort -n -r

28579 -0-> /opt/tantor/db/16/bin/postgres -D/var/lib/postgresql/tantor-se-16/data (PID 112360)

5629 -668-> postgres: walwriter   (PID 112364)

5166 -70-> /usr/lib/postgresql/15/bin/postgres -D/var/lib/postgresql/15/main-cconfig_file=/etc/postgresql/15/main/postgresql.conf (PID 112647)

3207 -668-> postgres: autovacuum launcher   (PID 112365)

2945 -668-> postgres: 15/main: autovacuum launcher   (PID 112653)

2933 -668-> postgres: autoprewarm leader   (PID 112366)

2685 -668-> postgres: 15/main: logical replication launcher   (PID 112654)

2644 -668-> postgres: checkpointer   (PID 112361)

2618 -668-> postgres: logical replication launcher   (PID 112368)

2366 -668-> postgres: pg_wait_sampling collector   (PID 112367)

2157 -668-> postgres: background writer   (PID 112362)

1497 -667-> postgres: 15/main: logger   (PID 112648)

1479 -667-> postgres: 15/main: checkpointer   (PID 112649)

1468 -667-> postgres: 15/main: walwriter   (PID 112652)

1438 -667-> postgres: 15/main: background writer   (PID 112650)

Команда показывает значение oom_score процессов экземпляров PostgreSQL.

У основного процесса экземпляра СУБД Тантор oom_score=0. У экземпляра Astralinux PostgreSQL oom_score=70.

Уменьшение oom_score было выполнено путем редактирования файла службы. Посмотрите содержимое файла:

postgres@tantor:~$ cat /usr/lib/systemd/system/tantor-se-server-16.service

[Unit]

Description=Tantor Special Edition database server 16

Documentation=https://www.postgresql.org/docs/16/static/

After=syslog.target

After=network.target

[Service]

Type=forking

User=postgres

Group=postgres

LimitNOFILE=infinity

LimitNOFILESoft=infinity

# Where to send early-startup messages from the server (before the logging options of postgresql.conf take effect)

# This is normally controlled by the global default set by systemd

# StandardOutput=syslog

# Disable OOM kill on the postmaster

OOMScoreAdjust=-1000

# ... but allow it still to be effective for child processes

# (note that these settings are ignored by Postgres releases before 9.5)

Environment=PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj

Environment=PG_OOM_ADJUST_VALUE=0

# Maximum number of seconds pg_ctl will wait for postgres to start.  Note that PGSTARTTIMEOUT should be less than

# TimeoutSec value.

Environment=PGSTARTTIMEOUT=270

Environment=PGDATA=/var/lib/postgresql/tantor-se-16/data

ExecStartPre=/opt/tantor/db/16/bin/postgresql-check-db-dir ${PGDATA}

ExecStart=/opt/tantor/db/16/bin/pg_ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT}

ExecStop=/opt/tantor/db/16/bin/pg_ctl stop -D ${PGDATA} -s -m fast

ExecReload=/opt/tantor/db/16/bin/pg_ctl reload -D ${PGDATA} -s

# Give a reasonable amount of time for the server to start up/shut down. Ideally, the timeout for starting

# PostgreSQL server should be handled more nicely by pg_ctl in ExecStart, so keep its timeout smaller than this

# value.

TimeoutSec=300

[Install]

WantedBy=multi-user.target

В файле написано, что OOM kill запрещается для процесса postmaster, но работает для остальных процессов экземпляра. Если нужно уменьшить значение oom_score, то можно изменить в этом файле значение параметра PG_OOM_ADJUST_VALUE.

3) Пункт опционален, его можно не выполнять. Понизьте oom_score на 200. Для этого отредактируйте файл службы и установите значение PG_OOM_ADJUST_VALUE=-300:

postgres@tantor:~$ su -

Password: root 

root@tantor:~# cd /usr/lib/systemd/system/

root@tantor:~# mcedit tantor-se-server-16.service

отредактируйте и затем сохраните файл клавишей F2 ENTER закройте редактор клавишей F10

root@tantor:/usr/lib/systemd/system# cat tantor-se-server-16.service | grep OOM

# Disable OOM kill on the postmaster

OOMScoreAdjust=-1000

Environment=PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj

Environment=PG_OOM_ADJUST_VALUE=-300

root@tantor:/usr/lib/systemd/system# systemctl daemon-reload

root@tantor:/usr/lib/systemd/system# restart

root@tantor:/usr/lib/systemd/system# for PID in $(pgrep "postgres"); do awk '/Pss/ {PSS+=$2} END { getline cmd < "/proc/'$PID'/cmdline"; sub("\0", " ", cmd); getline oom < "/proc/'$PID'/oom_score"; printf "%.0f -%s-> %s (PID %s) \n", PSS, oom, cmd, '$PID'}' /proc/$PID/smaps; done|sort -n -r

33392 -0-> /opt/tantor/db/16/bin/postgres -D/var/lib/postgresql/tantor-se-16/data (PID 119419)

4993 -70-> /usr/lib/postgresql/15/bin/postgres -D/var/lib/postgresql/15/main-cconfig_file=/etc/postgresql/15/main/postgresql.conf (PID 112647)

3232 -468-> postgres: autovacuum launcher   (PID 119424)

2865 -668-> postgres: 15/main: autovacuum launcher   (PID 112653)

2770 -468-> postgres: logical replication launcher   (PID 119427)

2648 -668-> postgres: 15/main: logical replication launcher   (PID 112654)

2533 -468-> postgres: background writer   (PID 119421)

2523 -468-> postgres: pg_wait_sampling collector   (PID 119426)

2019 -667-> postgres: 15/main: checkpointer   (PID 112649)

1777 -468-> postgres: autoprewarm leader   (PID 119425)

1562 -468-> postgres: checkpointer   (PID 119420)

1517 -667-> postgres: 15/main: walwriter   (PID 112652)

1480 -667-> postgres: 15/main: background writer   (PID 112650)

1475 -667-> postgres: 15/main: logger   (PID 112648)

1463 -468-> postgres: walwriter   (PID 119423)

У всех процессов экземпляра tantor oom_score уменьшился на 200. После редактирования файла службы перечитали конфигурацию командой systemctl daemon-reload и рестартовали экземпляр.

4) Проверьте, что ksm отключён:

postgres@tantor:~$ cat /proc/vmstat | grep ksm

ksm_swpin_copy 0

cow_ksm 0

postgres@tantor:~$ cat /sys/kernel/mm/ksm/run

0

postgres@tantor:~$ cat /sys/kernel/mm/ksm/pages_scanned

0

Эту проверку делают на всякий случай. ksm полезен и может быть включён, если в операционной системе запускаются виртуальные машины из одного файла образа виртуальной машины.

5) Проверьте значения параметров, влияющих на выделение памяти большего размера, чем есть:

postgres@tantor:~$ sudo sysctl -a | grep vm.over

vm.overcommit_kbytes = 0

vm.overcommit_memory = 0

vm.overcommit_ratio = 50

postgres@tantor:~$ sudo sysctl -a | grep vm.swap

vm.swappiness = 60

Так как в виртуальной машине отключён раздел подкачки, то vm.overcommit_memory должен быть равен нулю. Так как подкачка отключена, то значение параметра vm.swappiness не играет роли.

Часть 3. Выгрузка длинных строк утилитой pg_dump

1) Создайте базу данных с названием ela и таблицу следующими командами:

postgres@tantor:~$ psql

postgres=# create database ela;

CREATE DATABASE

postgres=# \c ela

You are now connected to database "ela" as user "postgres".NOTICE:  table "t2" does not exist, skipping

postgres=# drop table if exists t2;

create table t2 (c1 text, c2 text);

insert into t2 (c1) VALUES (repeat('a', 1024*1024*512));

update t2 set c2 = c1;

\q

DROP TABLE

CREATE TABLE

INSERT 0 1

UPDATE 1

2) Остановите экземпляр postgresql

postgres@tantor:~$ sudo systemctl stop postgresql

3) Установите в 0 число огромных страниц:

postgres@tantor:~$ sudo sysctl -w vm.nr_hugepages=0

vm.nr_hugepages = 0

4) Попробуйте выгрузить базу данных ela утилитой pg_dump:

postgres@tantor:~$ pg_dump -c -C -d ela -f ela.sql 

pg_dump: error: Dumping the contents of table "t2" failed: PQgetResult() failed.

pg_dump: detail: Error message from server: ERROR:  out of memory

DETAIL:  Cannot enlarge string buffer containing 536870913 bytes by 536870912 more bytes.

pg_dump: detail: Command was: COPY public.t2 (c1, c2) TO stdout;

Возникла ошибка невозможности выгрузить содержимое таблицы из-за превышения размера памяти под string buffer. Максимальный размер буфера 1Гб.

5) Начиная с версии 16.2 в СУБД Тантор есть параметр enable_large_allocations, который увеличивает размер строкового буфера до 2Гб. Параметр можно установить и в сессиях утилиты pg_dump, используя параметр утилиты. Выгрузите базу данных ela, используя этот параметр:

postgres@tantor:~$ time pg_dump -c -d ela -f ela.sql --enable-large-allocations

real    0m12.556s

user    0m1.614s

sys     0m0.699s

выгрузка базы данных ela заняла 12.556 секунд.

6) Был создан файл размером 1Гб:

postgres@tantor:~$ ls -al ela.sql 

-rw-r--r-- 1 postgres postgres 1073742755 ela.sql

Часть 4. Нехватка памяти

1) В окне терминала проверьте сколько памяти свободно:

postgres@tantor:~$ free

          total      used        free      shared  buff/cache   available

Mem:    4020792    993520     2888632      185788      546988     3027272

Swap:         0         0           0

Свободно 2.8Гб, доступно 3Гб

2) Запустите утилиту psql:

postgres@tantor:~$ psql -d ela

Type "help" for help.

ela=# \c ela

3) В другом терминале посмотрите список процессов экземпляров PostgreSQL:

root@tantor:~$ for PID in $(pgrep "postgres"); do awk '/Pss/ {PSS+=$2} END { getline cmd < "/proc/'$PID'/cmdline"; sub("\0", " ", cmd); getline oom < "/proc/'$PID'/oom_score"; printf "%.0f -%s-> %s (PID %s) \n", PSS, oom, cmd, '$PID'}' /proc/$PID/smaps; done|sort -n -r

3039132 -922-> postgres: postgres ela [local] COPY  (PID 12518)

28619 -0-> /opt/tantor/db/16/bin/postgres -D /var/lib/postgresql/tantor-se-16/data (PID 12499)

5502 -668-> postgres: walwriter   (PID 12503)

3031 -668-> postgres: autovacuum launcher   (PID 12504)

2753 -668-> postgres: checkpointer   (PID 12500)

2507 -668-> postgres: logical replication launcher   (PID 12507)

2499 -668-> postgres: pg_wait_sampling collector   (PID 12506)

2069 -668-> postgres: background writer   (PID 12501)

1697 -668-> postgres: autoprewarm leader   (PID 12505)

В первой строке номер серверного процесса, подсоединенного к базе данных ela.

3) В окне psql выполните скрипт, полученный утилитой pg_dump:

ela=# \i ela.sql

SET

CREATE TABLE

ALTER TABLE

psql:ela.sql:44: server closed the connection unexpectedly

        This probably means the server terminated abnormally

        before or while processing the request.

psql:ela.sql:44: error: connection to server was lost

Соединение было потеряно.

4) Посмотрите последние сообщения ядра linux:

postgres@tantor:~$ sudo dmesg | tail -n 120

[16387.760734] Mem-Info:

[16387.760737] active_anon:342614 inactive_anon:609810 isolated_anon:0

                active_file:22 inactive_file:71 isolated_file:0

                unevictable:0 dirty:8 writeback:0

                slab_reclaimable:5664 slab_unreclaimable:13043

                mapped:15337 shmem:46435 pagetables:5001

                sec_pagetables:0 bounce:0

                kernel_misc_reclaimable:0

                free:20934 free_pcp:1 free_cma:0

[16387.760743] Node 0 active_anon:1370456kB inactive_anon:2439240kB active_file:88kB inactive_file:284kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:61348kB dirty:32kB writeback:0kB shmem:185740kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:0kB writeback_tmp:0kB kernel_stack:5696kB pagetables:20004kB sec_pagetables:0kB all_unreclaimable? no

[16387.760749] Node 0 DMA free:14848kB boost:0kB min:260kB low:324kB high:388kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15360kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB

[16387.760756] lowmem_reserve[]: 0 3385 3825 3825 3825

[16387.760770] Node 0 DMA32 free:61272kB boost:0kB min:59580kB low:74472kB high:89364kB reserved_highatomic:0KB active_anon:1077032kB inactive_anon:2365224kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:32kB present:3653568kB managed:3555048kB mlocked:0kB bounce:0kB free_pcp:4kB local_pcp:0kB free_cma:0kB

[16387.760778] lowmem_reserve[]: 0 0 439 439 439

[16387.760791] Node 0 Normal free:7616kB boost:0kB min:7736kB low:9668kB high:11600kB reserved_highatomic:0KB active_anon:105944kB inactive_anon:261496kB active_file:416kB inactive_file:0kB unevictable:0kB writepending:0kB present:524288kB managed:450384kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB

[16387.760798] lowmem_reserve[]: 0 0 0 0 0

[16387.760811] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB (U) 0*1024kB 1*2048kB (M) 3*4096kB (M) = 14848kB

[16387.760846] Node 0 DMA32: 849*4kB (UME) 615*8kB (UME) 229*16kB (UME) 278*32kB (UME) 177*64kB (UE) 67*128kB (UME) 34*256kB (UME) 15*512kB (UME) 1*1024kB (U) 0*2048kB 1*4096kB (M) = 62284kB

[16387.760893] Node 0 Normal: 230*4kB (UME) 153*8kB (UME) 107*16kB (UME) 71*32kB (UME) 25*64kB (UME) 5*128kB (M) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 8368kB

[16387.760934] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB

[16387.760937] 46530 total pagecache pages

[16387.760939] 0 pages in swap cache

[16387.760941] Free swap  = 0kB

[16387.760943] Total swap = 0kB

[16387.760946] 1048462 pages RAM

[16387.760948] 0 pages HighMem/MovableOnly

[16387.760950] 43264 pages reserved

[16387.760952] 0 pages hwpoisoned

[16387.760954] Tasks state (memory values in pages):

[16387.760956] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name

[16387.760961] [    270]     0   270    13053      288   118784        0          -250 systemd-journal

[16387.760966] [    299]     0   299     8116      608    86016        0         -1000 systemd-udevd

[16387.760971] [    426]     0   426     3359       66    49152        0         -1000 auditd

[16387.760975] [    451]     0   451    59920      269   102400        0             0 accounts-daemon

[16387.760978] [    452]     0   452      658       32    45056        0             0 acpid

[16387.760982] [    455]   109   455     2246       96    61440        0             0 avahi-daemon

[16387.760986] [    456]     0   456     1814       64    53248        0             0 cron

[16387.760989] [    457]   100   457     2605      448    61440        0          -900 dbus-daemon

[16387.760993] [    461]   109   461     2202       98    57344        0             0 avahi-daemon

[16387.760996] [    467]   995   467    60688      895   110592        0             0 polkitd

[16387.761000] [    473]     0   473     6953      256    81920        0             0 systemd-logind

[16387.761003] [    562]     0   562    67078      832   163840        0             0 NetworkManager

[16387.761007] [    578]     0   578     4923      256    77824        0             0 wpa_supplicant

[16387.761010] [    585]     0   585    80121      589   122880        0             0 ModemManager

[16387.761013] [    703]   114   703   423624     1552   208896        0             0 docker-registry

[16387.761017] [    721]     0   721   340017     3498   299008        0          -999 containerd

[16387.761020] [    786]     0   786     4954      448    81920        0         -1000 sshd

[16387.761024] [    865]     0   865      620       96    45056        0             0 fly-getexe

[16387.761027] [    891]     0   891     1630       64    49152        0             0 agetty

[16387.761031] [   1744]     0  1744     9731     4013   118784        0             0 astra-event-dia

[16387.761034] [   1768]     0  1768   384560     7030   425984        0          -500 dockerd

[16387.761038] [   1774]     0  1774   345665     5100   466944        0             0 syslog-ng

[16387.761041] [   5571]     0  5571     3670      192    73728        0             0 fly-dm

[16387.761044] [   5578]   102  5578   100486    24100   581632        0             0 Xorg

[16387.761047] [   5587]     0  5587   106865      136   106496        0             0 VBoxService

[16387.761051] [   5642]   102  5642     5567      512    81920        0           100 systemd

[16387.761054] [   5645]   102  5645    28019     1385   102400        0           100 (sd-pam)

[16387.761058] [   5670]     0  5670     6821      400   102400        0             0 fly-dm

[16387.761061] [   5682]  1000  5682     5610      576    81920        0           100 systemd

[16387.761064] [   5683]  1000  5683    28019     1385   102400        0           100 (sd-pam)

[16387.761068] [   5698]  1000  5698    13047     4141   147456        0             0 fly-wm

[16387.761071] [   5758]  1000  5758     2317      256    57344        0           200 dbus-daemon

[16387.761074] [   5791]  1000  5791    60058      832   192512        0           200 kglobalaccel5

[16387.761078] [   5798]  1000  5798     4628       98    57344        0             0 VBoxClient

[16387.761081] [   5799]  1000  5799    37695      130    69632        0             0 VBoxClient

[16387.761085] [   5811]  1000  5811     4628      130    61440        0             0 VBoxClient

[16387.761088] [   5812]  1000  5812    37687       98    73728        0             0 VBoxClient

[16387.761091] [   5817]  1000  5817     4628      130    57344        0             0 VBoxClient

[16387.761095] [   5819]  1000  5819    37816       66    69632        0             0 VBoxClient

[16387.761098] [   5822]  1000  5822     4628       98    57344        0             0 VBoxClient

[16387.761101] [   5823]  1000  5823    37748      194    73728        0             0 VBoxClient

[16387.761104] [   5837]     0  5837    58952      256    98304        0             0 upowerd

[16387.761108] [   5844]  1000  5844     2867      202    49152        0             0 ssh-agent

[16387.761111] [   5870]  1000  5870   103544     1216   258048        0             0 polkit-kde-auth

[16387.761115] [   5871]  1000  5871   125625     1600   290816        0             0 org_kde_powerde

[16387.761118] [   5873]  1000  5873 67186318      736   196608        0             0 baloo_file

[16387.761121] [   5876]  1000  5876   188404     3439   364544        0             0 fly-notificatio

[16387.761124] [   5877]  1000  5877    39425      576   163840        0             0 astra-event-wat

[16387.761128] [   5880]  1000  5880    36132      384   139264        0             0 fly-cups-watch

[16387.761131] [   5881]  1000  5881    63043     1056   208896        0             0 kscreend

[16387.761135] [   5882]  1000  5882 67439028     7809   712704        0             0 fly-start-menu

[16387.761138] [   5883]  1000  5883    67294     1184   241664        0             0 fly-shutdown-sc

[16387.761142] [   5886]  1000  5886    69346     1391   262144        0             0 fly-touchpadd

[16387.761145] [   5892]  1000  5892    77765      288   102400        0             0 at-spi-bus-laun

[16387.761148] [   5896]  1000  5896    58767      160    94208        0             0 agent

[16387.761152] [   5900]  1000  5900    90195     1472   282624        0             0 fly-notify-osd-

[16387.761155] [   5911]  1000  5911   393645     8394   720896        0             0 fly-sound-apple

[16387.761158] [   5916]  1000  5916    87538     1600   266240        0             0 fly-reflex-serv

[16387.761171] [   5921]  1000  5921     2208      160    61440        0             0 dbus-daemon

[16387.761176] [   5922]  1000  5922    14788     3917   163840        0             0 applet.py

[16387.761179] [   5929]  1000  5929     4633      256    73728        0             0 compton

[16387.761182] [   5944]  1000  5944   123154     1376   278528        0           200 kactivitymanage

[16387.761186] [   5974]  1000  5974   106825      418   106496        0             0 pulseaudio

[16387.761190] [   5976]     0  5976    99686      565   139264        0             0 udisksd

[16387.761193] [   5985]  1000  5985    60389      384   106496        0             0 gsettings-helpe

[16387.761196] [   6002]  1000  6002    41071      224    86016        0             0 at-spi2-registr

[16387.761200] [   6003]  1000  6003   161984     4706   495616        0             0 nm-applet

[16387.761203] [   6017]  1000  6017    59383      832   188416        0           200 kscreen_backend

[16387.761207] [   6067]  1000  6067    59604      224   102400        0           200 gvfsd

[16387.761211] [   6450]  1000  6450   154277     5493   385024        0             0 fly-term

[16387.761214] [   6459]  1000  6459     2225      416    57344        0             0 bash

[16387.761218] [   6835]  1000  6835     5043      320    81920        0             0 su

[16387.761221] [   6836]   113  6836     2322      448    53248        0             0 bash

[16387.761225] [   8280]     0  8280     8723     1216   102400        0             0 cupsd

[16387.761229] [  10858]  1000 10858   154156     5320   376832        0             0 fly-term

[16387.761232] [  10865]  1000 10865     2225      384    57344        0             0 bash

[16387.761236] [  12288]   113 12288    66375     8928   229376        0          -900 postgres

[16387.761239] [  12289]   113 12289    19967      637   122880        0             0 postgres

[16387.761243] [  12290]   113 12290    66442     1313   155648        0             0 postgres

[16387.761246] [  12291]   113 12291    66409     1185   151552        0             0 postgres

[16387.761249] [  12295]   113 12295    66375     1729   143360        0             0 postgres

[16387.761252] [  12296]   113 12296    66878      993   172032        0             0 postgres

[16387.761256] [  12297]   113 12297    66854      865   159744        0             0 postgres

[16387.761260] [  12499]   113 12499    57491     4352   184320        0         -1000 postgres

[16387.761263] [  12500]   113 12500    57528     1104   151552        0             0 postgres

[16387.761267] [  12501]   113 12501    57524     1008   147456        0             0 postgres

[16387.761271] [  12503]   113 12503    57524     1744   143360        0             0 postgres

[16387.761274] [  12504]   113 12504    57923     1008   163840        0             0 postgres

[16387.761277] [  12505]   113 12505    57524      742   147456        0             0 postgres

[16387.761280] [  12506]   113 12506    57635      880   143360        0             0 postgres

[16387.761283] [  12507]   113 12507    57891      912   151552        0             0 postgres

[16387.761287] [  12517]   113 12517     6495      448    94208        0             0 psql

[16387.761290] [  12518]   113 12518  1630962   789553  6533120        0             0 postgres

[16387.761293] [  12540]  1000 12540     5043      256    86016        0             0 su

[16387.761297] [  12541]   113 12541     2221      384    57344        0             0 bash

[16387.761300] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null), cpuset=tantor-se-server-16.service,mems_allowed=0,global_oom, task_memcg=/system.slice/tantor-se-server-16.service,task=postgres,pid=12518, uid=113

[16387.761329] Out of memory: Killed process 12518 (postgres) total-vm:6523848kB, anon-rss:3151300kB, file-rss:0kB, shmem-rss:6912kB, UID:113 pgtables:6380kB oom_score_adj:0

Процесс OOM kill остановил серверный процесс, который выполнял скрипт.

При срабатывании OOM-kill значение oom_score_adj никакой роли не сыграло, так как в операционной системе не было потребителей памяти, кроме процессов PostgreSQL.

Процесс OOM kill показывает размер виртуальной памяти total-vm:6523848kB. 6523848kB/4kB (размер страницы)=1630962 (в страницах) это размер памяти серверного процесса на момент его остановки.

Распределение памяти в диагностических сообщениях отображается в страницах размером  4Кб, кроме столбца pgtables_bytes:

[16387.760954] Tasks state (memory values in pages):

[16387.760956] [  pid  ]  uid  tgid total_vm     rss pgtables_bytes swapents oom_score_adj name

[16387.761290] [  12518]  113 12518  1630962  789553        6533120     0        0     postgres

===== ==== примечание ==========

Серверный процесс читал файл в свою локальную память размером 3Гб.

В виртуальной машине 4Гб и нет подкачки. По данным утилиты free доступной памяти (available) было  3027272kibi. При этом операционная система выделила 6523848kB виртуальной памяти. Если бы значение vm.overcommit_memory=2 при vm.overcommit_ratio=50, то процесс смог бы выделить только 1,5Гб памяти и получил бы отказ на попытку выделения большего количества, несмотря на то, что доступной памяти было 3Гб. При этом бы процесс OOM-kill себя бы не проявлял. Пример:

postgres=# \i ela.sql

SET

CREATE TABLE

ALTER TABLE

psql:ela.sql:44: ERROR:  out of memory

DETAIL:  Failed on request of size 2147483646 in memory context "COPY".

CONTEXT:  COPY t2, line 1

Не пытайтесь установить на виртуальной машине vm.overcommit_memory=2 без включенного swap, либо увеличения:

root@tantor:~# sysctl -w vm.overcommit_ratio=100

иначе вы не сможете дать ни одной команды:

root@tantor:~# free

         total    used     free      shared  buff/cache   available

Mem:   4020796  948788  1958532      188700     1533332     3072008

Swap:        0       0        0

root@tantor:~# sysctl -w vm.overcommit_memory=2

vm.overcommit_memory = 2

root@tantor:~# free

-bash: fork: Cannot allocate memory

root@tantor:~# reboot

-bash: fork: Cannot allocate memory

После включения swap в следующей части практики можно будет проверить, что при vm.overcommit_memory=2 OOM kill не срабатывает, вместо срабатывания процессу, выделяющему память, выдаётся ошибка.

=====================

5) Посмотрите список процессов PostgreSQL:

postgres@tantor:~$ for PID in $(pgrep "postgres"); do awk '/Pss/ {PSS+=$2} END { getline cmd < "/proc/'$PID'/cmdline"; sub("\0", " ", cmd); getline oom < "/proc/'$PID'/oom_score"; printf "%.0f -%s-> %s (PID %s) \n", PSS, oom, cmd, '$PID'}' /proc/$PID/smaps; done|sort -n -r

Список пуст, либо работают только процессы экземпляра Astralinux PostgreSQL. После того как OOM kill остановил серверный процесс, экземпляр был перезапущен в соответствии со значением параметра конфигурации restart_after_crash:

postgres=# select name, setting, context, max_val, min_val from pg_settings where name ~ 'restart';

        name         | setting | context | max_val | min_val

---------------------+---------+---------+---------+---------

 restart_after_crash | on      | sighup  |         |

(1 row)

По умолчанию параметр включён и после сбоя серверного процесса процесс postgres аварийно остановит все дочерние процессы (эквивалент остановки в режиме immediate без контрольной точки) и запустит процессы заново (эквивалент "crash recovery" - запуска экземпляра после сбоя). Если отключить параметр, то все процессы экземпляра будут принудительно остановлены, в том числе процесс postgres. Состояние кластера после остановки будет таким же как после принудительной остановки командой pg_ctl stop -m immediate:

postgres@tantor:~$ pg_controldata | grep state

Database cluster state:               in production

6) Запустите экземпляр tantor:

postgres@tantor:~$ sudo systemctl start tantor-se-server-16

Если экземпляр не запускается, можно подождать пока он остановится или дать команду pg_ctl stop -m immediate и повторить команду sudo systemctl start tantor-se-server-16

7) Этот пункт можно не выполнять. Вызвать нехватку памяти и остановку psql может простой запрос:

postgres@tantor:~$ psql

postgres=# select repeat('a', 100000000) from generate_series(1, 100);

Killed

postgres@tantor:~$ sudo dmesg | tail -5

[ 1002.311864] [   6421]   113  6421   747298   718592  5861376     0     0 psql

[ 1002.311867] [   6422]   113  6422   139618    75066   770048     0     0 postgres

[ 1002.311870] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null), cpuset=containerd.service,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-3.scope, task=psql,pid=6421,uid=113

[ 1002.311894] Out of memory: Killed process 6421 (psql) total-vm:2989192kB, anon-rss:2874368kB, file-rss:0kB, shmem-rss:0kB, UID:113 pgtables:5724kB oom_score_adj:0

В случае, если vm.overcommit_memory=2 то результат будет:

postgres=# select repeat('a', 100000000) from generate_series(1, 100);

out of memory for query result

Установить vm.overcommit_memory=2 можно только после установки vm.overcommit_ratio=100 или включения swap, иначе в виртуальной машине сразу возникнет нехватка памяти и вы не сможете дать ни одной команды.

Обычно OOM kill останавливает процесс psql, но может остановить и процессы экземпляра, что приведёт к аварийной остановке экземпляра:

postgres=# select repeat('a', 1000000000) from generate_series(1, 1000);

server closed the connection unexpectedly

        This probably means the server terminated abnormally

        before or while processing the request.

The connection to the server was lost. Attempting reset: Failed.

The connection to the server was lost. Attempting reset: Failed.

!?>

[1211447.321264] [  pid  ]   uid  tgid  total_vm      rss pgtables_bytes swapents oom_score_adj name

[1211447.321658] [ 524388]   113 524388   756951   205344  4251648   313792             0 psql

[1211447.321661] [ 524389]   113 524389   808432   716332  6062080    17383             0 postgres

[1211447.321664] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=user.slice,mems_allowed=0, global_oom,task_memcg=/system.slice/tantor-se-server-16.service,task=postgres,pid=524389,uid=113

[1211447.321735] Out of memory: Killed process 524389 (postgres) total-vm:3233728kB, anon-rss:2863536kB, file-rss:1664kB, shmem-rss:128kB, UID:113 pgtables:5920kB oom_score_adj:0

При этом экземпяр может не запуститься и его надо будет запускать командой:

sudo systemctl start tantor-se-server-16

Часть 5. Включение подкачки (swap)

1) Добавьте файл для swap размером 2Гб и включите swap:

root@tantor:~# dd if=/dev/zero of=/swap_file bs=1M count=2048

2048+0 records in

2048+0 records out

2147483648 bytes (2.1 GB, 2.0 GiB) copied, 22.3827 s, 95.9 MB/s

root@tantor:~# chmod 600 /swap_file

root@tantor:~# mkswap /swap_file

Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)

no label, UUID=4b56ea3b-ac66-46ef-801b-2aa473f27ef6

root@tantor:~# swapon /swap_file

root@tantor:~# free -m

        total        used        free      shared  buff/cache   available

Mem:    3926         881         672          19        2680        3044

Swap:   2047           0        2047

При перезагрузке виртуальной машины подкачка не будет включена автоматически.

2) Выполните скрипт дампа:

postgres=# \timing

Timing is on.

ela=# \i ela.sql

...

SET

CREATE TABLE

ALTER TABLE

COPY 1

Time: 18979.619 ms (00:18.980)

Команда COPY загружала строку 18 секунд.

3) В том же окне psql, в котором выполнялся скрипт загрузки посмотрите значение параметра enable_large_allocations:

ela=# show enable_large_allocations;

 enable_large_allocations

--------------------------

 on

(1 row)

Параметр был включён при выполнении файла ela.sql командой:

SET enable_large_allocations TO on; из этого файла.

По умолчанию параметр выключен.

4) В другом окне терминала посмотрите начало файла ela.sql:

postgres@tantor:~$ head -n 20 ela.sql

--

-- PostgreSQL database dump

SET statement_timeout = 0;

SET lock_timeout = 0;

SET idle_in_transaction_session_timeout = 0;

SET transaction_timeout = 0;

SET client_encoding = 'UTF8';

SET standard_conforming_strings = on;

SELECT pg_catalog.set_config('search_path', '', false);

SET check_function_bodies = false;

SET xmloption = content;

SET client_min_messages = warning;

SET row_security = off;

SET enable_large_allocations TO on;

Значение параметра enable_large_allocations было выгружено утилитой pg_dump.

5) посмотрите характеристики параметра enable_large_allocations:

ela=# select * from pg_settings where name like '%large%' \gx

-[ RECORD 1 ]---+--------------------------------------------

name            | enable_large_allocations

setting         | on

unit            |

category        | Resource Usage / Memory

short_desc      | Sets whether to use large memory buffers - greater than 1 Gb, up to 2 Gb

extra_desc      |

context         | superuser

vartype         | bool

source          | session

min_val         |

max_val         |

enumvals        |

boot_val        | off

reset_val       | off

sourcefile      |

sourceline      |

pending_restart | f

Параметр может устанавливаться на разных уровнях, в том числе на уровне сессии.

Параметр увеличивает размер строкового буфера с 1Гб до 2Гб. Могут выгружаться строки размером до 2Гб. Строки больше 2Гб выгружаться не будут.

Часть 6. Страничный кэш

1) Откройте или переключитесь в терминал с правами root:

postgres@tantor:~$ su -

Password: root

2) Выполните команды:

root@tantor:~# cat /proc/meminfo | grep Cached

Cached:          1367440 kB

SwapCached:        49328 kB

root@tantor:~# free

        total      used      free    shared  buff/cache   available

Mem:  4020792    605576   2250740     36796     1452148     3415216

Swap: 2097148    508696   1588452

По умолчанию команда free показывает значения в kibibytes (число байт поделенных на 1024 1024). Для вывода в килобайтах нужно использовать параметр --kylo или --si (число байт поделенных на 1000). Разница заметная, во втором разряде слева (36820 37703):

root@tantor:~# free

               total        used        free      shared  buff/cache   available

Mem:         4020792      575192     3493796       36820      215152     3445600

Swap:        2097148      507160     1589988

root@tantor:~# free --si

               total        used        free      shared  buff/cache   available

Mem:         4117291      589750     3576889       37703      220323     3527540

Swap:        2147479      519331     1628147

root@tantor:~# free --bytes

               total        used        free      shared  buff/cache   available

Mem:      4117291008   588890112  3577745408    37703680   220340224  3528400896

Swap:     2147479552   519331840  1628147712

Cached входит в buff/cache , разница (с учётом разных единиц измерения) это значение buff.

3) Сделайте чистые блоки страничного кэша свободными:

root@tantor:~# echo 1 > /proc/sys/vm/drop_caches

root@tantor:~# cat /proc/meminfo | grep Cached

Cached:           156684 kB

SwapCached:        49332 kB

root@tantor:~# free

        total      used      free      shared  buff/cache   available

Mem:  4020792    536520   3530520       36800      184272     3484272

Swap: 2097148    508696   1588452

Значения Cached и buff/cache уменьшились на 1,2Гб.  Значение free увеличилось.

4) Посмотрите число страниц разного размера:

root@tantor:~# cat /proc/buddyinfo

Node 0, zone    DMA      0      0      0      0      0      0      0      1      0      1      3

Node 0, zone  DMA32   1670   1466    868    707    734    503    294    166    111    111    648

Node 0, zone Normal    444    283    262     98     31     10      3     39     32      2      1

Node 0 - номер физического процессора. Зоны:

 zone DMA    - виртуальная память со смещением от нуля до 16Мб

 zone DMA32  - от 16Мб до 4Гб

 zone Normal - от 4Гб и до 2^48 (2 в степени 48)

Каждая зона делится на части адресного пространства памяти размером (4096 байт *2^n):

                         4Кб   8Кб   16Кб    32Кб   64Кб 128Кб  256Кб  512Кб    1Мб     2Мб   4Мб

 5) Посмотрите индекс фрагментации наборов страниц:

root@tantor:~# cat /sys/kernel/debug/extfrag/extfrag_index

Node 0, zone    DMA -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000

Node 0, zone  DMA32 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000

Node 0, zone Normal -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000  0.964  0.982  0.991  0.996

Дефрагментация запустится автоматически при уменьшении свободной памяти ниже vm.min_free_kbytes=67584 или значения vm.watermark_scale_factor. Значение по умолчанию vm.watermark_scale_factor=10, что означает 0.1% от размера свободной физической памяти. Эти значения слишком малы и дефрагментация запускается в крайнем случае. Рекомендации по установке значений даны в теоретической части главы.

6) Запустите дефрагментацию вручную:

root@tantor:~# echo 1 > /proc/sys/vm/compact_memory

7) Проверьте результат дефрагментации (как изменился индекс фрагментации):

root@tantor:~# cat /sys/kernel/debug/extfrag/extfrag_index

Node 0, zone    DMA -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000

Node 0, zone  DMA32 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000

Node 0, zone Normal -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000 -1.000  0.991

8) Посмотрите сколько грязных 4-килобайтных страниц в страничном кэше linux:

root@tantor:~# cat /proc/vmstat | grep dirty

nr_dirty 126

nr_dirty_threshold 176446

nr_dirty_background_threshold 88115

9) Выполните команду sync, которая сбрасывает грязные страницы на диск:

root@tantor:~# sync

root@tantor:~# cat /proc/vmstat | grep dirty

nr_dirty 0

nr_dirty_threshold 174962

nr_dirty_background_threshold 87374

root@tantor:~# cat /proc/vmstat | grep dirty

nr_dirty 2

nr_dirty_threshold 175071

nr_dirty_background_threshold 87428

По команде sync сбрасываются все грязные страницы и nr_dirty в какой-то момент становится равен 0, но при работе процессов станицы постоянно грязнятся и значение почти сразу увеличивается.

10) Посмотрите значения параметров, относящихся к работе с грязными страницами:

root@tantor:~# sysctl -a | grep dirty

vm.dirty_background_bytes = 0

vm.dirty_background_ratio = 10

vm.dirty_bytes = 0

vm.dirty_expire_centisecs = 3000

vm.dirty_ratio = 20

vm.dirty_writeback_centisecs = 500

vm.dirtytime_expire_seconds = 43200

Длительность удержания страницы с момента изменения определяется параметром:

vm.dirty_expire_centisecs - сколько буфер может быть грязным, прежде чем будет помечен для записи, по умолчанию 3000 (30 секунд), можно поменять на 500 (5 секунд).

Также на удержание влияет параметр: vm.dirty_writeback_centisecs - период ожидания между записями на диск, по умолчанию 500 (5 секунд), можно уменьшить до 250 (2,5 секунды). Рекомендуемые значения остальных параметров:

vm.dirty_ratio = 10

vm.dirty_background_ratio = 3

Эти параметры можно не менять, так как страницы кэша linux на запись посылают процессы экземпляра вызовом fdatasync по WAL, fsync по файлам табличных пространств в конце контрольной точки и делают это для отказоустойчивости (защиты от пропадания питания). Этими параметрами можно сгладить пиковую нагрузку, которая возникает в конце выполнения контрольной точки. Но даже для сглаживания нагрузки имеются параметры PostgreSQL  checkpoint_flush_after и bgwriter_flush_after, которые также установлены в оптимальные для обычной нагрузки и обычного оборудования (HDD и SSD) значений.

11) Посмотрите параметры конфигурации PostgreSQL, влияющие на удержание грязных страниц страничного кэша:

postgres=# \dconfig *flush*

List of configuration parameters

       Parameter        | Value

------------------------+-------

 backend_flush_after    | 0

 bgwriter_flush_after   | 512kB

 checkpoint_flush_after | 256kB

 wal_writer_flush_after | 1MB

(4 rows)

Эти параметры ограничивают объём грязных страниц в страничном кэше linux и уменьшает вероятность затормаживания при выполнении fsync в конце контрольной точки или когда linux сбрасывает грязные страницы на диск в соответствии с параметрами из предыдущего пункта. Если параметры предыдущего пункта допускают накопление большого количества грязных страниц, могут возникать относительно длительные задержки, что делает работу экземпляра менее "гладкой".

12) Выполните команду:

postgres=# alter system set shared_preload_libraries = pg_stat_statements, pg_wait_sampling, pg_stat_kcache, pg_qualstats, pg_store_plans, pg_prewarm;

13) перегрузите экземпляр, так как изменение параметра применится только после перезапуска экземпляра:

root@tantor:~# systemctl restart tantor-se-server-16

Эта команда загрузит при запуске экземпляра разделяемые библиотеки в память процессов. Загруженная библиотека  pg_wait_sampling понадобится в следующей практике.

Практика к главе 3

Часть 1. Стандартный тест pgbench

1) В обсуждении https://www.postgresql.org/message-id/flat/53FD5D6C.40105%40catalyst.net.nz приводился пример теста pgbench с включенным HyperThread и выключенным на 4-ядерном процессоре. Посмотрим на каком числе клиентов достигается максимальный tps на вашей виртуальной машине. Создайте тестовые таблицы со scale factor 300 как в тесте по ссылке:

postgres@tantor:~$ pgbench -i -s 300

dropping old tables...

creating tables...

generating data (client-side)...

30000000 of 30000000 tuples (100%) done (elapsed 50.12 s, remaining 0.00 s)

vacuuming...

creating primary keys...

done in 78.79 s (drop tables 0.02 s, create tables 0.01 s, client-side generate 50.79 s, vacuum 2.46 s, primary keys 25.52 s).

Таблицы создавались 78 секунд.

2) Выполните 15-секундные тесты с разным числом соединений:

postgres@tantor:~$ pgbench -c 64 -T 15 2> /dev/null | grep tps

tps = 1773.570100 (without initial connection time)

postgres@tantor:~$ pgbench -c 100 -T 15 2> /dev/null | grep tps

tps = 1646.101354 (without initial connection time)

postgres@tantor:~$ pgbench -c 32 -T 15 2> /dev/null | grep tps

tps = 1685.528291 (without initial connection time)

postgres@tantor:~$ pgbench -c 16 -T 15 2> /dev/null | grep tps

tps = 1550.934797 (without initial connection time)

Максимальный tps достигается при 64 соединениях.

3) Повторите тест:

postgres@tantor:~$ pgbench -c 64 -T 15 2> /dev/null | grep tps

tps = 1676.523228 (without initial connection time)

postgres@tantor:~$ pgbench -c 100 -T 15 2> /dev/null | grep tps

tps = 1572.848543 (without initial connection time)

postgres@tantor:~$ pgbench -c 32 -T 15 2> /dev/null | grep tps

tps = 1694.453483 (without initial connection time)

postgres@tantor:~$ pgbench -c 16 -T 15 2> /dev/null | grep tps

tps = 1477.982431 (without initial connection time)

Значения tps немного понизились во всех тестах. Тест по умолчанию вносит изменения в строки таблиц и индексные записи. Повторные запуски тестов дают стабильно худшие результаты. Тест с изменением таблиц нельзя использовать без пересоздания таблиц.

В обсуждении, на которое была приведена ссылка, в зависимости от процессора максимальный tps достигался на 256, 96, 48 соединениях на процессорах с разным числом ядер. Точность до ближайшей степени двойки: приведено значение 256, а  реальный максимум может быть в диапазоне от 140 до 350.

4) Можно использовать select-only тест, который не меняет данные. Этот тест зависит от заполнения кэша буферов и первые выполнения теста имеют меньший tps, чем последующие. Максимальный tps стал достигаться на 16 соединениях.

postgres@tantor:~$ pgbench -b select-only -c 64 -T 15  2> /dev/null | grep tps

tps = 8687.455945 (without initial connection time)

postgres@tantor:~$ pgbench -b select-only -c 32 -T 15  2> /dev/null | grep tps

tps = 9112.963307 (without initial connection time)

postgres@tantor:~$ pgbench -b select-only -c 16 -T 15  2> /dev/null | grep tps

tps = 9611.093353 (without initial connection time)

postgres@tantor:~$ pgbench -b select-only -c 8 -T 15  2> /dev/null | grep tps

tps = 9548.481330 (without initial connection time)

postgres@tantor:~$ pgbench -b select-only -c 4 -T 15  2> /dev/null | grep tps

tps = 7841.653129 (without initial connection time)

postgres@tantor:~$ pgbench -b select-only -c 100 -T 15  2> /dev/null | grep tps

tps = 8780.049265 (without initial connection time)

postgres@tantor:~$ pgbench -b select-only -c 64 -T 15  2> /dev/null | grep tps

tps = 9200.191422 (without initial connection time)

postgres@tantor:~$ pgbench -b select-only -c 32 -T 15  2> /dev/null | grep tps

tps = 9499.272270 (without initial connection time)

postgres@tantor:~$ pgbench -b select-only -c 16 -T 15  2> /dev/null | grep tps

tps = 9820.530795 (without initial connection time)

postgres@tantor:~$ pgbench -b select-only -c 8 -T 15  2> /dev/null | grep tps

tps = 9637.473378 (without initial connection time)

postgres@tantor:~$ pgbench -b select-only -c 4 -T 15  2> /dev/null | grep tps

tps = 7825.917563 (without initial connection time)

Часть 2. Привязка процессов к ядру процессора

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

1) Посмотрите число ядер процессоров:

postgres@tantor:~$ nproc

4

2) Выполните команду, чтобы посмотреть привязку потоков ядра linux. У демона потоков ядра kthreadd идентификатор процесса pid=2:

for tid in $(pgrep -w 2 | tr '\n' ' '); do

 ps --no-headers -q "${tid}" -o pid -o user -o psr -o cmd;

 taskset -cp "${tid}";

done

     26 root       2 [cpuhp/2]

pid 26's current affinity list: 2

     27 root       2 [idle_inject/2]

pid 27's current affinity list: 2

     28 root       2 [migration/2]

pid 28's current affinity list: 2

     29 root       2 [ksoftirqd/2]

pid 29's current affinity list: 2

     73 root       3 [scsi_eh_2]

pid 73's current affinity list: 0-3

    137 root       2 [kworker/2:1H-kblockd]

...

Часть потоков ядра linux привязана к каждому из ядер cpu. kernel threads используются linux для выполнения фоновых операций.

3) Выполните команду, чтобы посмотреть привязку процессов с именем postgres:

for tid in $(pgrep postgres | tr '\n' ' '); do

 ps --no-headers -q "${tid}" -o pid -o user -o psr -o cmd;

 taskset -cp "${tid}";

done

 126673 postgres   1 /opt/tantor/db/16/bin/postgres -D /var/lib/postgresql/tantor-se-16/data

pid 126673's current affinity list: 0-3

 126674 postgres   1 postgres: checkpointer 

pid 126674's current affinity list: 0-3

 126675 postgres   3 postgres: background writer

pid 126675's current affinity list: 0-3

 126677 postgres   0 postgres: walwriter

pid 126677's current affinity list: 0-3

 126678 postgres   1 postgres: autovacuum launcher

pid 126678's current affinity list: 0-3

 126679 postgres   3 postgres: autoprewarm leader

pid 126679's current affinity list: 0-3

 126680 postgres   0 postgres: pg_wait_sampling collector

pid 126680's current affinity list: 0-3

 126681 postgres   3 postgres: logical replication launcher

pid 126681's current affinity list: 0-3

...

По умолчанию у процессов postgres привязки к cpu нет. В примере процессы могут быть назначены на любое доступное ядро: 0,1,2,3.

4) Привяжите процесс checkpointer к ядру 1:

postgres@tantor:~$ taskset -p 12290

pid 12290's current affinity list: 0-3

pid 12290's new affinity list: 1

5) Уберите привязку процесса checkpointer к ядру 1:

postgres@tantor:~$ taskset -p -c 0-999 12290

pid 12290's current affinity list: 1

pid 12290's new affinity list: 0-3

Опции убрать привязку нет, можно только указать новую привязку, в которой перечислить все ядра. Самое простое - указать диапазон начиная с 0 до максимального числа ядер или выше.

Часть 3. Переключения контекстов выполнения ("VCX/ICX")

1) Посмотрите частоту переключений контекстов выполнения процессов postgres:

postgres@tantor:~$ pidstat -w -l -C postgres

Linux 6.6.28-1-generic (tantor)      _x86_64_        (4 CPU)

02:25:37 PM   UID       PID   cswch/s nvcswch/s  Command

02:25:37 PM   113      1405      0.10      0.02  /opt/tantor/db/16/bin/postgres -D /var/lib/postgresql/tantor-se-16/data

02:25:37 PM   113      1485      0.07      0.01  /usr/lib/postgresql/15/bin/postgres -D /var/lib/postgresql/15/main -c config_file=/etc/postgresql/15/main/postgresql.conf

02:25:37 PM   113      1586      0.01      0.00  postgres: checkpointer

02:25:37 PM   113      1587      0.39      0.00  postgres: background writer

02:25:37 PM   113      1620      0.02      0.00  postgres: 15/main: logger

02:25:37 PM   113      1693      0.26      0.00  postgres: walwriter

02:25:37 PM   113      1694      0.10      0.01  postgres: autovacuum launcher

02:25:37 PM   113      1695      0.02      0.04  postgres: autoprewarm leader

02:25:37 PM   113      1696     94.35      0.11  postgres: pg_wait_sampling collector

02:25:37 PM   113      1698      0.01      0.00  postgres: logical replication launcher

02:25:37 PM   113      1751      0.01      0.00  postgres: 15/main: checkpointer

02:25:37 PM   113      1752      0.39      0.00  postgres: 15/main: background writer

02:25:37 PM   113      1817      0.26      0.00  postgres: 15/main: walwriter

02:25:37 PM   113      1818      0.05      0.01  postgres: 15/main: autovacuum launcher

02:25:37 PM   113      1819      0.01      0.00  postgres: 15/main: logical replication launcher

02:25:37 PM     0      7653      0.00      0.00  pidstat -w -l -C postgres

Если экземпляр работал больше часа или операционная система перегружалась, то pidstat покажет, что у процесса pg_wait_sampling collector контексты переключаются с частотой ~100 (в примере 94.46) в секунду. Этот процесс занимается сбором статистики, опрашивая процессы экземпляра. Большинство циклов опроса завершается быстро, процесс освобождает ядро и статистика cswch увеличивается. Jiffy - единица времени, которая представляет количество прерываний таймера от загрузки linux. При каждом прерывании таймера количество Jiffy  увеличивается на единицу. Связь между Jiffy и секундами определяется константой HZ в ядре linux. Это значение определяет количество Jiffies в секунду. В linux до версии 2.4 частота тика между Jifies была 10 мс. Начиная с linux 2.4 тик стал 1мс. Начиная с версии ядра 3.10 частота тика варьируется и может быть замедлена, если при компиляции ядра установить CONFIG_NO_HZ_FULL=y. В этом случае прерывания таймера отключаются не только для простаивающих процессоров, но при исполнении кода, если на ядре нет задач в очереди на исполнение.

2) Посмотрите текущее число переключений контекста выполнения для процесса pg_wait_sampling collector. С интервалом в ~секунду выполните команду:

postgres@tantor:~$ grep ctxt /proc/1696/status

voluntary_ctxt_switches:        304222

nonvoluntary_ctxt_switches:     334

postgres@tantor:~$ grep ctxt /proc/1696/status

voluntary_ctxt_switches:        304343

nonvoluntary_ctxt_switches:     335

Число произвольных переключений контекста по этой кумулятивной статистике около 100 в секунду. Непроизвольные переключения тоже присутствуют. Данные совпадают с результатом pidstat.  Процесс pg_wait_sampling collector опрашивает состояние всех процессов экземпляра с частотой, заданной параметром 

pg_wait_sampling.history_period или pg_wait_sampling.profile_period. Значения этих параметров по умолчанию 10 миллисекунд, что соответствует частоте 100 раз в секунду.

3) Если рестартовать экземпляр, то после перезапуска значения cswch/s будут постепенно увеличиваться. Выполните в терминале root:

root@tantor:~# systemctl restart tantor-se-server-16

root@tantor:~# pidstat -w -l -C postgres | grep sampling

02:36:31 PM   113      7728      4.25      0.00  postgres: pg_wait_sampling collector

Период усреднения - с момента запуска операционной системы, что делает использование утилиты pidstat бессмысленным.

Для получения осмысленного результата стоит пользоваться кумулятивными статистиками. До 10 в секунду при реальной частоте 100 в секунду значение дойдёт примерно через 7 минут. При этом кумулятивная статистика частоту показывает корректно 100 раз в секунду. Выполните два раза команду с интервалом примерно в секунду:

root@tantor:~# grep ctxt /proc/7728/status

voluntary_ctxt_switches:        13433

nonvoluntary_ctxt_switches:     10

root@tantor:~# grep ctxt /proc/7728/status

voluntary_ctxt_switches:        13551

nonvoluntary_ctxt_switches:     11

4) Для мониторинга переключений контекстов по всей операционной системе можно использовать утилиту perf:

root@tantor:~# perf stat -a

^C

 Performance counter stats for 'system wide':

         68,010.80 msec cpu-clock                        #    2.000 CPUs utilized

             9,885      context-switches                 #  145.345 /sec

               250      cpu-migrations                   #    3.676 /sec

             2,774      page-faults                      #   40.788 /sec

   <not supported>      cycles

   <not supported>      instructions

   <not supported>      branches

    <not supported>      branch-misses

      34.005359735 seconds time elapsed

Утилита с такими параметрами работает до ее остановки комбинацией клавиш <ctrl+c>.

Утилита выдаёт правильные значения: 145 переключений контекстов в секунду. Недостаток: не выдаёт число involuntary context switches.

Для сбора такой же статистики по отдельному процессу используется команда:

perf stat -p номер_процесса

Часть 4. Мониторинг нагрузки на процессор

1) Установите, если не установлены, утилиты atop и htop в терминале под пользователем root:

root@tantor:~# apt update

Hit:1 cdrom://OS Astra Linux 1.8.1.6  DVD 1.8_x86-64 InRelease

Hit:2 https://download.astralinux.ru/astra/stable/1.8_x86-64/repository-extended 1.8_x86-64 InRelease

Ign:3 https://download.astralinux.ru/astra/stable/1.8_x86-64/repository-devel 1.8_x86-64 InRelease

Hit:4 https://download.astralinux.ru/astra/stable/1.8_x86-64/repository-main 1.8_x86-64 InRelease

Err:5 https://download.astralinux.ru/astra/stable/1.8_x86-64/repository-devel 1.8_x86-64 Release

  404  Not Found [IP: 130.193.50.59 443]

Reading package lists... Done

E: The repository 'https://download.astralinux.ru/astra/stable/1.8_x86-64/repository-devel 1.8_x86-64 Release' does not have a Release file.

N: Updating from such a repository can't be done securely, and is therefore disabled by default.

N: See apt-secure(8) manpage for repository creation and user configuration details.

root@tantor:~# apt install htop -y

Reading package lists... Done

Building dependency tree... Done

Reading state information... Done

htop is already the newest version (3.2.2-2+b1).

0 upgraded, 0 newly installed, 0 to remove and 603 not upgraded.

root@tantor:~# apt install atop -y

Reading package lists... Done

Building dependency tree... Done

Reading state information... Done

atop is already the newest version (2.8.1-1+b1).

0 upgraded, 0 newly installed, 0 to remove and 603 not upgraded.

2) Удалите директорию, если она есть и запустите в терминале пользователя postgres утилиту pg_basebackup с замедлением резервирования до 50 килобайт в секунду:

postgres@tantor:~$ rm -rf /var/lib/postgresql/backup/1

postgres@tantor:~$ time pg_basebackup -c fast -D $HOME/backup/1 -P -r 50k

Утилита начнет резервирование. Окно терминала с работающей утилитой не нужно закрывать.

3) В другом терминале, под пользователем root, выполните команду top:

root@tantor:~# ps -e -o pcpu,vsz,rss,pss,cls,psr,rops,wops,s,cmd --sort -pcpu | head -2

%CPU    VSZ   RSS   PSS CLS PSR  ROPS  WOPS S CMD

99.9  24608  8576  1486  TS   1    43  8385 R pg_basebackup -c fast -D /var/lib/postgresql/backup/1 -P -r 1M

Какая проблема видна в выводе команды?

Загрузка процессора 99.9%

Дальше последовательно посмотрите результат вывода утилит top, atop, htop, чтобы понять какой утилитой удобнее выявлять проблему нагрузки на процессор.

4) Запустите утилиту top:

root@tantor:~# top

Какую нагрузку на процессор показывает утилита?

В столбце %CPU утилита показывает 100.0.

В поле %Cpu(s): 25.5 us, 0.5 sy.

5) Нажмите на клавиатуре клавишу 1. Вывод утилиты изменится, она покажет нагрузку отдельно по ядрам процессора:

Нагрузка на 3 ядре: %Cpu3: 100.0 us, 0.0 sy и это реальная нагрузка.

Это означает что третье ядро полностью нагружено, причем отношение USER/SYS 100:0.

Посмотрите справа вверху на метрику load average: 1.01, 1.00, 0.87

Метрика также присутствует в файле  /proc/loadavg и выводе команды uptime:

root@tantor:~# uptime

 09:39:07 up 18:01,  3 users,  load average: 0.19, 0.20, 0.18

Это метрика показывает число активных (работающих или желающих работать) процессов, усредненная на интервалах 1, 5, 15 минут. В метрике учитываются процессы, потребляющие процессорное время и ожидающие получения результата от дисковой подсистемы. Процессы, ожидающие поступления данных с сетевых интерфейсов в метрике не учитываются.

Если число активных процессов меньше числа ядер, то если все процессы активны, они не будут испытывать недостатка в вычислительных ресурсах. Но число процессов обычно больше, чем число ядер. Если появляется большое число активных процессов, то доступ к ядрам делится между активными процессами. При работе СУБД процессор обычно не является узким местом (дефицитным ресурсом) и метрика не указывает на какие-либо проблемы. Метрика может быть полезна тем, что сравнив три числа можно оценить, является ли текущая нагрузка пиковой или постоянной. Если создать большое число активных процессов, например, запустив в отдельном терминале утилиту pgbench с числом сессий 90:

postgres@tantor:~$ pgbench -c 90 -j 90 -T 10000 -P 5

pgbench (16.2)

starting vacuum...end.

progress: 5.0 s, 892.4 tps, lat 105.630 ms stddev 87.005, 0 failed

progress: 10.0 s, 413.0 tps, lat 237.783 ms stddev 257.410, 0 failed

...

По умолчанию параметр конфигурации max_connections=100, поэтому число сессий выбрано 90.

Дальше можно посмотреть вывод утилиты top суммарно по всем процессорам и по отдельности и можно будет увидеть, что если load превышает число ядер, то суммарная нагрузка на процессора становится полезной. Если суммарная нагрузка %Cpu(s) больше 90%, то процессор является узким местом. При долговременной нагрузке граница 90% (с целью определения дефицитности ресурса) может варьироваться от 85% до 95% в зависимости от доли ожидания дискового ввода-вывода.

Пример суммарной нагрузки - присутствует метрика %Cpu(s):

Средняя загрузка по всем ядрам: 100-28.6=71.4% процессор не является узким местом.

Однако, если снизить число серверных процессов с 90 до ~50 для четырех ядер в данном примере, то будут достигнуты максимальные tps. При большой загрузке процессоров переключения контекстов, а под сильно большой ожидания получения таймслотов на ядре процессора добавляют задержку. Накладные расходы на переключения контекстов (замена содержимого кэшей ядра) напрямую измерить нельзя.

Пример нагрузки по процессорам - метрики %Cpu0 ... %Cpu3 :

Нагрузка по процессорам полезна при load меньшим, чем число ядер и для определения нет ли процессов, которые загружают ядро на 100% и именно для этого процесса (потока который не может распаралеллиться и обслуживаться несколькими ядрами) процессор является узким местом.

Закройте утилиту top, нажав на клавиатуре клавишу q.

Если работает pgbench, то его можно остановить комбинацией клавиш <ctrl+c>.

6) Запустите утилиту mpstat:

root@tantor:~# mpstat -n

Linux 6.6.28-1-generic (tantor)       _x86_64_        (4 CPU)

08:40:00 PM NODE    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle

08:40:00 PM  all    5.71    0.05    0.39    0.42    0.00    0.46    0.00    0.00    0.00   92.97

Посмотрите удобно ли наблюдать этой утилитой нагрузку одного ядра на 100% и отношение USER/SYS?

7) Запустите утилиту atop:

root@tantor:~# atop

Зная реальную нагрузку найдите в окне утилиты atop нагрузку на процессор, которую даёт утилита pg_basebackup.

Через 10 секунд окно поменяется и выдаст другие цифры:

Отображаемые данные обновляются по умолчанию раз в 10 секунд.

Отметьте для себя: удобно ли просматривать нагрузку и видно ли отношение USER/SYS.

Закройте утилиту, нажав на клавиатуре клавишу q.

8) Запустите утилиту htop:

root@tantor:~# htop

Отметьте для себя: удобно ли просматривать нагрузку и видно ли отношение USER/SYS в утилите htop.

Нагрузка на ядра процессоров выдаются символами псевдографики.

Закройте утилиту, нажав на клавиатуре клавишу q.

Цель этой части практики выбрать утилиту, с помощью которой удобнее просматривать нагрузку на ядра процессоров.

Часть 5. Сбор статистик в файл и его просмотр утилитой atop

1) Утилита atop позволяет собирать и записывать статистики в бинарный файл. Файл можно "проигрывать" на другом хосте и это удобно для анализа. Минимальная частота сбора статистик 1 раз в секунду, по умолчанию раз в 10 секунд. Объем собираемых данных большой, но можно параметрами настроить какие статистики собирать для уменьшения размера файла.

2) Запустите сбор статистик с интервалом в 1 секунду в файл /atop.record :

root@tantor:~# atop -w /atop.record 1

Терминал не вернёт промпт, это нормально. Если файл существовал, то утилита не сотрёт собранные данные, а начнет дописывать данные в конец файла.

3) В отдельном терминале пользователя root запустите утилиту atop в режиме просмотра бинарного файла:

astra@tantor:~$ atop -r /atop.record

Используйте клавиши на клавиатуре 't' и 'T' (<Shift+t>) для перехода к следующему и возврату к предыдущему интервалу. В первой строке, выдаваемой утилитой показывается время на которое были собраны статистики. Для выхода из утилиты нажмите клавишу 'q'.

4) В терминале, где запущена утилита нажмите <ctrl+c>:

root@tantor:~# atop -w /atop.record 1

^C

root@tantor:~#

Утилита остановится. Файл можно повторно просматривать утилитой atop. Можно скопировать файл на другой хост и просматривать файл на другом хосте.

5) Удалите файл /atop.record:

root@tantor:~# rm -f /atop.record

6) Если утилита pg_basebackup не закончила резервирование, прервите работу утилиты, нажав на клавиатуре комбинацию клавиш <ctrl+c>:

postgres@tantor:~$ time pg_basebackup -c fast -D $HOME/backup/1 -P -r 50k

^C3781/902114 kB (68%), 0/1 tablespace

real    19m57.486s

user    19m53.055s

sys      0m3.413s

Обратите внимание, что утилита time выдала корректные значения USER/SYS.

7) Удалите директорию c бэкапом:

postgres@tantor:~$ rm -rf /var/lib/postgresql/backup/1

Часть 6. Источник времени linux

1) Посмотрите список источников, которые linux счел возможными к использованию:

postgres@tantor:~$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource

tsc acpi_pm

2) Посмотрите, какой источник времени используется:

postgres@tantor:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource

tsc

3) Создайте текстовый файл с названием clock_timing.c и содержимым:

#include <time.h>

int main()

{

 int rc;

 long i;

 struct timespec ts;

 for(i=0; i<10000000; i++) rc = clock_gettime(CLOCK_MONOTONIC, &ts);

 return 0;

}

4) Скомпилируйте файл:

postgres@tantor:~$ gcc clock_timing.c -o clock_timing -lrt

5) Программа 10 миллионов раз считывает показатель времени. Измерьте время выполнения программы:

postgres@tantor:~$ time ./clock_timing

real        0m13,967s

user        0m13,938s

sys        0m0,008s

Утилита time удобна для получения времени выполнения программ. Она возвращает реальные USER/SYS и общее время выполнения программы.

6) Выполните команду pg_test_timing:

postgres@tantor:~$ pg_test_timing 

Testing timing overhead for 3 seconds.

Per loop time including overhead: 3931.22 ns

Histogram of timing durations:

  < us   % of total      count

     1      0.02475        497

     2     60.52305    1215427

     4     39.20322     787281

     8      0.02480        498

    16      0.08869       1781

    32      0.06384       1282

    64      0.05348       1074

   128      0.01215        244

   256      0.00388         78

   512      0.00065         13

  1024      0.00060         12

  2048      0.00030          6

  4096      0.00035          7

  8192      0.00020          4

 16384      0.00005          1

Программа pg_test_timing стандартно поставляется с PostgreSQL, используется для измерения скорости источника времени, выдаёт распределение выдаваемых источником времени  значений.

Максимум распределения на ~2.5 миллисекундах.

Символами "us" обозначаются миллисекунды (µs). Колебания выдачи времени в приведённом выводе утилиты не меньше 1 миллисекунды. Это значит, что числа менее 1 миллисекунды являются случайными.

Программа pg_test_timing даёт более детальную информацию, чем clock_timing.c. Программа clock_timing.c приведена для иллюстрации простоты создания собственных тестов на языке С. На языке C написан код PostgreSQL.

7) Создайте таблицу для теста, выполнив команды в psql:

postgres=# drop table if exists t;

create table t(pk bigserial, c1 text default 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');

insert into t select *, 'a' from generate_series(1, 100000);

DROP TABLE

CREATE TABLE

INSERT 0 100000

8) Выполните команду:

postgres=# explain analyze select count(pk) from t;

                                       QUERY PLAN

----------------------------------------------------------------------------------------------

 Aggregate  (cost=1352.50..1352.51 rows=1 width=8) (actual time=307.270..307.276 rows=1 loops=1)

   ->  Seq Scan on t  (cost=0.00..1190.20 rows=64920 width=8) (actual time=0.017..152.937 rows=100000 loops=1)

 Planning Time: 0.038 ms

 Execution Time: 307.383 ms

(4 rows)

Время выполнения команды 307 миллисекунд.

9) Замените источник времени tsc на acpi_pm. В консоли root выполните команду:

root@tantor:~# echo acpi_pm>/sys/devices/system/clocksource/clocksource0/current_clocksource

Команду можно выполнить, не переключаясь в консоль root:

postgres@tantor:~$

sudo sh -c 'echo acpi_pm>/sys/devices/system/clocksource/clocksource0/current_clocksource'

10) Выполните команду:

postgres=# explain analyze select count(pk) from t;

                                 QUERY PLAN        

-----------------------------------------------------------------------------

 Aggregate  (cost=1352.50..1352.51 rows=1 width=8) (actual time=805.557..805.573 rows=1 loops=1)

   ->  Seq Scan on t  (cost=0.00..1190.20 rows=64920 width=8) (actual time=0.015..399.513 rows=100000 loops=1)

 Planning Time: 0.148 ms

 Execution Time: 805.792 ms

(4 rows)

Время выполнения команды увеличилось с 0.3 до 0.8 секунд.

На время выполнения простой команды explain analyze заметно повлияло изменение источника времени.

11) Измерьте время выполнения программы:

postgres@tantor:~$ time ./clock_timing

real    0m38.669s

user    0m16.329s

sys     0m22.331s

Время выполнения заметно увеличилось -  почти в 3 раза. Пропорция USER/SYS изменилась с 1:1 на 8:11. Можно убедиться, что пропорция USER/SYS может использоваться для выявления неэффективного кода. Перекос пропорции в сторону SYS (отклонение от пропорции 60:40) указывает на то, что код ядра, выдающий время, неэффективен.

12) Выполните команду pg_test_timing:

postgres@tantor:~$ pg_test_timing 

Testing timing overhead for 3 seconds.

Per loop time including overhead: 3889.59 ns

Histogram of timing durations:

  < us   % of total      count

     1      0.00389         30

     2      0.00052          4

     4     25.33700     195422

     8     74.23528     572570

    16      0.21470       1656

    32      0.08376        646

    64      0.10411        803

   128      0.01776        137

   256      0.00117          9

   512      0.00013          1

  1024      0.00052          4

  2048      0.00052          4

  4096      0.00039          3

  8192      0.00000          0

 16384      0.00026          2

Максимум распределения скорости выдачи временной метки с источником времени acpi_pm стал ~7 миллисекунд, а с источником времени tsc был ~ 2.5 миллисекунды.

13) Верните источник времени tsc:

root@tantor:~# echo tsc>/sys/devices/system/clocksource/clocksource0/current_clocksource

или

postgres@tantor:~$

sudo sh -c 'echo tsc>/sys/devices/system/clocksource/clocksource0/current_clocksource'

По умолчанию, источник времени каждый раз выбирается linux при загрузке. Есть вероятность, что будет произвольно выбран медленный источник времени. Такое может произойти и после обновления ядра linux. Вероятность увеличивают: неотключение энергосбережения в BIOS, включение Hyper Threading в BIOS, любая активность оборудования в процессе тестирования источника времени, например, активность Intel ME. Вероятность произвольной замены источника времени высока на виртуальных машинах, так как при загрузке виртуальной машины нагрузка на аппаратуру неравномерна.  Рекомендуется проверять, какой источник времени используется или фиксировать желаемый источник времени в параметрах загрузке ядра linux. Пример изменения /boot/grub/grub.cfg приведён в теоретической части курса. Наиболее быстрый источник времени tsc.

Часть 7. Сетевые соединения

1) Откройте терминал пользователя root или переключитесь в консоль root:

postgres@tantor:~$ su - 

Password: root

2) Посмотрите включён ли алгоритм медленного старта после простоя:

root@tantor:~# sysctl -a | grep net.ipv4.tcp_slow_start_after_idle

net.ipv4.tcp_slow_start_after_idle = 1

Алгоритм медленного старта после простоя включён. Если сессия простаивала и сетевого трафика не было, то в сетях с заметной сетевой задержкой (network latency) скорость передачи данных будет нарастать постепенно, а не сразу использовать полосу пропускания сети. Первые три пакета TCP передаются без задержки. Этого обычно достаточно для передачи команд и небольших результатов. Большая часть OLTP систем не испытывают замедления, так как запрос и результат вписывается в три сетевых пакета.

3) Посмотрите какой алгоритм управления нагрузкой на сетевой канал передачи данных используется:

root@tantor:~# sysctl -a | grep net.ipv4.tcp_congestion_control

net.ipv4.tcp_congestion_control = cubic

Используется алгоритм cubic. Это алгоритм, который устанавливает объем передаваемых данных измеряя потери пакетов TCP, что нежелательно и приводит к повторной передаче пакетов. Вероятность передачи больших объемов данных, использования сети с большой сетевой задержкой мала, поэтому на выбор алгоритма редко обращают внимание и сеть не является узким местом для СУБД и их клиентов. Однако, если по сетевому каналу передаются большие объемы данных, а это поточная репликация и резервирование, то их эффективность может быть меньше, чем могла бы быть.

4) Посмотрите параметры, определяющие поддержание сокета открытым:

root@tantor:~# sysctl -a | grep keepalive

net.ipv4.tcp_keepalive_intvl = 75

net.ipv4.tcp_keepalive_probes = 9

net.ipv4.tcp_keepalive_time = 7200

Это значения по умолчанию и их можно уменьшить.

Кроме этих параметров меняют значения параметра net.ipv4.tcp_retries2 и упомянутого ранее net.ipv4.tcp_slow_start_after_idle.

Часть 8. Замена политики планирования и проверка работы планировщика

1) Создайте файл для тестирования нагрузки на процессор:

astra@tantor:~$ mcedit i.sh

#!/bin/sh

while true; do echo 1 > /dev/null ; done;

2) Проверьте, что содержимое файла успешно сохранилось:

astra@tantor:~$ cat i.sh

#!/bin/sh

while true; do echo 1 > /dev/null ; done;

3) Запустите процессы равное числу ядер процессоров виртуальной машины. Приведён пример для четырёх ядер:

astra@tantor:~$ nproc

4

astra@tantor:~$ taskset./i.sh &

[2] 212239

astra@tantor:~$ taskset./i.sh &

[3] 212242

astra@tantor:~$ taskset./i.sh &

[4] 212243

astra@tantor:~$ taskset./i.sh &

[5] 212244

4) Два процесса нагружают оба ядра на 100%. Это можно проверить утилитой top.

Убедитесь, что утилита pidstat вводит в заблуждение, показывает небольшую нагрузку:

root@tantor:~# pidstat -w | grep i.sh

06:58:52 AM  1000    212239      0.00      0.02  i.sh

06:58:52 AM  1000    212242      0.00      0.02  i.sh

06:58:52 AM  1000    212243      0.00      0.02  i.sh

06:58:52 AM  1000    212244      0.00      0.02  i.sh

5) Посмотрите, что показывает утилита vmstat:

root@tantor:~# vmstat

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

 7  0      0 179276 271824 720548    0    0     2     3   75   78  2  0 98  0  0

Утилита vmstat показывает отсутствие нагрузки и небольшое число переключений контекстов.

При том, что число переключений довольно большое.

Выполните команду с интервалом примерно в секунду:

astra@tantor:~$ grep ctxt /proc/22242/status

voluntary_ctxt_switches:        0

nonvoluntary_ctxt_switches:     3841

astra@tantor:~$ grep ctxt /proc/22242/status

voluntary_ctxt_switches:        0

nonvoluntary_ctxt_switches:     3945

Контексты переключаются с частотой 100 раз в секунду.

6) Установите для процессов политику планировщика SCED_RR (Round Robin Scheduler) - timeslice выделенный процессам одинаков и равен значению параметра  kernel.sched_rr_timeslice_ms:

astra@tantor:~# sudo chrt -r -p 10 212242

astra@tantor:~# sudo chrt -r -p 10 212239

astra@tantor:~# sudo chrt -r -p 10 212243

astra@tantor:~# sudo chrt -r -p 10 212244

Процессы с политикой SCHED_DEADLINE могут вытеснять процессы с SCHED_FIFO и SCHED_RR, то есть являются наиболее приоритетными.

7) Проверьте результат выполнения команды:

astra@tantor:~$ chrt -p 212242

pid 212242's current scheduling policy: SCHED_RR

pid 212242's current scheduling priority: 10

8) Выполните команду с интервалом примерно в секунду:

root@tantor:~# grep ctxt /proc/212233/status

voluntary_ctxt_switches:        0

nonvoluntary_ctxt_switches:     27518

root@tantor:~# grep ctxt /proc/212233/status

voluntary_ctxt_switches:        0

nonvoluntary_ctxt_switches:     27523

Контексты стали переключаться с частотой 10 раз в секунду

9) Посмотрите timeslice планировщика RR:

astra@tantor:~$ sudo sysctl -a | grep kernel.sched_rr_timeslice_ms

kernel.sched_rr_timeslice_ms = 100

timeslice 100 миллисекунд = 1/10 секунды, что соответствует переключению 10 раз в секунду.

10) Установите timeslice в одну секунду:

astra@tantor:~# sudo sysctl kernel.sched_rr_timeslice_ms=1000

kernel.sched_rr_timeslice_ms = 1000

Частота переключений контекста не будет чаще 100 раз в секунду независимо от настроек. Это правильно, так как позволяет не производить большие накладные расходы на работу планировщика по переключению контекстов.

11) Проверьте, что контексты процессов c RR политикой стали переключаться раз в секунду. Выполните команды с интервалом раз в секунду и посмотрите насколько поменяются значения счетчика принудительных переключений контекста:

root@tantor:~# grep ctxt /proc/212233/status

voluntary_ctxt_switches:        0

nonvoluntary_ctxt_switches:     62348

root@tantor:~# grep ctxt /proc/212233/status

voluntary_ctxt_switches:        0

nonvoluntary_ctxt_switches:     62349

Значения будут увеличиваться на единицу с частотой раз в секунду.

12) Запустите команду и примерно через 20 секунд прервите её выполнение набрав <ctrl+c>:

root@tantor:~# perf stat -p 212233

^C

 Performance counter stats for process id '22381':

          9,340.10 msec task-clock:u                     #    0.477 CPUs utilized            

                 0      context-switches:u               #    0.000 /sec                     

                 0      cpu-migrations:u                 #    0.000 /sec                      

                 0      page-faults:u                    #    0.000 /sec                      

   <not supported>      cycles:u                                                              

   <not supported>      instructions:u                                                        

   <not supported>      branches:u                                                            

   <not supported>      branch-misses:u                                                      

      19.595645993 seconds time elapsed

Утилита perf выдает верные данные ноль произвольных переключений контекстов в секунду. Число принудительных переключений, которые более ценны для диагностики не показывает, чем вводит в заблуждение.

Утилита top при этом показывает правильные данные с достаточной точностью для частоты переключений контекстов в 1 секунду: загрузка ядер процессоров доходит до 100%. Суммарная загрузка всех ядрер %CPU по ~50% у каждого процесса i.sh

13) Остановите процессы:

astra@tantor:~$ killall i.sh

[1]-  Terminated              taskset./i.sh

[2]+  Terminated              taskset./i.sh

В этой части практики вы изучили как можно протестировать результат изменений параметров планировщика. По приведённому примеру можно протестировать работу планировщиков SCHED_OTHER, SCHED_FIFO, SCHED_DEADLINE.

Политика SCHED_OTHER (и её производные SCHED_BATCH, SСHED_IDLE) не являются политиками реального времени. К политикам реального времени (для интерактивных задач, где важна отзывчивость - получать timeslice с какой-то частотой) относятся: SCHED_FIFO - вытесняется только процессами с более высоким приоритетом или политикой SCHED_DEADLINE. Установка процессу политики SCHED_FIFO приводит к тому, что процесс может надолго занять ядро.

Практика к главе 4

Часть 1. Параметры дисковой подсистемы

1) Блочные устройства располагаются в директории /dev смонтированной на виртуальной файловой системе devtmpfs. Посмотрите какие устройства из /dev смонтированы:

root@tantor:~# mount | grep /dev 

udev on /dev type devtmpfs (rw,nosuid,relatime,size=1966296k,nr_inodes=491574,mode=755,inode64)

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

/dev/sda1 on / type ext4 (rw,relatime)

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)

hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)

mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)

В /dev находятся файлы только тех устройств, которые в настоящий момент доступны (подключены). Если устройство отключается, то файл удаляется из /dev.

В виртуальной машине смонтирован первый раздел /dev/sda.

2) Посмотрите список блочных устройств:

root@tantor:~# ls -l /dev | grep br

brw-rw----  1 root    disk      7,   0 loop0

brw-rw----  1 root    disk      7,   1 loop1

brw-rw----  1 root    disk      7,   2 loop2

brw-rw----  1 root    disk      7,   3 loop3

brw-rw----  1 root    disk      7,   4 loop4

brw-rw----  1 root    disk      7,   5 loop5

brw-rw----  1 root    disk      7,   6 loop6

brw-rw----  1 root    disk      7,   7 loop7

brw-rw----  1 root    disk    259,   0 nvme0n1

brw-rw----  1 root    disk      8,   0 sda

brw-rw----  1 root    disk      8,   1 sda1

brw-rw----+ 1 root    cdrom    11,   0 sr0

В виртуальной машине подключен виртуальный диск /dev/sda с одним разделом /dev/sda1.

Первая буква b обозначает block device. Вместо размера файла выдаются два числа: тип и порядковый номер (или режим работы) устройства.

3) Посмотрите содержимое директории /sys/dev/block:

root@tantor:~# ls -al /sys/dev/block

total 0

drwxr-xr-x 2 root root 0 .

drwxr-xr-x 4 root root 0 ..

lrwxrwxrwx 1 root root 0 11:0 -> ../../devices/pci0000:00/0000:00:01.1/ata2/host1/target1:0:0/1:0:0:0/block/sr0

lrwxrwxrwx 1 root root 0 259:0 -> ../../devices/pci0000:00/0000:00:0e.0/nvme/nvme0/nvme0n1

lrwxrwxrwx 1 root root 0 7:0 -> ../../devices/virtual/block/loop0

lrwxrwxrwx 1 root root 0 7:1 -> ../../devices/virtual/block/loop1

lrwxrwxrwx 1 root root 0 7:2 -> ../../devices/virtual/block/loop2

lrwxrwxrwx 1 root root 0 7:3 -> ../../devices/virtual/block/loop3

lrwxrwxrwx 1 root root 0 7:4 -> ../../devices/virtual/block/loop4

lrwxrwxrwx 1 root root 0 7:5 -> ../../devices/virtual/block/loop5

lrwxrwxrwx 1 root root 0 7:6 -> ../../devices/virtual/block/loop6

lrwxrwxrwx 1 root root 0 7:7 -> ../../devices/virtual/block/loop7

lrwxrwxrwx 1 root root 0 8:0 -> ../../devices/pci0000:00/0000:00:0d.0/ata1/host0/target0:0:0/0:0:0:0/block/sda

lrwxrwxrwx 1 root root 0 8:1 -> ../../devices/pci0000:00/0000:00:0d.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1

Директория содержит символические ссылки на блочные устройства. Устройство sda подключено к шине PCI через интерфейс ATA.

4) Посмотрите какой используется планировщик ввода-вывода с устройством sda:

root@tantor:~# cat /sys/block/sda/queue/scheduler

[none] mq-deadline

root@tantor:~# cat /sys/dev/block/8:0/queue/scheduler

[none] mq-deadline

С устройством sda используется планировщик с названием none.

5) Выполните следующие команды:

root@tantor:~# echo kyber > /sys/block/sda/queue/scheduler

root@tantor:~# cat /sys/dev/block/8:0/queue/scheduler

none mq-deadline [kyber]

root@tantor:~# echo bfq > /sys/block/sda/queue/scheduler

root@tantor:~# cat /sys/block/sda/queue/scheduler

none mq-deadline kyber [bfq]

root@tantor:~# echo abc > /sys/block/sda/queue/scheduler

-bash: echo: write error: Invalid argument

root@tantor:~# echo none > /sys/block/sda/queue/scheduler

root@tantor:~# cat /sys/block/sda/queue/scheduler

[none] mq-deadline kyber bfq

Команды меняют планировщик. Несуществующий планировщик abc указать нельзя. Изначально показывались не все доступные планировщики, сейчас показываются.

6) Посмотрите содержимое файла  /etc/udev/rules.d/70-schedulerset.rules, в котором устанавливаются параметры выбора планировщика ввода-вывода:

 root@tantor:~# cat /etc/udev/rules.d/70-schedulerset.rules

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"

Для всех устройств с названиями sda..sdz указан планировщик none.

7) Посмотрите размер физического сектора устройства:

root@tantor:~# lsblk -td

NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED       RQ-SIZE  RA WSAME

sda          0    512      0     512     512    0 none             32 128    0B

sr0          0    512      0     512     512    1 mq-deadline       2 128    0B

Linux считает, что размер сектора устройства sda 512 байт.

8) Посмотрите параметры, с которыми была смонтирована файловая система на разделе /dev/sda1:

root@tantor:~# tune2fs -l /dev/sda1 | grep opt

Default mount options:    user_xattr acl

root@tantor:~# mount | grep ext4

/dev/sda1 on / type ext4 (rw,relatime)

root@tantor:~# cat /etc/fstab | grep ext4

UUID=aca1a090-eba2-49ba-a8fc-ba12e9e2bf26 /   ext4    defaults   1 1

Файловая система смонтирована с параметрами по умолчанию. Параметры, которые определяют функционал файловой системы могут храниться в самом разделе (в "суперблоке").

9) Посмотрите полный список параметров:

root@tantor:~# cat /proc/fs/ext4/sda1/options

rw

bsddf

nogrpid

block_validity

dioread_nolock

nodiscard

delalloc

nowarn_on_error

journal_checksum

barrier

auto_da_alloc

user_xattr

acl

noquota

resuid=0

resgid=0

errors=continue

commit=5

min_batch_time=0

max_batch_time=15000

stripe=0

data=ordered

inode_readahead_blks=32

init_itable=10

max_dir_size_kb=0

10) Установите свойство discard в суперблоке файловой системы и проверьте, что оно установлено:

root@tantor:~# tune2fs -o +discard /dev/sda1

tune2fs 1.47.0 (5-Feb-2023)

root@tantor:~# tune2fs -l /dev/sda1 | grep opt

Default mount options:    user_xattr acl discard

К опциям, которые были добавилось свойство discard.

Опция discard может устанавливаться:

в суперблоке файловой системы как опция монтирования по умолчанию

в файле параметров монтирования файловой системы &mdash; /etc/fstab

в конфигурации cryptsetup &mdash; /etc/crypttab

в конфигурации LVM &mdash; /etc/lvm/lvm.conf

в конфигурации загрузчика &mdash; /boot/grub/grub.cfg

11) Проверьте, посылались ли команды discard операционной системой в контроллер sda:

root@tantor:~# fstrim -v /

fstrim: /: the discard operation is not supported

root@tantor:~# lsblk --discard

NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO

sda           0        0B       0B         0

└─sda1        0        0B       0B         0

sr0           0        0B       0B         0

Нули в DISC-GRAN и DISC-MAX означают, что discard не использовался.

Команды discard не посылались.

В виртуальной машине, на которой выполняются практики, разделы являются файлами. Файлы занимают место в файловой системе хоста, поэтому discard не используется.

12) Посмотрите как называется пакет, в котором устанавливалась утилита fstrim:

root@tantor:~# dpkg -S fstrim

util-linux: /sbin/fstrim

util-linux: /usr/share/man/man8/fstrim.8.gz

util-linux: /lib/systemd/system/fstrim.service

util-linux: /lib/systemd/system/fstrim.timer

util-linux: /usr/share/bash-completion/completions/fstrim

Пакет называется util-linux

Часть 2. Установка пакетов в Astralinux

1) Запустите новый терминал. В терминале пользователя astra запустите утилиту synaptic-pkexec:

astra@tantor:~$ synaptic-pkexec

В окне ввода пароля введите astra и нажмите кнопку OK

Synaptic это графический пакетный менеджер в Astralinux.

2) В меню Settings -> Repositories проверьте, что установлены две галочки на основном и расширенном репозиториях. Нажмите кнопку OK.

3) В меню Edit -> Search наберите fio. В поле Look in выберите Name. Нажмите кнопку Search:

4) В высветившимся списке пакетов выберите пакет fio. Если утилита установлена (есть зеленый кружок перед названием утилиты), то пропустите этот пункт. Также можно установить пакет uuid-runtime, если пакет uuid-runtime не установлен.

Если утилита fio не установлена, то в выпадающем меню выберите "Mark for installation". Если окно не закрылось нажмите Mark. На toolbar (три кнопки под меню) нажмите кнопку Apply.  В появившемся окне нажмите кнопку Apply. Если появится окно с вопросом про Kernel update нажмите Next.

5) Закройте окно Synaptic нажав крестик справа вверху окна приложения Synaptic.

6) В окне терминала пользователя astra наберите команду:

astra@tantor:~$ sudo apt install fio -y

Reading package lists... Done

Building dependency tree... Done

Reading state information... Done

fio is already the newest version (3.33-3+b1).

0 upgraded, 0 newly installed, 0 to remove and 636 not upgraded.

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

Закройте терминал пользователя astra набрав в нем комбинацию клавиш <ctrl+d>

7) Установите пакеты nvme-cli и uuid-runtime:

root@tantor:~# apt install nvme-cli uuid-runtime -y

Если откроется окно с псевдографикой синего цвета, нажмите OK в первом окне:

Окно уведомляет о том, что нужно обновить все пакеты для которых вышли обновления.

Убрать уведомления можно деинсталлировав пакет apt -y remove needrestart

Активный элемент окон псевдографики подсвечивается красным цветом. Для перехода между визуальными элементами окна используется клавиша <TAB>, клавиши стрелок на клавиатуре или мышь.

Откроется следующее окно. Нажмите клавишу <TAB>, в окне подсветится визуальный элемент <OK>.  

Служба uuidd будет запущена без перезагрузки linux и предлагается перезагрузить службы, которые зависят от того, что было выполнено при установке пакета. Набор служб менять не нужно. Если подсвечен красным цветом элемент окна <OK>, то нажмите на клавиатуре клавишу <ENTER> или кликните мышкой на элемент окна <OK.

Сообщение о желательности перелогиниться можно игнорировать и закрыть:

Была установлена утилита командной строки nvme и служба uuidd.

Утилита nvme, устанавливаемая в пакете nvme-cli используется для чтения характеристик и метрик устройств NVMe. Утилита используется для определения состояния чипов памяти, отслеживания срока службы, обновления прошивки, стирания содержимого, переинициализации, чтения журналов с ошибками.

Пакет uuidd обеспечивает уникальность генерируемых uuid на хостах с несколькими процессорами. Он устанавливается потому, что требуется для установки nvme-cli.

Утилита nvme используется для получения информации об устройствах NVMe.

Вы научились устанавливать пакеты в Astralinux.

Часть 3. Работа с SSD и тестирование производительности диска утилитой fio

1) Выполните несколько команд с помощью утилиты nvme:

root@tantor:~# nvme list

Nod          Generic    SN           Model                Namespace Usage Format                  FW Rev

------------ ---------- ------------ -------------------- --------- ----- ----------------------- --------

/dev/nvme0n1 /dev/ng0n1 VB1234-56789 ORCL-VBOX-NVME-VER12               1 8.59GB/8.59GB 512B + 0B 1.0    

root@tantor:~# nvme list-subsys

nvme-subsys0 - NQN=nqn.2014.08.org.nvmexpress:80ee80eeVB1234-56789 ORCL-VBOX-NVME-VER12

\

 +- nvme0 pcie 0000:00:0e.0 live

root@tantor:~# nvme id-ctrl /dev/nvme0n1 | head -6

NVME Identify Controller:

vid       : 0x80ee

ssvid     : 0x80ee

sn        : VB1234-56789

mn        : ORCL-VBOX-NVME-VER12

fr        : 1.0    

2) Посмотрите список устройств nvme:

root@tantor:~# ls /dev/nvm*

/dev/nvme0  /dev/nvme0n1  /dev/nvme-fabrics

Имеется одно устройство NVMe.

3) Создайте файловую систему на устройстве NVMe:

root@tantor:~# mkfs -E discard /dev/nvme0n1

mke2fs 1.47.0 (5-Feb-2023)

Creating filesystem with 2097152 4k blocks and 524288 inodes

Filesystem UUID: 0c0f68b7-d1d9-47ff-908c-9831503837f3

Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done

Writing inode tables: done

Writing superblocks and filesystem accounting information: done

Опция используется по умолчанию. Приведена для того, чтобы подчеркнуть важность очистки содержимого SSD. В описании команды ( man mkfs.ext4 ) указано, что опция discard посылает на контроллер устройства команду очистки содержимого:

Attempt  to  discard  blocks at mkfs time (discarding blocks initially is useful on solid state devices and sparse / thin-provisioned storage). When the device advertises that discard also zeroes data (any subsequent read  after  the  discard  and  before write  returns  zero), then mark all not-yet-zeroed inode tables as zeroed. This significantly speeds up file system initialization. This is set as default.

Обратите внимание, что журнал не был создан, отсутствует строка:

Creating journal (16384 blocks): done

4) Измените суперблок файловой системы, включив опцию discard:

root@tantor:~# tune2fs -o +discard /dev/nvme0n1

tune2fs 1.47.0 (5-Feb-2023)

5) Создайте директорию /u01, смонтируйте в неё созданную файловую систему, посмотрите какой размер у смонтированного раздела:

root@tantor:~# mkdir /u01

root@tantor:~# mount /dev/nvme0n1 /u01

root@tantor:/# df -Th | grep "^/dev"

/dev/sda1      ext4       47G   16G   29G  36% /

/dev/nvme0n1   ext2      7.9G   24K  7.5G   1% /u01

Раздел смонтирован в /u01, его размер 8Гб, файловая система ext2.

6) В терминале пользователя root выполните команду:

root@tantor:~# fio --ioengine=psync --filename=/tmp/test --size=1G --time_based --name=fio --group_reporting --runtime=10 --direct=1 --sync=1 --iodepth=1 --rw=read --bs=8k --numjobs=1

fio: (g=0): rw=read, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=psync, iodepth=1

fio-3.33

Starting 1 process

fio: Laying out IO file (1 file / 1024MiB)

Jobs: 1 (f=1): [R(1)][100.0%][r=36.4MiB/s][r=4664 IOPS][eta 00m:00s]

fio: (groupid=0, jobs=1): err= 0: pid=7432: Mon Dec  9 00:07:59 2024

  read: IOPS=4682, BW=36.6MiB/s (38.4MB/s)(366MiB/10001msec)

    clat (usec): min=92, max=8607, avg=207.12, stdev=306.94

     lat (usec): min=93, max=8608, avg=208.56, stdev=306.95

    clat percentiles (usec):

     |  1.00th=[  143],  5.00th=[  149], 10.00th=[  151], 20.00th=[  155],

     | 30.00th=[  157], 40.00th=[  159], 50.00th=[  159], 60.00th=[  161],

     | 70.00th=[  165], 80.00th=[  172], 90.00th=[  237], 95.00th=[  253],

     | 99.00th=[ 2245], 99.50th=[ 2900], 99.90th=[ 3490], 99.95th=[ 3654],

     | 99.99th=[ 3982]

   bw (  KiB/s): min=33213, max=40688, per=100.00%, avg=37505.37, stdev=1932.35, samples=19

   iops        : min= 4151, max= 5086, avg=4687.95, stdev=241.58, samples=19

  lat (usec)   : 100=0.01%, 250=94.32%, 500=3.66%, 750=0.61%, 1000=0.03%

  lat (msec)   : 2=0.15%, 4=1.22%, 10=0.01%

  cpu          : usr=12.33%, sys=11.35%, ctx=46830, majf=0, minf=14

  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%

     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

     issued rwts: total=46827,0,0,0 short=0,0,0,0 dropped=0,0,0,0

     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):

   READ: bw=36.6MiB/s (38.4MB/s), 36.6MiB/s-36.6MiB/s (38.4MB/s-38.4MB/s), io=366MiB (384MB), run=10001-10001msec

Disk stats (read/write):

  sda: ios=45651/4, merge=0/1, ticks=8268/7, in_queue=8282, util=97.89%

Красным выделены результаты теста. Остальной многословный вывод не требует внимания и используется в редких случаях.

Параметры теста:

Работа PostgreSQL с файловой системой соответствует --ioengine=psync

размер блока PostgreSQL --bs=8k

Размер очереди (iodepth) выбран 1, так как выбран direct=1

Тест выполнял только чтение из файла. Результат теста: максимальное число операций ввода-вывода IOPS=4682, средняя скорость 38.4MB/s.

7) Протестируйте раздел NVMe:

root@tantor:~# fio --ioengine=psync --filename=/u01/test --size=1G --time_based --name=fio --group_reporting --runtime=10 --direct=1 --sync=1 --iodepth=1 --rw=read --bs=8k --numjobs=1

fio: (g=0): rw=read, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=psync, iodepth=1

fio-3.33

Starting 1 process

fio: Laying out IO file (1 file / 1024MiB)

Jobs: 1 (f=1): [R(1)][100.0%][r=43.1MiB/s][r=5520 IOPS][eta 00m:00s]

fio: (groupid=0, jobs=1): err= 0: pid=7441: Mon Dec  9 00:08:59 2024

  read: IOPS=5312, BW=41.5MiB/s (43.5MB/s)(415MiB/10001msec)

    clat (usec): min=77, max=11930, avg=181.67, stdev=300.00

     lat (usec): min=78, max=11932, avg=183.12, stdev=300.04

    clat percentiles (usec):

     |  1.00th=[  128],  5.00th=[  133], 10.00th=[  137], 20.00th=[  139],

     | 30.00th=[  141], 40.00th=[  143], 50.00th=[  145], 60.00th=[  147],

     | 70.00th=[  149], 80.00th=[  151], 90.00th=[  167], 95.00th=[  229],

     | 99.00th=[ 2147], 99.50th=[ 2835], 99.90th=[ 3523], 99.95th=[ 3752],

     | 99.99th=[ 5932]

   bw (  KiB/s): min=38848, max=43936, per=99.80%, avg=42413.47, stdev=1514.01, samples=19

   iops        : min= 4856, max= 5492, avg=5301.68, stdev=189.25, samples=19

  lat (usec)   : 100=0.11%, 250=97.55%, 500=0.99%, 750=0.12%, 1000=0.08%

  lat (msec)   : 2=0.08%, 4=1.04%, 10=0.02%, 20=0.01%

  cpu          : usr=12.13%, sys=12.54%, ctx=53130, majf=0, minf=15

  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%

     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

     issued rwts: total=53128,0,0,0 short=0,0,0,0 dropped=0,0,0,0

     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):

   READ: bw=41.5MiB/s (43.5MB/s), 41.5MiB/s-41.5MiB/s (43.5MB/s-43.5MB/s), io=415MiB (435MB), run=10001-10001msec

Disk stats (read/write):

  nvme0n1: ios=52790/2, merge=0/1, ticks=8283/5, in_queue=8289, util=98.93%

Физически виртуальная машина хранит /dev/sda и /dev/nvme0 в соседних файлах VMDK в файловой системе хоста. Используются разные типы шин ввода-вывода: SATA и NVMe. Заметная разница в производительности ~10%. Практический результат в том, что использование NVMe в VirtualBox имеет преимущество по сравнению с SATA AHCI.

8) Были созданы временные файлы /tmp/test и /u01/test размером 1Гб каждый. Удалите эти файлы:

root@tantor:~# rm -f /tmp/test

root@tantor:~# rm -f /u01/test

9) Размонтируйте /u01:

root@tantor:~# umount /u01

10) Этот пункт выполнять необязательно.

Пример тестирования записи в пределах раздела. Раздел должен быть отмонтирован и после теста пересоздан, так как содержимое раздела будет затёрто:

root@tantor:/# fio --filename=/dev/nvme0n1 --name=a --blocksize=4k --rw=randwrite --iodepth=32 --runtime=10 --fsync=1 | grep BW=

  write: IOPS=583, BW=2335KiB/s (2391kB/s)(22.8MiB/10002msec); 0 zone resets

root@tantor:/# fio --filename=/dev/nvme0n1 --name=a --blocksize=8k --rw=randwrite --iodepth=32 --runtime=10 --fsync=1 | grep BW=

  write: IOPS=561, BW=4491KiB/s (4599kB/s)(43.9MiB/10002msec); 0 zone resets

root@tantor:/# fio --filename=/dev/nvme0n1 --name=a --blocksize=16k --rw=randwrite --iodepth=32 --runtime=10 --fsync=1 | grep BW=

  write: IOPS=504, BW=8066KiB/s (8260kB/s)(78.8MiB/10001msec); 0 zone resets

root@tantor:/# fio --filename=/dev/nvme0n1 --name=a --blocksize=32k --rw=randwrite --iodepth=32 --runtime=10 --fsync=1 | grep BW=

  write: IOPS=411, BW=12.9MiB/s (13.5MB/s)(129MiB/10002msec); 0 zone resets