Size: a a a

pgsql – PostgreSQL

2020 August 02

kp

krn p in pgsql – PostgreSQL
Sergey Vats
те во время создания ордера(если в ордере несколько товаров), в таблице товар-заказ, должно будет создаться несколько записей ({ orderId: 1, goodId: 1}, { orderId: 1; goodId: 2 }), я правильно понял?
Да, усе верно. Эт базовые вещи, до которых без пинка иногда не допетрить))
Плюс эта таблица должна иметь референсы на таблицу товаров и таблицу заказов соответсвенно
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Artemii
привет. есть база 40ГБ
там одна таблица 13ГБ (логи)
в 9.6
select * from log; работает, ну долговато
переехали в 11.8
select * from log; начинает жрать память машины (по забииксу) и Postgres процеcc - Killed
что можно посмотреть? конфиг какой нить или параметры
Во-первых, настройки OS посмотрите. Вот этого:

> Postgres процеcc - Killed

т.е. OOM kills, вообще не должно происходить.

Во-вторых, стоит проверить и настройки самого PostgreSQL, и посмотреть план запроса.
источник

SV

Sergey Vats in pgsql – PostgreSQL
krn p
Да, усе верно. Эт базовые вещи, до которых без пинка иногда не допетрить))
Плюс эта таблица должна иметь референсы на таблицу товаров и таблицу заказов соответсвенно
благодарю)
источник

kp

krn p in pgsql – PostgreSQL
Sergey Vats
благодарю)
Посмотрите как в постгрес работают join, описанная связь между таблицами - каноничный пример для разжёвывания джоинов
источник

SV

Sergey Vats in pgsql – PostgreSQL
krn p
Посмотрите как в постгрес работают join, описанная связь между таблицами - каноничный пример для разжёвывания джоинов
хорошо, сейчас чекну
источник

A

Artemii in pgsql – PostgreSQL
Yaroslav Schekin
Во-первых, настройки OS посмотрите. Вот этого:

> Postgres процеcc - Killed

т.е. OOM kills, вообще не должно происходить.

Во-вторых, стоит проверить и настройки самого PostgreSQL, и посмотреть план запроса.
1.цель моего вопроса здесь: как раз узнать какие настройки нужно посмотреть
2. если OOMkiller не придёт, то подозреваю, что пожрёт всю память и вобще всё ляжет
3 какие настройки postgresql посмотреть - это и был мой вопрос тоже
# explain analyze select * from log;
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                         QUERY PLAN                                                         │
├────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Seq Scan on log  (cost=0.00..1083078.35 rows=6832235 width=1145) (actual time=0.544..43662.580 rows=6511739 loops=1) │
│ Planning Time: 0.039 ms                                                                                                    │
│ Execution Time: 43897.532 ms                                                                                               │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
(3 rows)

Time: 43897.861 ms (00:43.898)
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Artemii
1.цель моего вопроса здесь: как раз узнать какие настройки нужно посмотреть
2. если OOMkiller не придёт, то подозреваю, что пожрёт всю память и вобще всё ляжет
3 какие настройки postgresql посмотреть - это и был мой вопрос тоже
# explain analyze select * from log;
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                         QUERY PLAN                                                         │
├────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Seq Scan on log  (cost=0.00..1083078.35 rows=6832235 width=1145) (actual time=0.544..43662.580 rows=6511739 loops=1) │
│ Planning Time: 0.039 ms                                                                                                    │
│ Execution Time: 43897.532 ms                                                                                               │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
(3 rows)

Time: 43897.861 ms (00:43.898)
> 1.цель моего вопроса здесь: как раз узнать какие настройки нужно посмотреть

В системе — см. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

> 2. если OOMkiller не придёт, то подозреваю, что пожрёт всю память и вобще всё ляжет

Ну конечно же, ведь когда OOM killer приходит, ведь ничего не ложится — так, что ли? ;)
Hint: на самом деле падает весь сервер PostgreSQL, а вот при out of memory прерывался бы только запрос в одной сессии — мне кажется, что это намного лучше.

> 3 какие настройки postgresql посмотреть - это и был мой вопрос тоже

В PostgreSQL — примерно эти:
SELECT name, category, setting, unit, context, short_desc
 FROM pg_settings
WHERE category IN ('Resource Usage / Memory', 'Query Tuning / Other Planner Options');

