Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
autovacuum_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas av varje autovacuum-arbetsprocess. |
| Datatyp | integer |
| Standardvärde | -1 |
| Tillåtna värden | -1-2097151 |
| Parametertyp | dynamic |
| Documentation | autovacuum_work_mem |
commit_timestamp_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger storleken på den dedikerade buffertpoolen som används för commit tidsstämpelcache. Ange 0 så att det här värdet bestäms som en bråkdel av shared_buffers. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 0-131072 |
| Parametertyp | statiskt |
| Documentation | commit_timestamp_buffers |
dynamisk_delat_minnestyp
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den dynamiska implementering av delat minne som används. |
| Datatyp | enumeration |
| Standardvärde | posix |
| Tillåtna värden | posix |
| Parametertyp | skrivskyddad |
| Documentation | dynamic_shared_memory_type |
hash_mem_multiplier
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Flera av de "work_mem" som ska användas för hash-tabeller. |
| Datatyp | numerisk |
| Standardvärde | 2 |
| Tillåtna värden | 1-1000 |
| Parametertyp | dynamic |
| Documentation | hash_mem_multiplier |
huge_pages
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Användning av stora sidor i Linux eller Windows. |
| Datatyp | enumeration |
| Standardvärde | try |
| Tillåtna värden | on,off,try |
| Parametertyp | statiskt |
| Documentation | huge_pages |
Description
Enorma sidor är en funktion som gör att minne kan hanteras i större block. Du kan vanligtvis hantera block på upp till 2 MB, till skillnad från standardsidorna på 4 KB.
Att använda stora sidor kan ge prestandafördelar som effektivt avlastar processorn:
- De minskar overheaden kopplad till minneshanteringsuppgifter, som färre TLB-missar (translation lookaside buffer).
- De förkortar den tid som krävs för minneshantering.
Mer specifikt kan du i PostgreSQL endast använda stora sidor för det delade minnesområdet. En betydande del av det delade minnesområdet allokeras för delade buffertar.
En annan fördel är att stora sidor förhindrar att det delade minnesområdet växlas ut till disken, vilket ytterligare stabiliserar prestandan.
Recommendations
- För servrar som har betydande minnesresurser bör du undvika att inaktivera stora sidor. Om du inaktiverar stora sidor kan prestandan försämras.
- Om du börjar med en mindre server som inte stöder stora sidor, men du förväntar dig att skala upp till en server som gör det, behåll
huge_pagesinställningenTRYför sömlös övergång och optimala prestanda.
Azure-specifika anteckningar
För servrar med fyra eller fler virtuella kärnor allokeras enorma sidor automatiskt från det underliggande operativsystemet. Funktionen är inte tillgänglig för servrar med färre än fyra virtuella kärnor. Antalet stora sidor justeras automatiskt om några inställningar för delat minne ändras, inklusive ändringar i shared_buffers.
storsida_storlek
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Storleken på storsidan som ska begäras. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0 |
| Parametertyp | skrivskyddad |
| Documentation | huge_page_size |
io_combine_limit
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Begränsa storleken på dataläsningar och skrivningar. |
| Datatyp | integer |
| Standardvärde | 16 |
| Tillåtna värden | 1-128 |
| Parametertyp | dynamic |
| Documentation | io_combine_limit |
io_max_combine_limit
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Serveromfattande begränsning som begränsar io_combine_limit. |
| Datatyp | integer |
| Standardvärde | 16 |
| Tillåtna värden | 1-128 |
| Parametertyp | dynamic |
| Documentation | io_max_combine_limit |
io_max_concurrency
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Maximalt antal IO:er som en process kan köra samtidigt. |
| Datatyp | integer |
| Standardvärde | 64 |
| Tillåtna värden | -1-1024 |
| Parametertyp | statiskt |
| Documentation | io_max_concurrency |
io_metod
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer metoden för att köra asynkron I/O. |
| Datatyp | enumeration |
| Standardvärde | worker |
| Tillåtna värden | worker,sync |
| Parametertyp | statiskt |
| Documentation | io_method |
io-arbetare
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Antal I/O-arbetsprocesser för io_method=worker. |
| Datatyp | integer |
| Standardvärde | 3 |
| Tillåtna värden | 1-32 |
| Parametertyp | dynamic |
| Documentation | io_workers |
logical_decoding_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för logisk avkodning. Så mycket minne kan användas av varje intern omordningsbuffert innan den spills till disken. |
| Datatyp | integer |
| Standardvärde | 65536 |
| Tillåtna värden | 64-2147483647 |
| Parametertyp | dynamic |
| Documentation | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för underhållsåtgärder. Detta omfattar åtgärder som VACUUM och CREATE INDEX. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 1024-2097151 |
| Parametertyp | dynamic |
| Documentation | maintenance_work_mem |
Description
maintenance_work_mem är en konfigurationsparameter i PostgreSQL. Den styr mängden minne som allokeras för underhållsåtgärder, till exempel VACUUM, CREATE INDEXoch ALTER TABLE. Till skillnad från work_mem, som påverkar minnesallokering för frågeåtgärder, maintenance_work_mem är reserverad för uppgifter som underhåller och optimerar databasstrukturen.
! [OBS] Om du anger
maintenance_work_memtill för aggressiva värden kan det med jämna mellanrum orsaka ett minnesfel i systemet. Det är mycket viktigt att förstå mängden minne som är tillgängligt på servern och antalet samtidiga åtgärder som kan allokera minne för de uppgifter som beskrevs tidigare innan du gör ändringar i den här parametern.
Huvudpunkter
-
Vakuumminneslock: Om du vill påskynda rensningen av döda tupplar genom att öka
maintenance_work_membör du vara medveten om att detVACUUMhar en inbyggd begränsning för insamling av döda tupplar. Den kan bara använda upp till 1 GB minne för den här processen. -
Separation av minne för autovacuum: Du kan använda inställningen
autovacuum_work_memför att styra det minne som autovacuum-åtgärder använder oberoende av varandra. Den här inställningen fungerar som en delmängd avmaintenance_work_mem. Du kan bestämma hur mycket minne autovacuum använder utan att påverka minnesallokeringen för andra underhållsaktiviteter och datadefinitionsåtgärder.
Azure-specifika anteckningar
Standardvärdet för maintenance_work_mem serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval i beräkningen som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen maintenance_work_mem .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern maintenance_work_mem enligt värdena i följande formel.
Formeln som används för att beräkna värdet maintenance_work_mem för är (long)(82.5 * ln(memoryGiB) + 40) * 1024.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | maintenance_work_mem |
|---|---|
| 2 GiB | 99 328 KiB |
| 4 GiB | 157 696 KiB |
| 8 GiB | 216 064 KiB |
| 16 GiB | 274 432 KiB |
| 32 GiB | 332 800 KiB |
| 48 GiB | 367 616 KiB |
| 64 GiB | 392 192 KiB |
| 80 GiB | 410 624 KiB |
| 128 GiB | 450 560 KiB |
| 160 GiB | 468 992 KiB |
| 192 GiB | 484 352 KiB |
| 256 GiB | 508 928 KiB |
| 384 GiB | 542 720 KiB |
| 432 GiB | 552 960 KiB |
| 672 GiB | 590 848 KiB |
max_förberedda_transaktioner
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet samtidiga förberedda transaktioner. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0-262143 |
| Parametertyp | statiskt |
| Documentation | max_prepared_transactions |
max_stack_depth
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Ställer in maximal stackdjup i kilobyte. |
| Datatyp | integer |
| Standardvärde | 2048 |
| Tillåtna värden | 2048 |
| Parametertyp | skrivskyddad |
| Documentation | max_stack_depth |
min_dynamiskt_delat_minne
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Mängden dynamiskt delat minne som reserverats vid start. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0 |
| Parametertyp | skrivskyddad |
| Documentation | min_dynamic_shared_memory |
multixact_medlem_buffertar
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger storleken på den dedikerade buffertpoolen som används för MultiXact-medlemscachen. |
| Datatyp | integer |
| Standardvärde | 32 |
| Tillåtna värden | 16-131072 |
| Parametertyp | statiskt |
| Documentation | multixact_member_buffers |
multixact_offset_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger storleken på den dedikerade buffertpoolen som används för MultiXact-offsetcacheminnet. |
| Datatyp | integer |
| Standardvärde | 16 |
| Tillåtna värden | 16-131072 |
| Parametertyp | statiskt |
| Documentation | multixact_offset_buffers |
notify_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger storleken på den dedikerade buffertpoolen som används för LISTEN/NOTIFY-meddelandecachen. |
| Datatyp | integer |
| Standardvärde | 16 |
| Tillåtna värden | 16-131072 |
| Parametertyp | statiskt |
| Documentation | notify_buffers |
serialiserbara_buffertar
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger storleken på den dedikerade buffertpoolen som används för serialiserbar transaktionscache. |
| Datatyp | integer |
| Standardvärde | 32 |
| Tillåtna värden | 16-131072 |
| Parametertyp | statiskt |
| Documentation | serializable_buffers |
shared_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger antalet buffertar för delat minne som används av servern. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 16-1073741823 |
| Parametertyp | statiskt |
| Documentation | shared_buffers |
Description
Konfigurationsparametern shared_buffers avgör hur mycket systemminne som allokeras till PostgreSQL-databasen för buffring av data. Den fungerar som en centraliserad minnespool som är tillgänglig för alla databasprocesser.
När data behövs kontrollerar databasprocessen först den delade bufferten. Om nödvändiga data finns hämtas de snabbt och kringgår en mer tidskrävande diskläsning. Delade buffertar fungerar som mellanhand mellan databasprocesserna och disken och minskar effektivt antalet nödvändiga I/O-åtgärder.
Azure-specifika anteckningar
Standardvärdet för shared_buffers serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval till den beräkning som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen shared_buffers .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern shared_buffers enligt värdena i följande formler.
För virtuella datorer med upp till 2 GiB minne, används formeln shared_buffers för att beräkna värdet av memoryGib * 16384.
För virtuella datorer med mer än 2 GiB är shared_buffers formeln som används för att beräkna värdet memoryGib * 32768.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
delat_minne_typ
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den implementering av delat minne som används för huvudregionen för delat minne. |
| Datatyp | enumeration |
| Standardvärde | mmap |
| Tillåtna värden | mmap |
| Parametertyp | skrivskyddad |
| Documentation | delad_minne_typ |
subtransaction_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger storleken på den dedikerade buffertpoolen som används för underöverföringscacheminnet. Ange 0 så att det här värdet bestäms som en bråkdel av shared_buffers. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 0-131072 |
| Parametertyp | statiskt |
| Documentation | subtransaction_buffers |
temp_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet tillfälliga buffertar som används av varje session. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 100-1073741823 |
| Parametertyp | dynamic |
| Documentation | temp_buffers |
transaction_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger storleken på den dedikerade buffertpoolen som används för transaktionsstatuscachen. Ange 0 så att det här värdet bestäms som en bråkdel av shared_buffers. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 0-131072 |
| Parametertyp | statiskt |
| Documentation | transaction_buffers |
vacuum_buffer_usage_limit
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger buffertpoolens storlek för VACUUM, ANALYZE och autovacuum. |
| Datatyp | integer |
| Standardvärde | 2048 |
| Tillåtna värden | 0-16777216 |
| Parametertyp | dynamic |
| Documentation | vacuum_buffer_usage_limit |
work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för frågearbetsytor. Så mycket minne kan användas av varje intern sorteringsåtgärd och hashtabell innan du växlar till tillfälliga diskfiler. |
| Datatyp | integer |
| Standardvärde | 4096 |
| Tillåtna värden | 4096-2097151 |
| Parametertyp | dynamic |
| Documentation | work_mem |
Description
Parametern work_mem i PostgreSQL styr mängden minne som allokerats för vissa interna åtgärder i varje databassessions privata minnesområde. Exempel på dessa åtgärder är sortering och hashning.
Till skillnad från delade buffertar, som finns i det delade minnesområdet, work_mem allokeras i ett privat minnesutrymme per session eller per fråga. Genom att ange en lämplig work_mem storlek kan du avsevärt förbättra effektiviteten för dessa åtgärder och minska behovet av att skriva tillfälliga data till disk.
Huvudpunkter
-
Privat anslutningsminne:
work_memär en del av det privata minne som varje databassession använder. Det här minnet skiljer sig från det delade minnesområde somshared_buffersanvänds. -
Frågespecifik användning: Alla sessioner eller frågor använder inte
work_mem. Enkla frågor somSELECT 1är osannolika att krävawork_mem. Komplexa förfrågningar som omfattar åtgärder som sortering eller hashning kan dock använda ett eller flera segment avwork_mem. -
Parallella åtgärder: För frågor som sträcker sig över flera parallella serverdelar kan varje serverdel potentiellt använda ett eller flera segment av
work_mem.
Övervaka och justera work_mem
Det är viktigt att kontinuerligt övervaka systemets prestanda och justera work_mem vid behov, främst om frågekörningstiderna relaterade till sorterings- eller hashåtgärder är långsamma. Här är sätt att övervaka prestanda med hjälp av verktyg som är tillgängliga i Azure-portalen:
-
Insikt om frågeprestanda: Kontrollera fliken De vanligaste frågorna efter temporära filer för att identifiera frågor som genererar tillfälliga filer. Den här situationen tyder på ett potentiellt behov av att öka
work_mem. - Felsökningsguider: Använd fliken Höga temporära filer i felsökningsguiderna för att identifiera problematiska frågor.
Detaljerad justering
När du hanterar parametern work_mem är det ofta mer effektivt att använda en detaljerad justeringsmetod i stället för att ange ett globalt värde. Den här metoden säkerställer att du allokerar minne på ett omdömesgillt sätt baserat på de specifika behoven hos processer och användare. Det minimerar också risken för problem med minnesbrist. Så här kan du gå till väga:
Användarnivå: Om en specifik användare främst är involverad i aggregerings- eller rapporteringsuppgifter, som är minnesintensiva, bör du överväga att anpassa värdet för den
work_memanvändaren.ALTER ROLEAnvänd kommandot för att förbättra prestandan för användarens åtgärder.Funktions-/procedurnivå: Om specifika funktioner eller procedurer genererar betydande temporära filer kan det vara fördelaktigt att öka
work_memvärdet på den specifika funktions- eller procedurnivån.ALTER FUNCTIONAnvänd kommandot ellerALTER PROCEDUREför att specifikt allokera mer minne till dessa åtgärder.Databasnivå: Ändra
work_mempå databasnivå om endast specifika databaser genererar ett stort antal temporära filer.Global nivå: Om en analys av systemet visar att de flesta frågor genererar små temporära filer, medan bara ett fåtal skapar stora filer, kan det vara klokt att öka
work_memvärdet globalt. Den här åtgärden underlättar för de flesta frågor att bearbeta i minnet, så att du kan undvika diskbaserade åtgärder och förbättra effektiviteten. Var dock alltid försiktig och övervaka minnesanvändningen på servern för att säkerställa att den kan hantera det ökadework_memvärdet.
Fastställa det minsta work_mem värdet för sorteringsåtgärder
Om du vill hitta det minsta work_mem värdet för en specifik fråga, särskilt en som genererar tillfälliga diskfiler under sorteringsprocessen, börjar du med att överväga den tillfälliga filstorlek som genererades under frågekörningen. Om en fråga till exempel genererar en temporär fil på 20 MB:
- Anslut till databasen med hjälp av psql eller önskad PostgreSQL-klient.
- Ange ett initialt
work_memvärde som är något högre än 20 MB för att ta hänsyn till ytterligare rubriker vid bearbetning i minnet. Använd ett kommando som:SET work_mem TO '25MB'. - Kör
EXPLAIN ANALYZEpå den problematiska frågan i samma session. - Granska utdata för
"Sort Method: quicksort Memory: xkB". Om det anger"external merge Disk: xkB", höj värdet förwork_memstegvis och testa igen tills"quicksort Memory"visas. Utseendet på"quicksort Memory"signalerar att frågan nu körs i minnet. - När du har fastställt värdet via den här metoden kan du använda det antingen globalt eller på mer detaljerade nivåer (enligt beskrivningen tidigare) för att passa dina driftbehov.
autovacuum_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas av varje autovacuum-arbetsprocess. |
| Datatyp | integer |
| Standardvärde | -1 |
| Tillåtna värden | -1-2097151 |
| Parametertyp | dynamic |
| Documentation | autovacuum_work_mem |
commit_timestamp_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger mängden minne som ska användas för att cachelagrar innehållet i pg_commit_ts. Enheten är 8 kB. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 0-131072 |
| Parametertyp | statiskt |
| Documentation | commit_timestamp_buffers |
dynamisk_delat_minnestyp
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den dynamiska implementering av delat minne som används. |
| Datatyp | enumeration |
| Standardvärde | posix |
| Tillåtna värden | posix |
| Parametertyp | skrivskyddad |
| Documentation | dynamic_shared_memory_type |
hash_mem_multiplier
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Flera av work_mem som ska användas för hash-tabeller. |
| Datatyp | numerisk |
| Standardvärde | 2 |
| Tillåtna värden | 1-1000 |
| Parametertyp | dynamic |
| Documentation | hash_mem_multiplier |
huge_pages
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Aktiverar/inaktiverar användningen av stora minnessidor. Den här inställningen gäller inte för servrar som har mindre än 4 virtuella kärnor. |
| Datatyp | enumeration |
| Standardvärde | try |
| Tillåtna värden | on,off,try |
| Parametertyp | statiskt |
| Documentation | huge_pages |
Description
Enorma sidor är en funktion som gör att minne kan hanteras i större block. Du kan vanligtvis hantera block på upp till 2 MB, till skillnad från standardsidorna på 4 KB.
Att använda stora sidor kan ge prestandafördelar som effektivt avlastar processorn:
- De minskar overheaden kopplad till minneshanteringsuppgifter, som färre TLB-missar (translation lookaside buffer).
- De förkortar den tid som krävs för minneshantering.
Mer specifikt kan du i PostgreSQL endast använda stora sidor för det delade minnesområdet. En betydande del av det delade minnesområdet allokeras för delade buffertar.
En annan fördel är att stora sidor förhindrar att det delade minnesområdet växlas ut till disken, vilket ytterligare stabiliserar prestandan.
Recommendations
- För servrar som har betydande minnesresurser bör du undvika att inaktivera stora sidor. Om du inaktiverar stora sidor kan prestandan försämras.
- Om du börjar med en mindre server som inte stöder stora sidor, men du förväntar dig att skala upp till en server som gör det, behåll
huge_pagesinställningenTRYför sömlös övergång och optimala prestanda.
Azure-specifika anteckningar
För servrar med fyra eller fler virtuella kärnor allokeras enorma sidor automatiskt från det underliggande operativsystemet. Funktionen är inte tillgänglig för servrar med färre än fyra virtuella kärnor. Antalet stora sidor justeras automatiskt om några inställningar för delat minne ändras, inklusive ändringar i shared_buffers.
storsida_storlek
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Storleken på storsidan som ska begäras. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0 |
| Parametertyp | skrivskyddad |
| Documentation | huge_page_size |
io_combine_limit
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Begränsa storleken på dataläsningar och skrivningar. |
| Datatyp | integer |
| Standardvärde | 16 |
| Tillåtna värden | 16 |
| Parametertyp | skrivskyddad |
| Documentation | io_combine_limit |
logical_decoding_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för logisk avkodning. |
| Datatyp | integer |
| Standardvärde | 65536 |
| Tillåtna värden | 64-2147483647 |
| Parametertyp | dynamic |
| Documentation | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för underhållsåtgärder som VACUUM, Create Index. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 1024-2097151 |
| Parametertyp | dynamic |
| Documentation | maintenance_work_mem |
Description
maintenance_work_mem är en konfigurationsparameter i PostgreSQL. Den styr mängden minne som allokeras för underhållsåtgärder, till exempel VACUUM, CREATE INDEXoch ALTER TABLE. Till skillnad från work_mem, som påverkar minnesallokering för frågeåtgärder, maintenance_work_mem är reserverad för uppgifter som underhåller och optimerar databasstrukturen.
! [OBS] Om du anger
maintenance_work_memtill för aggressiva värden kan det med jämna mellanrum orsaka ett minnesfel i systemet. Det är mycket viktigt att förstå mängden minne som är tillgängligt på servern och antalet samtidiga åtgärder som kan allokera minne för de uppgifter som beskrevs tidigare innan du gör ändringar i den här parametern.
Huvudpunkter
-
Vakuumminneslock: Om du vill påskynda rensningen av döda tupplar genom att öka
maintenance_work_membör du vara medveten om att detVACUUMhar en inbyggd begränsning för insamling av döda tupplar. Den kan bara använda upp till 1 GB minne för den här processen. -
Separation av minne för autovacuum: Du kan använda inställningen
autovacuum_work_memför att styra det minne som autovacuum-åtgärder använder oberoende av varandra. Den här inställningen fungerar som en delmängd avmaintenance_work_mem. Du kan bestämma hur mycket minne autovacuum använder utan att påverka minnesallokeringen för andra underhållsaktiviteter och datadefinitionsåtgärder.
Azure-specifika anteckningar
Standardvärdet för maintenance_work_mem serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval i beräkningen som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen maintenance_work_mem .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern maintenance_work_mem enligt värdena i följande formel.
Formeln som används för att beräkna värdet maintenance_work_mem för är (long)(82.5 * ln(memoryGiB) + 40) * 1024.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | maintenance_work_mem |
|---|---|
| 2 GiB | 99 328 KiB |
| 4 GiB | 157 696 KiB |
| 8 GiB | 216 064 KiB |
| 16 GiB | 274 432 KiB |
| 32 GiB | 332 800 KiB |
| 48 GiB | 367 616 KiB |
| 64 GiB | 392 192 KiB |
| 80 GiB | 410 624 KiB |
| 128 GiB | 450 560 KiB |
| 160 GiB | 468 992 KiB |
| 192 GiB | 484 352 KiB |
| 256 GiB | 508 928 KiB |
| 384 GiB | 542 720 KiB |
| 432 GiB | 552 960 KiB |
| 672 GiB | 590 848 KiB |
max_förberedda_transaktioner
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet samtidiga förberedda transaktioner. När du kör en replikserver måste du ange samma eller högre värde för den här parametern än på den primära servern. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0-262143 |
| Parametertyp | statiskt |
| Documentation | max_prepared_transactions |
max_stack_depth
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Ställer in maximal stackdjup i kilobyte. |
| Datatyp | integer |
| Standardvärde | 2048 |
| Tillåtna värden | 2048 |
| Parametertyp | skrivskyddad |
| Documentation | max_stack_depth |
min_dynamiskt_delat_minne
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Mängden dynamiskt delat minne som reserverats vid start. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0 |
| Parametertyp | skrivskyddad |
| Documentation | min_dynamic_shared_memory |
multixact_medlem_buffertar
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket delat minne som ska användas för att cachelagrar innehållet i pg_multixact/medlemmar. Enheten är 8 kB. |
| Datatyp | integer |
| Standardvärde | 32 |
| Tillåtna värden | 16-131072 |
| Parametertyp | statiskt |
| Documentation | multixact_member_buffers |
multixact_offset_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger mängden delat minne som ska användas för att cache innehållet i pg_multixact/förskjutningar. Enheten är 8 kB. |
| Datatyp | integer |
| Standardvärde | 16 |
| Tillåtna värden | 16-131072 |
| Parametertyp | statiskt |
| Documentation | multixact_offset_buffers |
notify_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket delat minne som ska användas för att cachelagrar innehållet i pg_notify. Enheten är 8 kB. |
| Datatyp | integer |
| Standardvärde | 16 |
| Tillåtna värden | 16-131072 |
| Parametertyp | statiskt |
| Documentation | notify_buffers |
serialiserbara_buffertar
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket delat minne som ska användas för att cachelagrar innehållet i pg_serial. Enheten är 8 kB. |
| Datatyp | integer |
| Standardvärde | 32 |
| Tillåtna värden | 16-131072 |
| Parametertyp | statiskt |
| Documentation | serializable_buffers |
shared_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger antalet buffertar för delat minne som används av servern. Enheten är 8 kB. Tillåtna värden ligger inom intervallet 10– 75 % av det tillgängliga minnet. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 16-1073741823 |
| Parametertyp | statiskt |
| Documentation | shared_buffers |
Description
Konfigurationsparametern shared_buffers avgör hur mycket systemminne som allokeras till PostgreSQL-databasen för buffring av data. Den fungerar som en centraliserad minnespool som är tillgänglig för alla databasprocesser.
När data behövs kontrollerar databasprocessen först den delade bufferten. Om nödvändiga data finns hämtas de snabbt och kringgår en mer tidskrävande diskläsning. Delade buffertar fungerar som mellanhand mellan databasprocesserna och disken och minskar effektivt antalet nödvändiga I/O-åtgärder.
Azure-specifika anteckningar
Standardvärdet för shared_buffers serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval till den beräkning som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen shared_buffers .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern shared_buffers enligt värdena i följande formler.
För virtuella datorer med upp till 2 GiB minne, används formeln shared_buffers för att beräkna värdet av memoryGib * 16384.
För virtuella datorer med mer än 2 GiB är shared_buffers formeln som används för att beräkna värdet memoryGib * 32768.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
delat_minne_typ
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den implementering av delat minne som används för huvudregionen för delat minne. |
| Datatyp | enumeration |
| Standardvärde | mmap |
| Tillåtna värden | mmap |
| Parametertyp | skrivskyddad |
| Documentation | delad_minne_typ |
subtransaction_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket delat minne som ska användas för att cachelagrar innehållet i pg_subtrans. Enheten är 8 kB. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 0-131072 |
| Parametertyp | statiskt |
| Documentation | subtransaction_buffers |
temp_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet tillfälliga buffertar som används av varje databassession. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 100-1073741823 |
| Parametertyp | dynamic |
| Documentation | temp_buffers |
transaction_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket delat minne som ska användas för att cachelagrar innehållet i pg_xact. Enheten är 8 kB. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 0-131072 |
| Parametertyp | statiskt |
| Documentation | transaction_buffers |
vacuum_buffer_usage_limit
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger buffertpoolens storlek för VACUUM, ANALYZE och autovacuum. |
| Datatyp | integer |
| Standardvärde | 2048 |
| Tillåtna värden | 0-16777216 |
| Parametertyp | dynamic |
| Documentation | vacuum_buffer_usage_limit |
work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket minne som ska användas av interna sorteringsåtgärder och hash-tabeller innan du skriver till tillfälliga diskfiler. |
| Datatyp | integer |
| Standardvärde | 4096 |
| Tillåtna värden | 4096-2097151 |
| Parametertyp | dynamic |
| Documentation | work_mem |
Description
Parametern work_mem i PostgreSQL styr mängden minne som allokerats för vissa interna åtgärder i varje databassessions privata minnesområde. Exempel på dessa åtgärder är sortering och hashning.
Till skillnad från delade buffertar, som finns i det delade minnesområdet, work_mem allokeras i ett privat minnesutrymme per session eller per fråga. Genom att ange en lämplig work_mem storlek kan du avsevärt förbättra effektiviteten för dessa åtgärder och minska behovet av att skriva tillfälliga data till disk.
Huvudpunkter
-
Privat anslutningsminne:
work_memär en del av det privata minne som varje databassession använder. Det här minnet skiljer sig från det delade minnesområde somshared_buffersanvänds. -
Frågespecifik användning: Alla sessioner eller frågor använder inte
work_mem. Enkla frågor somSELECT 1är osannolika att krävawork_mem. Komplexa förfrågningar som omfattar åtgärder som sortering eller hashning kan dock använda ett eller flera segment avwork_mem. -
Parallella åtgärder: För frågor som sträcker sig över flera parallella serverdelar kan varje serverdel potentiellt använda ett eller flera segment av
work_mem.
Övervaka och justera work_mem
Det är viktigt att kontinuerligt övervaka systemets prestanda och justera work_mem vid behov, främst om frågekörningstiderna relaterade till sorterings- eller hashåtgärder är långsamma. Här är sätt att övervaka prestanda med hjälp av verktyg som är tillgängliga i Azure-portalen:
-
Insikt om frågeprestanda: Kontrollera fliken De vanligaste frågorna efter temporära filer för att identifiera frågor som genererar tillfälliga filer. Den här situationen tyder på ett potentiellt behov av att öka
work_mem. - Felsökningsguider: Använd fliken Höga temporära filer i felsökningsguiderna för att identifiera problematiska frågor.
Detaljerad justering
När du hanterar parametern work_mem är det ofta mer effektivt att använda en detaljerad justeringsmetod i stället för att ange ett globalt värde. Den här metoden säkerställer att du allokerar minne på ett omdömesgillt sätt baserat på de specifika behoven hos processer och användare. Det minimerar också risken för problem med minnesbrist. Så här kan du gå till väga:
Användarnivå: Om en specifik användare främst är involverad i aggregerings- eller rapporteringsuppgifter, som är minnesintensiva, bör du överväga att anpassa värdet för den
work_memanvändaren.ALTER ROLEAnvänd kommandot för att förbättra prestandan för användarens åtgärder.Funktions-/procedurnivå: Om specifika funktioner eller procedurer genererar betydande temporära filer kan det vara fördelaktigt att öka
work_memvärdet på den specifika funktions- eller procedurnivån.ALTER FUNCTIONAnvänd kommandot ellerALTER PROCEDUREför att specifikt allokera mer minne till dessa åtgärder.Databasnivå: Ändra
work_mempå databasnivå om endast specifika databaser genererar ett stort antal temporära filer.Global nivå: Om en analys av systemet visar att de flesta frågor genererar små temporära filer, medan bara ett fåtal skapar stora filer, kan det vara klokt att öka
work_memvärdet globalt. Den här åtgärden underlättar för de flesta frågor att bearbeta i minnet, så att du kan undvika diskbaserade åtgärder och förbättra effektiviteten. Var dock alltid försiktig och övervaka minnesanvändningen på servern för att säkerställa att den kan hantera det ökadework_memvärdet.
Fastställa det minsta work_mem värdet för sorteringsåtgärder
Om du vill hitta det minsta work_mem värdet för en specifik fråga, särskilt en som genererar tillfälliga diskfiler under sorteringsprocessen, börjar du med att överväga den tillfälliga filstorlek som genererades under frågekörningen. Om en fråga till exempel genererar en temporär fil på 20 MB:
- Anslut till databasen med hjälp av psql eller önskad PostgreSQL-klient.
- Ange ett initialt
work_memvärde som är något högre än 20 MB för att ta hänsyn till ytterligare rubriker vid bearbetning i minnet. Använd ett kommando som:SET work_mem TO '25MB'. - Kör
EXPLAIN ANALYZEpå den problematiska frågan i samma session. - Granska utdata för
"Sort Method: quicksort Memory: xkB". Om det anger"external merge Disk: xkB", höj värdet förwork_memstegvis och testa igen tills"quicksort Memory"visas. Utseendet på"quicksort Memory"signalerar att frågan nu körs i minnet. - När du har fastställt värdet via den här metoden kan du använda det antingen globalt eller på mer detaljerade nivåer (enligt beskrivningen tidigare) för att passa dina driftbehov.
autovacuum_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas av varje autovacuum-arbetsprocess. |
| Datatyp | integer |
| Standardvärde | -1 |
| Tillåtna värden | -1-2097151 |
| Parametertyp | dynamic |
| Documentation | autovacuum_work_mem |
dynamisk_delat_minnestyp
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den dynamiska implementering av delat minne som används. |
| Datatyp | enumeration |
| Standardvärde | posix |
| Tillåtna värden | posix |
| Parametertyp | skrivskyddad |
| Documentation | dynamic_shared_memory_type |
hash_mem_multiplier
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Flera av work_mem som ska användas för hash-tabeller. |
| Datatyp | numerisk |
| Standardvärde | 2 |
| Tillåtna värden | 1-1000 |
| Parametertyp | dynamic |
| Documentation | hash_mem_multiplier |
huge_pages
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Aktiverar/inaktiverar användningen av stora minnessidor. Den här inställningen gäller inte för servrar som har mindre än 4 virtuella kärnor. |
| Datatyp | enumeration |
| Standardvärde | try |
| Tillåtna värden | on,off,try |
| Parametertyp | statiskt |
| Documentation | huge_pages |
Description
Enorma sidor är en funktion som gör att minne kan hanteras i större block. Du kan vanligtvis hantera block på upp till 2 MB, till skillnad från standardsidorna på 4 KB.
Att använda stora sidor kan ge prestandafördelar som effektivt avlastar processorn:
- De minskar overheaden kopplad till minneshanteringsuppgifter, som färre TLB-missar (translation lookaside buffer).
- De förkortar den tid som krävs för minneshantering.
Mer specifikt kan du i PostgreSQL endast använda stora sidor för det delade minnesområdet. En betydande del av det delade minnesområdet allokeras för delade buffertar.
En annan fördel är att stora sidor förhindrar att det delade minnesområdet växlas ut till disken, vilket ytterligare stabiliserar prestandan.
Recommendations
- För servrar som har betydande minnesresurser bör du undvika att inaktivera stora sidor. Om du inaktiverar stora sidor kan prestandan försämras.
- Om du börjar med en mindre server som inte stöder stora sidor, men du förväntar dig att skala upp till en server som gör det, behåll
huge_pagesinställningenTRYför sömlös övergång och optimala prestanda.
Azure-specifika anteckningar
För servrar med fyra eller fler virtuella kärnor allokeras enorma sidor automatiskt från det underliggande operativsystemet. Funktionen är inte tillgänglig för servrar med färre än fyra virtuella kärnor. Antalet stora sidor justeras automatiskt om några inställningar för delat minne ändras, inklusive ändringar i shared_buffers.
storsida_storlek
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Storleken på storsidan som ska begäras. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0 |
| Parametertyp | skrivskyddad |
| Documentation | huge_page_size |
logical_decoding_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för logisk avkodning. |
| Datatyp | integer |
| Standardvärde | 65536 |
| Tillåtna värden | 64-2147483647 |
| Parametertyp | dynamic |
| Documentation | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för underhållsåtgärder som VACUUM, Create Index. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 1024-2097151 |
| Parametertyp | dynamic |
| Documentation | maintenance_work_mem |
Description
maintenance_work_mem är en konfigurationsparameter i PostgreSQL. Den styr mängden minne som allokeras för underhållsåtgärder, till exempel VACUUM, CREATE INDEXoch ALTER TABLE. Till skillnad från work_mem, som påverkar minnesallokering för frågeåtgärder, maintenance_work_mem är reserverad för uppgifter som underhåller och optimerar databasstrukturen.
! [OBS] Om du anger
maintenance_work_memtill för aggressiva värden kan det med jämna mellanrum orsaka ett minnesfel i systemet. Det är mycket viktigt att förstå mängden minne som är tillgängligt på servern och antalet samtidiga åtgärder som kan allokera minne för de uppgifter som beskrevs tidigare innan du gör ändringar i den här parametern.
Huvudpunkter
-
Vakuumminneslock: Om du vill påskynda rensningen av döda tupplar genom att öka
maintenance_work_membör du vara medveten om att detVACUUMhar en inbyggd begränsning för insamling av döda tupplar. Den kan bara använda upp till 1 GB minne för den här processen. -
Separation av minne för autovacuum: Du kan använda inställningen
autovacuum_work_memför att styra det minne som autovacuum-åtgärder använder oberoende av varandra. Den här inställningen fungerar som en delmängd avmaintenance_work_mem. Du kan bestämma hur mycket minne autovacuum använder utan att påverka minnesallokeringen för andra underhållsaktiviteter och datadefinitionsåtgärder.
Azure-specifika anteckningar
Standardvärdet för maintenance_work_mem serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval i beräkningen som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen maintenance_work_mem .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern maintenance_work_mem enligt värdena i följande formel.
Formeln som används för att beräkna värdet maintenance_work_mem för är (long)(82.5 * ln(memoryGiB) + 40) * 1024.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | maintenance_work_mem |
|---|---|
| 2 GiB | 99 328 KiB |
| 4 GiB | 157 696 KiB |
| 8 GiB | 216 064 KiB |
| 16 GiB | 274 432 KiB |
| 32 GiB | 332 800 KiB |
| 48 GiB | 367 616 KiB |
| 64 GiB | 392 192 KiB |
| 80 GiB | 410 624 KiB |
| 128 GiB | 450 560 KiB |
| 160 GiB | 468 992 KiB |
| 192 GiB | 484 352 KiB |
| 256 GiB | 508 928 KiB |
| 384 GiB | 542 720 KiB |
| 432 GiB | 552 960 KiB |
| 672 GiB | 590 848 KiB |
max_förberedda_transaktioner
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet samtidiga förberedda transaktioner. När du kör en replikserver måste du ange samma eller högre värde för den här parametern än på den primära servern. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0-262143 |
| Parametertyp | statiskt |
| Documentation | max_prepared_transactions |
max_stack_depth
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Ställer in maximal stackdjup i kilobyte. |
| Datatyp | integer |
| Standardvärde | 2048 |
| Tillåtna värden | 2048 |
| Parametertyp | skrivskyddad |
| Documentation | max_stack_depth |
min_dynamiskt_delat_minne
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Mängden dynamiskt delat minne som reserverats vid start. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0 |
| Parametertyp | skrivskyddad |
| Documentation | min_dynamic_shared_memory |
shared_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger antalet buffertar för delat minne som används av servern. Enheten är 8 kB. Tillåtna värden ligger inom intervallet 10– 75 % av det tillgängliga minnet. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 16-1073741823 |
| Parametertyp | statiskt |
| Documentation | shared_buffers |
Description
Konfigurationsparametern shared_buffers avgör hur mycket systemminne som allokeras till PostgreSQL-databasen för buffring av data. Den fungerar som en centraliserad minnespool som är tillgänglig för alla databasprocesser.
När data behövs kontrollerar databasprocessen först den delade bufferten. Om nödvändiga data finns hämtas de snabbt och kringgår en mer tidskrävande diskläsning. Delade buffertar fungerar som mellanhand mellan databasprocesserna och disken och minskar effektivt antalet nödvändiga I/O-åtgärder.
Azure-specifika anteckningar
Standardvärdet för shared_buffers serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval till den beräkning som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen shared_buffers .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern shared_buffers enligt värdena i följande formler.
För virtuella datorer med upp till 2 GiB minne, används formeln shared_buffers för att beräkna värdet av memoryGib * 16384.
För virtuella datorer med mer än 2 GiB är shared_buffers formeln som används för att beräkna värdet memoryGib * 32768.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
delat_minne_typ
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den implementering av delat minne som används för huvudregionen för delat minne. |
| Datatyp | enumeration |
| Standardvärde | mmap |
| Tillåtna värden | mmap |
| Parametertyp | skrivskyddad |
| Documentation | delad_minne_typ |
temp_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet tillfälliga buffertar som används av varje databassession. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 100-1073741823 |
| Parametertyp | dynamic |
| Documentation | temp_buffers |
vacuum_buffer_usage_limit
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger buffertpoolens storlek för VACUUM, ANALYZE och autovacuum. |
| Datatyp | integer |
| Standardvärde | 256 |
| Tillåtna värden | 0-16777216 |
| Parametertyp | dynamic |
| Documentation | vacuum_buffer_usage_limit |
work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket minne som ska användas av interna sorteringsåtgärder och hash-tabeller innan du skriver till tillfälliga diskfiler. |
| Datatyp | integer |
| Standardvärde | 4096 |
| Tillåtna värden | 4096-2097151 |
| Parametertyp | dynamic |
| Documentation | work_mem |
Description
Parametern work_mem i PostgreSQL styr mängden minne som allokerats för vissa interna åtgärder i varje databassessions privata minnesområde. Exempel på dessa åtgärder är sortering och hashning.
Till skillnad från delade buffertar, som finns i det delade minnesområdet, work_mem allokeras i ett privat minnesutrymme per session eller per fråga. Genom att ange en lämplig work_mem storlek kan du avsevärt förbättra effektiviteten för dessa åtgärder och minska behovet av att skriva tillfälliga data till disk.
Huvudpunkter
-
Privat anslutningsminne:
work_memär en del av det privata minne som varje databassession använder. Det här minnet skiljer sig från det delade minnesområde somshared_buffersanvänds. -
Frågespecifik användning: Alla sessioner eller frågor använder inte
work_mem. Enkla frågor somSELECT 1är osannolika att krävawork_mem. Komplexa förfrågningar som omfattar åtgärder som sortering eller hashning kan dock använda ett eller flera segment avwork_mem. -
Parallella åtgärder: För frågor som sträcker sig över flera parallella serverdelar kan varje serverdel potentiellt använda ett eller flera segment av
work_mem.
Övervaka och justera work_mem
Det är viktigt att kontinuerligt övervaka systemets prestanda och justera work_mem vid behov, främst om frågekörningstiderna relaterade till sorterings- eller hashåtgärder är långsamma. Här är sätt att övervaka prestanda med hjälp av verktyg som är tillgängliga i Azure-portalen:
-
Insikt om frågeprestanda: Kontrollera fliken De vanligaste frågorna efter temporära filer för att identifiera frågor som genererar tillfälliga filer. Den här situationen tyder på ett potentiellt behov av att öka
work_mem. - Felsökningsguider: Använd fliken Höga temporära filer i felsökningsguiderna för att identifiera problematiska frågor.
Detaljerad justering
När du hanterar parametern work_mem är det ofta mer effektivt att använda en detaljerad justeringsmetod i stället för att ange ett globalt värde. Den här metoden säkerställer att du allokerar minne på ett omdömesgillt sätt baserat på de specifika behoven hos processer och användare. Det minimerar också risken för problem med minnesbrist. Så här kan du gå till väga:
Användarnivå: Om en specifik användare främst är involverad i aggregerings- eller rapporteringsuppgifter, som är minnesintensiva, bör du överväga att anpassa värdet för den
work_memanvändaren.ALTER ROLEAnvänd kommandot för att förbättra prestandan för användarens åtgärder.Funktions-/procedurnivå: Om specifika funktioner eller procedurer genererar betydande temporära filer kan det vara fördelaktigt att öka
work_memvärdet på den specifika funktions- eller procedurnivån.ALTER FUNCTIONAnvänd kommandot ellerALTER PROCEDUREför att specifikt allokera mer minne till dessa åtgärder.Databasnivå: Ändra
work_mempå databasnivå om endast specifika databaser genererar ett stort antal temporära filer.Global nivå: Om en analys av systemet visar att de flesta frågor genererar små temporära filer, medan bara ett fåtal skapar stora filer, kan det vara klokt att öka
work_memvärdet globalt. Den här åtgärden underlättar för de flesta frågor att bearbeta i minnet, så att du kan undvika diskbaserade åtgärder och förbättra effektiviteten. Var dock alltid försiktig och övervaka minnesanvändningen på servern för att säkerställa att den kan hantera det ökadework_memvärdet.
Fastställa det minsta work_mem värdet för sorteringsåtgärder
Om du vill hitta det minsta work_mem värdet för en specifik fråga, särskilt en som genererar tillfälliga diskfiler under sorteringsprocessen, börjar du med att överväga den tillfälliga filstorlek som genererades under frågekörningen. Om en fråga till exempel genererar en temporär fil på 20 MB:
- Anslut till databasen med hjälp av psql eller önskad PostgreSQL-klient.
- Ange ett initialt
work_memvärde som är något högre än 20 MB för att ta hänsyn till ytterligare rubriker vid bearbetning i minnet. Använd ett kommando som:SET work_mem TO '25MB'. - Kör
EXPLAIN ANALYZEpå den problematiska frågan i samma session. - Granska utdata för
"Sort Method: quicksort Memory: xkB". Om det anger"external merge Disk: xkB", höj värdet förwork_memstegvis och testa igen tills"quicksort Memory"visas. Utseendet på"quicksort Memory"signalerar att frågan nu körs i minnet. - När du har fastställt värdet via den här metoden kan du använda det antingen globalt eller på mer detaljerade nivåer (enligt beskrivningen tidigare) för att passa dina driftbehov.
autovacuum_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas av varje autovacuum-arbetsprocess. |
| Datatyp | integer |
| Standardvärde | -1 |
| Tillåtna värden | -1-2097151 |
| Parametertyp | dynamic |
| Documentation | autovacuum_work_mem |
dynamisk_delat_minnestyp
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den dynamiska implementering av delat minne som används. |
| Datatyp | enumeration |
| Standardvärde | posix |
| Tillåtna värden | posix |
| Parametertyp | skrivskyddad |
| Documentation | dynamic_shared_memory_type |
hash_mem_multiplier
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Flera av work_mem som ska användas för hash-tabeller. |
| Datatyp | numerisk |
| Standardvärde | 2 |
| Tillåtna värden | 1-1000 |
| Parametertyp | dynamic |
| Documentation | hash_mem_multiplier |
huge_pages
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Aktiverar/inaktiverar användningen av stora minnessidor. Den här inställningen gäller inte för servrar som har mindre än 4 virtuella kärnor. |
| Datatyp | enumeration |
| Standardvärde | try |
| Tillåtna värden | on,off,try |
| Parametertyp | statiskt |
| Documentation | huge_pages |
Description
Enorma sidor är en funktion som gör att minne kan hanteras i större block. Du kan vanligtvis hantera block på upp till 2 MB, till skillnad från standardsidorna på 4 KB.
Att använda stora sidor kan ge prestandafördelar som effektivt avlastar processorn:
- De minskar overheaden kopplad till minneshanteringsuppgifter, som färre TLB-missar (translation lookaside buffer).
- De förkortar den tid som krävs för minneshantering.
Mer specifikt kan du i PostgreSQL endast använda stora sidor för det delade minnesområdet. En betydande del av det delade minnesområdet allokeras för delade buffertar.
En annan fördel är att stora sidor förhindrar att det delade minnesområdet växlas ut till disken, vilket ytterligare stabiliserar prestandan.
Recommendations
- För servrar som har betydande minnesresurser bör du undvika att inaktivera stora sidor. Om du inaktiverar stora sidor kan prestandan försämras.
- Om du börjar med en mindre server som inte stöder stora sidor, men du förväntar dig att skala upp till en server som gör det, behåll
huge_pagesinställningenTRYför sömlös övergång och optimala prestanda.
Azure-specifika anteckningar
För servrar med fyra eller fler virtuella kärnor allokeras enorma sidor automatiskt från det underliggande operativsystemet. Funktionen är inte tillgänglig för servrar med färre än fyra virtuella kärnor. Antalet stora sidor justeras automatiskt om några inställningar för delat minne ändras, inklusive ändringar i shared_buffers.
storsida_storlek
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Storleken på storsidan som ska begäras. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0 |
| Parametertyp | skrivskyddad |
| Documentation | huge_page_size |
logical_decoding_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för logisk avkodning. |
| Datatyp | integer |
| Standardvärde | 65536 |
| Tillåtna värden | 64-2147483647 |
| Parametertyp | dynamic |
| Documentation | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för underhållsåtgärder som VACUUM, Create Index. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 1024-2097151 |
| Parametertyp | dynamic |
| Documentation | maintenance_work_mem |
Description
maintenance_work_mem är en konfigurationsparameter i PostgreSQL. Den styr mängden minne som allokeras för underhållsåtgärder, till exempel VACUUM, CREATE INDEXoch ALTER TABLE. Till skillnad från work_mem, som påverkar minnesallokering för frågeåtgärder, maintenance_work_mem är reserverad för uppgifter som underhåller och optimerar databasstrukturen.
! [OBS] Om du anger
maintenance_work_memtill för aggressiva värden kan det med jämna mellanrum orsaka ett minnesfel i systemet. Det är mycket viktigt att förstå mängden minne som är tillgängligt på servern och antalet samtidiga åtgärder som kan allokera minne för de uppgifter som beskrevs tidigare innan du gör ändringar i den här parametern.
Huvudpunkter
-
Vakuumminneslock: Om du vill påskynda rensningen av döda tupplar genom att öka
maintenance_work_membör du vara medveten om att detVACUUMhar en inbyggd begränsning för insamling av döda tupplar. Den kan bara använda upp till 1 GB minne för den här processen. -
Separation av minne för autovacuum: Du kan använda inställningen
autovacuum_work_memför att styra det minne som autovacuum-åtgärder använder oberoende av varandra. Den här inställningen fungerar som en delmängd avmaintenance_work_mem. Du kan bestämma hur mycket minne autovacuum använder utan att påverka minnesallokeringen för andra underhållsaktiviteter och datadefinitionsåtgärder.
Azure-specifika anteckningar
Standardvärdet för maintenance_work_mem serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval i beräkningen som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen maintenance_work_mem .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern maintenance_work_mem enligt värdena i följande formel.
Formeln som används för att beräkna värdet maintenance_work_mem för är (long)(82.5 * ln(memoryGiB) + 40) * 1024.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | maintenance_work_mem |
|---|---|
| 2 GiB | 99 328 KiB |
| 4 GiB | 157 696 KiB |
| 8 GiB | 216 064 KiB |
| 16 GiB | 274 432 KiB |
| 32 GiB | 332 800 KiB |
| 48 GiB | 367 616 KiB |
| 64 GiB | 392 192 KiB |
| 80 GiB | 410 624 KiB |
| 128 GiB | 450 560 KiB |
| 160 GiB | 468 992 KiB |
| 192 GiB | 484 352 KiB |
| 256 GiB | 508 928 KiB |
| 384 GiB | 542 720 KiB |
| 432 GiB | 552 960 KiB |
| 672 GiB | 590 848 KiB |
max_förberedda_transaktioner
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet samtidiga förberedda transaktioner. När du kör en replikserver måste du ange samma eller högre värde för den här parametern än på den primära servern. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0-262143 |
| Parametertyp | statiskt |
| Documentation | max_prepared_transactions |
max_stack_depth
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Ställer in maximal stackdjup i kilobyte. |
| Datatyp | integer |
| Standardvärde | 2048 |
| Tillåtna värden | 2048 |
| Parametertyp | skrivskyddad |
| Documentation | max_stack_depth |
min_dynamiskt_delat_minne
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Mängden dynamiskt delat minne som reserverats vid start. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0 |
| Parametertyp | skrivskyddad |
| Documentation | min_dynamic_shared_memory |
shared_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger antalet buffertar för delat minne som används av servern. Enheten är 8 kB. Tillåtna värden ligger inom intervallet 10– 75 % av det tillgängliga minnet. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 16-1073741823 |
| Parametertyp | statiskt |
| Documentation | shared_buffers |
Description
Konfigurationsparametern shared_buffers avgör hur mycket systemminne som allokeras till PostgreSQL-databasen för buffring av data. Den fungerar som en centraliserad minnespool som är tillgänglig för alla databasprocesser.
När data behövs kontrollerar databasprocessen först den delade bufferten. Om nödvändiga data finns hämtas de snabbt och kringgår en mer tidskrävande diskläsning. Delade buffertar fungerar som mellanhand mellan databasprocesserna och disken och minskar effektivt antalet nödvändiga I/O-åtgärder.
Azure-specifika anteckningar
Standardvärdet för shared_buffers serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval till den beräkning som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen shared_buffers .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern shared_buffers enligt värdena i följande formler.
För virtuella datorer med upp till 2 GiB minne, används formeln shared_buffers för att beräkna värdet av memoryGib * 16384.
För virtuella datorer med mer än 2 GiB är shared_buffers formeln som används för att beräkna värdet memoryGib * 32768.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
delat_minne_typ
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den implementering av delat minne som används för huvudregionen för delat minne. |
| Datatyp | enumeration |
| Standardvärde | mmap |
| Tillåtna värden | mmap |
| Parametertyp | skrivskyddad |
| Documentation | delad_minne_typ |
temp_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet tillfälliga buffertar som används av varje databassession. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 100-1073741823 |
| Parametertyp | dynamic |
| Documentation | temp_buffers |
work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket minne som ska användas av interna sorteringsåtgärder och hash-tabeller innan du skriver till tillfälliga diskfiler. |
| Datatyp | integer |
| Standardvärde | 4096 |
| Tillåtna värden | 4096-2097151 |
| Parametertyp | dynamic |
| Documentation | work_mem |
Description
Parametern work_mem i PostgreSQL styr mängden minne som allokerats för vissa interna åtgärder i varje databassessions privata minnesområde. Exempel på dessa åtgärder är sortering och hashning.
Till skillnad från delade buffertar, som finns i det delade minnesområdet, work_mem allokeras i ett privat minnesutrymme per session eller per fråga. Genom att ange en lämplig work_mem storlek kan du avsevärt förbättra effektiviteten för dessa åtgärder och minska behovet av att skriva tillfälliga data till disk.
Huvudpunkter
-
Privat anslutningsminne:
work_memär en del av det privata minne som varje databassession använder. Det här minnet skiljer sig från det delade minnesområde somshared_buffersanvänds. -
Frågespecifik användning: Alla sessioner eller frågor använder inte
work_mem. Enkla frågor somSELECT 1är osannolika att krävawork_mem. Komplexa förfrågningar som omfattar åtgärder som sortering eller hashning kan dock använda ett eller flera segment avwork_mem. -
Parallella åtgärder: För frågor som sträcker sig över flera parallella serverdelar kan varje serverdel potentiellt använda ett eller flera segment av
work_mem.
Övervaka och justera work_mem
Det är viktigt att kontinuerligt övervaka systemets prestanda och justera work_mem vid behov, främst om frågekörningstiderna relaterade till sorterings- eller hashåtgärder är långsamma. Här är sätt att övervaka prestanda med hjälp av verktyg som är tillgängliga i Azure-portalen:
-
Insikt om frågeprestanda: Kontrollera fliken De vanligaste frågorna efter temporära filer för att identifiera frågor som genererar tillfälliga filer. Den här situationen tyder på ett potentiellt behov av att öka
work_mem. - Felsökningsguider: Använd fliken Höga temporära filer i felsökningsguiderna för att identifiera problematiska frågor.
Detaljerad justering
När du hanterar parametern work_mem är det ofta mer effektivt att använda en detaljerad justeringsmetod i stället för att ange ett globalt värde. Den här metoden säkerställer att du allokerar minne på ett omdömesgillt sätt baserat på de specifika behoven hos processer och användare. Det minimerar också risken för problem med minnesbrist. Så här kan du gå till väga:
Användarnivå: Om en specifik användare främst är involverad i aggregerings- eller rapporteringsuppgifter, som är minnesintensiva, bör du överväga att anpassa värdet för den
work_memanvändaren.ALTER ROLEAnvänd kommandot för att förbättra prestandan för användarens åtgärder.Funktions-/procedurnivå: Om specifika funktioner eller procedurer genererar betydande temporära filer kan det vara fördelaktigt att öka
work_memvärdet på den specifika funktions- eller procedurnivån.ALTER FUNCTIONAnvänd kommandot ellerALTER PROCEDUREför att specifikt allokera mer minne till dessa åtgärder.Databasnivå: Ändra
work_mempå databasnivå om endast specifika databaser genererar ett stort antal temporära filer.Global nivå: Om en analys av systemet visar att de flesta frågor genererar små temporära filer, medan bara ett fåtal skapar stora filer, kan det vara klokt att öka
work_memvärdet globalt. Den här åtgärden underlättar för de flesta frågor att bearbeta i minnet, så att du kan undvika diskbaserade åtgärder och förbättra effektiviteten. Var dock alltid försiktig och övervaka minnesanvändningen på servern för att säkerställa att den kan hantera det ökadework_memvärdet.
Fastställa det minsta work_mem värdet för sorteringsåtgärder
Om du vill hitta det minsta work_mem värdet för en specifik fråga, särskilt en som genererar tillfälliga diskfiler under sorteringsprocessen, börjar du med att överväga den tillfälliga filstorlek som genererades under frågekörningen. Om en fråga till exempel genererar en temporär fil på 20 MB:
- Anslut till databasen med hjälp av psql eller önskad PostgreSQL-klient.
- Ange ett initialt
work_memvärde som är något högre än 20 MB för att ta hänsyn till ytterligare rubriker vid bearbetning i minnet. Använd ett kommando som:SET work_mem TO '25MB'. - Kör
EXPLAIN ANALYZEpå den problematiska frågan i samma session. - Granska utdata för
"Sort Method: quicksort Memory: xkB". Om det anger"external merge Disk: xkB", höj värdet förwork_memstegvis och testa igen tills"quicksort Memory"visas. Utseendet på"quicksort Memory"signalerar att frågan nu körs i minnet. - När du har fastställt värdet via den här metoden kan du använda det antingen globalt eller på mer detaljerade nivåer (enligt beskrivningen tidigare) för att passa dina driftbehov.
autovacuum_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas av varje autovacuum-arbetsprocess. |
| Datatyp | integer |
| Standardvärde | -1 |
| Tillåtna värden | -1-2097151 |
| Parametertyp | dynamic |
| Documentation | autovacuum_work_mem |
dynamisk_delat_minnestyp
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den dynamiska implementering av delat minne som används. |
| Datatyp | enumeration |
| Standardvärde | posix |
| Tillåtna värden | posix |
| Parametertyp | skrivskyddad |
| Documentation | dynamic_shared_memory_type |
hash_mem_multiplier
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Flera av work_mem som ska användas för hash-tabeller. |
| Datatyp | numerisk |
| Standardvärde | 1 |
| Tillåtna värden | 1-1000 |
| Parametertyp | dynamic |
| Documentation | hash_mem_multiplier |
huge_pages
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Aktiverar/inaktiverar användningen av stora minnessidor. Den här inställningen gäller inte för servrar som har mindre än 4 virtuella kärnor. |
| Datatyp | enumeration |
| Standardvärde | try |
| Tillåtna värden | on,off,try |
| Parametertyp | statiskt |
| Documentation | huge_pages |
Description
Enorma sidor är en funktion som gör att minne kan hanteras i större block. Du kan vanligtvis hantera block på upp till 2 MB, till skillnad från standardsidorna på 4 KB.
Att använda stora sidor kan ge prestandafördelar som effektivt avlastar processorn:
- De minskar overheaden kopplad till minneshanteringsuppgifter, som färre TLB-missar (translation lookaside buffer).
- De förkortar den tid som krävs för minneshantering.
Mer specifikt kan du i PostgreSQL endast använda stora sidor för det delade minnesområdet. En betydande del av det delade minnesområdet allokeras för delade buffertar.
En annan fördel är att stora sidor förhindrar att det delade minnesområdet växlas ut till disken, vilket ytterligare stabiliserar prestandan.
Recommendations
- För servrar som har betydande minnesresurser bör du undvika att inaktivera stora sidor. Om du inaktiverar stora sidor kan prestandan försämras.
- Om du börjar med en mindre server som inte stöder stora sidor, men du förväntar dig att skala upp till en server som gör det, behåll
huge_pagesinställningenTRYför sömlös övergång och optimala prestanda.
Azure-specifika anteckningar
För servrar med fyra eller fler virtuella kärnor allokeras enorma sidor automatiskt från det underliggande operativsystemet. Funktionen är inte tillgänglig för servrar med färre än fyra virtuella kärnor. Antalet stora sidor justeras automatiskt om några inställningar för delat minne ändras, inklusive ändringar i shared_buffers.
storsida_storlek
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Storleken på storsidan som ska begäras. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0 |
| Parametertyp | skrivskyddad |
| Documentation | huge_page_size |
logical_decoding_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för logisk avkodning. |
| Datatyp | integer |
| Standardvärde | 65536 |
| Tillåtna värden | 64-2147483647 |
| Parametertyp | dynamic |
| Documentation | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för underhållsåtgärder som VACUUM, Create Index. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 1024-2097151 |
| Parametertyp | dynamic |
| Documentation | maintenance_work_mem |
Description
maintenance_work_mem är en konfigurationsparameter i PostgreSQL. Den styr mängden minne som allokeras för underhållsåtgärder, till exempel VACUUM, CREATE INDEXoch ALTER TABLE. Till skillnad från work_mem, som påverkar minnesallokering för frågeåtgärder, maintenance_work_mem är reserverad för uppgifter som underhåller och optimerar databasstrukturen.
! [OBS] Om du anger
maintenance_work_memtill för aggressiva värden kan det med jämna mellanrum orsaka ett minnesfel i systemet. Det är mycket viktigt att förstå mängden minne som är tillgängligt på servern och antalet samtidiga åtgärder som kan allokera minne för de uppgifter som beskrevs tidigare innan du gör ändringar i den här parametern.
Huvudpunkter
-
Vakuumminneslock: Om du vill påskynda rensningen av döda tupplar genom att öka
maintenance_work_membör du vara medveten om att detVACUUMhar en inbyggd begränsning för insamling av döda tupplar. Den kan bara använda upp till 1 GB minne för den här processen. -
Separation av minne för autovacuum: Du kan använda inställningen
autovacuum_work_memför att styra det minne som autovacuum-åtgärder använder oberoende av varandra. Den här inställningen fungerar som en delmängd avmaintenance_work_mem. Du kan bestämma hur mycket minne autovacuum använder utan att påverka minnesallokeringen för andra underhållsaktiviteter och datadefinitionsåtgärder.
Azure-specifika anteckningar
Standardvärdet för maintenance_work_mem serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval i beräkningen som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen maintenance_work_mem .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern maintenance_work_mem enligt värdena i följande formel.
Formeln som används för att beräkna värdet maintenance_work_mem för är (long)(82.5 * ln(memoryGiB) + 40) * 1024.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | maintenance_work_mem |
|---|---|
| 2 GiB | 99 328 KiB |
| 4 GiB | 157 696 KiB |
| 8 GiB | 216 064 KiB |
| 16 GiB | 274 432 KiB |
| 32 GiB | 332 800 KiB |
| 48 GiB | 367 616 KiB |
| 64 GiB | 392 192 KiB |
| 80 GiB | 410 624 KiB |
| 128 GiB | 450 560 KiB |
| 160 GiB | 468 992 KiB |
| 192 GiB | 484 352 KiB |
| 256 GiB | 508 928 KiB |
| 384 GiB | 542 720 KiB |
| 432 GiB | 552 960 KiB |
| 672 GiB | 590 848 KiB |
max_förberedda_transaktioner
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet samtidiga förberedda transaktioner. När du kör en replikserver måste du ange samma eller högre värde för den här parametern än på den primära servern. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0-262143 |
| Parametertyp | statiskt |
| Documentation | max_prepared_transactions |
max_stack_depth
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Ställer in maximal stackdjup i kilobyte. |
| Datatyp | integer |
| Standardvärde | 2048 |
| Tillåtna värden | 2048 |
| Parametertyp | skrivskyddad |
| Documentation | max_stack_depth |
min_dynamiskt_delat_minne
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Mängden dynamiskt delat minne som reserverats vid start. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0 |
| Parametertyp | skrivskyddad |
| Documentation | min_dynamic_shared_memory |
shared_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger antalet buffertar för delat minne som används av servern. Enheten är 8 kB. Tillåtna värden ligger inom intervallet 10– 75 % av det tillgängliga minnet. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 16-1073741823 |
| Parametertyp | statiskt |
| Documentation | shared_buffers |
Description
Konfigurationsparametern shared_buffers avgör hur mycket systemminne som allokeras till PostgreSQL-databasen för buffring av data. Den fungerar som en centraliserad minnespool som är tillgänglig för alla databasprocesser.
När data behövs kontrollerar databasprocessen först den delade bufferten. Om nödvändiga data finns hämtas de snabbt och kringgår en mer tidskrävande diskläsning. Delade buffertar fungerar som mellanhand mellan databasprocesserna och disken och minskar effektivt antalet nödvändiga I/O-åtgärder.
Azure-specifika anteckningar
Standardvärdet för shared_buffers serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval till den beräkning som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen shared_buffers .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern shared_buffers enligt värdena i följande formler.
För virtuella datorer med upp till 2 GiB minne, används formeln shared_buffers för att beräkna värdet av memoryGib * 16384.
För virtuella datorer med mer än 2 GiB är shared_buffers formeln som används för att beräkna värdet memoryGib * 32768.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
delat_minne_typ
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den implementering av delat minne som används för huvudregionen för delat minne. |
| Datatyp | enumeration |
| Standardvärde | mmap |
| Tillåtna värden | mmap |
| Parametertyp | skrivskyddad |
| Documentation | delad_minne_typ |
temp_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet tillfälliga buffertar som används av varje databassession. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 100-1073741823 |
| Parametertyp | dynamic |
| Documentation | temp_buffers |
work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket minne som ska användas av interna sorteringsåtgärder och hash-tabeller innan du skriver till tillfälliga diskfiler. |
| Datatyp | integer |
| Standardvärde | 4096 |
| Tillåtna värden | 4096-2097151 |
| Parametertyp | dynamic |
| Documentation | work_mem |
Description
Parametern work_mem i PostgreSQL styr mängden minne som allokerats för vissa interna åtgärder i varje databassessions privata minnesområde. Exempel på dessa åtgärder är sortering och hashning.
Till skillnad från delade buffertar, som finns i det delade minnesområdet, work_mem allokeras i ett privat minnesutrymme per session eller per fråga. Genom att ange en lämplig work_mem storlek kan du avsevärt förbättra effektiviteten för dessa åtgärder och minska behovet av att skriva tillfälliga data till disk.
Huvudpunkter
-
Privat anslutningsminne:
work_memär en del av det privata minne som varje databassession använder. Det här minnet skiljer sig från det delade minnesområde somshared_buffersanvänds. -
Frågespecifik användning: Alla sessioner eller frågor använder inte
work_mem. Enkla frågor somSELECT 1är osannolika att krävawork_mem. Komplexa förfrågningar som omfattar åtgärder som sortering eller hashning kan dock använda ett eller flera segment avwork_mem. -
Parallella åtgärder: För frågor som sträcker sig över flera parallella serverdelar kan varje serverdel potentiellt använda ett eller flera segment av
work_mem.
Övervaka och justera work_mem
Det är viktigt att kontinuerligt övervaka systemets prestanda och justera work_mem vid behov, främst om frågekörningstiderna relaterade till sorterings- eller hashåtgärder är långsamma. Här är sätt att övervaka prestanda med hjälp av verktyg som är tillgängliga i Azure-portalen:
-
Insikt om frågeprestanda: Kontrollera fliken De vanligaste frågorna efter temporära filer för att identifiera frågor som genererar tillfälliga filer. Den här situationen tyder på ett potentiellt behov av att öka
work_mem. - Felsökningsguider: Använd fliken Höga temporära filer i felsökningsguiderna för att identifiera problematiska frågor.
Detaljerad justering
När du hanterar parametern work_mem är det ofta mer effektivt att använda en detaljerad justeringsmetod i stället för att ange ett globalt värde. Den här metoden säkerställer att du allokerar minne på ett omdömesgillt sätt baserat på de specifika behoven hos processer och användare. Det minimerar också risken för problem med minnesbrist. Så här kan du gå till väga:
Användarnivå: Om en specifik användare främst är involverad i aggregerings- eller rapporteringsuppgifter, som är minnesintensiva, bör du överväga att anpassa värdet för den
work_memanvändaren.ALTER ROLEAnvänd kommandot för att förbättra prestandan för användarens åtgärder.Funktions-/procedurnivå: Om specifika funktioner eller procedurer genererar betydande temporära filer kan det vara fördelaktigt att öka
work_memvärdet på den specifika funktions- eller procedurnivån.ALTER FUNCTIONAnvänd kommandot ellerALTER PROCEDUREför att specifikt allokera mer minne till dessa åtgärder.Databasnivå: Ändra
work_mempå databasnivå om endast specifika databaser genererar ett stort antal temporära filer.Global nivå: Om en analys av systemet visar att de flesta frågor genererar små temporära filer, medan bara ett fåtal skapar stora filer, kan det vara klokt att öka
work_memvärdet globalt. Den här åtgärden underlättar för de flesta frågor att bearbeta i minnet, så att du kan undvika diskbaserade åtgärder och förbättra effektiviteten. Var dock alltid försiktig och övervaka minnesanvändningen på servern för att säkerställa att den kan hantera det ökadework_memvärdet.
Fastställa det minsta work_mem värdet för sorteringsåtgärder
Om du vill hitta det minsta work_mem värdet för en specifik fråga, särskilt en som genererar tillfälliga diskfiler under sorteringsprocessen, börjar du med att överväga den tillfälliga filstorlek som genererades under frågekörningen. Om en fråga till exempel genererar en temporär fil på 20 MB:
- Anslut till databasen med hjälp av psql eller önskad PostgreSQL-klient.
- Ange ett initialt
work_memvärde som är något högre än 20 MB för att ta hänsyn till ytterligare rubriker vid bearbetning i minnet. Använd ett kommando som:SET work_mem TO '25MB'. - Kör
EXPLAIN ANALYZEpå den problematiska frågan i samma session. - Granska utdata för
"Sort Method: quicksort Memory: xkB". Om det anger"external merge Disk: xkB", höj värdet förwork_memstegvis och testa igen tills"quicksort Memory"visas. Utseendet på"quicksort Memory"signalerar att frågan nu körs i minnet. - När du har fastställt värdet via den här metoden kan du använda det antingen globalt eller på mer detaljerade nivåer (enligt beskrivningen tidigare) för att passa dina driftbehov.
autovacuum_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas av varje autovacuum-arbetsprocess. |
| Datatyp | integer |
| Standardvärde | -1 |
| Tillåtna värden | -1-2097151 |
| Parametertyp | dynamic |
| Documentation | autovacuum_work_mem |
dynamisk_delat_minnestyp
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den dynamiska implementering av delat minne som används. |
| Datatyp | enumeration |
| Standardvärde | posix |
| Tillåtna värden | posix |
| Parametertyp | skrivskyddad |
| Documentation | dynamic_shared_memory_type |
hash_mem_multiplier
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Flera av work_mem som ska användas för hash-tabeller. |
| Datatyp | numerisk |
| Standardvärde | 1 |
| Tillåtna värden | 1-1000 |
| Parametertyp | dynamic |
| Documentation | hash_mem_multiplier |
huge_pages
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Aktiverar/inaktiverar användningen av stora minnessidor. Den här inställningen gäller inte för servrar som har mindre än 4 virtuella kärnor. |
| Datatyp | enumeration |
| Standardvärde | try |
| Tillåtna värden | on,off,try |
| Parametertyp | statiskt |
| Documentation | huge_pages |
Description
Enorma sidor är en funktion som gör att minne kan hanteras i större block. Du kan vanligtvis hantera block på upp till 2 MB, till skillnad från standardsidorna på 4 KB.
Att använda stora sidor kan ge prestandafördelar som effektivt avlastar processorn:
- De minskar overheaden kopplad till minneshanteringsuppgifter, som färre TLB-missar (translation lookaside buffer).
- De förkortar den tid som krävs för minneshantering.
Mer specifikt kan du i PostgreSQL endast använda stora sidor för det delade minnesområdet. En betydande del av det delade minnesområdet allokeras för delade buffertar.
En annan fördel är att stora sidor förhindrar att det delade minnesområdet växlas ut till disken, vilket ytterligare stabiliserar prestandan.
Recommendations
- För servrar som har betydande minnesresurser bör du undvika att inaktivera stora sidor. Om du inaktiverar stora sidor kan prestandan försämras.
- Om du börjar med en mindre server som inte stöder stora sidor, men du förväntar dig att skala upp till en server som gör det, behåll
huge_pagesinställningenTRYför sömlös övergång och optimala prestanda.
Azure-specifika anteckningar
För servrar med fyra eller fler virtuella kärnor allokeras enorma sidor automatiskt från det underliggande operativsystemet. Funktionen är inte tillgänglig för servrar med färre än fyra virtuella kärnor. Antalet stora sidor justeras automatiskt om några inställningar för delat minne ändras, inklusive ändringar i shared_buffers.
logical_decoding_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för logisk avkodning. |
| Datatyp | integer |
| Standardvärde | 65536 |
| Tillåtna värden | 64-2147483647 |
| Parametertyp | dynamic |
| Documentation | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för underhållsåtgärder som VACUUM, Create Index. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 1024-2097151 |
| Parametertyp | dynamic |
| Documentation | maintenance_work_mem |
Description
maintenance_work_mem är en konfigurationsparameter i PostgreSQL. Den styr mängden minne som allokeras för underhållsåtgärder, till exempel VACUUM, CREATE INDEXoch ALTER TABLE. Till skillnad från work_mem, som påverkar minnesallokering för frågeåtgärder, maintenance_work_mem är reserverad för uppgifter som underhåller och optimerar databasstrukturen.
! [OBS] Om du anger
maintenance_work_memtill för aggressiva värden kan det med jämna mellanrum orsaka ett minnesfel i systemet. Det är mycket viktigt att förstå mängden minne som är tillgängligt på servern och antalet samtidiga åtgärder som kan allokera minne för de uppgifter som beskrevs tidigare innan du gör ändringar i den här parametern.
Huvudpunkter
-
Vakuumminneslock: Om du vill påskynda rensningen av döda tupplar genom att öka
maintenance_work_membör du vara medveten om att detVACUUMhar en inbyggd begränsning för insamling av döda tupplar. Den kan bara använda upp till 1 GB minne för den här processen. -
Separation av minne för autovacuum: Du kan använda inställningen
autovacuum_work_memför att styra det minne som autovacuum-åtgärder använder oberoende av varandra. Den här inställningen fungerar som en delmängd avmaintenance_work_mem. Du kan bestämma hur mycket minne autovacuum använder utan att påverka minnesallokeringen för andra underhållsaktiviteter och datadefinitionsåtgärder.
Azure-specifika anteckningar
Standardvärdet för maintenance_work_mem serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval i beräkningen som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen maintenance_work_mem .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern maintenance_work_mem enligt värdena i följande formel.
Formeln som används för att beräkna värdet maintenance_work_mem för är (long)(82.5 * ln(memoryGiB) + 40) * 1024.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | maintenance_work_mem |
|---|---|
| 2 GiB | 99 328 KiB |
| 4 GiB | 157 696 KiB |
| 8 GiB | 216 064 KiB |
| 16 GiB | 274 432 KiB |
| 32 GiB | 332 800 KiB |
| 48 GiB | 367 616 KiB |
| 64 GiB | 392 192 KiB |
| 80 GiB | 410 624 KiB |
| 128 GiB | 450 560 KiB |
| 160 GiB | 468 992 KiB |
| 192 GiB | 484 352 KiB |
| 256 GiB | 508 928 KiB |
| 384 GiB | 542 720 KiB |
| 432 GiB | 552 960 KiB |
| 672 GiB | 590 848 KiB |
max_förberedda_transaktioner
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet samtidiga förberedda transaktioner. När du kör en replikserver måste du ange samma eller högre värde för den här parametern än på den primära servern. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0-262143 |
| Parametertyp | statiskt |
| Documentation | max_prepared_transactions |
max_stack_depth
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Ställer in maximal stackdjup i kilobyte. |
| Datatyp | integer |
| Standardvärde | 2048 |
| Tillåtna värden | 2048 |
| Parametertyp | skrivskyddad |
| Documentation | max_stack_depth |
shared_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger antalet buffertar för delat minne som används av servern. Enheten är 8 kB. Tillåtna värden ligger inom intervallet 10– 75 % av det tillgängliga minnet. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 16-1073741823 |
| Parametertyp | statiskt |
| Documentation | shared_buffers |
Description
Konfigurationsparametern shared_buffers avgör hur mycket systemminne som allokeras till PostgreSQL-databasen för buffring av data. Den fungerar som en centraliserad minnespool som är tillgänglig för alla databasprocesser.
När data behövs kontrollerar databasprocessen först den delade bufferten. Om nödvändiga data finns hämtas de snabbt och kringgår en mer tidskrävande diskläsning. Delade buffertar fungerar som mellanhand mellan databasprocesserna och disken och minskar effektivt antalet nödvändiga I/O-åtgärder.
Azure-specifika anteckningar
Standardvärdet för shared_buffers serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval till den beräkning som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen shared_buffers .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern shared_buffers enligt värdena i följande formler.
För virtuella datorer med upp till 2 GiB minne, används formeln shared_buffers för att beräkna värdet av memoryGib * 16384.
För virtuella datorer med mer än 2 GiB är shared_buffers formeln som används för att beräkna värdet memoryGib * 32768.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
delat_minne_typ
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den implementering av delat minne som används för huvudregionen för delat minne. |
| Datatyp | enumeration |
| Standardvärde | mmap |
| Tillåtna värden | mmap |
| Parametertyp | skrivskyddad |
| Documentation | delad_minne_typ |
temp_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet tillfälliga buffertar som används av varje databassession. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 100-1073741823 |
| Parametertyp | dynamic |
| Documentation | temp_buffers |
work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket minne som ska användas av interna sorteringsåtgärder och hash-tabeller innan du skriver till tillfälliga diskfiler. |
| Datatyp | integer |
| Standardvärde | 4096 |
| Tillåtna värden | 4096-2097151 |
| Parametertyp | dynamic |
| Documentation | work_mem |
Description
Parametern work_mem i PostgreSQL styr mängden minne som allokerats för vissa interna åtgärder i varje databassessions privata minnesområde. Exempel på dessa åtgärder är sortering och hashning.
Till skillnad från delade buffertar, som finns i det delade minnesområdet, work_mem allokeras i ett privat minnesutrymme per session eller per fråga. Genom att ange en lämplig work_mem storlek kan du avsevärt förbättra effektiviteten för dessa åtgärder och minska behovet av att skriva tillfälliga data till disk.
Huvudpunkter
-
Privat anslutningsminne:
work_memär en del av det privata minne som varje databassession använder. Det här minnet skiljer sig från det delade minnesområde somshared_buffersanvänds. -
Frågespecifik användning: Alla sessioner eller frågor använder inte
work_mem. Enkla frågor somSELECT 1är osannolika att krävawork_mem. Komplexa förfrågningar som omfattar åtgärder som sortering eller hashning kan dock använda ett eller flera segment avwork_mem. -
Parallella åtgärder: För frågor som sträcker sig över flera parallella serverdelar kan varje serverdel potentiellt använda ett eller flera segment av
work_mem.
Övervaka och justera work_mem
Det är viktigt att kontinuerligt övervaka systemets prestanda och justera work_mem vid behov, främst om frågekörningstiderna relaterade till sorterings- eller hashåtgärder är långsamma. Här är sätt att övervaka prestanda med hjälp av verktyg som är tillgängliga i Azure-portalen:
-
Insikt om frågeprestanda: Kontrollera fliken De vanligaste frågorna efter temporära filer för att identifiera frågor som genererar tillfälliga filer. Den här situationen tyder på ett potentiellt behov av att öka
work_mem. - Felsökningsguider: Använd fliken Höga temporära filer i felsökningsguiderna för att identifiera problematiska frågor.
Detaljerad justering
När du hanterar parametern work_mem är det ofta mer effektivt att använda en detaljerad justeringsmetod i stället för att ange ett globalt värde. Den här metoden säkerställer att du allokerar minne på ett omdömesgillt sätt baserat på de specifika behoven hos processer och användare. Det minimerar också risken för problem med minnesbrist. Så här kan du gå till väga:
Användarnivå: Om en specifik användare främst är involverad i aggregerings- eller rapporteringsuppgifter, som är minnesintensiva, bör du överväga att anpassa värdet för den
work_memanvändaren.ALTER ROLEAnvänd kommandot för att förbättra prestandan för användarens åtgärder.Funktions-/procedurnivå: Om specifika funktioner eller procedurer genererar betydande temporära filer kan det vara fördelaktigt att öka
work_memvärdet på den specifika funktions- eller procedurnivån.ALTER FUNCTIONAnvänd kommandot ellerALTER PROCEDUREför att specifikt allokera mer minne till dessa åtgärder.Databasnivå: Ändra
work_mempå databasnivå om endast specifika databaser genererar ett stort antal temporära filer.Global nivå: Om en analys av systemet visar att de flesta frågor genererar små temporära filer, medan bara ett fåtal skapar stora filer, kan det vara klokt att öka
work_memvärdet globalt. Den här åtgärden underlättar för de flesta frågor att bearbeta i minnet, så att du kan undvika diskbaserade åtgärder och förbättra effektiviteten. Var dock alltid försiktig och övervaka minnesanvändningen på servern för att säkerställa att den kan hantera det ökadework_memvärdet.
Fastställa det minsta work_mem värdet för sorteringsåtgärder
Om du vill hitta det minsta work_mem värdet för en specifik fråga, särskilt en som genererar tillfälliga diskfiler under sorteringsprocessen, börjar du med att överväga den tillfälliga filstorlek som genererades under frågekörningen. Om en fråga till exempel genererar en temporär fil på 20 MB:
- Anslut till databasen med hjälp av psql eller önskad PostgreSQL-klient.
- Ange ett initialt
work_memvärde som är något högre än 20 MB för att ta hänsyn till ytterligare rubriker vid bearbetning i minnet. Använd ett kommando som:SET work_mem TO '25MB'. - Kör
EXPLAIN ANALYZEpå den problematiska frågan i samma session. - Granska utdata för
"Sort Method: quicksort Memory: xkB". Om det anger"external merge Disk: xkB", höj värdet förwork_memstegvis och testa igen tills"quicksort Memory"visas. Utseendet på"quicksort Memory"signalerar att frågan nu körs i minnet. - När du har fastställt värdet via den här metoden kan du använda det antingen globalt eller på mer detaljerade nivåer (enligt beskrivningen tidigare) för att passa dina driftbehov.
autovacuum_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas av varje autovacuum-arbetsprocess. |
| Datatyp | integer |
| Standardvärde | -1 |
| Tillåtna värden | -1-2097151 |
| Parametertyp | dynamic |
| Documentation | autovacuum_work_mem |
dynamisk_delat_minnestyp
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den dynamiska implementering av delat minne som används. |
| Datatyp | enumeration |
| Standardvärde | posix |
| Tillåtna värden | posix |
| Parametertyp | skrivskyddad |
| Documentation | dynamic_shared_memory_type |
hash_mem_multiplier
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Flera av work_mem som ska användas för hash-tabeller. |
| Datatyp | numerisk |
| Standardvärde | 1 |
| Tillåtna värden | 1-1000 |
| Parametertyp | dynamic |
| Documentation | hash_mem_multiplier |
huge_pages
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Aktiverar/inaktiverar användningen av stora minnessidor. Den här inställningen gäller inte för servrar som har mindre än 4 virtuella kärnor. |
| Datatyp | enumeration |
| Standardvärde | try |
| Tillåtna värden | on,off,try |
| Parametertyp | statiskt |
| Documentation | huge_pages |
Description
Enorma sidor är en funktion som gör att minne kan hanteras i större block. Du kan vanligtvis hantera block på upp till 2 MB, till skillnad från standardsidorna på 4 KB.
Att använda stora sidor kan ge prestandafördelar som effektivt avlastar processorn:
- De minskar overheaden kopplad till minneshanteringsuppgifter, som färre TLB-missar (translation lookaside buffer).
- De förkortar den tid som krävs för minneshantering.
Mer specifikt kan du i PostgreSQL endast använda stora sidor för det delade minnesområdet. En betydande del av det delade minnesområdet allokeras för delade buffertar.
En annan fördel är att stora sidor förhindrar att det delade minnesområdet växlas ut till disken, vilket ytterligare stabiliserar prestandan.
Recommendations
- För servrar som har betydande minnesresurser bör du undvika att inaktivera stora sidor. Om du inaktiverar stora sidor kan prestandan försämras.
- Om du börjar med en mindre server som inte stöder stora sidor, men du förväntar dig att skala upp till en server som gör det, behåll
huge_pagesinställningenTRYför sömlös övergång och optimala prestanda.
Azure-specifika anteckningar
För servrar med fyra eller fler virtuella kärnor allokeras enorma sidor automatiskt från det underliggande operativsystemet. Funktionen är inte tillgänglig för servrar med färre än fyra virtuella kärnor. Antalet stora sidor justeras automatiskt om några inställningar för delat minne ändras, inklusive ändringar i shared_buffers.
maintenance_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för underhållsåtgärder som VACUUM, Create Index. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 1024-2097151 |
| Parametertyp | dynamic |
| Documentation | maintenance_work_mem |
Description
maintenance_work_mem är en konfigurationsparameter i PostgreSQL. Den styr mängden minne som allokeras för underhållsåtgärder, till exempel VACUUM, CREATE INDEXoch ALTER TABLE. Till skillnad från work_mem, som påverkar minnesallokering för frågeåtgärder, maintenance_work_mem är reserverad för uppgifter som underhåller och optimerar databasstrukturen.
! [OBS] Om du anger
maintenance_work_memtill för aggressiva värden kan det med jämna mellanrum orsaka ett minnesfel i systemet. Det är mycket viktigt att förstå mängden minne som är tillgängligt på servern och antalet samtidiga åtgärder som kan allokera minne för de uppgifter som beskrevs tidigare innan du gör ändringar i den här parametern.
Huvudpunkter
-
Vakuumminneslock: Om du vill påskynda rensningen av döda tupplar genom att öka
maintenance_work_membör du vara medveten om att detVACUUMhar en inbyggd begränsning för insamling av döda tupplar. Den kan bara använda upp till 1 GB minne för den här processen. -
Separation av minne för autovacuum: Du kan använda inställningen
autovacuum_work_memför att styra det minne som autovacuum-åtgärder använder oberoende av varandra. Den här inställningen fungerar som en delmängd avmaintenance_work_mem. Du kan bestämma hur mycket minne autovacuum använder utan att påverka minnesallokeringen för andra underhållsaktiviteter och datadefinitionsåtgärder.
Azure-specifika anteckningar
Standardvärdet för maintenance_work_mem serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval i beräkningen som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen maintenance_work_mem .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern maintenance_work_mem enligt värdena i följande formel.
Formeln som används för att beräkna värdet maintenance_work_mem för är (long)(82.5 * ln(memoryGiB) + 40) * 1024.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | maintenance_work_mem |
|---|---|
| 2 GiB | 99 328 KiB |
| 4 GiB | 157 696 KiB |
| 8 GiB | 216 064 KiB |
| 16 GiB | 274 432 KiB |
| 32 GiB | 332 800 KiB |
| 48 GiB | 367 616 KiB |
| 64 GiB | 392 192 KiB |
| 80 GiB | 410 624 KiB |
| 128 GiB | 450 560 KiB |
| 160 GiB | 468 992 KiB |
| 192 GiB | 484 352 KiB |
| 256 GiB | 508 928 KiB |
| 384 GiB | 542 720 KiB |
| 432 GiB | 552 960 KiB |
| 672 GiB | 590 848 KiB |
max_förberedda_transaktioner
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet samtidiga förberedda transaktioner. När du kör en replikserver måste du ange samma eller högre värde för den här parametern än på den primära servern. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0-262143 |
| Parametertyp | statiskt |
| Documentation | max_prepared_transactions |
max_stack_depth
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Ställer in maximal stackdjup i kilobyte. |
| Datatyp | integer |
| Standardvärde | 2048 |
| Tillåtna värden | 2048 |
| Parametertyp | skrivskyddad |
| Documentation | max_stack_depth |
shared_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger antalet buffertar för delat minne som används av servern. Enheten är 8 kB. Tillåtna värden ligger inom intervallet 10– 75 % av det tillgängliga minnet. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 16-1073741823 |
| Parametertyp | statiskt |
| Documentation | shared_buffers |
Description
Konfigurationsparametern shared_buffers avgör hur mycket systemminne som allokeras till PostgreSQL-databasen för buffring av data. Den fungerar som en centraliserad minnespool som är tillgänglig för alla databasprocesser.
När data behövs kontrollerar databasprocessen först den delade bufferten. Om nödvändiga data finns hämtas de snabbt och kringgår en mer tidskrävande diskläsning. Delade buffertar fungerar som mellanhand mellan databasprocesserna och disken och minskar effektivt antalet nödvändiga I/O-åtgärder.
Azure-specifika anteckningar
Standardvärdet för shared_buffers serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval till den beräkning som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen shared_buffers .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern shared_buffers enligt värdena i följande formler.
För virtuella datorer med upp till 2 GiB minne, används formeln shared_buffers för att beräkna värdet av memoryGib * 16384.
För virtuella datorer med mer än 2 GiB är shared_buffers formeln som används för att beräkna värdet memoryGib * 32768.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
delat_minne_typ
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den implementering av delat minne som används för huvudregionen för delat minne. |
| Datatyp | enumeration |
| Standardvärde | mmap |
| Tillåtna värden | mmap |
| Parametertyp | skrivskyddad |
| Documentation | delad_minne_typ |
temp_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet tillfälliga buffertar som används av varje databassession. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 100-1073741823 |
| Parametertyp | dynamic |
| Documentation | temp_buffers |
work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket minne som ska användas av interna sorteringsåtgärder och hash-tabeller innan du skriver till tillfälliga diskfiler. |
| Datatyp | integer |
| Standardvärde | 4096 |
| Tillåtna värden | 4096-2097151 |
| Parametertyp | dynamic |
| Documentation | work_mem |
Description
Parametern work_mem i PostgreSQL styr mängden minne som allokerats för vissa interna åtgärder i varje databassessions privata minnesområde. Exempel på dessa åtgärder är sortering och hashning.
Till skillnad från delade buffertar, som finns i det delade minnesområdet, work_mem allokeras i ett privat minnesutrymme per session eller per fråga. Genom att ange en lämplig work_mem storlek kan du avsevärt förbättra effektiviteten för dessa åtgärder och minska behovet av att skriva tillfälliga data till disk.
Huvudpunkter
-
Privat anslutningsminne:
work_memär en del av det privata minne som varje databassession använder. Det här minnet skiljer sig från det delade minnesområde somshared_buffersanvänds. -
Frågespecifik användning: Alla sessioner eller frågor använder inte
work_mem. Enkla frågor somSELECT 1är osannolika att krävawork_mem. Komplexa förfrågningar som omfattar åtgärder som sortering eller hashning kan dock använda ett eller flera segment avwork_mem. -
Parallella åtgärder: För frågor som sträcker sig över flera parallella serverdelar kan varje serverdel potentiellt använda ett eller flera segment av
work_mem.
Övervaka och justera work_mem
Det är viktigt att kontinuerligt övervaka systemets prestanda och justera work_mem vid behov, främst om frågekörningstiderna relaterade till sorterings- eller hashåtgärder är långsamma. Här är sätt att övervaka prestanda med hjälp av verktyg som är tillgängliga i Azure-portalen:
-
Insikt om frågeprestanda: Kontrollera fliken De vanligaste frågorna efter temporära filer för att identifiera frågor som genererar tillfälliga filer. Den här situationen tyder på ett potentiellt behov av att öka
work_mem. - Felsökningsguider: Använd fliken Höga temporära filer i felsökningsguiderna för att identifiera problematiska frågor.
Detaljerad justering
När du hanterar parametern work_mem är det ofta mer effektivt att använda en detaljerad justeringsmetod i stället för att ange ett globalt värde. Den här metoden säkerställer att du allokerar minne på ett omdömesgillt sätt baserat på de specifika behoven hos processer och användare. Det minimerar också risken för problem med minnesbrist. Så här kan du gå till väga:
Användarnivå: Om en specifik användare främst är involverad i aggregerings- eller rapporteringsuppgifter, som är minnesintensiva, bör du överväga att anpassa värdet för den
work_memanvändaren.ALTER ROLEAnvänd kommandot för att förbättra prestandan för användarens åtgärder.Funktions-/procedurnivå: Om specifika funktioner eller procedurer genererar betydande temporära filer kan det vara fördelaktigt att öka
work_memvärdet på den specifika funktions- eller procedurnivån.ALTER FUNCTIONAnvänd kommandot ellerALTER PROCEDUREför att specifikt allokera mer minne till dessa åtgärder.Databasnivå: Ändra
work_mempå databasnivå om endast specifika databaser genererar ett stort antal temporära filer.Global nivå: Om en analys av systemet visar att de flesta frågor genererar små temporära filer, medan bara ett fåtal skapar stora filer, kan det vara klokt att öka
work_memvärdet globalt. Den här åtgärden underlättar för de flesta frågor att bearbeta i minnet, så att du kan undvika diskbaserade åtgärder och förbättra effektiviteten. Var dock alltid försiktig och övervaka minnesanvändningen på servern för att säkerställa att den kan hantera det ökadework_memvärdet.
Fastställa det minsta work_mem värdet för sorteringsåtgärder
Om du vill hitta det minsta work_mem värdet för en specifik fråga, särskilt en som genererar tillfälliga diskfiler under sorteringsprocessen, börjar du med att överväga den tillfälliga filstorlek som genererades under frågekörningen. Om en fråga till exempel genererar en temporär fil på 20 MB:
- Anslut till databasen med hjälp av psql eller önskad PostgreSQL-klient.
- Ange ett initialt
work_memvärde som är något högre än 20 MB för att ta hänsyn till ytterligare rubriker vid bearbetning i minnet. Använd ett kommando som:SET work_mem TO '25MB'. - Kör
EXPLAIN ANALYZEpå den problematiska frågan i samma session. - Granska utdata för
"Sort Method: quicksort Memory: xkB". Om det anger"external merge Disk: xkB", höj värdet förwork_memstegvis och testa igen tills"quicksort Memory"visas. Utseendet på"quicksort Memory"signalerar att frågan nu körs i minnet. - När du har fastställt värdet via den här metoden kan du använda det antingen globalt eller på mer detaljerade nivåer (enligt beskrivningen tidigare) för att passa dina driftbehov.
autovacuum_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas av varje autovacuum-arbetsprocess. |
| Datatyp | integer |
| Standardvärde | -1 |
| Tillåtna värden | -1-2097151 |
| Parametertyp | dynamic |
| Documentation | autovacuum_work_mem |
dynamisk_delat_minnestyp
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Väljer den dynamiska implementering av delat minne som används. |
| Datatyp | enumeration |
| Standardvärde | posix |
| Tillåtna värden | posix |
| Parametertyp | skrivskyddad |
| Documentation | dynamic_shared_memory_type |
huge_pages
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Aktiverar/inaktiverar användningen av stora minnessidor. Den här inställningen gäller inte för servrar som har mindre än 4 virtuella kärnor. |
| Datatyp | enumeration |
| Standardvärde | try |
| Tillåtna värden | on,off,try |
| Parametertyp | statiskt |
| Documentation | huge_pages |
Description
Enorma sidor är en funktion som gör att minne kan hanteras i större block. Du kan vanligtvis hantera block på upp till 2 MB, till skillnad från standardsidorna på 4 KB.
Att använda stora sidor kan ge prestandafördelar som effektivt avlastar processorn:
- De minskar overheaden kopplad till minneshanteringsuppgifter, som färre TLB-missar (translation lookaside buffer).
- De förkortar den tid som krävs för minneshantering.
Mer specifikt kan du i PostgreSQL endast använda stora sidor för det delade minnesområdet. En betydande del av det delade minnesområdet allokeras för delade buffertar.
En annan fördel är att stora sidor förhindrar att det delade minnesområdet växlas ut till disken, vilket ytterligare stabiliserar prestandan.
Recommendations
- För servrar som har betydande minnesresurser bör du undvika att inaktivera stora sidor. Om du inaktiverar stora sidor kan prestandan försämras.
- Om du börjar med en mindre server som inte stöder stora sidor, men du förväntar dig att skala upp till en server som gör det, behåll
huge_pagesinställningenTRYför sömlös övergång och optimala prestanda.
Azure-specifika anteckningar
För servrar med fyra eller fler virtuella kärnor allokeras enorma sidor automatiskt från det underliggande operativsystemet. Funktionen är inte tillgänglig för servrar med färre än fyra virtuella kärnor. Antalet stora sidor justeras automatiskt om några inställningar för delat minne ändras, inklusive ändringar i shared_buffers.
maintenance_work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala minne som ska användas för underhållsåtgärder som VACUUM, Create Index. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 1024-2097151 |
| Parametertyp | dynamic |
| Documentation | maintenance_work_mem |
Description
maintenance_work_mem är en konfigurationsparameter i PostgreSQL. Den styr mängden minne som allokeras för underhållsåtgärder, till exempel VACUUM, CREATE INDEXoch ALTER TABLE. Till skillnad från work_mem, som påverkar minnesallokering för frågeåtgärder, maintenance_work_mem är reserverad för uppgifter som underhåller och optimerar databasstrukturen.
! [OBS] Om du anger
maintenance_work_memtill för aggressiva värden kan det med jämna mellanrum orsaka ett minnesfel i systemet. Det är mycket viktigt att förstå mängden minne som är tillgängligt på servern och antalet samtidiga åtgärder som kan allokera minne för de uppgifter som beskrevs tidigare innan du gör ändringar i den här parametern.
Huvudpunkter
-
Vakuumminneslock: Om du vill påskynda rensningen av döda tupplar genom att öka
maintenance_work_membör du vara medveten om att detVACUUMhar en inbyggd begränsning för insamling av döda tupplar. Den kan bara använda upp till 1 GB minne för den här processen. -
Separation av minne för autovacuum: Du kan använda inställningen
autovacuum_work_memför att styra det minne som autovacuum-åtgärder använder oberoende av varandra. Den här inställningen fungerar som en delmängd avmaintenance_work_mem. Du kan bestämma hur mycket minne autovacuum använder utan att påverka minnesallokeringen för andra underhållsaktiviteter och datadefinitionsåtgärder.
Azure-specifika anteckningar
Standardvärdet för maintenance_work_mem serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval i beräkningen som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen maintenance_work_mem .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern maintenance_work_mem enligt värdena i följande formel.
Formeln som används för att beräkna värdet maintenance_work_mem för är (long)(82.5 * ln(memoryGiB) + 40) * 1024.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | maintenance_work_mem |
|---|---|
| 2 GiB | 99 328 KiB |
| 4 GiB | 157 696 KiB |
| 8 GiB | 216 064 KiB |
| 16 GiB | 274 432 KiB |
| 32 GiB | 332 800 KiB |
| 48 GiB | 367 616 KiB |
| 64 GiB | 392 192 KiB |
| 80 GiB | 410 624 KiB |
| 128 GiB | 450 560 KiB |
| 160 GiB | 468 992 KiB |
| 192 GiB | 484 352 KiB |
| 256 GiB | 508 928 KiB |
| 384 GiB | 542 720 KiB |
| 432 GiB | 552 960 KiB |
| 672 GiB | 590 848 KiB |
max_förberedda_transaktioner
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet samtidiga förberedda transaktioner. När du kör en replikserver måste du ange samma eller högre värde för den här parametern än på den primära servern. |
| Datatyp | integer |
| Standardvärde | 0 |
| Tillåtna värden | 0-262143 |
| Parametertyp | statiskt |
| Documentation | max_prepared_transactions |
max_stack_depth
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Ställer in maximal stackdjup i kilobyte. |
| Datatyp | integer |
| Standardvärde | 2048 |
| Tillåtna värden | 2048 |
| Parametertyp | skrivskyddad |
| Documentation | max_stack_depth |
shared_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger antalet buffertar för delat minne som används av servern. Enheten är 8 kB. Tillåtna värden ligger inom intervallet 10– 75 % av det tillgängliga minnet. |
| Datatyp | integer |
| Standardvärde | Beror på resurser (virtuella kärnor, RAM-minne eller diskutrymme) som allokerats till servern. |
| Tillåtna värden | 16-1073741823 |
| Parametertyp | statiskt |
| Documentation | shared_buffers |
Description
Konfigurationsparametern shared_buffers avgör hur mycket systemminne som allokeras till PostgreSQL-databasen för buffring av data. Den fungerar som en centraliserad minnespool som är tillgänglig för alla databasprocesser.
När data behövs kontrollerar databasprocessen först den delade bufferten. Om nödvändiga data finns hämtas de snabbt och kringgår en mer tidskrävande diskläsning. Delade buffertar fungerar som mellanhand mellan databasprocesserna och disken och minskar effektivt antalet nödvändiga I/O-åtgärder.
Azure-specifika anteckningar
Standardvärdet för shared_buffers serverparametern beräknas när du etablerar instansen av en flexibel Azure Database for PostgreSQL-server baserat på det produktnamn som du väljer för dess beräkning. Eventuella efterföljande ändringar av produktval till den beräkning som stöder den flexibla servern påverkar inte standardvärdet för serverparametern för den instansen shared_buffers .
Varje gång du ändrar den produkt som tilldelats en instans bör du också justera värdet för parametern shared_buffers enligt värdena i följande formler.
För virtuella datorer med upp till 2 GiB minne, används formeln shared_buffers för att beräkna värdet av memoryGib * 16384.
För virtuella datorer med mer än 2 GiB är shared_buffers formeln som används för att beräkna värdet memoryGib * 32768.
Baserat på den tidigare formeln visar följande tabell de värden som den här serverparametern skulle ställas in på beroende på mängden minne som har etablerats:
| Minnesstorlek | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
temp_buffers
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger det maximala antalet tillfälliga buffertar som används av varje databassession. |
| Datatyp | integer |
| Standardvärde | 1024 |
| Tillåtna värden | 100-1073741823 |
| Parametertyp | dynamic |
| Documentation | temp_buffers |
work_mem
| Attribute | Värde |
|---|---|
| Kategori | Resursanvändning/minne |
| Description | Anger hur mycket minne som ska användas av interna sorteringsåtgärder och hash-tabeller innan du skriver till tillfälliga diskfiler. |
| Datatyp | integer |
| Standardvärde | 4096 |
| Tillåtna värden | 4096-2097151 |
| Parametertyp | dynamic |
| Documentation | work_mem |
Description
Parametern work_mem i PostgreSQL styr mängden minne som allokerats för vissa interna åtgärder i varje databassessions privata minnesområde. Exempel på dessa åtgärder är sortering och hashning.
Till skillnad från delade buffertar, som finns i det delade minnesområdet, work_mem allokeras i ett privat minnesutrymme per session eller per fråga. Genom att ange en lämplig work_mem storlek kan du avsevärt förbättra effektiviteten för dessa åtgärder och minska behovet av att skriva tillfälliga data till disk.
Huvudpunkter
-
Privat anslutningsminne:
work_memär en del av det privata minne som varje databassession använder. Det här minnet skiljer sig från det delade minnesområde somshared_buffersanvänds. -
Frågespecifik användning: Alla sessioner eller frågor använder inte
work_mem. Enkla frågor somSELECT 1är osannolika att krävawork_mem. Komplexa förfrågningar som omfattar åtgärder som sortering eller hashning kan dock använda ett eller flera segment avwork_mem. -
Parallella åtgärder: För frågor som sträcker sig över flera parallella serverdelar kan varje serverdel potentiellt använda ett eller flera segment av
work_mem.
Övervaka och justera work_mem
Det är viktigt att kontinuerligt övervaka systemets prestanda och justera work_mem vid behov, främst om frågekörningstiderna relaterade till sorterings- eller hashåtgärder är långsamma. Här är sätt att övervaka prestanda med hjälp av verktyg som är tillgängliga i Azure-portalen:
-
Insikt om frågeprestanda: Kontrollera fliken De vanligaste frågorna efter temporära filer för att identifiera frågor som genererar tillfälliga filer. Den här situationen tyder på ett potentiellt behov av att öka
work_mem. - Felsökningsguider: Använd fliken Höga temporära filer i felsökningsguiderna för att identifiera problematiska frågor.
Detaljerad justering
När du hanterar parametern work_mem är det ofta mer effektivt att använda en detaljerad justeringsmetod i stället för att ange ett globalt värde. Den här metoden säkerställer att du allokerar minne på ett omdömesgillt sätt baserat på de specifika behoven hos processer och användare. Det minimerar också risken för problem med minnesbrist. Så här kan du gå till väga:
Användarnivå: Om en specifik användare främst är involverad i aggregerings- eller rapporteringsuppgifter, som är minnesintensiva, bör du överväga att anpassa värdet för den
work_memanvändaren.ALTER ROLEAnvänd kommandot för att förbättra prestandan för användarens åtgärder.Funktions-/procedurnivå: Om specifika funktioner eller procedurer genererar betydande temporära filer kan det vara fördelaktigt att öka
work_memvärdet på den specifika funktions- eller procedurnivån.ALTER FUNCTIONAnvänd kommandot ellerALTER PROCEDUREför att specifikt allokera mer minne till dessa åtgärder.Databasnivå: Ändra
work_mempå databasnivå om endast specifika databaser genererar ett stort antal temporära filer.Global nivå: Om en analys av systemet visar att de flesta frågor genererar små temporära filer, medan bara ett fåtal skapar stora filer, kan det vara klokt att öka
work_memvärdet globalt. Den här åtgärden underlättar för de flesta frågor att bearbeta i minnet, så att du kan undvika diskbaserade åtgärder och förbättra effektiviteten. Var dock alltid försiktig och övervaka minnesanvändningen på servern för att säkerställa att den kan hantera det ökadework_memvärdet.
Fastställa det minsta work_mem värdet för sorteringsåtgärder
Om du vill hitta det minsta work_mem värdet för en specifik fråga, särskilt en som genererar tillfälliga diskfiler under sorteringsprocessen, börjar du med att överväga den tillfälliga filstorlek som genererades under frågekörningen. Om en fråga till exempel genererar en temporär fil på 20 MB:
- Anslut till databasen med hjälp av psql eller önskad PostgreSQL-klient.
- Ange ett initialt
work_memvärde som är något högre än 20 MB för att ta hänsyn till ytterligare rubriker vid bearbetning i minnet. Använd ett kommando som:SET work_mem TO '25MB'. - Kör
EXPLAIN ANALYZEpå den problematiska frågan i samma session. - Granska utdata för
"Sort Method: quicksort Memory: xkB". Om det anger"external merge Disk: xkB", höj värdet förwork_memstegvis och testa igen tills"quicksort Memory"visas. Utseendet på"quicksort Memory"signalerar att frågan nu körs i minnet. - När du har fastställt värdet via den här metoden kan du använda det antingen globalt eller på mer detaljerade nivåer (enligt beskrivningen tidigare) för att passa dina driftbehov.