powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Затык при записи большого объема при помощи COPY, нужен совет
14 сообщений из 14, страница 1 из 1
Затык при записи большого объема при помощи COPY, нужен совет
    #39553311
MakPol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброго времени суток!
Необходимо догнать архивную базу данными. Это порядка 30 гигов в файлах для последующего залива при помощи COPY
Файлы по 400 метров идут примерно. В каждом по 15 лямов записей. Заметил, что сначала заливка идет бодро и на заливку такого файла требуется 3-4 минуты, что нормально. Но вот спустя время я вижу, что время возрастает до 12-14 минут. При том что сервер не нагружен в плане запросов. Посмотрел по диску и вижу

DSK | vdc | busy 92% | | read 513 | write 25711 | KiB/r 13 | | KiB/w 21 | MBr/s 0.69 | MBw/s 53.04 | | avq 74.95 | avio 0.35 ms

и если смотреть кто же грузит, то в atop вижу
PID DSK COMMAND-LINE
4827 85% postgres: checkpointer process
31445 12% postgres: wal writer process
9462 3% postgres: postgres zabbix [local] COPY
17363 0% postgres: stats collector process
Т.е. диск в основном терзает checkpointer process
Как понимаю это идет сброс shared_buffers, которые у меня на сервере 7680MB, но поработав немного и посбрасывав шустро уже не ускоряется.
Может как-то можно умудриться вручную в процессе "пнуть" сервер, чтобы освежить его?
Очень желательно не прерывая процесс заливки
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39553355
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MakPol,

Скормите этот запрос `psql` (как есть) и приведите результат:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
SELECT round(100.0*checkpoints_req/checkpoints,1)                                                  "Forced checkpoint ratio (%)",
       round(min_since_reset/checkpoints,2)                                                        "Minutes between checkpoints",
       round(checkpoint_write_time::numeric/(checkpoints*1000),2)                                  "Average write time per checkpoint (s)",
       round(checkpoint_sync_time::numeric/(checkpoints*1000),2)                                   "Average sync time per checkpoint (s)",
       round(total_buffers/128.0,1)                                                                "Total MB written",
       round(buffers_checkpoint/(128.0*checkpoints),2)                                             "MB per checkpoint",
       round(buffers_checkpoint/(128.0*min_since_reset*60),2)                                      "Checkpoint MBps",
       round(buffers_clean/(128.0*min_since_reset*60),2)                                           "`bgwriter` MBps",
       round(buffers_backend/(128.0*min_since_reset*60),2)                                         "Backend MBps",
       round(total_buffers/(128.0*min_since_reset*60),4)                                           "Total MBps",
       round(100.0*buffers_checkpoint/total_buffers,1)                                             "Clean by checkpoints (%)",
       round(100.0*buffers_clean/total_buffers,1)                                                  "Clean by `bgwriter` (%)",
       round(100.0*buffers_backend/total_buffers,1)                                                "Clean by backends (%)",
       round(100.0*maxwritten_clean/(min_since_reset*60000/bgwriter_delay),2)                      "`bgwriter` halt-only length (buffers)",
       coalesce(round(100.0*maxwritten_clean/(nullif(buffers_clean,0)/bgwriter_lru_maxpages),2),0) "`bgwriter` halt ratio (%)",
       round(1.0*buffers_alloc/total_buffers,3)                                                    "New buffer allocation ratio",
       min_since_reset                                                                             "Minutes since reset",
       now()-pg_postmaster_start_time()                                                            "Uptime",
       '-------'                                                                                   "-------------------------------------",
       *
  FROM (
    SELECT checkpoints_timed,
           checkpoints_req,
           checkpoints_timed + checkpoints_req checkpoints,
           checkpoint_sync_time,
           checkpoint_write_time,
           buffers_checkpoint,
           buffers_clean,
           maxwritten_clean,
           buffers_backend,
           buffers_backend_fsync,
           buffers_alloc,
           buffers_checkpoint + buffers_clean + buffers_backend total_buffers,
           pg_postmaster_start_time() startup,
           stats_reset,
           round(extract('epoch' from now() - stats_reset)/60)::numeric min_since_reset,
           delay.setting::numeric bgwriter_delay,
           lru.setting::numeric bgwriter_lru_maxpages,
           ratio.setting::numeric bgwriter_lru_multiplier,
           ckpt_s.setting::numeric max_wal_size,
           ckpt_t.setting::numeric checkpoint_timeout
      FROM pg_stat_bgwriter
      JOIN pg_settings lru   ON lru.name = 'bgwriter_lru_maxpages'
      JOIN pg_settings delay ON delay.name = 'bgwriter_delay'
      JOIN pg_settings ratio ON ratio.name = 'bgwriter_lru_multiplier'
      JOIN pg_settings ckpt_s ON ckpt_s.name = 'max_wal_size'
      JOIN pg_settings ckpt_t ON ckpt_t.name = 'checkpoint_timeout'
        ) bgstats\x\g\x
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39553434
MakPol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Name |Value
-------------------------------------|---------------------------------------------------
Forced checkpoint ratio (%) |96.8
Minutes between checkpoints |1.03
Average write time per checkpoint (s)|48.91
Average sync time per checkpoint (s) |2.78
Total MB written |298163.6
MB per checkpoint |583.20
Checkpoint MBps |9.46
`bgwriter` MBps |0.01
Backend MBps |2.41
Total MBps |11.8885
Clean by checkpoints (%) |79.6
Clean by `bgwriter` (%) |0.1
Clean by backends (%) |20.3
`bgwriter` halt-only length (buffers)|0.16
`bgwriter` halt ratio (%) |58.77
New buffer allocation ratio |0.244
Minutes since reset |418
Uptime |0 years 0 mons 0 days 7 hours 6 mins 54.643957 secs
-------------------------------------|-------
checkpoints_timed |13
checkpoints_req |394
checkpoints |407
checkpoint_sync_time |1130250
checkpoint_write_time |19907329
buffers_checkpoint |30382626
buffers_clean |34371
maxwritten_clean |202
buffers_backend |7747948
buffers_backend_fsync |0
buffers_alloc |9323780
total_buffers |38164945
startup |2017-11-15 06:08:06
stats_reset |2017-11-15 06:16:52
min_since_reset |418
bgwriter_delay |200
bgwriter_lru_maxpages |100
bgwriter_lru_multiplier |2
max_wal_size |128
checkpoint_timeout |3600
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39553521
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MakPolТ.е. диск в основном терзает checkpointer process
Как понимаю это идет сброс shared_buffers, которые у меня на сервере 7680MB, но поработав немного и посбрасывав шустро уже не ускоряется.
Может как-то можно умудриться вручную в процессе "пнуть" сервер, чтобы освежить его?
Очень желательно не прерывая процесс заливки

