Дуже повільний процес pg_restore.. Can anybody help by advice?

older
Системный администратор (выездная...

Oleh Hrynchuk

8 Jun 2022 8 Jun '22

12:57 p.m.

Привіт усім. Маю стійке переконання, що щось не відтюнено в мене на серваку. Але що не пробував - ефекту нуль. Суть: Є досить здорова база постгреса, під 150 GB. В ній штук 10-12 здорових (5-16 GB) таблиць із здоровими індексами. pg_dump на ній "в 5 смичків" (-j5) відпрацьовує за лічені хвилини. А ось на іншій машині під Ubuntu 18.04 (2 x Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 48 GB RAM, 1TB SSD) pg_restore цієї БД (твкож з -j5) триває 15 годин!!! Які параметри postgresql.conf чи sysctl.conf показати? Де що в консерваторії підкрутити? Коли глянути htop під час pg_restore - всі 12 cores ніби досить рівномірно завантажені (ну в залежності від обробки тих чи інших таблиць), пам"ять також нормально юзається під буфери та кеш.. а всеодно ресториться все з черепашою швидкістю :( Перепробував різні тюнінги "з книжок" та/чи "як пишуть розумні люди в отих ваших інтернетах". І поки-що нуль ефекту :(. Достало... ((( -- Regards, /oleh hrynchuk

Attachments:

attachment.html (text/html — 1.7 KB)

Show replies by date

Mykola Ulianytskyi

8 Jun 8 Jun

1:06 p.m.

New subject: [uanog] Дуже повільний процес pg_restore.. Can anybody help by advice?

Привіт https://www.postgresql.org/docs/current/populate.html -- Best regards, Mykola On Wed, Jun 8, 2022 at 3:57 PM Oleh Hrynchuk wrote:

...

Привіт усім.

Маю стійке переконання, що щось не відтюнено в мене на серваку. Але що не пробував - ефекту нуль.

Суть: Є досить здорова база постгреса, під 150 GB. В ній штук 10-12 здорових (5-16 GB) таблиць із здоровими індексами. pg_dump на ній "в 5 смичків" (-j5) відпрацьовує за лічені хвилини. А ось на іншій машині під Ubuntu 18.04 (2 x Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 48 GB RAM, 1TB SSD) pg_restore цієї БД (твкож з -j5) триває 15 годин!!!

Які параметри postgresql.conf чи sysctl.conf показати? Де що в консерваторії підкрутити?

Коли глянути htop під час pg_restore - всі 12 cores ніби досить рівномірно завантажені (ну в залежності від обробки тих чи інших таблиць), пам"ять також нормально юзається під буфери та кеш.. а всеодно ресториться все з черепашою швидкістю :(

Перепробував різні тюнінги "з книжок" та/чи "як пишуть розумні люди в отих ваших інтернетах". І поки-що нуль ефекту :(. Достало... (((

-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Taras Heichenko

2:20 p.m.

...

On 8 Jun 2022, at 15:57, Oleh Hrynchuk wrote:

Привіт усім.

Маю стійке переконання, що щось не відтюнено в мене на серваку. Але що не пробував - ефекту нуль.

Колись я писав логи такаксу в базу. І спочатку воно йшло добре, а потім сповільнювалось. І достатньо помітно сповільнювалось. Виявилось, що допомагає періодичний запуск команди VACUUM. У мене це було достатньо давно, але ідея приблизно така: мені не потрібна ніяка істроія завантаження і т.п. Мені треба просто завантажити дані в таблиці. Все, що цьому заважє – нафіг. Типу індекси і потім можна побудувати.

...

Суть: Є досить здорова база постгреса, під 150 GB. В ній штук 10-12 здорових (5-16 GB) таблиць із здоровими індексами. pg_dump на ній "в 5 смичків" (-j5) відпрацьовує за лічені хвилини. А ось на іншій машині під Ubuntu 18.04 (2 x Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 48 GB RAM, 1TB SSD) pg_restore цієї БД (твкож з -j5) триває 15 годин!!!

Які параметри postgresql.conf чи sysctl.conf показати? Де що в консерваторії підкрутити?

Коли глянути htop під час pg_restore - всі 12 cores ніби досить рівномірно завантажені (ну в залежності від обробки тих чи інших таблиць), пам"ять також нормально юзається під буфери та кеш.. а всеодно ресториться все з черепашою швидкістю :(

Перепробував різні тюнінги "з книжок" та/чи "як пишуть розумні люди в отих ваших інтернетах". І поки-що нуль ефекту :(. Достало... (((

-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Taras Heichenko tasic@academ.kiev.ua

Vladimir Sharun

2:41 p.m.

Хай, shared memory size у 20% БД та віддати її у Постгрес на його буфера. Років 10-15 тому я експериментував із цією проблемою рестора і там була пряма залежність від наданої пам'яті. Доречі у мускуля така ж хрінота є, залежить від sort_buffer_size кажися. ps: для 150Гб бази 48Гб рами - андерпровіжнінг 20.4.1. Memory shared_buffers (integer) Sets the amount of memory the database server uses for shared memory buffers. The default is typically 128 megabytes (128MB), but might be less if your kernel settings will not support it (as determined during initdb). This setting must be at least 128 kilobytes. However, settings significantly higher than the minimum are usually needed for good performance. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. (Non-default values of BLCKSZ change the minimum value.) This parameter can only be set at server start. If you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system. There are some workloads where even larger settings for shared_buffers are effective, but because PostgreSQL also relies on the operating system cache, it is unlikely that an allocation of more than 40% of RAM to shared_buffers will work better than a smaller amount. Larger settings for shared_buffers usually require a corresponding increase in max_wal_size, in order to spread out the process of writing large quantities of new or changed data over a longer period of time. On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate, so as to leave adequate space for the operating system. 8 червня 2022, 15:57:42, від "Oleh Hrynchuk" : Привіт усім. Маю стійке переконання, що щось не відтюнено в мене на серваку. Але що не пробував - ефекту нуль. Суть: Є досить здорова база постгреса, під 150 GB. В ній штук 10-12 здорових (5-16 GB) таблиць із здоровими індексами. pg_dump на ній "в 5 смичків" (-j5) відпрацьовує за лічені хвилини. А ось на іншій машині під Ubuntu 18.04 (2 x Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 48 GB RAM, 1TB SSD) pg_restore цієї БД (твкож з -j5) триває 15 годин!!! Які параметри postgresql.conf чи sysctl.conf показати? Де що в консерваторії підкрутити? Коли глянути htop під час pg_restore - всі 12 cores ніби досить рівномірно завантажені (ну в залежності від обробки тих чи інших таблиць), пам"ять також нормально юзається під буфери та кеш.. а всеодно ресториться все з черепашою швидкістю :( Перепробував різні тюнінги "з книжок" та/чи "як пишуть розумні люди в отих ваших інтернетах". І поки-що нуль ефекту :(. Достало... ((( -- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

VASYL MELNYK

12 Jun 12 Jun

12:28 p.m.

New subject: [uanog] Дуже повільний процес pg_restore.. Can anybody help by advice?

Не бачу нічого дивно, адже пг_ресторе створює індекси, а 150 гіг це все ж таки не іграшки, швидкість зчитування може суттєво відрізнятись від запису. Та й до всього ссд сата це не ссд нвме - в мене на саті база ледь рухається. Тобто факторів більш ніж до чорта. ср, 8 июн. 2022 г. в 15:57, Oleh Hrynchuk :

...

Привіт усім.

Маю стійке переконання, що щось не відтюнено в мене на серваку. Але що не пробував - ефекту нуль.

Суть: Є досить здорова база постгреса, під 150 GB. В ній штук 10-12 здорових (5-16 GB) таблиць із здоровими індексами. pg_dump на ній "в 5 смичків" (-j5) відпрацьовує за лічені хвилини. А ось на іншій машині під Ubuntu 18.04 (2 x Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 48 GB RAM, 1TB SSD) pg_restore цієї БД (твкож з -j5) триває 15 годин!!!

Які параметри postgresql.conf чи sysctl.conf показати? Де що в консерваторії підкрутити?

Коли глянути htop під час pg_restore - всі 12 cores ніби досить рівномірно завантажені (ну в залежності від обробки тих чи інших таблиць), пам"ять також нормально юзається під буфери та кеш.. а всеодно ресториться все з черепашою швидкістю :(

Перепробував різні тюнінги "з книжок" та/чи "як пишуть розумні люди в отих ваших інтернетах". І поки-що нуль ефекту :(. Достало... (((

-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Oleh Hrynchuk

13 Jun 13 Jun

6:28 a.m.

New subject: [uanog] Дуже повільний процес pg_restore.. Can anybody help by advice?

Дуже дякую усім за консультації! Заспокоївся :) І розглядаємо придбання нового заліза, або винесення геть усього в AWS. нд, 12 черв. 2022 р. о 15:28 VASYL MELNYK пише:

...

Не бачу нічого дивно, адже пг_ресторе створює індекси, а 150 гіг це все ж таки не іграшки, швидкість зчитування може суттєво відрізнятись від запису. Та й до всього ссд сата це не ссд нвме - в мене на саті база ледь рухається.

Тобто факторів більш ніж до чорта.

ср, 8 июн. 2022 г. в 15:57, Oleh Hrynchuk :

...
Привіт усім.

Маю стійке переконання, що щось не відтюнено в мене на серваку. Але що не пробував - ефекту нуль.

Суть: Є досить здорова база постгреса, під 150 GB. В ній штук 10-12 здорових (5-16 GB) таблиць із здоровими індексами. pg_dump на ній "в 5 смичків" (-j5) відпрацьовує за лічені хвилини. А ось на іншій машині під Ubuntu 18.04 (2 x Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 48 GB RAM, 1TB SSD) pg_restore цієї БД (твкож з -j5) триває 15 годин!!!

Які параметри postgresql.conf чи sysctl.conf показати? Де що в консерваторії підкрутити?

Коли глянути htop під час pg_restore - всі 12 cores ніби досить рівномірно завантажені (ну в залежності від обробки тих чи інших таблиць), пам"ять також нормально юзається під буфери та кеш.. а всеодно ресториться все з черепашою швидкістю :(

Перепробував різні тюнінги "з книжок" та/чи "як пишуть розумні люди в отих ваших інтернетах". І поки-що нуль ефекту :(. Достало... (((

-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Regards, /oleh hrynchuk

Maksym Tulyuk

12:37 p.m.

IMHO, треба подивитися на швидкість запису на I/O - якщо pg_restore пише на максимальній швидкості, то треба міняти залізо; якщо ні, то можно піднімати shared_buffers, maintenance_work_mem, wal_buffers, checkpoint_segments або виключати full_page_writes, auto_vacuum та логгінг. Best withes, Maksym On 8 Jun 2022, 14:57 +0200, Oleh Hrynchuk , wrote:

...

Привіт усім.

Маю стійке переконання, що щось не відтюнено в мене на серваку. Але що не пробував - ефекту нуль.

Суть: Є досить здорова база постгреса, під 150 GB. В ній штук 10-12 здорових (5-16 GB) таблиць із здоровими індексами. pg_dump на ній "в 5 смичків" (-j5) відпрацьовує за лічені хвилини. А ось на іншій машині під Ubuntu 18.04 (2 x Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 48 GB RAM, 1TB SSD) pg_restore цієї БД (твкож з -j5) триває 15 годин!!!

Які параметри postgresql.conf чи sysctl.conf показати? Де що в консерваторії підкрутити?

Коли глянути htop під час pg_restore - всі 12 cores ніби досить рівномірно завантажені (ну в залежності від обробки тих чи інших таблиць), пам"ять також нормально юзається під буфери та кеш.. а всеодно ресториться все з черепашою швидкістю :(

Перепробував різні тюнінги "з книжок" та/чи "як пишуть розумні люди в отих ваших інтернетах". І поки-що нуль ефекту :(. Достало... (((

-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

VASYL MELNYK

14 Jun 14 Jun

6:22 a.m.

New subject: [uanog] Дуже повільний процес pg_restore.. Can anybody help by advice?

...

IMHO, треба подивитися на швидкість запису на I/O - якщо pg_restore пише на максимальній швидкості, то треба міняти залізо; якщо ні, то можно піднімати shared_buffers, maintenance_work_mem, wal_buffers, checkpoint_segments або виключати full_page_writes, auto_vacuum та логгінг.

Та ну , Олег же написав - мінімальний тюнинг виконано, а цього для нормальної роботи достатньо. То все що написано то для роботи важливо - не для ресторе.

Oleh Hrynchuk

8:10 a.m.

New subject: [uanog] Дуже повільний процес pg_restore.. Can anybody help by advice?

Привіт, шановні колеги. Ще раз дякую за слушні зауваження! Подивився, перечитав, подумав іще раз, і таки схиляюся до думки, що це моє залізо "не тягне". Там ще у фоні висить купа jdk-процесів, контейнерів і проч. І хоча на вихідні (коли я стартую pg_restore) як правило ніхто їх активно не використовує, проте вони все ж забирають певні ресурси. вт, 14 черв. 2022 р. о 09:22 VASYL MELNYK пише:

...

IMHO, треба подивитися на швидкість запису на I/O - якщо pg_restore пише

...
на максимальній швидкості, то треба міняти залізо; якщо ні, то можно піднімати shared_buffers, maintenance_work_mem, wal_buffers, checkpoint_segments або виключати full_page_writes, auto_vacuum та логгінг.

Та ну , Олег же написав - мінімальний тюнинг виконано, а цього для нормальної роботи достатньо. То все що написано то для роботи важливо - не для ресторе. _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Regards, /oleh hrynchuk

VASYL MELNYK

10:28 a.m.

New subject: [uanog] Дуже повільний процес pg_restore.. Can anybody help by advice?

Я гадаю ти сам чудово розумієш, що тримати бд разом з аплікухою неправильно. В мене давно вже один сервіс - одна віртуалка, виняток тільки для старої бази 1с, але це на віндовс та й там просто без мс скуля воно не живе - один майстер золоті руки колись конфу писав, запустити на линуху не виходить, а витрачати час на це немає сенсу. Ось так і живе. А решта сервісів кожен окремо. вт, 14 июн. 2022 г. в 11:10, Oleh Hrynchuk :

...

Привіт, шановні колеги.

Ще раз дякую за слушні зауваження! Подивився, перечитав, подумав іще раз, і таки схиляюся до думки, що це моє залізо "не тягне". Там ще у фоні висить купа jdk-процесів, контейнерів і проч. І хоча на вихідні (коли я стартую pg_restore) як правило ніхто їх активно не використовує, проте вони все ж забирають певні ресурси.

вт, 14 черв. 2022 р. о 09:22 VASYL MELNYK пише:

...
IMHO, треба подивитися на швидкість запису на I/O - якщо pg_restore пише

...
на максимальній швидкості, то треба міняти залізо; якщо ні, то можно піднімати shared_buffers, maintenance_work_mem, wal_buffers, checkpoint_segments або виключати full_page_writes, auto_vacuum та логгінг.

Та ну , Олег же написав - мінімальний тюнинг виконано, а цього для нормальної роботи достатньо. То все що написано то для роботи важливо - не для ресторе. _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Regards, /oleh hrynchuk

Oleh Hrynchuk

10:52 a.m.

New subject: [uanog] Дуже повільний процес pg_restore.. Can anybody help by advice?

вт, 14 черв. 2022 р. о 13:28 VASYL MELNYK пише:

...

Я гадаю ти сам чудово розумієш, що тримати бд разом з аплікухою неправильно.

+ Але тачка некритична. Чисто для QA. Тому так сталося історично. Жила собі, не тужила, доки об"єми баз не стали ось отакі. Причому практично усі сервіси від початку там розподілені по докер-контейнерах. Лише ось PostgreSQL сам по собі, ну ще Apache2/Nginx.

...

В мене давно вже один сервіс - одна віртуалка, виняток тільки для старої бази 1с, але це на віндовс та й там просто без мс скуля воно не живе - один майстер золоті руки колись конфу писав, запустити на линуху не виходить, а витрачати час на це немає сенсу. Ось так і живе.

А решта сервісів кожен окремо.

І це безумовно правильно. вт, 14 июн. 2022 г. в 11:10, Oleh Hrynchuk :

...

...
Привіт, шановні колеги.

Ще раз дякую за слушні зауваження! Подивився, перечитав, подумав іще раз, і таки схиляюся до думки, що це моє залізо "не тягне". Там ще у фоні висить купа jdk-процесів, контейнерів і проч. І хоча на вихідні (коли я стартую pg_restore) як правило ніхто їх активно не використовує, проте вони все ж забирають певні ресурси.

вт, 14 черв. 2022 р. о 09:22 VASYL MELNYK пише:

...
IMHO, треба подивитися на швидкість запису на I/O - якщо pg_restore пише

...
на максимальній швидкості, то треба міняти залізо; якщо ні, то можно піднімати shared_buffers, maintenance_work_mem, wal_buffers, checkpoint_segments або виключати full_page_writes, auto_vacuum та логгінг.

Та ну , Олег же написав - мінімальний тюнинг виконано, а цього для нормальної роботи достатньо. То все що написано то для роботи важливо - не для ресторе. _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Regards, /oleh hrynchuk

-- Regards, /oleh hrynchuk

967

Age (days ago)

973

Last active (days ago)

List overview

Download

10 comments

6 participants

participants (6)

Maksym Tulyuk
Mykola Ulianytskyi
Oleh Hrynchuk
Taras Heichenko
VASYL MELNYK
Vladimir Sharun

Дуже повільний процес pg_restore.. Can anybody help by advice?

tags

participants (6)