Den här artikeln gör inte anspråk på att vara en komplett presentation av alla PostgreSQL-konfigurationsalternativ, och i jämförande tester täcker jag inte alla databasdriftlägen. Jag råder intresserade att studera boken på länken

Introduktion

Jag har jobbat mycket med PostgreSQL och tycker att det är ett utmärkt DBMS. Jag har en multi-gigabyte arbetsdatabas (inte 1C) som omedelbart behandlar enorma mängder data. PostgreSQL använder sig utmärkt av index, klarar parallella arbetsbelastningar bra, funktionaliteten hos lagrade procedurer är utmärkt, det finns bra administrations- och prestandaverktyg direkt, och communityn har skapat användbara verktyg. Men jag blev förvånad över att höra att många 1C-administratörer har en dålig uppfattning om PostgreSQL, att den är långsam och knappt överträffar filversionen av databasen, och bara MSSQL kan rädda situationen.

Efter att ha undersökt frågan hittade jag många artiklar om installation av PostgreSQL steg för steg för dummies, både på Linux och på Windows. Men de allra flesta artiklar beskriver installationen tills den är "installerad - låt oss skapa en databas", och berör inte frågan om konfiguration alls. I de återstående nämns konfiguration endast på nivån "ange sådana värden", med praktiskt taget ingen förklaring till varför.

Och om metoden med "en-knappsinstallation" är tillämplig på MSSQL och många produkter för Windows i allmänhet, så gäller den tyvärr inte för PostgreSQL. Standardinställningarna begränsar dess minnesanvändning avsevärt, så att du kan installera det även på en miniräknare och det kommer inte att störa driften av resten av programvaran. PostgreSQL måste konfigureras för ett specifikt system, och först då kan det visa sitt bästa. I särskilt svåra fall kan du justera inställningarna för PostgreSQL, databas och filsystem varandra, men det gäller i högre grad Linux-system där det finns fler möjligheter att anpassa allt.

Det bör påminnas om att för 1C är PostgreSQL-sammansättningen från DBMS-utvecklarna inte lämplig, endast sammansatt från patchade 1C-källkoder. Färdiga kompatibla sammansättningar erbjuds av 1C (via ITS-diskar och ett konto för de med ett supportabonnemang) och EterSoft

Testning utfördes i Windows-miljö, men alla konfigurationsrekommendationer är inte plattformsspecifika och gäller för alla operativsystem.

Testning och jämförelse

När jag testade satte jag mig inte för att utföra tester i alla driftlägen och scenarier, bara en grov kontroll av lyckad konfiguration.

För att testa använde jag följande konfiguration:
Värdmaskin: Win7, Core i5-760 2,8MHz, 4 kärnor, 12GB RAM, VMWare 10
Virtuell: Win7 x64, 2 kärnor, 4GB RAM, separat fysisk HDD för att vara värd för en databas (inte SSD)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
IC 8.3.5 1383

En databas användes, dt-upload 780MB.
Efter att ha återställt databasen:
filstorlek 1CD i filversion - 10GB,
PostgreSQL-databasstorlek - 8 GB,
MSSQL-databasstorleken är 6,7 GB.

För testet använde jag en begäran om ett urval av motpartsavtal (21k) med ett urval av ytterligare detaljer från olika register, för varje avtal gjordes faktiskt ett separat urval från registren. Jag tog den konfiguration som fanns till hands - kraftigt modifierad på basis av Accounting 3.0.

Under testningen körde jag förfrågan med en och två klienter flera gånger tills stabila resultat erhölls. Jag struntade i de första körningarna.

Testa med en klient:

Sampling på värden från en filversion med databasen placerad på SSD - 31c
Välj från en filvariant i virtuell maskin(Med hårddisk) - 46s
Sampling från en MSSQL-databas - first pass - 25s eller 9s (uppenbarligen beroende på relevansen av DBMS-cachen) (minnesförbrukningen av DBMS-processen var cirka 1,3 GB)
Sampling från PostgreSQL med standardinställningar - 43s (minnesförbrukningen översteg inte 80MB per anslutning)
Sampling från optimerad PostgreSQL - 21s (minnesförbrukningen var 120 MB per anslutning)

Testa med två kunder:

Sampling på värden från en filversion med databasen placerad på en SSD - 34s vardera
Sampling från en filversion i en virtuell maskin (från en hårddisk) - 56s vardera
Sampling från en MSSQL-databas - 50s eller 20s (uppenbarligen beroende på relevansen av DBMS-cachen)
Sampling från PostgreSQL med standardinställningar - 60s vardera
Sampling från optimerad PostgreSQL - 40s vardera

Testanteckningar:

1. Efter att ha lagt till den tredje kärnan började PostgreSQL- och MSSQL-varianter att fungera i "två klienter"-testet nästan med utförandet av "en klient"-testet, d.v.s. framgångsrikt parallelliserat. Vad som hindrade dem från att parallellt arbeta med två kärnor förblev ett mysterium för mig.
2. MSSQL tog upp mycket minne på en gång, PostgreSQL krävde betydligt mindre i alla lägen, och släppte nästan allt direkt efter att ha slutfört frågan.
3. MSSQL körs som en enda process. PostgreSQL lanserar en separat process per anslutning + tjänsteprocesser. Detta gör att även 32-bitarsvarianten kan använda minnet effektivt vid behandling av förfrågningar från flera klienter.
4. Att öka minnet för PostgreSQL i inställningar över värdena som visas nedan ledde inte till en märkbar ökning av prestanda.
5. De första testerna tog i alla fall längre tid än vid efterföljande mätningar, jag gjorde inga speciella mätningar, men MSSQL började subjektivt snabbare.

Konfigurera PostgreSQL

Det finns en utmärkt bok på ryska om att konfigurera och optimera PostgreSQL: Det är vettigt för varje elefantälskare att bokmärka den här länken. Boken beskriver många tekniker för att optimera DBMS, skapa feltoleranta och distribuerade system. Men nu ska vi titta på något som kommer att vara användbart för alla - konfigurera minnesanvändning. PostgreSQL kommer inte att använda mer minne än vad inställningarna tillåter, och med standardinställningar använder PostgreSQL ett minimum av minne. Samtidigt bör du inte ange mer minne än vad som är tillgängligt för användning - systemet kommer att börja använda växlingsfilen med alla de fruktansvärda konsekvenserna för serverns prestanda. Ett antal tips för att ställa in PostgreSQL finns på ITS-disken.

På Windows finns PostgreSQL-konfigurationsfiler i installationskatalogen i Datakatalogen:

• postgresql.conf- huvudfil med DBMS-inställningar
• pg_hba.conf- en fil med åtkomstinställningar för klienter. I synnerhet kan du här specificera vilka användare från vilka IP-adresser som kan ansluta till vissa databaser, och om det är nödvändigt att kontrollera användarens lösenord, och i så fall med vilken metod.
• pg_ident.conf- en fil med konvertering av användarnamn från system till internt (de flesta användare kommer sannolikt inte att behöva det)

Filerna är text, du kan redigera dem med anteckningsblock. Rader som börjar med # betraktas som kommentarer och ignoreras.

Parametrar relaterade till minneskapacitet kan kompletteras med suffixen kB, MB, GB - kilobyte, megabyte, gigabyte, till exempel 128MB. Parametrar som beskriver tidsintervall kan kompletteras med suffixen ms, s, min, h, d - millisekunder, sekunder, minuter, timmar, dagar, till exempel, 5min

Om du har glömt lösenordet till Postgress är det inga problem, du kan skriva in det pg_hba.conf linje:

Värd för alla 127.0.0.1/32-förtroende

Och anslut av vilken användare som helst (t.ex. postgres) till DBMS på den lokala datorn på 127.0.0.1 utan att kontrollera lösenordet.

Optimering minnesanvändning

Inställningar för minnesanvändning finns i postgresql.conf

Optimala parametervärden beror på volymen gratis random access minne, storleken på databasen och enskilda element i databasen (tabeller och index), komplexiteten hos frågor (i princip bör du anta att frågorna kommer att vara ganska komplexa - flera anslutningar i frågor är ett typiskt scenario) och antalet samtidigt aktiva kunder. Förresten, PostgreSQL lagrar databastabeller och index i separata filer (<каталог установки PG>\databas\<идентификатор БД>\), och storleken på objekt kan uppskattas. Du kan också använda det medföljande verktyget pgAdmin för att ansluta till databasen, expandera "Schema" - "public" och generera en statistikrapport för elementet "Tables".