Для начала увеличить размер wal лога (checkpoint_segments или max_wal_size смотря о версии базы) и поднять checkpoint timeout до 1часа хотя бы.
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39553537
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MakPol,

max_wal_size надо с 2GB где-то до 32GB поднять.
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39553565
MakPol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Версия 9.5
# show checkpoint_timeout ;
checkpoint_timeout
--------------------
1h

Попробовал поднять
postgres=# show max_wal_size ;
max_wal_size
--------------
2GB
(1 row)

postgres=# alter system set max_wal_size to "32GB";
ALTER SYSTEM

postgres=# select pg_reload_conf();
pg_reload_conf
----------------
t
(1 row)

postgres=# show max_wal_size ;
max_wal_size
--------------
32GB
(1 row)
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39553616
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MakPolВерсия 9.5
# show checkpoint_timeout ;
checkpoint_timeout
--------------------
1h

Попробовал поднять
postgres=# show max_wal_size ;
max_wal_size
--------------
2GB
(1 row)

postgres=# alter system set max_wal_size to "32GB";
ALTER SYSTEM

postgres=# select pg_reload_conf();
pg_reload_conf
----------------
t
(1 row)

postgres=# show max_wal_size ;
max_wal_size
--------------
32GB
(1 row)


да как то так... но dirty buffers так или иначе надо будет сбрасывать на диск в какой то момент, и если диск у вас тормозной то установившаяся скорость записи будет именно такая как вы описали скорее всего. А 3-4 минуты на файл это пока его можно в память писать а не на диск.
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39553729
MakPol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А 3-4 минуты на файл это пока его можно в память писать а не на диск.
В смысле? Имеется в виду tmpfs задействовать?
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39553965
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MakPolА 3-4 минуты на файл это пока его можно в память писать а не на диск.
В смысле? Имеется в виду tmpfs задействовать?

Нет это пока он в shared buffers пишется а не начинает реально на диск сбрасываться (не считая WAL конечно).
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39554026
MakPol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Толком проверить работу пока не удалось. Ночью тупо pg_xlog забился после увеличения max_wal_size с 2GB до 32GB и сервер сказал...
2017-11-15 20:46:19 UTC [28111]: [6-1] PANIC: could not write to file "pg_xlog/xlogtemp.28111": No space left on device
2017-11-15 20:46:19 UTC 127.0.0.1(42428) [1636]: [1-1] FATAL: the database system is in recovery mode
2017-11-15 20:46:19 UTC 127.0.0.1(42429) [1637]: [1-1] FATAL: the database system is in recovery mode
2017-11-15 20:46:20 UTC 172.25.59.60(45931) [1648]: [1-1] FATAL: the database system is in recovery mode
2017-11-15 20:46:20 UTC 172.25.59.60(45932) [1649]: [1-1] FATAL: the database system is in recovery mode
2017-11-15 20:46:20 UTC 172.25.59.60(45933) [1650]: [1-1] FATAL: the database system is in recovery mode
2017-11-15 20:46:20 UTC 172.25.59.60(45934) [1651]: [1-1] FATAL: the database system is in recovery mode
2017-11-15 20:46:20 UTC 172.25.59.60(45935) [1652]: [1-1] FATAL: the database system is in recovery mode
2017-11-15 20:46:20 UTC 172.25.59.60(45936) [1653]: [1-1] FATAL: the database system is in recovery mode
2017-11-15 20:46:20 UTC 127.0.0.1(42430) [1663]: [1-1] FATAL: the database system is in recovery mode
2017-11-15 20:46:20 UTC 127.0.0.1(42431) [1664]: [1-1] FATAL: the database system is in recovery mode
2017-11-15 20:46:21 UTC [4817]: [8-1] LOG: startup process (PID 28111) was terminated by signal 6: Aborted
2017-11-15 20:46:21 UTC [4817]: [9-1] LOG: aborting startup due to startup process failure
Там у меня лунка была отдельно подцеплена и 90 гигов там было.
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39554048
MakPol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Что-то наивно полагал, что ограничил размер, который максимум у меня может быть в pg_xlog параметром wal_keep_segments
Но...
wal_keep_segments (integer)
Задаёт минимальное число файлов прошлых сегментов журнала, которые будут сохраняться в каталоге pg_xlog, чтобы резервный сервер мог выбрать их при потоковой репликации. Обычно сегмент имеет размер 16 мегабайт. Если резервный сервер, подключённый к передающему, отстаёт больше чем на wal_keep_segments сегментов, передающий удаляет сегменты WAL, всё ещё необходимые резервному, и в этом случае соединение репликации прерывается. В результате этого затем также будут прерваны зависимые соединения. (Однако резервный сервер сможет восстановиться, выбрав этот сегмент из архива, если осуществляется архивация WAL.)