А лучше почитайте https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

А по плану — это на v9.6, правильно? Вы EXPLAIN (без ANALYZE) на 11.8 посмотрите.
источник

A

Artemii in pgsql – PostgreSQL
> В системе — см. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

overcommit у меня 0, как и рекомендовано в разных руководствах. если поставить 2, как там рекомендуется - что будет?

> Ну конечно же, ведь когда OOM killer приходит, ведь ничего не ложится — так, что ли? ;)
Hint: на самом деле падает весь сервер PostgreSQL, а вот при out of memory прерывался бы только запрос в одной сессии — мне кажется, что это намного лучше.

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

A

Artemii in pgsql – PostgreSQL
│            name            │               category               │  setting  │ unit │  context   │                                       short_desc                                       │

│ autovacuum_work_mem        │ Resource Usage / Memory              │ -1        │ kB   │ sighup     │ Sets the maximum memory to be used by each autovacuum worker process.                  │
│ constraint_exclusion       │ Query Tuning / Other Planner Options │ partition │      │ user       │ Enables the planner to use constraints to optimize queries.                            │
│ cursor_tuple_fraction      │ Query Tuning / Other Planner Options │ 0.1       │      │ user       │ Sets the planner's estimate of the fraction of a cursor's rows that will be retrieved. │
│ default_statistics_target  │ Query Tuning / Other Planner Options │ 100       │      │ user       │ Sets the default statistics target.                                                    │
│ dynamic_shared_memory_type │ Resource Usage / Memory              │ posix     │      │ postmaster │ Selects the dynamic shared memory implementation used.                                 │
│ force_parallel_mode        │ Query Tuning / Other Planner Options │ off       │      │ user       │ Forces use of parallel query facilities.                                               │
│ from_collapse_limit        │ Query Tuning / Other Planner Options │ 8         │      │ user       │ Sets the FROM-list size beyond which subqueries are not collapsed.                     │
│ huge_pages                 │ Resource Usage / Memory              │ try       │      │ postmaster │ Use of huge pages on Linux or Windows.                                                 │
│ jit                        │ Query Tuning / Other Planner Options │ off       │      │ user       │ Allow JIT compilation.                                                                 │
│ join_collapse_limit        │ Query Tuning / Other Planner Options │ 8         │      │ user       │ Sets the FROM-list size beyond which JOIN constructs are not flattened.                │
│ maintenance_work_mem       │ Resource Usage / Memory              │ 2097152   │ kB   │ user       │ Sets the maximum memory to be used for maintenance operations.                         │
│ max_prepared_transactions  │ Resource Usage / Memory              │ 0         │      │ postmaster │ Sets the maximum number of simultaneously prepared transactions.                       │
│ max_stack_depth            │ Resource Usage / Memory              │ 2048      │ kB   │ superuser  │ Sets the maximum stack depth, in kilobytes.                                            │
│ shared_buffers             │ Resource Usage / Memory              │ 1048576   │ 8kB  │ postmaster │ Sets the number of shared memory buffers used by the server.                           │
│ temp_buffers               │ Resource Usage / Memory              │ 1024      │ 8kB  │ user       │ Sets the maximum number of temporary buffers used by each session.                     │
│ track_activity_query_size  │ Resource Usage / Memory              │ 1024      │ B    │ postmaster │ Sets the size reserved for pg_stat_activity.query, in bytes.                           │
│ work_mem                   │ Resource Usage / Memory              │ 20971     │ kB   │ user       │ Sets the maximum memory to be used for query workspaces.                               │


> А лучше почитайте

прочитано давно и затюнено. еще в 9.6, а принципиального поведения с отличиями в 11.8 там нет
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Artemii
> В системе — см. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

overcommit у меня 0, как и рекомендовано в разных руководствах. если поставить 2, как там рекомендуется - что будет?

> Ну конечно же, ведь когда OOM killer приходит, ведь ничего не ложится — так, что ли? ;)
Hint: на самом деле падает весь сервер PostgreSQL, а вот при out of memory прерывался бы только запрос в одной сессии — мне кажется, что это намного лучше.

у меня именно OOMkiller прихдит и убивает только тот процесс, который делает этот запрос. а остальные процессы и сам postgresql продолжают работать
> overcommit у меня 0, как и рекомендовано в разных руководствах.