Därefter kommer jag att ge ungefärliga värden från vilka du kan börja ställa in. Efter första installationen Det rekommenderas att köra servern i driftlägen och övervaka minnesförbrukningen. Beroende på erhållna resultat kan det vara nödvändigt att justera parametervärdena.

När jag satte upp servern för testning förlitade jag mig på följande beräkningar:
Endast 4GB RAM. Konsumenter - Windows OS, 1C-server, PostgreSQL och systemdiskcache. Jag antog att upp till 2,5 GB RAM kan allokeras för DBMS

Värden kan anges med suffixen kB, MB, GB (värden i kilobyte, megabyte eller gigabyte). Efter att ha ändrat värdena måste du starta om PostgreSQL-tjänsten.

shared_buffers - Delad serverbuffert

Storleken på PostgreSQL-läs- och skrivcachen som delas av alla anslutningar. Om data inte finns i cachen läses den från disk (möjligen cachad av operativsystemet)

Om buffertstorleken är otillräcklig för att lagra ofta använda arbetsdata, kommer den ständigt att skrivas och läsas från OS-cachen eller från disken, vilket kommer att ha en extremt negativ inverkan på prestandan.

Men detta är inte allt minne som krävs för drift, du bör inte ange för mycket stor betydelse, annars finns det inget minne kvar både för att faktiskt utföra klientförfrågningar (och ju fler det finns, desto högre minnesförbrukning) och för operativsystemet och andra applikationer, till exempel 1C-serverprocessen. Servern förlitar sig också på OS-cachen och försöker att inte hålla i sin buffert det som sannolikt cachelagras av systemet.

Testet som används

shared_buffers = 512MB

work_mem- minne för sortering, dataaggregation, etc.

Tilldelas för varje begäran, eventuellt flera gånger för komplexa förfrågningar. Om det inte finns tillräckligt med minne kommer PostgreSQL att använda temporära filer. Om värdet är för stort kan RAM-minnet överanvändas och operativsystemet kommer att börja använda växlingsfilen med motsvarande sänkning i prestanda.

Det finns en rekommendation vid beräkning att ta mängden tillgängligt minne minus shared_buffers, och dividera med antalet samtidigt körda förfrågningar. Vid komplexa frågor bör divisorn ökas, d.v.s. minska resultatet. För det aktuella fallet, baserat på 5 aktiva användare (2,5 GB-0,5 GB (shared_buffers))/5=400 MB. Om DBMS anser att frågorna är ganska komplexa, eller om ytterligare användare dyker upp, måste värdet minskas.

För enkla frågor är små värden tillräckliga - upp till ett par megabyte, men för komplexa frågor (och detta är ett typiskt scenario för 1C) kommer mer att krävas. Rekommendation - för minne 1-4GB kan du använda värden på 32-128MB. Jag använde den i testet

work_mem = 128MB

underhållsarbete_mem- Minne för sopsamlingskommandon, statistik, indexskapande.

Det rekommenderas att ställa in värdet till 50-75 % av storleken på den största tabellen eller indexet, men så att det finns tillräckligt med minne för att köra systemet och applikationerna. Det rekommenderas att ställa in värden som är större än work_mem. Jag använde den i testet
maintenance_work_mem = 192 MB

temp_buffertar- en buffert för temporära objekt, främst för temporära tabeller.

Du kan installera cirka 16 MB. Jag använde den i testet
temp_buffers = 32MB

effektiv_cache_storlek- ungefärlig storlek på filsystemets diskcache.

Optimeraren använder detta värde när man bygger en frågeplan för att uppskatta sannolikheten för att data hittas i en cache (med snabb slumpmässig åtkomst) eller på en långsam disk. I Windows kan den aktuella mängden minne som allokerats för cachen ses i aktivitetshanteraren.

Autovacuum - "sopsamling"

PostgreSQL, som en typisk representant för "versionerade" DBMS:er (i motsats till blockerande sådana), blockerar inte oberoende tabeller och poster från att läsa transaktioner när data ändras (i fallet med 1C gör 1C-servern själv detta). Istället skapas en kopia av den modifierade posten, som blir synlig för efterföljande transaktioner, medan befintliga fortsätter att se den data som var aktuell i början av deras transaktion. Som ett resultat ackumuleras föråldrad data i tabeller - tidigare versionerändrade register. För att DBMS ska kunna använda det frigjorda utrymmet är det nödvändigt att utföra "sopsamling" - för att avgöra vilka av posterna som inte längre används. Detta kan göras explicit med ett SQL-kommando VAKUUM, eller vänta på att bordet ska behandlas av den automatiska sophämtaren - AUTOVAKUUM. Fram till en viss version var sophämtning associerad med statistikinsamling (planeraren använder data om antalet poster i tabeller och fördelningen av värden för indexerade fält för att bygga en optimal frågeplan). Å ena sidan måste sophämtning göras så att tabeller inte växer och effektivt använder diskutrymme. Å andra sidan lägger plötsligt påbörjad sophämtning ytterligare belastning på disken och tabellerna, vilket leder till en ökning av exekveringstiden för frågor. En liknande effekt skapas av automatisk statistikinsamling (det kan självklart startas med kommandot ANALYSERA eller tillsammans med sophämtning VAKUUMANALYSER). Och även om PostgreSQL förbättrar dessa mekanismer från version till version för att minimera Negativ påverkan på prestanda (till exempel, i tidigare versioner, blockerade sophämtning helt åtkomst till tabellen, eftersom version 9.0 fungerade VAKUUM accelererad), finns det något att konfigurera här.

Du kan inaktivera autovakuum helt med följande parameter:

autovakuum = av

För att Autovacuum ska fungera krävs också parametern track_counts = on, annars kommer den inte att fungera.

Som standard är båda alternativen aktiverade. I själva verket kan autovakuum inte inaktiveras helt - även med autovacuum = av, ibland (efter ett stort antal transaktioner) startar autovacuum.

Kommentar: VAKUUM minskar vanligtvis inte tabellfilens storlek, markerar bara lediga områden som är tillgängliga för återanvändning. Om du fysiskt vill frigöra överflödigt utrymme och minimera det upptagna diskutrymmet behöver du kommandot VAKUUM FULL. Det här alternativet blockerar åtkomst till tabellen medan den körs och krävs vanligtvis inte. Mer information om att använda kommandot VACUUM finns i dokumentationen (på engelska).

Om Autovacuum inte är helt inaktiverat kan du konfigurera dess inflytande på exekveringen av frågor med hjälp av följande parametrar:

autovacuum_max_workers- det maximala antalet parallella rengöringsprocesser.

autovacuum_naptime - det minsta intervall som är kortare än vilket autovacuum inte startar. Standard är 1 minut. Du kan öka den, om data ändras ofta kommer analysen att utföras mer sällan.

autovacuum_vacuum_threshold, - antalet ändrade eller raderade poster i tabellen som krävs för att utlösa sophämtningsprocessen VAKUUM eller samla in statistik ANALYSERA. Standard är 50.

autovacuum_vacuum_scale_factor , autovacuum_analyze_scale_factor - koefficient för tabellstorlek i poster som läggs till autovacuum_vacuum_threshold Och autovacuum_analyze_threshold respektive. Standardvärdena är 0,2 (dvs. 20 % av antalet poster) respektive 0,1 (10 %).

Låt oss överväga ett exempel med en tabell med 10 000 poster. Sedan, med standardinställningar, efter 50+10000*0.1=1050 ändrade eller raderade poster, kommer statistikinsamling att startas ANALYSERA, och efter 2050 förändringar - sophämtning VAKUUM.

Om du ökar tröskeln och scale_factor kommer underhållsprocesser att köras mer sällan, men små tabeller kan växa avsevärt. Om databasen huvudsakligen består av små tabeller kan den totala ökningen av diskutrymmesförbrukning vara betydande, så du kan öka dessa värden, men klokt.

Därför kan det vara meningsfullt att öka intervallet för autovacuum_naptime och öka tröskeln och scale_factor något. I laddade databaser kan det vara ett alternativ att avsevärt höja scale_factor (ett värde på 1 gör att tabellerna kan "svälla" två gånger) och ställa in daglig exekvering till schemaläggaren VAKUUMANALYSER under perioder med minimal databasbelastning.