Этот параметр задаёт только минимальное число сегментов, сохраняемое в каталоге pg_xlog; система может сохранить больше сегментов для архивации WAL или для восстановления с момента контрольной точки. Если wal_keep_segments равен нулю (это значение по умолчанию), система не сохраняет никакие дополнительные сегменты для резервных серверов, поэтому число старых сегментов WAL, доступных для резервных серверов, зависит от положения предыдущей контрольной точи и состояния архивации WAL. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.

Я же стал реплику pg_basebackup еще догонять и приехали...

Может кто ткнет носом, как я могу настроить постгрю так, чтобы pg_xlog ни при каких не перевалило за 85 Гб, а то пока лунку не раздобыть больше, а икслоги рядом с базой, что-то не хочется.
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39554131
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MakPolЧто-то наивно полагал, что ограничил размер, который максимум у меня может быть в pg_xlog параметром wal_keep_segments
Но...
wal_keep_segments (integer)
Задаёт минимальное число файлов прошлых сегментов журнала, которые будут сохраняться в каталоге pg_xlog, чтобы резервный сервер мог выбрать их при потоковой репликации. Обычно сегмент имеет размер 16 мегабайт. Если резервный сервер, подключённый к передающему, отстаёт больше чем на wal_keep_segments сегментов, передающий удаляет сегменты WAL, всё ещё необходимые резервному, и в этом случае соединение репликации прерывается. В результате этого затем также будут прерваны зависимые соединения. (Однако резервный сервер сможет восстановиться, выбрав этот сегмент из архива, если осуществляется архивация WAL.)

Этот параметр задаёт только минимальное число сегментов, сохраняемое в каталоге pg_xlog; система может сохранить больше сегментов для архивации WAL или для восстановления с момента контрольной точки. Если wal_keep_segments равен нулю (это значение по умолчанию), система не сохраняет никакие дополнительные сегменты для резервных серверов, поэтому число старых сегментов WAL, доступных для резервных серверов, зависит от положения предыдущей контрольной точи и состояния архивации WAL. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.

Я же стал реплику pg_basebackup еще догонять и приехали...

Может кто ткнет носом, как я могу настроить постгрю так, чтобы pg_xlog ни при каких не перевалило за 85 Гб, а то пока лунку не раздобыть больше, а икслоги рядом с базой, что-то не хочется.

Максимум где то max_wal_size+wal_keep_segments может быть.
В вашем случае наверное лучше уменьшать wal_keep_segments и увеличивать max_wal_size.
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39554152
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MakPolМожет кто ткнет носом, как я могу настроить постгрю так, чтобы pg_xlog ни при каких не перевалило за 85 Гб
Никак.
Нет настройки ограничения максимального объёма wal. Зато есть гайки, которые могут ещё дополнительно задержать удаление старых wal: https://toster.ru/q/478884#answer_1126741

Maxim BogukМаксимум где то max_wal_size+wal_keep_segments может быть
А не дважды max_wal_size? wal же до 11 версии за 2 checkpoint сохраняется.
...
Рейтинг: 0 / 0
Затык при записи большого объема при помощи COPY, нужен совет
    #39554158
MakPol
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim BogukМаксимум где то max_wal_size+wal_keep_segments может быть.
В вашем случае наверное лучше уменьшать wal_keep_segments и увеличивать max_wal_size.
Тоже верно, сделаю так. А на время когда надо базу 4Тб при помощи pg_basebackup тогда альтер сделаю и увеличу wal_keep_segments
wal_keep_segments*16MB вроде
...
Рейтинг: 0 / 0
14 сообщений из 14, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Затык при записи большого объема при помощи COPY, нужен совет
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]