|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
Доброго времени суток! Необходимо догнать архивную базу данными. Это порядка 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, но поработав немного и посбрасывав шустро уже не ускоряется. Может как-то можно умудриться вручную в процессе "пнуть" сервер, чтобы освежить его? Очень желательно не прерывая процесс заливки ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2017, 10:50 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
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.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2017, 11:53 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2017, 13:16 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
MakPolТ.е. диск в основном терзает checkpointer process Как понимаю это идет сброс shared_buffers, которые у меня на сервере 7680MB, но поработав немного и посбрасывав шустро уже не ускоряется. Может как-то можно умудриться вручную в процессе "пнуть" сервер, чтобы освежить его? Очень желательно не прерывая процесс заливки Для начала увеличить размер wal лога (checkpoint_segments или max_wal_size смотря о версии базы) и поднять checkpoint timeout до 1часа хотя бы. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2017, 14:06 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
MakPol, max_wal_size надо с 2GB где-то до 32GB поднять. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2017, 14:15 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
Версия 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) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2017, 14:37 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
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 минуты на файл это пока его можно в память писать а не на диск. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2017, 15:17 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
А 3-4 минуты на файл это пока его можно в память писать а не на диск. В смысле? Имеется в виду tmpfs задействовать? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2017, 16:58 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
MakPolА 3-4 минуты на файл это пока его можно в память писать а не на диск. В смысле? Имеется в виду tmpfs задействовать? Нет это пока он в shared buffers пишется а не начинает реально на диск сбрасываться (не считая WAL конечно). ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2017, 04:23 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
Толком проверить работу пока не удалось. Ночью тупо 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 гигов там было. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2017, 08:47 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
Что-то наивно полагал, что ограничил размер, который максимум у меня может быть в 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 Гб, а то пока лунку не раздобыть больше, а икслоги рядом с базой, что-то не хочется. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2017, 09:17 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
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. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2017, 10:55 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
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 сохраняется. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2017, 11:07 |
|
Затык при записи большого объема при помощи COPY, нужен совет
|
|||
---|---|---|---|
#18+
Maxim BogukМаксимум где то max_wal_size+wal_keep_segments может быть. В вашем случае наверное лучше уменьшать wal_keep_segments и увеличивать max_wal_size. Тоже верно, сделаю так. А на время когда надо базу 4Тб при помощи pg_basebackup тогда альтер сделаю и увеличу wal_keep_segments wal_keep_segments*16MB вроде ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2017, 11:12 |
|
|
start [/forum/topic.php?fid=53&msg=39554131&tid=1996104]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
others: | 294ms |
total: | 423ms |
0 / 0 |