default_statistics_target - tilldelar mängden statistik som samlas in av kommandot ANALYSERA. Standardvärdet är 100. Större värden ökar exekveringstiden för kommandot ANALYSE, men tillåter schemaläggaren att bygga mer effektiva frågeplaner. Det finns rekommendationer att öka till 300.

Prestanda kan kontrolleras AUTOVAKUUM, vilket gör det längre men mindre stressande för systemet.

vacuum_cost_page_hit- storleken på "böterna" för att bearbeta ett block som finns i shared_buffers. Förknippas med behovet av att blockera åtkomst till bufferten. Standardvärde 1

vacuum_cost_page_miss - storleken på "böterna" för att bearbeta ett block på disk. Förknippas med blockering av en buffert, sökning efter data i en buffert, läsning av data från disk. Standardvärde 10

vacuum_cost_page_dirty- storleken på "böterna" för blockmodifiering. Förknippas med behovet av att återställa modifierade data till disk. Standardvärde 20

vacuum_cost_limit- det maximala antalet "böter" efter vilket monteringsprocessen kan "frysas" under vacuum_cost_delay. Standard 200

vacuum_cost_delay- dags att "frysa" sophämtningsprocessen när vacuum_cost_limit uppnåtts. Standardvärde 0ms

autovacuum_vacuum_cost_delay- dags att "frysa" sophämtningsprocessen för autovakuum. Standard är 20ms. Om satt till -1 kommer värdet vacuum_cost_delay att användas

autovacuum_vacuum_cost_limit- den maximala storleken på "böterna" för autovakuum. Standardvärde -1 - vacuum_cost_limit värde används

Rapporterad användning vacuum_cost_page_hit = 6, vacuum_cost_limit = 100, autovacuum_vacuum_cost_delay = 200ms minskar effekten av AUTOVACUUM med upp till 80 %, men tredubblar dess utförandetid.

Ställa in diskinspelning

När en transaktion slutförs, skriver PostgreSQL först data till en speciell transaktionslogg WAL (Write-ahead log) och sedan till databasen efter att loggdata garanterat skrivs till disk. Standardmekanismen är fsync, när PostgreSQL kraftfullt rensar data (logg) från OS-diskcachen till disken, och först efter en lyckad skrivning (logg) informeras klienten om att transaktionen slutfördes framgångsrikt. Genom att använda en transaktionslogg kan du slutföra en transaktion eller återställa databasen om ett fel uppstår när du skriver data.

I upptagna system med stora skrivvolymer kan det vara meningsfullt att flytta transaktionsloggen till en separat fysisk disk (men inte till en annan partition på samma disk!). För att göra detta måste du stoppa DBMS, flytta pg_xlog-katalogen till en annan plats och skapa en symbolisk länk på den gamla platsen, till exempel med hjälp av junction-verktyget. Far Manager (Alt-F6) kan också skapa länkar. I det här fallet måste du se till att den nya platsen har åtkomsträttigheter för användaren som kör PostgreSQL (vanligtvis postgres).

Om det finns ett stort antal datamodifieringsoperationer kan du behöva öka värdet checkpoint_segments, som styr mängden data som kan vänta på att överföras från loggen till själva databasen. Standardvärdet är 3. Det bör beaktas att utrymme tilldelas för loggen, beräknat med formeln (checkpoint_segments * 2 + 1) * 16 MB, som med ett värde på 32 redan kommer att kräva mer än 1 GB disk Plats.

PostgreSQL rensar data från OS-filcachen till disken efter att varje skrivtransaktion har slutförts. Å ena sidan garanterar detta att data på disken alltid är uppdaterad, å andra sidan, med ett stort antal transaktioner, minskar prestandan. Inaktivera helt fsync möjligt genom att specificera

fsync=av
full_page_writes = av

Detta kan endast göras om du litar till 100 % på utrustningen och UPS:en (källa avbrottsfri strömförsörjning). Annars finns det risk att man vid en systemkrasch får en förstörd databas. Och i alla fall skulle en RAID-kontroller med ett batteri för att driva minnet av oskrivna data inte heller skada.

Ett definitivt alternativ kan vara att använda parametern

synchronous_commit = av

I det här fallet, efter ett framgångsrikt svar för att slutföra transaktionen, kan det ta lite tid innan transaktionen skrivs säkert till disken. Vid en plötslig avstängning kommer databasen inte att förstöras, men data från de senaste transaktionerna kan gå förlorade.

Om du inte inaktiverar fsync helt kan du ange synkroniseringsmetoden i parametern. Artikeln från ITS-disken hänvisar till verktyget pg_test_fsync, men det hittades inte i min PostgreSQL-build. Enligt 1C visade sig metoden i deras fall i Windows vara optimal open_datasync(uppenbarligen är detta metoden som används som standard).

Om många små skrivtransaktioner används (i fallet med 1C kan detta vara en massuppdatering av katalogen utanför transaktionen), en kombination av parametrarna commit_delay (transaktionsavslutningsfördröjning i mikrosekunder, standard 0) och commit_siblings (standard 5) kan hjälpa. När alternativen är aktiverade kan slutförandet av transaktionen försenas med commit_delay if det här ögonblicketÅtminstone commit_siblings-transaktioner exekveras. I det här fallet kommer resultatet av alla genomförda transaktioner att skrivas samman för att optimera diskskrivningar.

Andra parametrar som påverkar prestandan

wal_buffertar- mängden minne i shared_buffers för att upprätthålla transaktionsloggar. Rekommendation: med 1-4GB tillgängligt minne, använd värden på 256KB-1MB. Dokumentationen anger att användningen av värdet "-1" automatiskt justerar värdet beroende på värdet på shared_buffers.

slumpmässig_sida_kostnad- "kostnaden" för slumpmässig läsning, som används vid sökning efter data med hjälp av index. Standard är 4.0. Enheten är tiden för sekventiell dataåtkomst. För snabba diskarrayer, särskilt SSD-enheter, är det vettigt att sänka värdet; i det här fallet kommer PostgreSQL att använda index mer aktivt.

Boken på länken har några andra parametrar som kan konfigureras. Det rekommenderas också starkt att du läser PostgreSQL-dokumentationen om tilldelning av specifika parametrar.

Det rekommenderas att ändra parametrarna från QUERY TUNING-sektionen, särskilt de som är relaterade till att förbjuda schemaläggaren från att använda specifika sökmetoder, endast om du har en fullständig förståelse för vad du gör. Det är väldigt enkelt att optimera en typ av fråga och förstöra prestandan för alla andra. Effektiviteten av att ändra de flesta parametrar i det här avsnittet beror på data i databasen, frågor till dessa data (dvs. versionen av 1C som används, bland annat) och versionen av DBMS.

Slutsats

PostgreSQL är ett kraftfullt DBMS i kapabla händer, men det kräver noggrann konfiguration. Den kan användas tillsammans med 1C och få anständig prestanda, och dess fria natur kommer att vara en mycket trevlig bonus.

Kritik och tillägg till denna artikel är välkomna.

Användbara länkar

http://postgresql.leopard.in.ua/ - bokwebbplats " Arbeta med PostgreSQL-konfiguration och skalning ", den mest kompletta och begripliga guiden, enligt min mening, för att konfigurera och administrera PostgreSQL

http://etersoft.ru/products/postgre - här kan du ladda ner en 1C-kompatibel version av PostgreSQL för Windows och olika distributioner och versioner av Linux. För dig som inte har ett abonnemang på ITS eller behöver en version för Linux version, som inte presenteras på v8.1c.ru.

http://www.postgresql.org/docs/9.2/static/ - officiell dokumentation om PostgreSQL (på engelska)

Artiklar från ITS-disken om inställning av PostgreSQL

Artikelredigeringshistorik

• 2015-01-29 - initial version publicerad
• 2015-01-31 - artikeln kompletterades med ett avsnitt om AUTOVACUUM, en länk till originaldokumentationen lades till.

I framtiden har jag för avsikt att testa driften av DBMS i läget för att lägga till och ändra data.

Vi kommer att installera en montering från företaget Postgres Professional. På sidan med versionen för 1C:Enterprise hittar vi information om att installera den senaste versionen av PostgreSQL på CentOS 7.

Låt oss ansluta arkiven och installera PostgreSQL 9.6:

Sudo rpm -ivh http://1c.postgrespro.ru/keys/postgrespro-1c-centos96.noarch.rpm sudo yum makecache sudo yum installera postgresql-pro-1c-9.6

Grundläggande PostgreSQL-inställning

Vi initierar tjänstedatabaser med rysk lokalisering:

Su postgres /usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data --locale=ru_RU.UTF-8 avsluta tjänsten postgresql-9.6 initdb

Starta PostgreSQL-tjänsten och lägg till den vid start:

Systemctl aktivera postgresql-9.6 systemctl start postgresql-9.6 systemctl status postgresql-9.6

Vi ställer in ett lösenord för postgres-användaren för att kunna ansluta till servern på distans:

Su - postgres psql ALTER USER postgres MED KRYPTAT LÖSENORD "ditt lösenord"; \q avsluta

Mcedit /var/lib/pgsql/9.6/data/pg_hba.conf

i filen som öppnas, avkommentera och ändra raderna:

värd för alla 127.0.0.1/32 ident på värd för alla alla 127.0.0.1/32 md5

värd för alla alla 0.0.0.0/0 ident på värd alla alla 0.0.0.0/0 md5

Optimera PostgreSQL-inställningar (postgresql.conf) för 1C:Enterprise

Här kommer inställningarna för PostgreSQL som körs i en virtuell ESXi 6.5-maskin.

Resurser tilldelade för den virtuella datorn:

processor - 8 vCPU;

minne - 48 GB;

disk för OS - 50 GB på LUN-hårdvara RAID1 från SAS HDD;

disk för databas - 170 GB på programvaran RAID1 från SSD

disk för loggar - 100 GB på programvaran RAID1 från SSD

För att redigera inställningarna, kör kommandot:

Mcedit /var/lib/pgsql/9.6/data/postgresql.conf

Kommenterade parametrar som vi kommer att ändra måste aktiveras.

CPU

autovacuum_max_workers = 4

autovacuum_max_workers = NCores/4..2 men inte mindre än 4

Antal autovakuumprocesser. Den allmänna regeln är att ju fler skrivförfrågningar, desto fler processer. På en skrivskyddad databas räcker det med en process.

ssl=av

Stäng av kryptering. För säkra datacenter är kryptering meningslös, men leder till ökad CPU-belastning

Minne

shared_buffers = 12 GB

shared_buffers = RAM/4

Mängden minne som tilldelats av PgSQL för den delade sidcachen. Detta minne delas mellan alla PgSQL-processer. operativ system Den cachar själva data, så det finns inget behov av att allokera allt tillgängligt RAM-minne för cachen.

temp_buffers = 256MB

Maximalt antal sidor för tillfälliga tabeller. De där. detta är den övre gränsen för storleken på temporära bord i varje session.

work_mem = 64MB

work_mem = RAM/32..64 eller 32MB..128MB

Minnesgräns för behandling av en begäran. Detta minne är individuellt för varje session. Teoretiskt sett är det maximala minnet som krävs lika med max_connections * work_mem, i praktiken händer detta inte eftersom de flesta sessioner nästan alltid väntar. Detta rådgivande värde används av optimeraren: den försöker förutsäga storleken på det minne som krävs för frågan, och om detta värde är större än work_mem, säger det till executorn att omedelbart skapa en temporär tabell. work_mem är inte en gräns i full mening: optimeraren kan missa, och begäran kommer att ta upp mer minne, kanske många gånger mer. Detta värde kan minskas genom att övervaka antalet tillfälliga filer som skapas:

maintenance_work_mem = 2 GB

maintenance_work_mem = RAM/16..32 eller work_mem * 4 eller 256 MB..4GB

Minnesgräns för underhållsuppgifter, som att samla in statistik (ANALYSE), sophämtning (VAKUUM), skapa index (CREATE INDEX) och lägga till främmande nycklar. Storleken på minnet som allokeras för dessa operationer bör vara jämförbart med fysisk storlek det största indexet på skivan.

effektiv_cache_storlek = 36 GB

effective_cache_size = RAM - shared_buffers

Uppskattning av filsystemets cachestorlek. Genom att öka parametern ökar systemets benägenhet att välja IndexScan-planer. Och det här är bra.

Skivor

effektiv_io_samtidighet = 5

En uppskattning av de samtidiga förfrågningar till ett disksystem som det kan betjäna på en gång. För en enda disk = 1, för RAID - 2 eller fler.

random_page_cost = 1.3

random_page_cost = 1,5-2,0 för RAID, 1,1-1,3 för SSD

Kostnad för att läsa en slumpmässig sida (standard 4). Ju kortare söktiden för disksystemet är, desto mindre (men > 1,0) bör denna parameter vara. Ett alltför stort parametervärde ökar PgSQL:s tendens att välja planer som skannar hela tabellen (PgSQL anser att det är billigare att läsa hela tabellen sekventiellt än att slumpmässigt läsa indexet). Och det är dåligt.

autovakuum=på

Sätter på autovakuum.

autovacuum_naptime = 20s

Autovacuum process sovtid. Om värdet är för stort kommer tabellerna inte att hinna dammsuga och som ett resultat kommer uppblåsningen och storleken på tabeller och index att öka. Ett litet värde kommer att resultera i onödig uppvärmning.

bgwriter_delay = 20ms

Vilotid mellan diskskrivcykler för bakgrundsskrivprocessen. Denna process är ansvarig för att synkronisera sidor som finns i shared_buffers med disk. Ett för stort värde för denna parameter kommer att öka belastningen på checkpointprocessen och processer som betjänar sessioner (backend). Ett litet värde kommer att resultera i att en av kärnorna är fullastad.

bgwriter_lru_multiplier = 4.0

bgwriter_lru_maxpages = 400

Alternativ som styr inspelningsintensiteten för bakgrundsinspelningsprocessen. I en cykel skriver bgwriter inte mer än vad som skrevs i den senaste cykeln, multiplicerat med bgwriter_lru_multiplier, men inte mer än bgwriter_lru_maxpages.

synchronous_commit = av

Inaktivera disksynkronisering vid tidpunkten för commit. Skapar risk för att förlora de senaste transaktionerna (inom 0,5-1 sekunder), men garanterar databasens integritet, det finns inga luckor i commit-kedjan. Men det ökar produktiviteten avsevärt.

wal_keep_segments = 256

wal_keep_segments = 32..256

Maximalt antal WAL-segment mellan kontrollpunkter. För frekventa kontrollpunkter leder till en betydande skrivbelastning på diskundersystemet. Varje segment är 16MB stort

wal_buffers = 16 MB

Mängden delat minne som kommer att användas för att buffra WAL-data som ännu inte skrivits till disken. Standardvärdet på -1 anger en storlek som är lika med 1/32 (cirka 3%) av , men inte mindre än 64 KB och inte mer än storleken på ett enskilt WAL-segment (vanligtvis 16 MB). Detta värde kan ställas in manuellt om den automatiskt valda är för liten eller stor, men alla positiva tal mindre än 32 KB kommer att behandlas som 32 KB. Denna parameter kan endast ställas in vid serverstart.

Innehållet i WAL-buffertar skrivs till disk när varje transaktion genomförs, så mycket stora värden kommer sannolikt inte att ge någon större nytta. Ett värde på minst några megabyte kan dock förbättra skrivprestandan på en upptagen server när många klienter genomför transaktioner samtidigt. Autotuning, som arbetar med standardvärdet (-1), väljer rimliga värden i de flesta fall.

default_statistics_target = 1000

Ställer in standardgränsen för statistikmål som gäller för kolumner för vilka ALTER TABLE SET STATISTICS inte har angett individuella gränser. Ju högre värde som är satt, desto längre tid tar det att köra ANALYSE, men desto högre kvalitet kan schemaläggarens uppskattningar vara. Standardvärdet för denna parameter är 100.

checkpoint_completion_target = 0,9

Graden av "smetande" av kontrollpunkten. Registreringshastigheten under en kontrollpunkt justeras så att kontrollpunktstiden är lika med tiden som förflutit sedan tidigare, multiplicerat med checkpoint_completion_-målet.

min_wal_size = 4G
max_wal_size = 8G

min_wal_size = 512 MB .. 4G
max_wal_size = 2 * min_wal_size

Minsta och maximala storlek på WAL-filer. Liknar checkpoint_segments

fsync=på

Att inaktivera alternativet resulterar i ökad prestanda, men det finns en betydande risk att förlora all data om strömmen plötsligt slås av. Observera: om RAID har en cache och är i återskrivningsläge, kontrollera närvaron och funktionaliteten hos RAID-kontrollerns cachebatteri! Annars kan data som skrivs till RAID-cachen gå förlorade när strömmen stängs av, och som ett resultat garanterar PgSQL inte dataintegritet.

row_security = av

Inaktiverar Record Level Resolution Control

enable_nestloop = av

Aktiverar eller inaktiverar schemaläggarens användning av kapslade loopkopplingsplaner. Det är inte möjligt att helt eliminera kapslade loopar, men om du stänger av det här alternativet kommer inte schemaläggaren att använda den här metoden, om andra kan tillämpas. Som standard är denna inställning på.

Lås

max_locks_per_transaction = 256

Maximalt antal index-/tabelllås i en transaktion

Inställningar för 1C-plattformen

standard_conforming_strings = av

Tillåt att \-tecken används för escape

escape_string_warning = av

Varna inte för att använda tecknet \ för att escape

Säkerhetsinställningar

Låt oss se till att PostgreSQL-servern endast är synlig för 1C: Enterprise-servern installerad på samma maskin.

listen_addresses = 'localhost'

Om 1C: Enterprise-servern är installerad på en annan dator eller om det finns ett behov av att ansluta till DBMS-servern med snapin-modulen PGAdmin, så istället lokal värd du måste ange adressen till denna maskin.

Databaslagring

PostgreSQL, som nästan alla DBMS, är avgörande för diskundersystemet, därför, för att öka prestandan hos DBMS, kommer vi att placera PostgreSQL-systemet, loggar och själva databaserna på olika diskar.

Stoppar servern

Systemctl stoppa postgresql-9.6

Vi överför loggar till en 120GB SSD:

Mv /var/lib/pgsql/9.6/data/pg_xlog /raid120 mv /var/lib/pgsql/9.6/data/pg_clog /raid120 mv /var/lib/pgsql/9.6/data/pg_log /raid120

Ln -s /raid120/pg_xlog /var/lib/pgsql/9.6/data/pg_xlog ln -s /raid120/pg_clog /var/lib/pgsql/9.6/data/pg_clog ln -s /raid120/pg_log /var/lib/ pgsql/9.6/data/pg_log

Vi kommer också att överföra katalogen med databaserna:

Mv /var/lib/pgsql/9.6/data/base /raid200

Ln -s /raid200/base /var/lib/pgsql/9.6/data/base

Låt oss starta servern och kontrollera dess status

Systemctl start postgresql-9.6 systemctl status postgresql-9.6

Använd case som en PostgreSQL-databasserver på windows plattform inte särskilt populärt, men det uppstår oftast när du på något sätt behöver spara pengar på produkter från MS. Det finns också specialiserade applikationer som fungerar bäst med PostgreSQL. För 1c finns det en modifierad version av PostgreSQL som, som utvecklarna försäkrar, ger en prestandanivå och feltolerans jämförbar med MSSQL. Är det verkligen så, låt oss kolla det i praktiken :)

1. Installera PostgreSQL

Ladda ner den senaste versionen av PostgreSQL 64-bitars 9.1.2-1.1C från 1c-webbplatsen, packa upp arkivet, kör msi-paketet, det utan int har inte en stor filstorlek.

Klicka på Start.
Lämna installationsalternativen som standard.

Ange ett lösenord för användaren postgres varifrån tjänsten kommer att starta . Klicka på Nästa. Om du installerar PostgreSQL för första gången kommer guiden att uppmana dig att skapa en användare postgres.

Välj UTF8-kodning vid initieringsstadiet av databasen. Ställ in inloggning och lösenord för den interna postgres-användaren. Uppmärksamhet! PostgreSQL-tjänstens användarlösenord och det interna användarlösenordet för PostgreSQL-databasen får inte vara detsamma. Lösenordet måste vara minst fyra tecken långt. Om du planerar att köra 1C-servern och PostgreSQL på olika maskiner, måste du markera kryssrutan "Stödanslutningar från valfri IP, inte bara lokalvärd". Klicka på Nästa och Nästa igen. :)

Klicka på Nästa två gånger till och vänta tills installationen är klar.

Gå sedan till Start\Alla program\PostgreSQL 9.1.2-1.1C(x64). Starta administrationsverktyget pgAdmin III. Låt oss försöka ansluta till databasen. Ange lösenordet som du angav under installationen.
Och vi får följande fel: Fel vid anslutning till servern: FATAL: lösenordsautentisering misslyckades för användaren "postgres".

Ganska oväntat med tanke på att lösenordet skrevs rätt. Jag bestämde mig för att mixtra med pg_hba.conf, men vid första anblicken är allt bra där.

# TYP DATABAS ANVÄNDARADRESSMETOD # IPv4 lokala anslutningar: host all postgres::1/128 md5 host all postgres 127.0.0.1/32 md5 host all postgres 192.168.1.0/24 md5

Jag bestämde mig för att ändra auktoriseringsmetoden från md5 till trust. Jag startar om tjänsten och försöker ansluta till databasen igen. Den här gången får jag det här meddelandet.
Mer än en är faktiskt tillgänglig på pgAdmins webbplats en ny version. Därefter lyckades anslutningen till databasen!!?!! Jag minns att md5 tidigare inte orsakade sådana problem, tydligen är denna glitch verkligen relaterad till gammal version pgAdmin.
Nu kan vi skapa en databas för behoven hos 1C, eller göra det med 1C själv :)

2. Installation 1C enterprise 8.2.

För installationen noterar vi följande komponenter: 1C:Enterprise, 1C:Enterprise Server, Webservertilläggsmoduler, 1C:Enterprise-serveradministration.
Vid installationsstadiet "Installera 1C Enterprise as a Service" ställer vi in ​​lösenordet för användaren USR1C82.
Klicka på nästa och övervaka installationsförloppet :) Till användaren USR1CV82 Följande rättigheter måste tilldelas under installationen:

Logga in som en tjänst (Logga in som en tjänst), Logga in som ett batchjobb (Logga in som ett batchjobb). Du kan se den på Lokal datorpolicy\Datorkonfiguration\Windows-inställningar\Säkerhetsinställningar\Lokala policyer\User Right Assignments.

Låt oss gå till utrustningen Administration av 1C Enterprise-servrar, Vi ser att klustret har rest sig och hänger på port 1541. Vår server finns också på fliken "Arbetande servrar". Nu kan du lägga till databasen till 1C-servern. För att göra detta, gå till fliken " Informationsbaser"Högerklicka och välj Ny - Informationsbas. Ställ in nödvändiga parametrar för att ansluta till PostgreSQL-servern. Klicka på OK. Låt oss lansera 1C: Enterprise. Vi väljer att lägga till en befintlig infobas på servern.
Ställ sedan in anslutningsparametrarna. Klicka på "Nästa" och slutligen "Slutför".
Operationen för att skapa en databas kan göras direkt från 1C: Enterprise. För att göra detta, vid start, välj "Skapa en ny informationsbas».

För att ansluta 1C-klienter till servern utifrån och driva databasservern på brandväggen måste följande portar vara öppna:

Serveragent ( ragent) - tcp:1540 Chief cluster manager ( rmngr) - tcp:1541 Utbud av nätverksportar för dynamisk distribution av arbetsprocesser - tcp:1560-1591, tcp:5432 - Postgresql. Låt oss skapa en regel genom standardgränssnittet, eller genom att använda kommandot:

netsh advfirewall brandvägg lägg till regelnamn = "1Cv8-Server" dir=in action=allow protocol=TCP localport=1540,1541,5432,1560-1590 enable=yes profile=ANY remoteip=ANY interfacetype=LAN

Nu kan vi enkelt starta 1C:Enterprise-klienten från en annan dator och lägga till den befintliga informationsbasen newdb. Glöm inte licenser och mjukvara/hårdvaruskydd. Nu kan vi ladda ner Gilev-testet och mäta vårt systems prestanda.

På VirtualBox med 1 GB minne, Dual-Core 2,6 GHz, 319-release 1c ger Gilev-testet 11,42 poäng, ungefär samma som på CentOS. Vid 16.362 är det lite mer än 11.60 poäng. Att optimera inställningarna med EnterpriseDB Tuning Wizard gav ingen märkbar ökning (11.66 och 11.62), även om det generellt sett kan vara fördelaktigt. :)

3. Rutinarbete på PostgreSQL-servern.

Säkerhetskopiering.

