[uanog] =?utf-8?Q?=D0=94=D1=83=D0=B6=D0=B5_=D0=BF=D0=BE=D0=B2=D1=96=D0=BB=D1=8C=D0=BD=D0=B8=D0=B9_=D0=BF=D1=80=D0=BE=D1=86=D0=B5=D1=81_?=pg_restore.. Can anybody help by advice?

[Maksym Tulyuk]

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 <oleh.hrynchuk at gmail.com>, 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 at uanog.kiev.ua
> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20220613/499f56f7/attachment.htm>