Привіт 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

Хай, 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

Дуже дякую усім за консультації! Заспокоївся :) І розглядаємо придбання нового заліза, або винесення геть усього в 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

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

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

Я гадаю ти сам чудово розумієш, що тримати бд разом з аплікухою неправильно. В мене давно вже один сервіс - одна віртуалка, виняток тільки для старої бази 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