Starta administrationsverktyget pgAdmin III och högerklicka på önskad databas. Välj "Backup".
Välj format (Custom (komprimeringsnivå från 0 till 9), Tar, Simple, Catalog). När det gäller komprimeringsnivå, komprimerar "anpassat format" för valfri komprimeringsnivå bäst, sedan "katalog", sedan "enkelt" och slutligen "tar". Vi anger kodningen UTF8, rollnamnet är postgresql. Vi lämnar alla ytterligare alternativ som standard. Klicka på knappen "Backup". Fältet "Meddelanden" visar en lista över alla utförda operationer med en slutförandekod. Om 0, då framgång. Här kan du också se hur du kör en liknande operation från kommandoraden.

F)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --användarnamn "postgres" --rolle "postgres" --inget lösenord --format anpassad --blobs --compress 9 --encoding UTF8 --verbose --fil "G:\Backups\gilev_dump.backup" "newdb"

Följaktligen det automatiska skriptet Reserv exemplar, som vi lägger till i schemaläggaren kan se ut ungefär så här:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --användarnamn "postgres" --rolle "postgres" --no-password --format anpassat --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump_%date:~0.2%_%date:~3.2%_%date:~6.4% .backup" "newdb"

Återhämtning.

För att återställa, välj den databas som vi vill återställa data från säkerhetskopia, helst tomt. Högerklicka och välj "Återställning". Ställ in säkerhetskopian, rollnamn: postgres, klicka på "Återställ"
Använd kommandoraden:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_restore.exe" --host 192.168.1.200 --port 5432 --användarnamn "postgres" --dbname "testdb" --rolle "postgres" --no -lösenord --verbose "G:\Backups\gilev_dump_26_09_2012.backup"

där testdb är en tom databas i vilken säkerhetskopieringsarkivet återställs.

Underhållsverksamhet:

VACUUM kommando:

Rengör sekventiellt alla tabeller i den för närvarande anslutna databasen, tar bort temporär data och frigör diskutrymme. Oftast exekveras VACUUM-kommandot exakt för att få maximal mängd ledigt diskutrymme på disken och öka hastigheten för dataåtkomst.

VAKUUM— markerar utrymmet som upptas av gamla versioner av poster som ledigt. Att använda denna variant av kommandot minskar som regel inte storleken på filen som innehåller tabellen, men låter dig förhindra att den växer okontrollerat och fixar den på en acceptabel nivå. När du kör VACUUM är parallell åtkomst till tabellen som bearbetas möjlig. Det finns flera ytterligare alternativ med VAKUUM: VAKUUM FULL, VAKUUMFRYS, VAKUUMANALYS.

VAKUUM FULL försöker ta bort alla gamla versioner av poster och följaktligen minska storleken på filen som innehåller tabellen. Detta kommandoalternativ låser helt tabellen som bearbetas.

VAKUUMFRYS - Om VACUUM FULL tar bort "skräp" från tabeller och flyttar poster så att tabellerna ligger kompakt på disken och består av det minsta antalet fragment, medan komprimering tar lång tid och blockerar poster, så tar VACUUM FREEZE helt enkelt bort "skräp" från tabeller, men själva posterna rör sig inte, så det är snabbare och blockerar inte skrivningar. För närvarande ersätts detta alternativ av autovakuum - automatisk sophämtning in postgresql.conf plus flera ytterligare alternativ som utökar funktionaliteten:

autovakuum=på# Aktiverar automatisk sophämtning.
log_autovacuum_min_duration = -1# Om du ställer in den på noll loggas alla autovakuumåtgärder. Minus ett (som standard) förbjuder utmatning till loggen. Till exempel om du ställer in värdet
lika med 250 ms, då kommer alla autovakuum- och analysåtgärder som körs i 250 ms eller mer att loggas. Att aktivera denna inställning kan vara användbart för att spåra autovakuum.
Det här alternativet kan endast ställas in i postgresql.conf-filen eller i kommandorad server.
autovacuum_naptime = 10 min# Tid i sekunder efter vilken databasen kontrolleras med avseende på behovet av sophämtning. Som standard händer detta en gång per minut.
autovacuum_vacuum_threshold= 1800 # Tröskel för antalet raderade och ändrade poster i en tabell, vid överskridande av vilken sophämtning som sker (VAKUUM).
autovacuum_analyze_threshold= 900 # Tröskel för antalet infogade, raderade och modifierade poster i någon tabell, vid överskridande av vilken analysprocessen (ANALYSERA) startas.
autovacuum_vacuum_scale_factor= 0,2 # Andel av ändrade och raderade poster i förhållande till tabellen, ovanför vilken sophämtning utlöses.
autovacuum_analyze_scale_factor= 0,1 # Samma som föregående variabel, men i förhållande till analys.
VAKUUMANALYSER— Om databasen har tabeller där data inte ändras eller tas bort, utan bara läggs till, kan du för sådana tabeller använda ett separat ANALYZE-kommando. Det är också värt att använda det här kommandot för en separat tabell efter att ha lagt till ett stort antal poster till den.

ANALYZE kommando:

Serverar för att uppdatera information om distributionen av data i tabellen. Denna information används av optimeraren för att välja den snabbaste exekveringsplanen för frågor. Vanligtvis används kommandot tillsammans med VAKUUMANALYSER.

REINDEX-kommando (omindexering):

Används för att bygga om befintliga index. Det är vettigt att använda det i så fall

— skada på indexet;

- konstant ökning av dess storlek.

Det andra fallet kräver viss förklaring. Ett index, som en tabell, innehåller block med gamla versioner av poster. PostgreSQL kan inte alltid återanvända dessa block, och därför växer indexfilen gradvis i storlek. Om uppgifterna i tabellen ändras ofta kan de växa ganska snabbt. Om du märker detta beteende hos ett index bör du konfigurera det för att regelbundet köra REINDEX-kommandot. Observera: REINDEX-kommandot, som VACUUM FULL, låser tabellen helt, så det måste köras när serverbelastningen är minimal.

Frågan om vilken DBMS - Postgresql eller MS SQL för 1C som är den mest optimala - har varit föremål för många artiklar. I den här artikeln kommer vi att titta på optimeringsstegen för båda. Varje leverantörs DBMS har både sina egna konfigurationsrekommendationer och rekommendationer från 1C. Det bör noteras att beroende på utrustning, serverkonfiguration och antalet användare som ställer in olika belastningar, kan detaljerna i processen för att optimera DBMS för 1C och implementera rekommendationer ändras.

Konfigurera PostgreSQL för 1C

Erfarenhet av att driva 1C-databaser på PostgreSQL har visat att den högsta prestanda och optimala prestanda för 1C och PostgreSQL uppnåddes på Linux, så det är tillrådligt att använda det. Men oavsett operativsystem är det viktigt att komma ihåg att standardinställningarna som anges vid installation av PostgreSQL endast är avsedda för att starta DBMS-servern. Det kan inte vara tal om någon industriell exploatering! Nästa steg efter lanseringen är att optimera PostgreSQL för 1C:

• Först inaktiverar vi energibesparing (annars kan förseningar i svar från databasen öka oförutsägbart) och förbjuder utbyte av delat minne.
• Vi konfigurerar de grundläggande parametrarna för DBMS-servern (rekommendationer för konfiguration beskrivs tillräckligt detaljerat, både på säljarens officiella webbplats och av 1C, så vi kommer bara att fokusera på de viktigaste).
• Standardrekommendationerna från 1C-företaget föreslår att HyperThreading-mekanismer inaktiveras. Men att testa Postgres-pro på servrar med SMT (simultaneous multi threading) aktiverat visade olika resultat.

Att ställa in shared_buffers till RAM/4 är standardrekommendationen, men SQL Server-exemplet antyder att ju mer minne som allokeras till den, desto bättre prestanda (med sidspolning inaktiverad). Det vill säga, ju fler datasidor som finns i RAM, desto färre diskåtkomster. Frågan uppstår: varför en så liten cache? Svaret är enkelt: om shared_buffers är stor, så byts några av de oanvända sidorna till disk. Men hur spårar man ögonblicket när återställningen slutar och parameterindikatorn är optimal? För att uppnå och nå den optimala shared_buffers-indikatorn måste dess värde höjas i produktionen dagligen (om möjligt) med ett visst steg och se i vilket ögonblick sidor kommer att börja spolas till disken (swap kommer att öka).

