Nedostatek pameti po migraci na novy HW

13 views
Skip to first unread message

Tom Ka

unread,
Jun 2, 2021, 5:53:48 AM6/2/21
to PostgreSQL-cz
Dobry den,

rad bych pozadal o radu v nasledujici situaci. Provozuji PostgreSQL verze 11 (posledni verze z repozitare postgresql.org) + PostGIS pro zpracovani dat pro OpenStreetMap. Provedl jsem upgrade na novy HW, kde na starem stroji bylo 64GB RAM, na novem je 96GB RAM. Postgres jsem prenesl s identickym nastavenim (presun disku), PostGIS jsem upgradoval z 2.4 na verzi 2.5. Ulohy, ktere drive (tydny) bezely bez problemu najednou zacaly padat, v logu je videt problem s alokaci pameti. Pri kontrole se opravdu alokuje veskera dostupna pamet. Pri analyze se zpracovavaji data ruznych zemi (oblasti), problem je kupodivu s malymi zememi, velke funguji v poradku. Nakonec jsem dosel k tomu, ze query plan se pro funkcni a nefunkcni zeme lisi nasledovne:

dotaz je:
SELECT array_agg('N' || id::text) AS ids, ST_AsText(geom)
FROM nodes
WHERE   tags - ARRAY['source', 'created_by', 'converted_by', 'attribution'] = ''::hstore
GROUP BY geom
HAVING ST_NPoints(ST_Union(geom)) = 1 AND count(*) > 1

EXPLAIN pro zemi, kde dojde pamet (at_karnten):

HashAggregate  (cost=125155.44..126697.92 rows=53 width=96)
  Group Key: geom
  Filter: ((count(*) > 1) AND (st_npoints(st_union(geom)) = 1))
  ->  Gather  (cost=1000.00..124594.23 rows=32069 width=40)
        Workers Planned: 2
        ->  Parallel Seq Scan on nodes  (cost=0.00..120387.33
rows=13362 width=40)
              Filter: ((tags -
'{source,created_by,converted_by,attribution}'::text[]) = ''::hstore)

Pro zemi, kde funguje: (at_niederostereich)
GroupAggregate  (cost=402538.17..409333.89 rows=166 width=96)
  Group Key: geom
  Filter: ((count(*) > 1) AND (st_npoints(st_union(geom)) = 1))
  ->  Sort  (cost=402538.17..402787.58 rows=99761 width=40)
        Sort Key: geom
        ->  Gather  (cost=1000.00..394254.92 rows=99761 width=40)
              Workers Planned: 2
              ->  Parallel Seq Scan on nodes  (cost=0.00..383278.83
rows=41567 width=40)
                    Filter: ((tags -
'{source,created_by,converted_by,attribution}'::text[]) = ''::hstore)

Rozdil je tedy v provedeni sortu. Mohl by mi prosim nekdo poradit, jaka pamet se v ramci postgres pro tohle pouzije a ktere volby nastaveni tedy zkusit zkontrolovat resp. kde v dokumentaci hledat ohledne chovani pri sprave pameti, ktera se tohoto pripadu tyka?

Pokud pomohou jakekoliv dalsi informace, dejte prosim vedet.

Dekuji za pomoc
Tomas Kasparek.

Tom Ka

unread,
Jun 2, 2021, 6:19:59 AM6/2/21
to PostgreSQL-cz
Diky moc Pavlovi Stehulovi za rychlou tel konzultaci. Problem se "vyresil" pouzitim SET enable_hashagg = off;

Hezky den
Tomas Kasparek


Dne středa 2. června 2021 v 11:53:48 UTC+2 uživatel Tom Ka napsal:

Pavel Stehule

unread,
Jun 2, 2021, 6:30:58 AM6/2/21
to PostgreSQL-cz
Dobry den

