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

Vladimir Sharun vladimir.sharun at ukr.net
Wed Jun 8 17:41:03 EEST 2022


Хай,

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" <oleh.hrynchuk at gmail.com>:

Привіт усім.

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

Суть:
Є досить здорова база постгреса, під 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/20220608/50cba9da/attachment-0001.htm>


More information about the uanog mailing list