Dessutom påverkas "large-parametern" negativt av att arbeta med många små sidor, som som standard har en storlek på 8Kb. Att arbeta med dem ökar omkostnaderna. Vad kan man göra med detta för att optimera för 1C? PostgreSQL 9.4 introducerade parametern huge_pages, som kan aktiveras, men bara på Linux. Som standard ingår enorma sidor med en standardstorlek på 2048 kB. Dessutom måste stöd för dessa sidor vara aktiverat i operativsystemet. Genom att optimera lagringsstrukturen kan du alltså uppnå en större shared_buffers-indikator.

work_mem = RAM/32..64 eller 32MB..128MB Ställer in mängden minne för varje session som kommer att användas för intern sortering, sammanslagning etc. innan temporära filer används. Om denna volym överskrids kommer servern att använda temporära filer på disken, vilket avsevärt kan minska hastigheten på bearbetningsförfrågningar. Denna parameter används vid exekvering av operatorer: ORDER BY, DISTINCT, merge joins, etc.

Räkna ytterligare denna parameter kan göras enligt följande: (Delat minne shared_buffers - minne för andra program) / antal aktiva anslutningar. Detta värde kan minskas genom att övervaka antalet tillfälliga filer som skapas. Sådan statistik om storleken och antalet temporära filer kan erhållas från systemvyn pg_stat_database.

effective_cache_size = RAM - shared_buffers Huvudsyftet med denna parameter är att tala om för frågeoptimeraren vilken metod för att hämta data att välja: full scan eller index scan. Ju högre parametervärde, desto större är sannolikheten att använda indexskanning. I det här fallet tar inte servern hänsyn till att data kan finnas kvar i minnet när en begäran utförs, och nästa begäran behöver inte hämta den från disken.

Installerar PostgreSQL

Att installera 1C på PostgreSQL under Windows är en ganska enkel process. När du kör installationspaketet måste du ange UTF-8-kodning. Faktum är att detta är den enda intressanta nyansen och ingen ytterligare konfiguration av PostgreSQL för 1C 8.3 från Windows krävs. Att installera och konfigurera PostgreSQL för 1C på Linux OS kan orsaka ett antal svårigheter. För att övervinna dem, som ett exempel, låt oss överväga att köra (med distributionskit från den ledande ryska leverantören PostgreSQL-Pro och 1C-företaget) PostgreSQL på en Ubuntu 16.04 x64-server

Installation av 1C distributionssatser för PostgreSQL DBMS

1. Ladda ner den angivna positionen för PostgreSQL DBMS-distributionssatsen:

2. Ladda upp PostgreSQL till servern;

3. Du kan packa upp PostgreSQL DBMS-installationsprogrammet med kommandot:

tar -xvf postgresql-9.4.2-1.1C_amd64_deb.tar.bz2

4. Innan du installerar PostgreSQL DBMS-distributionssatsen, låt oss kontrollera närvaron av den nödvändiga lokalen i systemet (som standard ru_RU.UTF-8):

5.Om systemet som PostgreSQL kommer att fungera med har installerats på ett annat språk än ryska, måste du skapa nya språk:

locale-gen ru_RU update-locale LANG=ru_RU.UTF8 dpkg-reconfigure locales

6.Om den nödvändiga lokalen fortfarande är tillgänglig installerar du den som standard:

locale –a nano /etc/default/locale Ersätt innehållet med LANG=ru_RU.UTF-8

7. Efter omstarten, installera de nödvändiga paketen för vår version av PostgreSQL:

apt-get installera libxslt1.1 ssl-cert

8.PostgreSQL-paketversion 9.4.2-1.1C är länkad till libicu-paketversion libicu48. Den nödvändiga versionen finns inte längre i förvaret, men du kan ladda ner den;

9. Ladda ner och placera i katalogen där nedladdade filer för PostgreSQL lagras;

10.Genom att gå till katalogen med PostgreSQL-filerna utför vi installationen genom att sekventiellt skriva följande kommandon:

CD<Путь к папке с файлами>dpkg -i libicu48_4.8.1.1-3ubuntu0.6_amd64.deb dpkg -i libpq5_9.4.2-1.1C_amd64.deb dpkg -i postgresql-client-common_154.1.1C_all.deb dpkg -i postgresql-common_154.1.1C_all.deb dpkg -i postgresql-client-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-contrib-9.4_9.4.2-1.4_debd

11.Klart. PostgreSQL DBMS distributionskit är installerat.

Installera PostgreSQL-Pro-distributioner

För att installera servern måste du köra följande kommandon i följd:

sudo sh -c "echo "deb http:// 1c.postgrespro.ru/deb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/postgrespro-1c.list" wget --quiet -O - ​​​​http:// 1c.postgrespro.ru/keys/GPG-KEY-POSTGRESPRO-1C-92 | sudo apt-key add - && sudo apt-get update sudo apt-get install postgresql-pro-1c-9.4

För att komma åt servern, redigera parametrarna i filen pg_hba.conf

CD<Путь до каталога pg_hba.conf>cp pg_hba.conf pg_hba.conf.old bash -c "echo "local all postgres trust" > pg_hba.conf" bash -c "echo "host all all all all md5" >> pg_hba.conf"

Själva filen har följande struktur:

Filen är väldokumenterad, men engelska språket. Låt oss kort titta på huvudparametrarna:

• Lokal lokal anslutning endast via unix
• Värd TCP/IP-anslutning
• Hostssl krypterad SSL-anslutning via TCP/IP (servern måste byggas med SSL-stöd, ssl-parametern måste också ställas in)
• Hostnossl okrypterad anslutning via TCP/IP

• förtroende erkänna utan autentisering
• avvisa vägra utan autentisering
• Lösenord klartext lösenordsbegäran
• md5 lösenordsbegäran i MD5-form
• ldap verifiera användarnamn och lösenord med LDAP-server
• radie Verifierar användarnamn och lösenord med RADIUS-server
• pam verifiera användarnamn och lösenord med hjälp av plugin-tjänsten

Mer detaljerad och detaljerad information finns i dokumentationen för PostgreSQL-produkten.

root@NODE2:/home/asd# tjänst --status-all |grep postgres [ - ] postgresql root@NODE2:/home/asd# tjänst postgresql start root@NODE2:/home/asd# tjänst --status-all | grep postgres [ + ] postgresql

När du har slutfört den grundläggande installationen måste du konfigurera konfigurationsfil server postgresql.conf, enligt detaljerna för PostgreSQL, 1C server och Ubuntu serverkonfiguration.

Optimering av 1C för MS SQL Server

Installera Senaste uppdateringarna för SQL Server.

Operativsystemet reserverar utrymme och fyller det med nollor, vilket tar ganska lång tid i följande händelser:

• Skapande av databas;
• Lägga till datafiler, transaktionslogg, till en befintlig databas;
• Öka storleken på en befintlig fil (inklusive Autogrow-operationer);
• Vi återställer databaser eller grupper av filer.

Beslutas det här problemet lägga till rollen (under vilken servern körs) till objektet lokalpolitik säkerhet "Utför volymunderhållsuppgifter."

Om möjligt är det nödvändigt att distribuera TempDB-databasen (den används särskilt intensivt i RCSI-hanterat låsläge) och transaktionsloggen på olika diskar.

På servern där det fungerar SQL-server, bör energisparläget ställas in på "Hög prestanda".

Mappen med databasfilerna ska inte komprimeras.

På fliken "Minne" för servern ställer vi in ​​miniminivån till 50% av det totala minnet. Vi beräknar det maximala med hjälp av en av formlerna:

• Maximalt minne = Total volym - storlek enligt OS - storlek för 1C (om det finns, efter att tidigare ha mätt minnet som används med räknare) eller
• Maximalt minne = Total storlek – (1024* Total storlek/16384).

Vi begränsar DOP-parametern "Max grad av parallellism" och sätter den till "1".

Vi uppdaterar statistiken enligt schema. Börjar med SQL Server 2008, uppdatering av statistik gör att frågor kompileras om och rensar följaktligen procedurcachen, så det finns inget behov av att utföra en separat procedur för att rensa procedurcachen.

Vi indexerar regelbundet om tabellen och defragmenterar indexen.

Vi upprättar den korrekta bokningspolicyn. Om du inte behöver återhämta dig till den sista tidpunkten före en systemkrasch, och de senaste 5 minuterna eller mer inte är kritiska för ditt företag, ställ sedan in återställningsmodellen på "Enkel". Detta kommer att påskynda din inspelningshastighet avsevärt. Huvudsaken är att den differentierade säkerhetskopieringen kan slutföras inom den angivna tiden.