st 2. 6. 2021 v 12:20 odesílatel Tom Ka <tomas.k...@gmail.com> napsal:
Diky moc Pavlovi Stehulovi za rychlou tel konzultaci. Problem se "vyresil" pouzitim SET enable_hashagg = off;

Ty geometrie budou asi docela velke, a delat nad nima agregaci v pameti nemusi byt dobry napad. Je mozne ze ve starsim postgisu neexistovala hash funkce pro typ geometrie, tudiz se nemohl pouzit hash aggregate, a tudiz vam to nepadalo. Vypnuti hash agg neni asi uplne idealni - hashagg je rychlejsi, ale neni to delane na extra dlouhe hodnoty.

Vubec je GROUP BY geom dobry napad?

Pavel





--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/7fda3f78-5f0b-45d0-89f8-3487d602ddfan%40googlegroups.com.

Tom Ka

unread,
Jun 2, 2021, 6:36:14 AM6/2/21
to postgr...@googlegroups.com
st 2. 6. 2021 v 12:30 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:
> Ty geometrie budou asi docela velke, a delat nad nima agregaci v pameti nemusi byt dobry napad. Je mozne ze ve starsim postgisu neexistovala hash funkce pro typ geometrie, tudiz se nemohl pouzit hash aggregate, a tudiz vam to nepadalo. Vypnuti hash agg neni asi uplne idealni - hashagg je rychlejsi, ale neni to delane na extra dlouhe hodnoty.
>
> Vubec je GROUP BY geom dobry napad?