Это какие-то неправильные руководства. ;) А я дал Вам ссылку на официальную документацию, где даются и объяснения такой настройки.

> у меня именно OOMkiller прихдит и убивает только тот процесс, который делает этот запрос.

Да это же прямо-таки чудо! ;)
Вы логи PostgreSQL посмотрите, убедитесь в обратном (а если не убедитесь — возможно, там убивается postmaster, что куда хуже — опять-таки, см. ссылку).
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Artemii
│            name            │               category               │  setting  │ unit │  context   │                                       short_desc                                       │

│ autovacuum_work_mem        │ Resource Usage / Memory              │ -1        │ kB   │ sighup     │ Sets the maximum memory to be used by each autovacuum worker process.                  │
│ constraint_exclusion       │ Query Tuning / Other Planner Options │ partition │      │ user       │ Enables the planner to use constraints to optimize queries.                            │
│ cursor_tuple_fraction      │ Query Tuning / Other Planner Options │ 0.1       │      │ user       │ Sets the planner's estimate of the fraction of a cursor's rows that will be retrieved. │
│ default_statistics_target  │ Query Tuning / Other Planner Options │ 100       │      │ user       │ Sets the default statistics target.                                                    │
│ dynamic_shared_memory_type │ Resource Usage / Memory              │ posix     │      │ postmaster │ Selects the dynamic shared memory implementation used.                                 │
│ force_parallel_mode        │ Query Tuning / Other Planner Options │ off       │      │ user       │ Forces use of parallel query facilities.                                               │
│ from_collapse_limit        │ Query Tuning / Other Planner Options │ 8         │      │ user       │ Sets the FROM-list size beyond which subqueries are not collapsed.                     │
│ huge_pages                 │ Resource Usage / Memory              │ try       │      │ postmaster │ Use of huge pages on Linux or Windows.                                                 │
│ jit                        │ Query Tuning / Other Planner Options │ off       │      │ user       │ Allow JIT compilation.                                                                 │
│ join_collapse_limit        │ Query Tuning / Other Planner Options │ 8         │      │ user       │ Sets the FROM-list size beyond which JOIN constructs are not flattened.                │
│ maintenance_work_mem       │ Resource Usage / Memory              │ 2097152   │ kB   │ user       │ Sets the maximum memory to be used for maintenance operations.                         │
│ max_prepared_transactions  │ Resource Usage / Memory              │ 0         │      │ postmaster │ Sets the maximum number of simultaneously prepared transactions.                       │
│ max_stack_depth            │ Resource Usage / Memory              │ 2048      │ kB   │ superuser  │ Sets the maximum stack depth, in kilobytes.                                            │
│ shared_buffers             │ Resource Usage / Memory              │ 1048576   │ 8kB  │ postmaster │ Sets the number of shared memory buffers used by the server.                           │
│ temp_buffers               │ Resource Usage / Memory              │ 1024      │ 8kB  │ user       │ Sets the maximum number of temporary buffers used by each session.                     │
│ track_activity_query_size  │ Resource Usage / Memory              │ 1024      │ B    │ postmaster │ Sets the size reserved for pg_stat_activity.query, in bytes.                           │
│ work_mem                   │ Resource Usage / Memory              │ 20971     │ kB   │ user       │ Sets the maximum memory to be used for query workspaces.                               │


> А лучше почитайте

прочитано давно и затюнено. еще в 9.6, а принципиального поведения с отличиями в 11.8 там нет
Да толку это тут-то показывать? ;( Мы же ни "железа", ни нагрузки не знаем...
Это я просто ответил на тему "что читать и смотреть".
источник

A

Artemii in pgsql – PostgreSQL
> Это какие-то неправильные руководства. ;) А я дал Вам ссылку на официальную документацию, где даются и объяснения такой настройки.

в документации  написано " оно может уничтожить главный управляющий процесс PostgreSQL (postmaster)" и даются рекомендации как этого избежать выставив overcommit 2 или другую настройку
зачем мне это если у меня НЕ уничтожается управляющий процесс?
коллеги из Postgres.ai наверно не зря писали ./server-audit.sh скрипты для аудита постгрес окружения. И там overcommit 0 - зелененький, а 2 - красненький.

> Вы логи PostgreSQL посмотрите, убедитесь в обратном

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

> Да толку это тут-то показывать? ;( Мы же ни "железа", ни нагрузки не знаем..
c5.4xlarge
16 CPU
$ free -m
             total        used        free      shared  buff/cache   available
Mem:          31149        3095       18508        8456        9546       19151
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Artemii
> Это какие-то неправильные руководства. ;) А я дал Вам ссылку на официальную документацию, где даются и объяснения такой настройки.

в документации  написано " оно может уничтожить главный управляющий процесс PostgreSQL (postmaster)" и даются рекомендации как этого избежать выставив overcommit 2 или другую настройку
зачем мне это если у меня НЕ уничтожается управляющий процесс?
коллеги из Postgres.ai наверно не зря писали ./server-audit.sh скрипты для аудита постгрес окружения. И там overcommit 0 - зелененький, а 2 - красненький.

> Вы логи PostgreSQL посмотрите, убедитесь в обратном

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

> Да толку это тут-то показывать? ;( Мы же ни "железа", ни нагрузки не знаем..
c5.4xlarge
16 CPU
$ free -m
             total        used        free      shared  buff/cache   available
Mem:          31149        3095       18508        8456        9546       19151
> коллеги из Postgres.ai наверно не зря писали ./server-audit.sh скрипты для аудита постгрес окружения. И там overcommit 0 - зелененький, а 2 - красненький.

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

> и один из процессов исполняет мой запрос.  и именно этот запрос прибивается, не задевая управляющий процесс и другие процессы.

А можете это показать?

> c5.4xlarge
Вот этот?
c5.4xlarge   16   32   EBS-Only   Up to 10   4,750
А диски там какие (в списке не видно, я не стал дальше искать)?

Нагрузка по-прежнему неизвестна. Вы хотя бы всё, что у Вас спрашивает http://pgconfigurator.cybertec.at/ , покажите.

И да, можете показать EXPLAIN с 11.8, всё-таки?
источник

h

horpto in pgsql – PostgreSQL
Artemii
это где как - линка на ликбез?
https://postgrespro.ru/docs/postgrespro/10/sql-declare но есть нюансы с пгбаунсером
источник

A

Artemii in pgsql – PostgreSQL
> которые строго противоречат официальной документации

не противоречат. т.к. в официальной документации это описание идёт с пометкой "возможно/может быть в вашем случае", а это не так

> А можете это показать?
postgres@db:~$ ps axuwwf |grep -e postgresql.conf -A0 -e SELECT
postgres 28256  0.0  0.0  12940  1084 pts/0    S+   10:18   0:00  |                       \_ grep -e postgresql.conf -A0 -e SELECT
--
postgres  1358  0.2  0.6 8789252 213432 ?      S    Jul29  11:46 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
--
postgres 27402 48.3  6.9 8806152 2211584 ?     Ds   10:16   0:49  \_ postgres: 11/main: postgres novakid [local] SELECT
#—————————-

Aug  2 10:19:42 db kernel: [306159.019632] [27394]   113 27394  4928905  4901342    9630      21        0             0 psql
Aug  2 10:19:42 db kernel: [306159.019634] [27402]   113 27402  2201655  1271306    4262      12        0             0 postgres
Aug  2 10:19:42 db kernel: [306159.019635] [28951]   113 28951  2197626     2886     104       6        0             0 postgres
Aug  2 10:19:42 db kernel: [306159.019637] Out of memory: Kill process 27394 (psql) score 615 or sacrifice child
Aug  2 10:19:42 db kernel: [306159.023000] Killed process 27394 (psql) total-vm:19715620kB, anon-rss:19604016kB, file-rss:1280kB

#-------------------

ubuntu@db:~$ sudo systemctl status postgresql@11-main.service
● postgresql@11-main.service - PostgreSQL Cluster 11-main
  Loaded: loaded (/lib/systemd/system/postgresql@.service; enabled; vendor preset: enabled)
  Active: active (running) since Wed 2020-07-29 21:16:58 UTC; 3 days ago
 Process: 25688 ExecReload=/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i reload (code=exited, status=0/SUCCESS)
 Process: 1261 ExecStart=/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i start (code=exited, status=0/SUCCESS)
Main PID: 1358 (postgres)
  CGroup: /system.slice/system-postgresql.slice/postgresql@11-main.service
          ├─ 1358 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
...
источник

A

Artemii in pgsql – PostgreSQL
прибился 27394 (psql)
а сам сервер 3 дня работает
источник

A

Artemii in pgsql – PostgreSQL
> И да, можете показать EXPLAIN с 11.8, всё-таки?

так уже ж. 9.6 давно нету - я с него ничего показать не могу. вот EXPLAIN без ANALYZE
┌────────────────────────────────────────────────────────────────────────┐
│                               QUERY PLAN                               │
├────────────────────────────────────────────────────────────────────────┤
│ Seq Scan on log  (cost=0.00..1084061.36 rows=6838436 width=1145) │
└────────────────────────────────────────────────────────────────────────┘
(1 row)

Time: 1.333 ms

почему, кстати, с ANALYZE не помогло? там тоже самое, только данных больше
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Artemii
> которые строго противоречат официальной документации

не противоречат. т.к. в официальной документации это описание идёт с пометкой "возможно/может быть в вашем случае", а это не так

> А можете это показать?
postgres@db:~$ ps axuwwf |grep -e postgresql.conf -A0 -e SELECT
postgres 28256  0.0  0.0  12940  1084 pts/0    S+   10:18   0:00  |                       \_ grep -e postgresql.conf -A0 -e SELECT
--
postgres  1358  0.2  0.6 8789252 213432 ?      S    Jul29  11:46 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
--
postgres 27402 48.3  6.9 8806152 2211584 ?     Ds   10:16   0:49  \_ postgres: 11/main: postgres novakid [local] SELECT
#—————————-

Aug  2 10:19:42 db kernel: [306159.019632] [27394]   113 27394  4928905  4901342    9630      21        0             0 psql
Aug  2 10:19:42 db kernel: [306159.019634] [27402]   113 27402  2201655  1271306    4262      12        0             0 postgres
Aug  2 10:19:42 db kernel: [306159.019635] [28951]   113 28951  2197626     2886     104       6        0             0 postgres
Aug  2 10:19:42 db kernel: [306159.019637] Out of memory: Kill process 27394 (psql) score 615 or sacrifice child
Aug  2 10:19:42 db kernel: [306159.023000] Killed process 27394 (psql) total-vm:19715620kB, anon-rss:19604016kB, file-rss:1280kB

#-------------------

ubuntu@db:~$ sudo systemctl status postgresql@11-main.service
● postgresql@11-main.service - PostgreSQL Cluster 11-main
  Loaded: loaded (/lib/systemd/system/postgresql@.service; enabled; vendor preset: enabled)
  Active: active (running) since Wed 2020-07-29 21:16:58 UTC; 3 days ago
 Process: 25688 ExecReload=/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i reload (code=exited, status=0/SUCCESS)
 Process: 1261 ExecStart=/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i start (code=exited, status=0/SUCCESS)
Main PID: 1358 (postgres)
  CGroup: /system.slice/system-postgresql.slice/postgresql@11-main.service
          ├─ 1358 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
...
> т.к. в официальной документации это описание идёт с пометкой "возможно/может быть в вашем случае", а это не так

Т.е. падение сервера Вас / специалистов Postgres.ai в подобных случаях устраивает? ;)
Аргументы какие-то есть?

> Killed process 27394 (psql) total-vm:19715620kB, anon-rss:19604016kB, file-rss:1280kB

У Вас не процесс PostgreSQL (backend) убивается, а клиент (psql)!

> а сам сервер 3 дня работает

Везёт (пока), то есть.
источник

A

Artemii in pgsql – PostgreSQL
> Т.е. падение сервера Вас / специалистов Postgres.ai в подобных случаях устраивает? ;)
> Аргументы какие-то есть?
> У Вас не процесс PostgreSQL (backend) убивается, а клиент (psql)!

извините, вам сколько лет?
я уже в нескольких сообщениях вам пишу, что прибивается не сервер (НЕ управляющий процесс), а процесс в котором запускается SELECT
и бинго, теперь вы это тоже обнаружили
источник

AG

Alex Gonchar in pgsql – PostgreSQL
Artemii
> Т.е. падение сервера Вас / специалистов Postgres.ai в подобных случаях устраивает? ;)
> Аргументы какие-то есть?
> У Вас не процесс PostgreSQL (backend) убивается, а клиент (psql)!

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