Vi uppnår förbättringar i arbetet med TempDB under I/O genom att skapa ytterligare datafiler. Om det finns färre än 8 logiska processorer, rekommenderas det att du skapar en datafil för varje logisk processor. Om det finns fler än 8 logiska processorer, rekommenderas det att skapa 8 datafiler och, öka med en vid en multipel av 4, se till att uppskatta belastningen på TempDB.

1 nov 2012 Fördelar med att använda fritt distribuerat programvara uppenbar. Tyvärr är nackdelarna också uppenbara - det finns inget officiellt stöd, dokumentationen är ofta motsägelsefull, ofullständig och spridd överallt olika källor. Den här artikeln hjälper dig att förstå processen med att installera PosgreSQL för 1C:Enterprise 8 och undvika fallgropar som inte beskrivs i den officiella dokumentationen.

Nödvändiga komponenter för installation

PostgreSQL DBMS distribueras gratis och ingår i leveranspaketet för 1C-applikationsservern. Applikationsservern 1C:Enterprise 8 finns i två versioner: 32-bitars och 64-bitars. Postgre klarar båda.

Så vi har distributionssatser till hands:

• Postgre: postgresql-9_1_2-1_1Cx64.zip, vänligen tillhandahållen av 1C.
• Distribution av 1C:Enterprise-applikationsservern för Windows x64, version 8.2.16.368.

Det verkar som att det inte kunde vara enklare - bara starta och installera. Lätt! Men att installera i standardläge ger en liten begränsning: klustret kommer att finnas i mappen "Program Files". Alla kommer inte att gilla det. Låt oss överväga två installationsalternativ, enkla och avancerade.

Artikeln är uppdelad i 5 avsnitt:

1) Installation av 1C-server.

2) Installera PostgreSQL i en standardform, tillräckligt för att köra 1C utan ytterligare inställningar.

3) Installera PostgreSQL och välj klusterlagringsmappen.

4) Skapande av en ny 1C-informationsbas.

5) Ange mappen för lagring av databasfiler på DBMS-servern.

Se till att läsa hela artikeln innan installation!

Installation av 1C applikationsserver

Vi startar setup.exe från mappen med 1C-serverdistributionssatsen.

Om du installerar applikationsservern inte som en tjänst, måste du starta den manuellt varje gång. Det här alternativet behövs sällan. Vi installerar den som en tjänst och bestämmer under vilken användare den ska lanseras. Av säkerhetsskäl är det bättre att skapa en separat användare USR1CV82 istället för att låta tjänsten köras med fullständiga rättigheter.

Efter installation av applikationsservern kommer systemet att uppmana dig att installera drivrutinen för HASP-skyddsnyckeln. Vi instämmer:

Vi väntar på ett meddelande:

Om meddelandet är annorlunda finns det troligen "svansar" kvar i systemet från tidigare installationer av HASP-drivrutiner. Ta bort dem alla och försök igen.

Klart, vi har installerat applikationsservern 1C:Enterprise 8 framgångsrikt.

Installera PostgreSQL i en standardform, tillräckligt för att köra 1C utan ytterligare inställningar

Kör "postgresql-9.1.2-1.1C(x64).msi"

Du behöver inte ändra installationsalternativen, 1C fungerar. Ytterligare.

Postgre, liksom 1C-servern, kan själv skapa en användare som du kommer att köra tjänsten under. Jag uppmärksammar er på att om ni anger konto med administratörsrättigheter kommer tjänsten inte att fungera korrekt. Se till att skapa en ny användare.

Nästa installationsfönster.

Vi initierar klustret. Om vår databasserver och 1C-applikationsserver finns på olika datorer, markera sedan rutan "Stöd anslutningar från valfri IP", annars rör vi den inte. Var noga med att ange UTF8-kodning. Skapa en DBMS-superanvändare. Ytterligare…

För det inledande arbetet behöver vi inget extra, avmarkera rutan och slutför installationen.

Resultatet av våra ansträngningar är färdigt att använda PostgreSQL. Om vi ​​är övertygade om att databaserna kommer att finnas i Program Files\PostgreSQL\9.1.2-1.1C\data, avslutar vi där, öppnar databaserna och njuter av processen. Men oftare än inte "ligger" databaser på specialdesignade diskarrayer, och inte på systemdisk. För att konfigurera dataplatsen, läs följande avsnitt innan installation.

Installera Postgre med att välja en klusterlagringsplats

Vi fortsätter att installera Postgre och utför alla steg tills vi uppmanas att initiera klustret:

Avmarkera "Initiera databaskluster" och klicka på "Nästa".

Ja, det är vi säkra på.

Avmarkera "Kör Stack Builder vid avslut" och slutför installationen.

1. Det är nödvändigt att ge fullständiga rättigheter till mappen där vi installerade PostgreSQL, vanligtvis är detta C:\Program Files\PostgreSQL

2. Starta cmd som administratör. Om du gör detta i win7, kör det sedan som administratör.

3. Skapa en mapp där klustret ska lagras. Till exempel d:\postgredata.

md d:\postgredata

4. Vi initierar klustret manuellt och anger sökvägen där det kommer att finnas.

“C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\initdb.exe” -D d:\postgredata --locale=Russian_Russia --encoding=UTF8 -U postgres

5. Ta bort PostgreSQL-tjänsten som installerades under installationen.

sc ta bort pgsql-9.1.2-1.1C-x64

Där pgsql-9.1.2-1.1C-x64 är namnet på tjänsten. Om du inte känner till namnet exakt kan du titta på egenskaperna för tjänsten "PostgreSQL Database Server..." (Start - Kontrollpanelen - Administrativa verktyg - Tjänster)

6. Skapa ny tjänst indikerar vårt kluster

“C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\pg_ctl” register -N pgsql -U postgresql -P lösenord -D d:/postgredata

7. Låt oss nu gå till tjänster. Starta – Kontrollpanelen – Administration – Tjänster och starta vår tjänst.

Skapa en ny 1C-databas på en server med PostgreSQL

Det finns flera alternativ för att skapa en databas. Du kan prova att skapa en databas genom pgAdmin3, 1C-serverns administrationskonsol. Men här kommer du att ställas inför många obegripliga frågor och en massa fel, svaren som du kommer att spendera lång tid på att leta efter. Lämna det till experterna. Vårt mål är att få en fungerande bas med minimal ansträngning. Låt oss beskriva det enklaste sättet att uppnå detta.

Vi lanserar 1C-klienten.

Klicka på "Lägg till...".

Vi kommer på ett namn för databasen, anger "På 1C:Enterprise-servern", sedan.

Serverkluster 1C:Enterprise– localhost, om vi skapar en databas på samma dator där 1C-servern är installerad, eller namnet på 1C-applikationsservern, om den är på en annan.

Namnet på infobasen i klustret- i framtiden kommer detta namn att anges när du ansluter från andra datorer.

DBMS typ– Välj PostgreSQL.

Databasserver- ange namnet på PostgreSQL-servern. Om vi ​​skapar en databas på servern anger vi även localhost.

Databas namn– med detta namn kommer en databas att skapas i PostgreSQL.

Användarlösenord– namnet på användaren som vi angav som superanvändare när vi installerade PostgreSQL. Var noga med att markera kryssrutan "Skapa en databas om den inte finns".

Frågan uppstår - var kommer databasen att lagras fysiskt? I basmappen för det angivna klustret. Tänk om vi inte vill att det ska ligga där alla baser är? Det finns inget vi kan göra åt det ännu, vi skapar bara en bas och går vidare. Ytterligare…

Specificerar databaslagringsmappen

Så vi har skapat en bas. I de flesta fall är det här installationen slutar. Men om det finns många databaser, och det finns flera diskarrayer för olika grupper av databaser, måste du ange var databaserna ska finnas fysiskt. För att göra detta, kör pgAdmin3 från Start – Program – PostgreSQL. Anslut till vår server.

När du först ansluter kommer Postgre att be om ett lösenord för postgres-användaren (som vi skapade under installationen).

Vi skapar ett nytt TableSpace, detta kommer att vara mappen där våra databaser kommer att lagras.

Angav lagringsplatsen för databasfilerna. OK.

Nu öppnar vi egenskaperna för den tidigare skapade databasen, vars plats vi vill ändra.

Ändra egenskapen Tablespace. Efter att ha klickat på "OK" kommer databasfilerna att flyttas automatiskt. Redo! Vi hoppas att artikeln var användbar för dig. Om så är fallet, lämna kommentarer och dela länkar till den här sidan. Tack!