Vypnul jsem jen pro konkretni problematicky dotaz. Budu dal
konzultovat s vyvojari toho baliku
(https://wiki.openstreetmap.org/wiki/Osmose), jestli to nejde udelat
nejake lepe.

Diky tom.k

Jan Michálek

unread,
Jun 2, 2021, 8:40:44 AM6/2/21
to postgr...@googlegroups.com
Group by geom, to, si myslim, dobrej nápad není, i když tady to budou patrně jenom body.
Jestli to správně chápu, co to má dělat, tak to má sgrupit atributy, který mají stejnou geometrii.
Na tohle bych já osobně použil nějakou z cluster fcí Postgisu.
ta trvá dlouho, ale je šetrná k paměti. Případně jde použít na to rekurzivní cte.

Je;

st 2. 6. 2021 v 12:36 odesílatel Tom Ka <tomas.k...@gmail.com> napsal:
--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.


--
Jelen
Starší čeledín datovýho chlíva

Tomas Vondra

unread,
Jun 2, 2021, 12:05:20 PM6/2/21
to postgr...@googlegroups.com, Pavel Stehule
On 6/2/21 12:30 PM, Pavel Stehule wrote:
> Dobry den
>
> st 2. 6. 2021 v 12:20 odesílatel Tom Ka <tomas.k...@gmail.com
> <mailto:tomas.k...@gmail.com>> napsal:
>
> Diky moc Pavlovi Stehulovi za rychlou tel konzultaci. Problem se
> "vyresil" pouzitim SET enable_hashagg = off;
>
>
> Ty geometrie budou asi docela velke, a delat nad nima agregaci v pameti
> nemusi byt dobry napad. Je mozne ze ve starsim postgisu neexistovala
> hash funkce pro typ geometrie, tudiz se nemohl pouzit hash aggregate, a
> tudiz vam to nepadalo. Vypnuti hash agg neni asi uplne idealni - hashagg
> je rychlejsi, ale neni to delane na extra dlouhe hodnoty.
>
> Vubec je GROUP BY geom dobry napad?
>

Druhá možnost je že se hashagg povolí díky tomu že od PG13 umí odlévat
data na disk, a tudíž je to bezpečnější. Ale v situaci kdy ta skupin
neustále roste (což např. array_agg splňuje) tak to omezení paměti není
úplně funkční.

Bylo by zajímavé nechat to běžet, naalokovat hodně paměti ale ještě před
pádem z toho vypsat statistiku memory contextů, tj. připojit se přes gdb
a udělat

$ p MemoryContextStats(TopMemoryContext)

celkem spolehlivě ta paměť bude naalokovaná v hashagg.

T.

Pavel Stehule

unread,
Jun 2, 2021, 12:34:35 PM6/2/21
to Tomas Vondra, PostgreSQL-cz


st 2. 6. 2021 v 18:05 odesílatel Tomas Vondra <tv.f...@gmail.com> napsal:
On 6/2/21 12:30 PM, Pavel Stehule wrote:
> Dobry den
>
> st 2. 6. 2021 v 12:20 odesílatel Tom Ka <tomas.k...@gmail.com
> <mailto:tomas.k...@gmail.com>> napsal:
>
>     Diky moc Pavlovi Stehulovi za rychlou tel konzultaci. Problem se
>     "vyresil" pouzitim SET enable_hashagg = off;
>
>
> Ty geometrie budou asi docela velke, a delat nad nima agregaci v pameti
> nemusi byt dobry napad. Je mozne ze ve starsim postgisu neexistovala
> hash funkce pro typ geometrie, tudiz se nemohl pouzit hash aggregate, a
> tudiz vam to nepadalo. Vypnuti hash agg neni asi uplne idealni - hashagg
> je rychlejsi, ale neni to delane na extra dlouhe hodnoty.
>
> Vubec je GROUP BY geom dobry napad?
>

Druhá možnost je že se hashagg povolí díky tomu že od PG13 umí odlévat
data na disk, a tudíž je to bezpečnější. Ale v situaci kdy ta skupin
neustále roste (což např. array_agg splňuje) tak to omezení paměti není
úplně funkční.

ale oni jsou jeste na 11tce.

Tom Ka

unread,
Jun 3, 2021, 1:39:50 AM6/3/21
to postgr...@googlegroups.com
Diky vsem za reakce a pomoc. Po nocnim chroupani vetsiny statu to
vypada, ze vypnuti hash aggregate pro dany dotaz pomohlo a vse jede
stabilne.

Ano, tato uloha hleda duplicity v geometriich, vstupuji do ni dle
konkretni zeme/oblasti jednotky az desitky milionu bodu.

Hezky den tom.k

st 2. 6. 2021 v 18:34 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRAfLTALaBcFFA4kkvPc8kSdkz%3DAGcOTpvCHR8PS%2B8PkjA%40mail.gmail.com.

Pavel Stehule

unread,
Jun 3, 2021, 1:52:36 AM6/3/21
to PostgreSQL-cz


čt 3. 6. 2021 v 7:39 odesílatel Tom Ka <tomas.k...@gmail.com> napsal:
Diky vsem za reakce a pomoc. Po nocnim chroupani vetsiny statu to
vypada, ze vypnuti hash aggregate pro dany dotaz pomohlo a vse jede
stabilne.

kdybyste mel cas, tak tohle by byl hezky test pro Postgres 13. Jestli by tam zafungoval spravne fallback pro hashagg, kdyz se vycerpa workmem

Pavel

Tom Ka

unread,
Jun 3, 2021, 2:18:53 PM6/3/21
to postgr...@googlegroups.com

On Thu, 3 Jun 2021, 07:52 Pavel Stehule, <pavel....@gmail.com> wrote:

kdybyste mel cas, tak tohle by byl hezky test pro Postgres 13. Jestli by tam zafungoval spravne fallback pro hashagg, kdyz se vycerpa workmem

Pavel

Dam si to na TODO list, ted je toho bohuzel hodne, takze spis az tak v cervenci.

Diky tom.k

Pavel Stehule

unread,
Jun 3, 2021, 2:24:18 PM6/3/21
to PostgreSQL-cz


čt 3. 6. 2021 v 20:18 odesílatel Tom Ka <tomas.k...@gmail.com> napsal:
ook, v pohode.

Nekdy by clovek potreboval byt 10x



Diky tom.k

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages