Tento článok si nerobí nárok na úplnú prezentáciu všetkých možností konfigurácie PostgreSQL a v porovnávacom testovaní nepokrývam všetky režimy prevádzky databázy. Záujemcom odporúčam preštudovať si knihu na odkaze

Úvod

Veľa som pracoval s PostgreSQL a myslím si, že je to vynikajúci DBMS. Mám viacgigabajtovú pracovnú databázu (nie 1C), ktorá okamžite spracováva obrovské množstvo údajov. PostgreSQL výborne využíva indexy, dobre si poradí s paralelnými pracovnými záťažami, funkčnosť uložených procedúr je vynikajúca, existujú dobré nástroje na správu a výkon, komunita vytvorila užitočné pomôcky. Bol som však prekvapený, keď som sa dozvedel, že mnohí správcovia 1C majú zlú mienku o PostgreSQL, že je pomalý a sotva prekonáva verziu súboru databázy a situáciu môže zachrániť iba MSSQL.

Po preskúmaní otázky som našiel veľa článkov o inštalácii PostgreSQL krok za krokom pre figuríny, a to na Linuxe aj na Windows. Prevažná väčšina článkov však popisuje inštaláciu až po „nainštalované - poďme vytvoriť databázu“ a vôbec sa nedotýkajú otázky konfigurácie. Vo zvyšných je konfigurácia spomenutá iba na úrovni „zadať takéto hodnoty“, prakticky bez vysvetlenia prečo.

A ak je prístup „inštalácie jedným tlačidlom“ použiteľný pre MSSQL a mnoho produktov pre Windows vo všeobecnosti, potom, žiaľ, neplatí pre PostgreSQL. Predvolené nastavenia výrazne obmedzujú jeho využitie pamäte, takže ho môžete nainštalovať aj na kalkulačku a nebude prekážať pri fungovaní zvyšku softvéru. PostgreSQL musí byť nakonfigurovaný pre konkrétny systém a až potom môže ukázať to najlepšie. V obzvlášť závažných prípadoch môžete vyladiť nastavenia PostgreSQL, databázy a systém súborov navzájom, ale vo väčšej miere to platí pre systémy Linux, kde je viac možností si všetko prispôsobiť.

Je potrebné pripomenúť, že pre 1C nie je vhodné zostavenie PostgreSQL od vývojárov DBMS, iba zostavené z opravených zdrojových kódov 1C. Hotové kompatibilné zostavy ponúkajú 1C (prostredníctvom diskov ITS a účtu pre tých, ktorí majú predplatenú podporu) a EterSoft

Testovanie sa uskutočnilo v Prostredie Windows, ale všetky odporúčania týkajúce sa konfigurácie nie sú špecifické pre platformu a platia pre akýkoľvek OS.

Testovanie a porovnávanie

Pri testovaní som sa nepustil do testov vo všetkých prevádzkových režimoch a scenároch, len na hrubú kontrolu úspešnej konfigurácie.

Na testovanie som použil nasledujúcu konfiguráciu:
Hostiteľský počítač: Win7, Core i5-760 2,8 MHz, 4 jadrá, 12 GB RAM, VMWare 10
Virtuálne: Win7 x64, 2 jadrá, 4 GB RAM, samostatné fyzické HDD na hosťovanie databázy (nie SSD)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
1C 8.3.5 1383

Bola použitá databáza, dt-upload 780 MB.
Po obnovení databázy:
veľkosť súboru 1CD vo verzii súboru - 10GB,
Veľkosť databázy PostgreSQL – 8 GB,
Veľkosť databázy MSSQL je 6,7 GB.

Na test som použil požiadavku na vzor zmlúv protistrany (21k) s výberom ďalších detailov z rôznych registrov, pre každú dohodu bol vlastne vyhotovený samostatný vzor z registrov. Vzal som konfiguráciu, ktorá bola po ruke - silne upravenú na základe účtovníctva 3.0.

Počas testovania som niekoľkokrát spustil požiadavku s jedným a dvoma klientmi, kým sa nedosiahli stabilné výsledky. Ignoroval som prvé jazdy.

Testovanie s jedným klientom:

Vzorkovanie na hostiteľovi z verzie súboru s databázou umiestnenou na SSD - 31c
Výber z variantu súboru v virtuálny prístroj(S pevný disk) - 46 s
Vzorkovanie z databázy MSSQL - prvý prechod - 25 alebo 9 s (zrejme v závislosti od relevantnosti vyrovnávacej pamäte DBMS) (spotreba pamäte procesom DBMS bola približne 1,3 GB)
Vzorkovanie z PostgreSQL s predvolenými nastaveniami - 43 s (spotreba pamäte nepresiahla 80 MB na pripojenie)
Vzorkovanie z optimalizovaného PostgreSQL - 21s (spotreba pamäte bola 120 MB na pripojenie)

Testovanie s dvoma klientmi:

Vzorkovanie na hostiteľovi z verzie súboru s databázou umiestnenou na SSD - každá 34 s
Vzorkovanie z verzie súboru vo virtuálnom stroji (z pevného disku) – každý 56 s
Vzorkovanie z databázy MSSQL - 50 alebo 20 s (zrejme v závislosti od relevantnosti vyrovnávacej pamäte DBMS)
Vzorkovanie z PostgreSQL s predvolenými nastaveniami - každé 60 s
Vzorkovanie z optimalizovaného PostgreSQL – každý po 40s

Poznámky k testovaniu:

1. Po pridaní tretieho jadra začali v teste „dvoch klientov“ fungovať varianty PostgreSQL a MSSQL takmer s výkonom testu „jeden klient“, t.j. úspešne paralelizované. Čo im bránilo v paralelnej práci na dvoch jadrách, mi zostalo záhadou.
2. MSSQL zabralo veľa pamäte naraz, PostgreSQL si vyžadoval výrazne menej vo všetkých režimoch a takmer celú ju uvoľnil hneď po dokončení dotazu.
3. MSSQL beží ako jeden proces. PostgreSQL spúšťa samostatný proces na pripojenie + servisné procesy. To umožňuje aj 32-bitovému variantu efektívne využívať pamäť pri spracovávaní požiadaviek od viacerých klientov.
4. Zvýšenie pamäte pre PostgreSQL v nastaveniach nad hodnoty uvedené nižšie neviedlo k výraznému zvýšeniu výkonu.
5. Prvé testy vo všetkých prípadoch trvali dlhšie ako pri následných meraniach, nerobil som žiadne špeciálne merania, ale MSSQL sa subjektívne rozbiehalo rýchlejšie.

Konfigurácia PostgreSQL

V ruštine existuje vynikajúca kniha o konfigurácii a optimalizácii PostgreSQL: Pre každého milovníka slonov má zmysel uložiť si tento odkaz do záložiek. Kniha popisuje mnoho techník na optimalizáciu DBMS, vytváranie systémov odolných voči chybám a distribuovaných systémov. Teraz sa však pozrieme na niečo, čo sa bude hodiť každému – na konfiguráciu využitia pamäte. PostgreSQL nebude využívať viac pamäte, ako povoľujú nastavenia, a pri predvolených nastaveniach PostgreSQL používa minimum pamäte. Zároveň by ste nemali špecifikovať viac pamäte, ako je k dispozícii na použitie - systém začne používať odkladací súbor so všetkými z toho vyplývajúcimi strašnými dôsledkami pre výkon servera. Množstvo tipov na nastavenie PostgreSQL je uvedených na disku ITS.

V systéme Windows sa konfiguračné súbory PostgreSQL nachádzajú v inštalačnom adresári v adresári Data:

• postgresql.conf- hlavný súbor s nastaveniami DBMS
• pg_hba.conf- súbor s nastaveniami prístupu pre klientov. Konkrétne tu môžete určiť, ktorí používatelia, z ktorých IP adries sa môžu pripojiť k určitým databázam, a či je potrebné skontrolovať heslo používateľa, a ak áno, akým spôsobom.
• pg_ident.conf- súbor s konverziou používateľských mien zo systémového na interné (väčšina používateľov ho pravdepodobne nebude potrebovať)

Súbory sú textové, môžete ich upravovať pomocou poznámkového bloku. Riadky začínajúce na # sa považujú za komentáre a ignorujú sa.

Parametre súvisiace s kapacitou pamäte je možné doplniť koncovkami kB, MB, GB - kilobajty, megabajty, gigabajty, napríklad 128MB. Parametre popisujúce časové intervaly je možné doplniť príponami ms, s, min, h, d - milisekundy, sekundy, minúty, hodiny, dni, napríklad 5min

Ak ste zabudli heslo pre Postgress, nevadí, môžete ho napísať pg_hba.conf riadok:

Hostite všetky dôveryhodné 127.0.0.1/32

A pripojiť sa ľubovoľným používateľom (napr. postgres) do DBMS na lokálnom počítači na 127.0.0.1 bez kontroly hesla.

Optimalizácia Využitie pamäte

Nastavenia využitia pamäte sa nachádzajú v postgresql.conf

Optimálne hodnoty parametrov závisia od objemu voľného Náhodný vstup do pamäťe, veľkosť databázy a jednotlivých prvkov databázy (tabuľky a indexy), zložitosť dopytov (v zásade treba predpokladať, že dopyty budú pomerne zložité – typickým scenárom je viacero spojení v dopytoch) a počet súčasne aktívnych klientov. Mimochodom, PostgreSQL ukladá databázové tabuľky a indexy samostatné súbory (<каталог установки PG>\data\base\<идентификатор БД>\) a možno odhadnúť veľkosti objektov. Môžete tiež použiť obslužný program pgAdmin na pripojenie k databáze, rozbaliť „Schemas“ - „public“ a vygenerovať štatistickú správu pre prvok „Tables“.

Ďalej uvediem približné hodnoty, od ktorých môžete začať ladiť. Po pôvodné nastavenie Odporúča sa spustiť server v prevádzkových režimoch a sledovať spotrebu pamäte. V závislosti od získaných výsledkov môže byť potrebné upraviť hodnoty parametrov.

Pri nastavovaní servera na testovanie som sa spoliehal na nasledujúce výpočty:
Iba 4 GB RAM. Spotrebitelia - OS Windows, server 1C, PostgreSQL a vyrovnávacia pamäť systémového disku. Predpokladal som, že pre DBMS je možné alokovať až 2,5 GB RAM

Hodnoty je možné zadať pomocou prípon kB, MB, GB (hodnoty v kilobajtoch, megabajtoch alebo gigabajtoch). Po zmene hodnôt je potrebné reštartovať službu PostgreSQL.

shared_buffers – vyrovnávacia pamäť zdieľaného servera

Veľkosť vyrovnávacej pamäte na čítanie a zápis PostgreSQL zdieľaná všetkými pripojeniami. Ak údaje nie sú vo vyrovnávacej pamäti, načítajú sa z disku (pravdepodobne uložené do vyrovnávacej pamäte OS)

Ak je veľkosť vyrovnávacej pamäte nedostatočná na ukladanie často používaných pracovných údajov, budú sa neustále zapisovať a čítať z vyrovnávacej pamäte OS alebo z disku, čo bude mať mimoriadne negatívny vplyv na výkon.

Ale to nie je všetka pamäť potrebná na prevádzku, nemali by ste špecifikovať príliš veľa veľký význam, inak nezostane žiadna pamäť pre skutočné vykonávanie požiadaviek klienta (a čím viac ich je, tým vyššia je spotreba pamäte), ako aj pre OS a ďalšie aplikácie, napríklad proces servera 1C. Server sa tiež spolieha na vyrovnávaciu pamäť OS a snaží sa neuchovávať vo svojej vyrovnávacej pamäti to, čo s najväčšou pravdepodobnosťou ukladá systém.

Použitý test

shared_buffers = 512 MB

work_mem- pamäť na triedenie, agregáciu dát a pod.

Pridelené pre každú požiadavku, prípadne niekoľkokrát pre zložité požiadavky. Ak nie je dostatok pamäte, PostgreSQL použije dočasné súbory. Ak je hodnota príliš veľká, RAM môže byť nadmerne využívaná a OS začne používať odkladací súbor so zodpovedajúcim poklesom výkonu.

Pri výpočte sa odporúča brať množstvo dostupnej pamäte mínus shared_buffers a vydeliť počtom súčasne vykonaných požiadaviek. V prípade zložitých dopytov by sa mal deliteľ zvýšiť, t.j. znížiť výsledok. Pre uvažovaný prípad na základe 5 aktívnych používateľov (2,5 GB – 0,5 GB (shared_buffers))/5 = 400 MB. Ak DBMS považuje dopyty za pomerne zložité alebo ak sa objavia ďalší používatelia, hodnotu bude potrebné znížiť.

Pre jednoduché dotazy postačujú malé hodnoty - do niekoľkých megabajtov, ale pre zložité dotazy (a to je typický scenár pre 1C) bude potrebných viac. Odporúčanie - pre pamäť 1-4GB môžete použiť hodnoty 32-128MB. Použil som ho v teste

work_mem = 128 MB

údržba_práca_mem- pamäť pre príkazy na zber odpadu, štatistiky, vytváranie indexov.

Odporúča sa nastaviť hodnotu na 50-75% veľkosti najväčšej tabuľky alebo indexu, ale tak, aby bol dostatok pamäte na spustenie systému a aplikácií. Odporúča sa nastaviť hodnoty vyššie ako work_mem. Použil som ho v teste
maintenance_work_mem = 192 MB

temp_buffers- buffer pre dočasné objekty, hlavne pre dočasné tabuľky.

Môžete nainštalovať približne 16 MB. Použil som ho v teste
temp_buffers = 32 MB

efektívna_veľkosť_cache- približná veľkosť diskovej vyrovnávacej pamäte systému súborov.

Optimalizátor používa túto hodnotu pri vytváraní plánu dotazov na odhadnutie pravdepodobnosti nájdenia údajov vo vyrovnávacej pamäti (s rýchlym náhodným prístupom) alebo na pomalom disku. V systéme Windows je možné aktuálne množstvo pamäte pridelenej pre vyrovnávaciu pamäť zobraziť v správcovi úloh.

Autovakuum - "zber odpadu"

PostgreSQL, ako typický predstaviteľ „verzovaných“ DBMS (na rozdiel od blokujúcich), nezávisle neblokuje tabuľky a záznamy z čítania transakcií pri zmene údajov (v prípade 1C to robí samotný server 1C). Namiesto toho sa vytvorí kópia upraveného záznamu, ktorá sa stane viditeľnou pre nasledujúce transakcie, zatiaľ čo existujúce budú naďalej vidieť údaje, ktoré boli aktuálne na začiatku ich transakcie. V dôsledku toho sa v tabuľkách hromadia neaktuálne údaje - predchádzajúce verzie zmenených záznamov. Aby DBMS využil uvoľnený priestor, je potrebné vykonať „zber odpadu“ - určiť, ktoré zo záznamov sa už nepoužívajú. Dá sa to urobiť explicitne pomocou príkazu SQL VÁKUUM alebo počkajte na spracovanie tabuľky automatickým zberačom odpadu - AUTOVAKUUM. Do určitej verzie bol tiež zber odpadu spojený so zberom štatistík (plánovač používa údaje o počte záznamov v tabuľkách a rozdelení hodnôt indexovaných polí na zostavenie optimálneho plánu dotazov). Na jednej strane sa musí robiť garbage collection, aby tabuľky nerástli a efektívne využívali miesto na disku. Na druhej strane, náhle spustené zbieranie odpadu spôsobuje dodatočné zaťaženie disku a tabuliek, čo vedie k predĺženiu času vykonávania dotazu. Podobný efekt vytvára automatický zber štatistík (samozrejme ho možno spustiť príkazom ANALÝZA alebo spolu s odvozom odpadu ANALÝZA Vákua). A hoci PostgreSQL vylepšuje tieto mechanizmy od verzie k verzii, aby sa minimalizovala Negatívny vplyv na výkon (napríklad v starších verziách zber odpadu úplne zablokoval prístup k tabuľke, pretože od verzie 9.0 funguje VÁKUUM zrýchlené), tu je čo konfigurovať.

Automatické vysávanie môžete úplne zakázať pomocou nasledujúceho parametra:

autovakuum = vypnuté

Aby funkcia Autovacuum fungovala, je potrebný parameter track_counts = on, inak nebude fungovať.

V predvolenom nastavení sú obe možnosti povolené. V skutočnosti sa autovakuum nedá úplne vypnúť – aj pri autovakue = vypnuté sa niekedy (po veľkom počte transakcií) spustí autovakuovanie.

komentár: VÁKUUM zvyčajne nezmenšuje veľkosť súboru tabuľky, iba označuje voľné oblasti dostupné na opätovné použitie. Ak chcete fyzicky uvoľniť prebytočný priestor a minimalizovať obsadené miesto na disku, budete potrebovať príkaz VÁKUUM PLNÉ. Táto možnosť blokuje prístup k tabuľke počas jej spustenia a zvyčajne sa nevyžaduje. Viac informácií o používaní príkazu VACUUM nájdete v dokumentácii (v angličtine).

Ak funkcia Autovacuum nie je úplne vypnutá, môžete nakonfigurovať jej vplyv na vykonávanie dotazu pomocou nasledujúcich parametrov:

autovacuum_max_workers- maximálny počet paralelne bežiace procesyčistenie

autovacuum_naptime - minimálny interval, po ktorý sa nespustí autovakuovanie. Predvolená je 1 minúta. Môžete ho zvýšiť, potom ak sa údaje často menia, analýza sa bude vykonávať menej často.

autovacuum_vacuum_threshold, - počet zmenených alebo odstránených záznamov v tabuľke potrebný na spustenie procesu zberu odpadu VÁKUUM alebo zbieranie štatistík ANALÝZA. Predvolená hodnota je 50.

autovacuum_vacuum_scale_factor , autovacuum_analyze_scale_factor - pridaný koeficient veľkosti tabuľky v záznamoch autovacuum_vacuum_threshold A autovacuum_analyze_threshold resp. Predvolené hodnoty sú 0,2 (t. j. 20 % z počtu záznamov) a 0,1 (10 %).

Zoberme si príklad s tabuľkou s 10 000 záznamami. Potom, s predvolenými nastaveniami, po 50+10000*0,1=1050 zmenených alebo odstránených záznamoch sa spustí zber štatistík ANALÝZA, a po roku 2050 zmeny - odvoz odpadu VÁKUUM.

Ak zvýšite prah a scale_factor, procesy údržby budú prebiehať menej často, ale malé tabuľky môžu výrazne narásť. Ak databáza pozostáva primárne z malých tabuliek, celkové zvýšenie spotreby miesta na disku môže byť značné, takže tieto hodnoty môžete zvýšiť, ale rozumne.

Preto môže mať zmysel zvýšiť interval autovacuum_naptime a mierne zvýšiť prah a scale_factor. V načítaných databázach môže byť alternatívou výrazne zvýšiť scale_factor (hodnota 1 umožní, aby sa tabuľky „nafúkli“ dvakrát) a nastaviť denné vykonávanie na plánovač ANALÝZA Vákua v obdobiach minimálneho zaťaženia databázy.

default_statistics_target - priradí množstvo štatistík zhromaždených príkazom ANALÝZA. Predvolená hodnota je 100. Väčšie hodnoty predlžujú čas vykonania príkazu ANALYZE, ale umožňujú plánovaču vytvárať efektívnejšie plány dotazov. Existujú odporúčania na zvýšenie na 300.

Výkon sa dá kontrolovať AUTOVAKUUM, čím je dlhší, ale menej zaťažujúci systém.

vákuum_cost_page_hit- veľkosť „pokuty“ pre spracovanie bloku umiestneného v shared_buffers. Súvisí s potrebou blokovania prístupu do vyrovnávacej pamäte. Predvolená hodnota 1

vákuum_cost_page_miss - veľkosť "pokuty" za spracovanie bloku na disku. Súvisí s blokovaním vyrovnávacej pamäte, vyhľadávaním údajov vo vyrovnávacej pamäti, čítaním údajov z disku. Predvolená hodnota 10

Vacuum_cost_page_dirty- veľkosť „pokuty“ pre modifikáciu bloku. Súvisí s potrebou resetovať upravené dáta na disk. Predvolená hodnota 20

vákuum_cost_limit - maximálna veľkosť"pokuty", po ktorých môže byť proces montáže "zmrazený" na dobu trvania vákuum_cost_delay. Predvolená hodnota 200

vákuum_cost_delay- čas na „zmrazenie“ procesu zberu odpadu po dosiahnutí vakua_cost_limit. Predvolená hodnota 0 ms

autovacuum_vacuum_cost_delay- čas na „zmrazenie“ procesu zberu odpadu pre automatické vysávanie. Predvolená hodnota je 20 ms. Ak je nastavená na -1, použije sa hodnota vákuum_cost_delay

autovacuum_vacuum_cost_limit- maximálna veľkosť "pokuty" pre autovakuum. Predvolená hodnota -1 - použije sa hodnota vákuum_cost_limit

Hlásené použitie vákuum_cost_page_hit = 6, vákuum_cost_limit = 100, autovacuum_vacuum_cost_delay = 200 ms znižuje vplyv AUTOVákua až o 80%, ale strojnásobuje čas jeho vykonania.

Nastavenie nahrávania na disk

Po dokončení transakcie PostgreSQL najskôr zapíše údaje do špeciálneho transakčného protokolu WAL (Write-ahead log) a potom do databázy, keď je zaručený zápis údajov protokolu na disk. Predvolený mechanizmus je fsync, kedy PostgreSQL násilne vyprázdni dáta (log) z diskovej cache OS na disk a až po úspešnom zápise (logu) je klient informovaný o úspešnom dokončení transakcie. Používanie protokolu transakcií vám umožňuje dokončiť transakciu alebo obnoviť databázu, ak dôjde k zlyhaniu počas zapisovania údajov.

V rušných systémoch s veľkými objemami zápisu môže mať zmysel presunúť protokol transakcií na samostatný fyzický disk (ale nie na iný oddiel toho istého disku!). Ak to chcete urobiť, musíte zastaviť DBMS, presunúť adresár pg_xlog na iné miesto a vytvoriť symbolický odkaz v starom umiestnení, napríklad pomocou pomocného programu spojenia. Far Manager (Alt-F6) môže tiež vytvárať prepojenia. V tomto prípade sa musíte uistiť, že nové umiestnenie má prístupové práva pre používateľa, ktorý používa PostgreSQL (zvyčajne postgres).

Ak existuje veľký počet operácií úpravy údajov, možno budete musieť zvýšiť hodnotu checkpoint_segments, ktorá riadi množstvo údajov, ktoré môžu čakať na prenos z protokolu do samotnej databázy. Predvolená hodnota je 3. Treba brať do úvahy, že pre denník je pridelený priestor vypočítaný podľa vzorca (kontrolné_segmenty * 2 + 1) * 16 MB, čo už pri hodnote 32 bude vyžadovať viac ako 1 GB disku priestor.

PostgreSQL vyprázdni údaje z vyrovnávacej pamäte OS na disk po dokončení každej transakcie zápisu. Na jednej strane to zaručuje, že dáta na disku sú vždy aktuálne, na druhej strane pri veľkom počte transakcií klesá výkon. Úplne zakázať fsync možné špecifikáciou

fsync=off
full_page_writes = vypnuté

Dá sa to urobiť iba vtedy, ak 100% dôverujete zariadeniu a UPS (zdroj neprerušiteľný zdroj napájania). V opačnom prípade v prípade zlyhania systému hrozí získanie zničenej databázy. A každopádne RAID radič s batériou na napájanie pamäte nezapísaných dát by tiež nezaškodil.

Jednoznačnou alternatívou môže byť použitie parametra

synchronous_commit = vypnuté

V tomto prípade po úspešnej odpovedi na dokončenie transakcie môže chvíľu trvať, kým sa transakcia bezpečne zapíše na disk. V prípade náhleho vypnutia nedôjde k zničeniu databázy, ale môže dôjsť k strate údajov z posledných transakcií.

Ak úplne nezakážete fsync, môžete v parametri určiť metódu synchronizácie. Článok z disku ITS odkazuje na utilitu pg_test_fsync, ale tá sa nenašla v mojej zostave PostgreSQL. Podľa 1C sa v ich prípade v systéme Windows metóda ukázala ako optimálna open_datasync(zrejme je to metóda, ktorá sa štandardne používa).

Ak sa používa veľa malých transakcií zápisu (v prípade 1C to môže byť hromadná aktualizácia adresára mimo transakcie), kombinácia parametrov commit_delay (čas oneskorenia dokončenia transakcie v mikrosekundách, predvolená hodnota 0) a commit_siblings (predvolená hodnota 5) môžem pomôcť. Keď sú voľby povolené, dokončenie transakcie môže byť oneskorené príkazom commit_delay if tento moment Vykonajú sa aspoň transakcie commit_siblings. V tomto prípade sa výsledok všetkých dokončených transakcií zapíše spolu, aby sa optimalizovali zápisy na disk.

Ďalšie parametre, ktoré ovplyvňujú výkon

wal_buffers- množstvo pamäte v zdieľaných_bufferoch na udržiavanie transakčných protokolov. Odporúčanie: s 1-4GB dostupnej pamäte použite hodnoty 256KB-1MB. V dokumentácii sa uvádza, že použitie hodnoty "-1" automaticky upraví hodnotu v závislosti od hodnoty shared_buffers.

random_page_cost- „cena“ náhodného čítania, ktorá sa používa pri vyhľadávaní údajov pomocou indexov. Predvolená hodnota je 4.0. Jednotka je čas postupného prístupu k údajom. Pri rýchlych diskových poliach, najmä SSD, má zmysel hodnotu znížiť, v tomto prípade bude PostgreSQL aktívnejšie využívať indexy.

Kniha na odkaze má niektoré ďalšie parametre, ktoré je možné nakonfigurovať. Dôrazne sa tiež odporúča, aby ste si prečítali dokumentáciu PostgreSQL o priraďovaní špecifických parametrov.

Odporúča sa zmeniť parametre zo sekcie QUERY TUNING, najmä tie, ktoré súvisia so zákazom plánovača používať špecifické metódy vyhľadávania, iba ak plne rozumiete tomu, čo robíte. Je veľmi jednoduché optimalizovať jeden typ dotazu a zničiť výkon všetkých ostatných. Efektívnosť zmeny väčšiny parametrov v tejto časti závisí od údajov v databáze, dopytov na tieto údaje (t. j. okrem iného od použitej verzie 1C) a od verzie DBMS.

Záver

PostgreSQL je výkonný DBMS v schopných rukách, ale vyžaduje starostlivú konfiguráciu. Dá sa použiť v spojení s 1C a získať slušný výkon a jeho voľná povaha bude veľmi príjemným bonusom.

Kritika a doplnky k tomuto článku sú vítané.

užitočné odkazy

http://postgresql.leopard.in.ua/ – webová stránka knihy “ Práca s konfiguráciou a škálovaním PostgreSQL “, podľa mňa najkompletnejší a najzrozumiteľnejší návod na konfiguráciu a správu PostgreSQL

http://etersoft.ru/products/postgre - tu si môžete stiahnuť zostavu PostgreSQL kompatibilnú s 1C pre Windows a rôzne distribúcie a verzie Linuxu. Pre tých, ktorí nemajú predplatné ITS alebo vyžadujú verziu pre Verzia pre Linux, ktorý nie je uvedený na v8.1c.ru.

http://www.postgresql.org/docs/9.2/static/ - oficiálna dokumentácia k PostgreSQL (v angličtine)

Články z disku ITS o nastavení PostgreSQL

História úprav článku

• 29.01.2015 - zverejnená prvotná verzia
• 31.01.2015 - článok bol doplnený o časť AUTOVAKUUM, pridaný odkaz na pôvodnú dokumentáciu.

V budúcnosti mienim otestovať fungovanie DBMS v režime pridávania a zmeny údajov.

Namontujeme montáž od firmy Postgres Professional. Na stránke s verziou pre 1C:Enterprise nájdeme informácie o inštalácii najnovšej verzie PostgreSQL na CentOS 7.

Poďme pripojiť úložiská a nainštalovať PostgreSQL 9.6:

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

Základné nastavenie PostgreSQL

Inicializujeme servisné databázy s ruskou lokalizáciou:

Su postgres /usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data --locale=ru_RU.UTF-8 ukončí službu postgresql-9.6 initdb

Spustite službu PostgreSQL a pridajte ju do spustenia:

Systemctl povoliť postgresql-9.6 systemctl spustiť postgresql-9.6 systemctl stav postgresql-9.6

Nastavili sme heslo pre používateľa postgres, aby sme sa mohli vzdialene pripojiť k serveru:

Su - postgres psql ZMENIŤ POUŽÍVATEĽA postgres SO ŠIFROVANÝM HESLOM "vaše heslo"; \q odchod

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

v súbore, ktorý sa otvorí, odkomentujte a zmeňte riadky:

hostiť všetky 127.0.0.1/32 ident na hostiť všetky 127.0.0.1/32 md5

hostiť všetky 0.0.0.0/0 ident na hostiť všetky 0.0.0.0/0 md5

Optimalizácia nastavení PostgreSQL (postgresql.conf) pre 1C:Enterprise

Tu budú nastavenia pre PostgreSQL spustený na virtuálnom stroji ESXi 6.5.

Prostriedky pridelené pre VM:

procesor - 8 vCPU;

pamäť - 48 GB;

disk pre OS - 50 GB na hardvéri LUN RAID1 z HDD SAS;

disk pre databázu - 170 GB na softvérovom RAID1 z SSD

disk pre logy - 100 GB na softvérovom RAID1 z SSD

Ak chcete upraviť nastavenia, spustite príkaz:

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

Komentované parametre, ktoré budeme meniť, musia byť aktivované.

CPU

autovacuum_max_workers = 4

autovacuum_max_workers = NCores/4..2, ale nie menej ako 4

Počet procesov v autovákue. Všeobecným pravidlom je, že čím viac požiadaviek na zápis, tým viac procesov. V databáze určenej len na čítanie stačí jeden proces.

ssl=off

Vypnite šifrovanie. Pre zabezpečené dátové centrá je šifrovanie bezvýznamné, ale vedie k zvýšenému zaťaženiu procesora

Pamäť

shared_buffers = 12 GB

shared_buffers = RAM/4

Množstvo pamäte pridelenej PgSQL pre zdieľanú vyrovnávaciu pamäť stránok. Táto pamäť je zdieľaná medzi všetkými procesmi PgSQL. operačný systémÚdaje ukladá do vyrovnávacej pamäte sám, takže nie je potrebné alokovať všetku dostupnú pamäť RAM pre vyrovnávaciu pamäť.

temp_buffers = 256 MB

Maximálny počet strán pre dočasné tabuľky. Tie. toto je horný limit veľkosti dočasných tabuliek v každej relácii.

work_mem = 64 MB

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

Pamäťový limit na spracovanie jednej požiadavky. Táto pamäť je individuálna pre každú reláciu. Teoreticky sa maximálna požadovaná pamäť rovná max_connections * work_mem, v praxi sa to nestáva, pretože väčšina relácií takmer vždy čaká. Túto poradnú hodnotu používa optimalizátor: pokúša sa predpovedať veľkosť požadovanej pamäte pre dotaz a ak je táto hodnota väčšia ako work_mem, povie vykonávateľovi, aby okamžite vytvoril dočasnú tabuľku. work_mem nie je limit v plnom zmysle: optimalizátor môže vynechať a požiadavka zaberie viac pamäte, možno mnohokrát viac. Túto hodnotu je možné znížiť sledovaním počtu vytvorených dočasných súborov:

maintenance_work_mem = 2 GB

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

Limit pamäte pre úlohy údržby, ako je zhromažďovanie štatistík (ANALYZE), zber odpadu (VACUUM), vytváranie indexov (CREATE INDEX) a pridávanie cudzích kľúčov. Veľkosť pamäte pridelenej pre tieto operácie by mala byť porovnateľná s fyzická veľkosť najväčší index na disku.

efektívna_veľkosť_cache = 36 GB

effect_cache_size = RAM - zdieľané_buffery

Odhadovaná veľkosť vyrovnávacej pamäte systému súborov. Zvýšením parametra sa zvýši náchylnosť systému na výber plánov IndexScan. A toto je dobré.

Disky

efektívny_io_súbežnosť = 5

Odhad simultánnych požiadaviek na diskový systém, ktorý môže naraz obsluhovať. Pre jeden disk = 1, pre RAID - 2 alebo viac.

random_page_cost = 1,3

random_page_cost = 1,5 – 2,0 pre RAID, 1,1 – 1,3 pre SSD

Náklady na čítanie náhodnej stránky (predvolená hodnota 4). Čím menší je čas vyhľadávania diskového systému, tým menší (ale > 1,0) by mal byť tento parameter. Príliš veľká hodnota parametra zvyšuje tendenciu PgSQL vyberať plány, ktoré skenujú celú tabuľku (PgSQL považuje za lacnejšie čítať celú tabuľku postupne ako náhodne čítať index). A to je zle.

autovakuum=zap

Zapnutie autovákua.

autovacuum_naptime = 20 s

Čas spánku procesu automatického vákua. Ak je hodnota príliš veľká, tabuľky sa nestihnú vysať a v dôsledku toho sa zvýši nafúknutie a veľkosť tabuliek a indexov. Malá hodnota bude mať za následok zbytočné zahrievanie.

bgwriter_delay = 20 ms

Čas spánku medzi cyklami zápisu na disk procesu zápisu na pozadí. Tento proces je zodpovedný za synchronizáciu stránok umiestnených v shared_buffers s diskom. Príliš veľká hodnota tohto parametra zvýši zaťaženie procesu kontrolného bodu a procesov obsluhujúcich relácie (backend). Malá hodnota spôsobí, že jedno z jadier bude plne zaťažené.

bgwriter_lru_multiplier = 4,0

bgwriter_lru_maxpages = 400

Možnosti, ktoré riadia intenzitu nahrávania procesu nahrávania na pozadí. V jednom cykle nezapíše bgwriter viac ako to, čo bolo napísané v poslednom cykle, vynásobené bgwriter_lru_multiplier, ale nie viac ako bgwriter_lru_maxpages.

synchronous_commit = vypnuté

Zakázať synchronizáciu disku v čase odovzdania. Vytvára riziko straty niekoľkých posledných transakcií (v priebehu 0,5-1 sekundy), ale zaručuje integritu databázy, v reťazci odovzdania nie sú žiadne medzery. Ale výrazne zvyšuje produktivitu.

wal_keep_segments = 256

wal_keep_segments = 32..256

Maximálny počet segmentov WAL medzi kontrolnými bodmi. Príliš časté kontrolné body vedú k výraznému zaťaženiu diskového subsystému zápisom. Každý segment má veľkosť 16 MB

wal_buffers = 16 MB

Množstvo zdieľanej pamäte, ktorá sa použije na vyrovnávanie údajov WAL, ktoré ešte nie sú zapísané na disk. Predvolená hodnota -1 určuje veľkosť rovnajúcu sa 1/32 (približne 3 %) , ale nie menej ako 64 KB a nie viac ako veľkosť jedného segmentu WAL (zvyčajne 16 MB). Túto hodnotu je možné nastaviť manuálne, ak je automaticky vybraná hodnota príliš malá alebo veľká, ale každé kladné číslo menšie ako 32 KB bude považované za 32 KB. Tento parameter je možné nastaviť len pri štarte servera.

Obsah vyrovnávacích pamätí WAL sa zapisuje na disk, keď je každá transakcia potvrdená, takže veľmi veľké hodnoty pravdepodobne neprinesú veľa výhod. Hodnota aspoň niekoľkých megabajtov však môže zlepšiť výkon zápisu na zaneprázdnenom serveri, keď mnoho klientov vykonáva transakcie naraz. Automatické ladenie, ktoré pracuje s predvolenou hodnotou (-1), vo väčšine prípadov vyberie rozumné hodnoty.

default_statistics_target = 1000

Nastaví predvolený cieľový limit štatistiky, ktorý sa vzťahuje na stĺpce, pre ktoré ALTER TABLE SET STATISTICS nešpecifikoval individuálne limity. Čím vyššia je nastavená hodnota, tým dlhšie trvá spustenie ANALYZE, ale tým vyššia môže byť kvalita odhadov plánovača. Predvolená hodnota pre tento parameter je 100.

checkpoint_completion_target = 0,9

Stupeň „rozmazania“ kontrolného bodu. Rýchlosť záznamu počas kontrolného bodu sa nastaví tak, aby sa čas kontrolného bodu rovnal času, ktorý uplynul od minulosti, vynásobený cieľom checkpoint_completion_ target.

min_wal_size = 4G
max_wal_size = 8G

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

Minimálna a maximálna veľkosť súborov WAL. Podobne ako checkpoint_segments

fsync=on

Vypnutím tejto možnosti sa zvýši výkon, ale pri náhlom vypnutí napájania existuje značné riziko straty všetkých údajov. Upozornenie: ak má RAID vyrovnávaciu pamäť a je v režime spätného zápisu, skontrolujte prítomnosť a funkčnosť batérie vyrovnávacej pamäte radiča RAID! V opačnom prípade sa môžu po vypnutí napájania stratiť údaje zapísané do vyrovnávacej pamäte RAID a v dôsledku toho PgSQL nezaručuje integritu údajov.

row_security = vypnuté

Vypnutie kontroly rozlíšenia úrovne záznamu

enable_nestloop = vypnuté

Povolí alebo zakáže plánovačom použitie plánov spojenia vnorených slučiek. Nie je možné úplne odstrániť vnorené slučky, ale ak túto možnosť vypnete, plánovač ju nepoužije túto metódu, ak je možné uplatniť iné. Štandardne je toto nastavenie zapnuté.

Zámky

max_locks_per_transaction = 256

Maximálny počet zámkov indexu/tabuľky v jednej transakcii

Nastavenia pre platformu 1C

standard_conforming_strings = vypnuté

Povoliť použitie znaku \ na escapovanie

escape_string_warning = vypnuté

Nevarujte pred použitím znaku \ na escapovanie

Bezpečnostné nastavenia

Uistite sa, že server PostgreSQL je viditeľný iba pre server 1C: Enterprise nainštalovaný na rovnakom počítači.

listen_addresses = 'localhost'

Ak je server 1C: Enterprise nainštalovaný na inom počítači alebo je potrebné pripojiť sa k serveru DBMS pomocou modulu PGAdmin, potom localhost musíte zadať adresu tohto stroja.

Úložisko databázy

PostgreSQL, ako takmer každý DBMS, je kritický pre diskový subsystém, preto pre zvýšenie výkonu DBMS umiestnime systém PostgreSQL, protokoly a samotné databázy na rôzne disky.

Zastavenie servera

Systemctl stop postgresql-9.6

Prenášame protokoly na 120 GB 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

Prenesieme aj adresár s databázami:

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

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

Spustite server a skontrolujte jeho stav

Systemctl štart postgresql-9.6 stav systemctl postgresql-9.6

Prípad použitia ako databázový server PostgreSQL na platforma windows nie je veľmi populárny, ale zvyčajne sa vyskytuje, keď potrebujete nejako ušetriť peniaze na produkty od MS. Existujú aj špecializované aplikácie, ktoré najlepšie fungujú s PostgreSQL. Pre 1c existuje upravená zostava PostgreSQL, ktorá, ako vývojári ubezpečujú, poskytuje úroveň výkonu a tolerancie chýb porovnateľnú s MSSQL. Je to naozaj tak, overme si to v praxi :)

1. Nainštalujte PostgreSQL

Stiahnite si najnovšiu zostavu PostgreSQL 64-bit 9.1.2-1.1C zo stránky 1c, rozbaľte archív, spustite balík msi, ten bez int nemá veľký súbor.

Kliknite na tlačidlo Štart.
Ponechajte možnosti inštalácie ako predvolené.

Nastavte heslo pre používateľa postgres od ktorého sa služba spustí . Kliknite na tlačidlo Ďalej. Ak inštalujete PostgreSQL prvýkrát, sprievodca vás vyzve na vytvorenie používateľa postgres.

Vo fáze inicializácie databázy vyberte kódovanie UTF8. Nastavte prihlasovacie meno a heslo pre interného používateľa postgres. Pozor! Používateľské heslá služby PostgreSQL a heslo používateľa internej databázy PostgreSQL nesmú byť rovnaké. Heslo musí mať aspoň štyri znaky. Ak plánujete spustiť server 1C a PostgreSQL na rôznych počítačoch, musíte začiarknuť políčko „Podpora pripojenia z akejkoľvek adresy IP, nielen z lokálneho hostiteľa“. Kliknite na Ďalej a znova na Ďalej. :)

Dvakrát kliknite na Ďalej a počkajte na dokončenie inštalácie.

Potom prejdite na Štart\Všetky programy\PostgreSQL 9.1.2-1.1C(x64). Spustite administračný nástroj pgAdmin III. Skúsme sa pripojiť k databáze. Zadajte heslo, ktoré ste zadali počas inštalácie.
A dostaneme nasledujúcu chybu: Chyba pri pripájaní k serveru: FATAL: overenie hesla pre používateľa „postgres“ zlyhalo.

Celkom neočakávané, vzhľadom na to, že heslo bolo napísané správne. Rozhodol som sa pohrať s pg_hba.conf, ale tam je na prvý pohľad všetko v poriadku.

# TYP DATABÁZY SPÔSOB ADRESY POUŽÍVATEĽA # Lokálne pripojenia IPv4: hostiteľ všetkých postgres::1/128 md5 hostiteľ všetkých postgres 127.0.0.1/32 md5 hostiteľ všetkých postgres 192.168.1.0/24 md5

Rozhodol som sa zmeniť spôsob autorizácie z md5 na trust. Reštartujem službu a pokúsim sa znova pripojiť k databáze. Tentoraz dostávam túto správu.
Na webovej stránke pgAdmin je k dispozícii viac ako jeden novú verziu. Potom je pripojenie k databáze úspešné!!?!! Pamätám si, že predtým md5 nespôsobovalo takéto problémy, zrejme s tým táto chyba naozaj súvisí stará verzia pgAdmin.
Teraz môžeme vytvoriť databázu pre potreby 1C, alebo to urobiť pomocou samotného 1C :)

2. Inštalácia 1C podniku 8.2.

Pri inštalácii si všimneme nasledujúce komponenty: 1C:Enterprise, 1C:Enterprise Server, moduly rozšírenia webového servera, správa 1C:Enterprise server.
Vo fáze inštalácie „Install 1C Enterprise as a Service“ nastavíme heslo pre používateľa USR1C82.
Kliknite ďalej a sledujte priebeh inštalácie :) Používateľovi USR1CV82 Počas inštalácie musia byť priradené nasledujúce práva:

Prihláste sa ako služba (Prihláste sa ako služba), Prihláste sa ako dávková úloha (Prihláste sa ako dávková úloha). Môžete si ho pozrieť na Politika miestneho počítača\Konfigurácia počítača\Nastavenia systému Windows\Nastavenia zabezpečenia\Miestne politiky\Priradenia používateľských práv.

Poďme k výbave Správa serverov 1C Enterprise, Vidíme, že klaster sa zdvihol a visí na porte 1541. Náš server sa nachádza aj na karte „Pracovné servery“. Teraz môžete pridať databázu na server 1C. Ak to chcete urobiť, prejdite na kartu „ Informačné základne„Kliknite pravým tlačidlom myši a vyberte Novinka - Informačná základňa. Nastavte potrebné parametre na pripojenie k serveru PostgreSQL. Kliknite na tlačidlo OK. Poďme spustiť 1C: Enterprise. Rozhodli sme sa pridať existujúcu informačnú základňu na server.
Ďalej nastavte parametre pripojenia. Kliknite na „Ďalej“ a nakoniec na „Dokončiť“.
Operáciu na vytvorenie databázy je možné vykonať priamo z 1C: Enterprise. Ak to chcete urobiť, pri spustení vyberte „Vytvoriť nový informačnú základňu».

Ak chcete pripojiť klientov 1C k serveru zvonku a prevádzkovať databázový server na bráne firewall, musia byť otvorené nasledujúce porty:

Serverový agent ( ragant) - tcp:1540 hlavný manažér klastra ( rmngr) - tcp:1541 Rozsah sieťových portov pre dynamickú distribúciu pracovných procesov - tcp:1560-1591, tcp:5432 - Postgresql. Vytvorme pravidlo cez štandardné rozhranie alebo pomocou príkazu:

netsh advfirewall firewall add rule name="1Cv8-Server" dir=in action=allow protocol=TCP localport=1540,1541,5432,1560-1590 enable=yes profile=ANY remoteip=ANY interfacetype=LAN

Teraz môžeme jednoducho spustiť klienta 1C:Enterprise z iného počítača a pridať existujúcu informačnú základňu newdb. Nezabudnite na licencie a ochranu softvéru/hardvéru. Teraz si môžeme stiahnuť Gilevov test a zmerať výkon nášho systému.

Na VirtualBoxe s 1 GB pamäte, dvojjadrovým 2,6 GHz, 319-vydanie 1c, Gilev test dáva 11,42 bodu, približne rovnako ako na CentOS. Pri 16,362 je o niečo viac ako 11,60 bodu. Optimalizácia nastavení pomocou Sprievodcu ladením EnterpriseDB nepriniesla výrazné zvýšenie (11,66 a 11,62), hoci môže byť vo všeobecnosti prospešné. :)

3. Rutinná práca na PostgreSQL serveri.

Zálohovanie.

Spustite administračný nástroj pgAdmin III a kliknite pravým tlačidlom myši na požadovanú databázu. Vyberte "Zálohovať".
Vyberte formát (Vlastný (úroveň kompresie od 0 do 9), Tar, Jednoduchý, Katalóg). Pokiaľ ide o úroveň kompresie, najlepšie sa komprimuje „vlastný formát“ akejkoľvek úrovne kompresie, potom „adresár“, potom „jednoduchý“ a nakoniec „tar“. Uvádzame kódovanie UTF8, názov role je postgresql. Všetky ďalšie možnosti ponecháme ako predvolené. Kliknite na tlačidlo „Zálohovať“. Pole „Správy“ zobrazuje zoznam všetkých vykonaných operácií s kódom dokončenia. Ak 0, tak úspech. Tu môžete tiež vidieť, ako spustiť podobnú operáciu z príkazového riadku.

F)\pgAdmin III\1.16\pg_dump.exe" --hostiteľ 192.168.1.200 --port 5432 --používateľské meno "postgres" --rola "postgres" --no-password --format custom --blobs --compress 9 --kódovanie UTF8 --verbose --file "G:\Backups\gilev_dump.backup" "newdb"

V súlade s tým automatický skript Rezervovať kópiu, ktorý pridáme do plánovača, môže vyzerať nejako takto:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_dump.exe" --hostiteľ 192.168.1.200 --port 5432 --username "postgres" --rola "postgres" --no-password --format custom --blobs --compress 9 --kódovanie UTF8 --verbose --file "G:\Backups\gilev_dump_%date:~0.2%_%date:~3.2%_%date:~6.4% .backup" "newdb"

zotavenie.

Pre obnovu vyberte databázu, do ktorej chceme dáta obnoviť záložná kópia, najlepšie prázdne. Kliknite pravým tlačidlom myši a vyberte možnosť „Obnoviť“. Nastavte záložný súbor, názov role: postgres, kliknite na „Obnoviť“
Pomocou príkazového riadku:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_restore.exe" --hostiteľ 192.168.1.200 --port 5432 --username "postgres" --dbname "testdb" --rola "postgres" --no -password --verbose "G:\Backups\gilev_dump_26_09_2012.backup"

kde testdb je prázdna databáza, do ktorej sa obnovuje záloha.

Operácie údržby:

Príkaz VACUUM:

Postupne vyčistí všetky tabuľky aktuálne pripojenej databázy, vymaže dočasné údaje a uvoľní miesto na disku. Príkaz VACUUM sa najčastejšie vykonáva práve preto, aby sa získalo maximálne množstvo voľného miesta na disku a zvýšila sa rýchlosť prístupu k dátam.

VÁKUUM— označí miesto, ktoré zaberajú staré verzie záznamov, ako voľné. Použitie tohto variantu príkazu spravidla neznižuje veľkosť súboru obsahujúceho tabuľku, ale umožňuje vám zabrániť jeho nekontrolovateľnému rastu a opraviť ho na prijateľnej úrovni. Pri spustení VACUUM je možný paralelný prístup k spracovávanej tabuľke. Je ich viacero ďalšie možnosti pomocou VACUUM: VACUUM FULL, VACUUM FREEZE, VACUUM ANALYZE.

VÁKUUM PLNÉ pokúsi odstrániť všetky staré verzie záznamov a podľa toho zmenšiť veľkosť súboru obsahujúceho tabuľku. Táto možnosť príkazu úplne uzamkne spracovávanú tabuľku.

VÁKUOVÉ MRAZENIE - Ak VACUUM FULL odstraňuje „odpad“ z tabuliek a presúva záznamy tak, že tabuľky sú umiestnené kompaktne na disku a pozostávajú z najmenšieho počtu fragmentov, pričom kompresia trvá dlho a blokuje záznamy, potom VACUUM FREEZE jednoducho odstráni „odpad“ z tabuľky, ale samotné záznamy sa nepohybujú, takže je rýchlejší a neblokuje zápisy. V súčasnosti je táto možnosť nahradená autovakuom - automatickým zberom odpadu v postgresql.conf plus niekoľko ďalších možností, ktoré rozširujú funkčnosť:

autovakuum=zap# Umožňuje automatický zber odpadu.
log_autovacuum_min_duration = -1# Nastavením na nulu sa zaprotokolujú všetky činnosti automatického vákua. Mínus jedna (štandardne) zakazuje výstup do denníka. Napríklad, ak nastavíte hodnotu
rovná 250 ms, potom sa zaznamenajú všetky činnosti automatického vákuovania a analýzy, ktoré trvajú 250 ms alebo viac. Povolenie tohto nastavenia môže byť užitočné pri sledovaní automatického vákua.
Túto možnosť je možné nastaviť iba v súbore postgresql.conf alebo v príkazový riadok server.
autovacuum_naptime = 10 min# Čas v sekundách, po ktorom je databáza skontrolovaná na potrebu zberu odpadu. Štandardne sa to deje raz za minútu.
autovacuum_vacuum_threshold= 1800 # Hranica pre počet vymazaných a upravených záznamov v ktorejkoľvek tabuľke, pri prekročení ktorej dôjde k hromadeniu odpadu (VACUUM).
autovacuum_analyze_threshold= 900 # Hranica pre počet vložených, vymazaných a upravených záznamov v ktorejkoľvek tabuľke, pri prekročení ktorej sa spustí proces analýzy (ANALÝZA).
autovacuum_vacuum_scale_factor= 0,2 # Percento zmenených a odstránených záznamov vo vzťahu k tabuľke, nad ktorými sa spúšťa garbage collection.
autovacuum_analyze_scale_factor= 0,1 # Rovnaké ako predchádzajúca premenná, ale vo vzťahu k analýze.
ANALÝZA Vákua— Ak má databáza tabuľky, v ktorých sa údaje nemenia ani neodstraňujú, ale iba pridávajú, potom pre takéto tabuľky môžete použiť samostatný príkaz ANALYZE. Tento príkaz sa oplatí použiť aj pre samostatnú tabuľku po pridaní veľkého počtu záznamov.

Príkaz ANALYZE:

Slúži na aktualizáciu informácií o rozdelení údajov v tabuľke. Tieto informácie používa optimalizátor na výber najrýchlejšieho plánu vykonávania dotazu. Príkaz sa zvyčajne používa v spojení s ANALÝZA Vákua.

Príkaz REINDEX (preindexovanie):

Používa sa na prebudovanie existujúcich indexov. V prípade má zmysel ho použiť

— poškodenie indexu;

- neustále zvyšovanie jeho veľkosti.

Druhý prípad si vyžaduje vysvetlenie. Index, podobne ako tabuľka, obsahuje bloky so starými verziami záznamov. PostgreSQL nemôže vždy znovu použiť tieto bloky, a preto indexový súbor postupne rastie. Ak sa údaje v tabuľke často menia, môže rásť pomerne rýchlo. Ak si všimnete toto správanie indexu, mali by ste ho nakonfigurovať tak, aby pravidelne spúšťal príkaz REINDEX. Poznámka: Príkaz REINDEX, podobne ako VACUUM FULL, úplne uzamkne tabuľku, takže musí byť vykonaný, keď je zaťaženie servera minimálne.

Otázka, ktorý DBMS - Postgresql alebo MS SQL pre 1C je najoptimálnejší - bola predmetom mnohých článkov. V tomto článku sa pozrieme na kroky optimalizácie oboch. DBMS každého dodávateľa má svoje vlastné konfiguračné odporúčania a odporúčania od 1C. Je potrebné poznamenať, že v závislosti od vybavenia, konfigurácie servera a počtu používateľov, ktorí nastavujú rôzne zaťaženia, sa môžu zmeniť podrobnosti procesu optimalizácie DBMS pre 1C a implementácie odporúčaní.

Nastavenie PostgreSQL pre 1C

Skúsenosti s prevádzkou 1C databáz na PostgreSQL ukázali, že najvyšší výkon a optimálny výkon 1C a PostgreSQL bol dosiahnutý na Linuxe, preto je vhodné ho používať. Bez ohľadu na operačný systém je však dôležité si uvedomiť, že predvolené nastavenia špecifikované pri inštalácii PostgreSQL sú určené len na spustenie servera DBMS. O nejakom priemyselnom vykorisťovaní nemôže byť ani reči! Ďalším krokom po spustení bude optimalizácia PostgreSQL pre 1C:

• Najprv zakážeme úsporu energie (inak sa oneskorenia v odpovediach z databázy môžu nepredvídateľne zvýšiť) a zakážeme swapovanie zdieľanej pamäte.
• Nakonfigurujeme základné parametre servera DBMS (odporúčania pre konfiguráciu sú dostatočne podrobne popísané na oficiálnej webovej stránke predajcu aj spoločnosťou 1C, takže sa zameriame iba na tie najdôležitejšie).
• Štandardné odporúčania spoločnosti 1C odporúčajú deaktivovať mechanizmy HyperThreading. Ale testovanie Postgres-pro na serveroch s povoleným SMT (simultánne multivlákno) ukázalo iné výsledky.

Nastavenie shared_buffers na RAM/4 je predvolené odporúčanie, ale Príklad SQL Server hovorí, že čím viac pamäte je mu pridelené, tým lepší je jeho výkon (so zakázaným vyplachovaním stránky). To znamená, že čím viac dátových stránok je umiestnených v RAM, tým menej prístupov na disk. Vynára sa otázka: prečo taká malá keška? Odpoveď je jednoduchá: ak sú shared_buffers veľké, potom sa niektoré nepoužívané stránky vymenia na disk. Ale ako sledovať okamih, keď sa reset zastaví a indikátor parametrov je optimálny? Na dosiahnutie a dosiahnutie optimálneho ukazovateľa shared_buffers je potrebné jeho hodnotu zvyšovať v produkcii denne (ak je to možné) s určitým prírastkom a sledovať, v akom momente sa stránky začnú vyprázdniť na disk (výmena swapu sa zvýši).

Okrem toho je „veľký parameter“ negatívne ovplyvnený prácou s mnohými malými stránkami, ktoré majú štandardne veľkosť 8 Kb. Práca s nimi zvyšuje režijné náklady. Čo sa s tým dá urobiť na optimalizáciu pre 1C? PostgreSQL 9.4 predstavil parameter huge_pages, ktorý je možné povoliť, ale iba v systéme Linux. Štandardne sú zahrnuté veľké stránky s predvolenou veľkosťou 2048 kB. Okrem toho musí byť v OS povolená podpora pre tieto stránky. Optimalizáciou štruktúry úložiska teda môžete dosiahnuť väčší ukazovateľ shared_buffers.

work_mem = RAM/32..64 alebo 32MB..128MB Nastavuje množstvo pamäte pre každú reláciu, ktorá sa použije na interné triedenie, zlučovanie atď. pred použitím dočasných súborov. Ak je tento objem prekročený, server použije dočasné súbory na disku, čo môže výrazne znížiť rýchlosť spracovania požiadaviek. Tento parameter sa používa pri vykonávaní operátorov: ORDER BY, DISTINCT, merge joins atď.

Vypočítajte dodatočne tento parameter možno vykonať nasledovne: (Zdieľaná pamäť shared_buffers - pamäť pre iné programy) / počet aktívnych spojení. Túto hodnotu je možné znížiť sledovaním počtu vytvorených dočasných súborov. Takéto štatistiky o veľkosti a počte dočasných súborov možno získať zo systémového pohľadu pg_stat_database.

efektivní_cache_size = RAM - shared_buffers Hlavným účelom tohto parametra je povedať optimalizátoru dotazov, ktorý spôsob získavania údajov si má vybrať: úplné skenovanie alebo indexové skenovanie. Čím vyššia je hodnota parametra, tým väčšia je pravdepodobnosť použitia indexového skenovania. V tomto prípade server neberie do úvahy, že údaje môžu zostať v pamäti pri vykonávaní požiadavky a ďalšia požiadavka ich nemusí získať z disku.

Inštalácia PostgreSQL

Inštalácia 1C na PostgreSQL pod Windows je pomerne jednoduchý proces. Pri spustení inštalačného balíka musíte zadať kódovanie UTF-8. V skutočnosti je to jediná zaujímavá nuansa a nie je potrebná žiadna ďalšia konfigurácia PostgreSQL pre 1C 8.3 zo systému Windows. Inštalácia a konfigurácia PostgreSQL pre 1C v operačnom systéme Linux môže spôsobiť množstvo problémov. Aby sme ich prekonali, ako príklad zvážme spustenie (pomocou distribučných súprav od popredného ruského dodávateľa PostgreSQL-Pro a spoločnosti 1C) PostgreSQL na serveri Ubuntu 16.04 x64

Inštalácia distribučných súprav 1C pre PostgreSQL DBMS

1. Stiahnite si špecifikovanú pozíciu distribučnej súpravy PostgreSQL DBMS:

2. Nahrajte PostgreSQL na server;

3. Inštalačný program PostgreSQL DBMS môžete rozbaliť príkazom:

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

4. Pred inštaláciou distribučnej súpravy PostgreSQL DBMS skontrolujte prítomnosť požadovaného miestneho nastavenia v systéme (štandardne ru_RU.UTF-8):

5. Ak bol systém, s ktorým bude PostgreSQL fungovať, nainštalovaný v inom jazyku ako v ruštine, musíte vytvoriť nové miestne nastavenia:

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

6. Ak je požadované miestne nastavenie stále dostupné, štandardne ho nainštalujte:

locale –a nano /etc/default/locale Nahradiť obsah reťazcom LANG=ru_RU.UTF-8

7. Po reštarte nainštalujte potrebné balíčky pre našu verziu PostgreSQL:

apt-get nainštalovať libxslt1.1 ssl-cert

8. Verzia balíka PostgreSQL 9.4.2-1.1C je prepojená s verziou balíka libicu libicu48. Požadovaná verzia už nie je v úložisku, ale môžete si ju stiahnuť;

9.Stiahnuť a umiestniť do adresára, kde sú uložené stiahnuté súbory pre PostgreSQL;

10. Prechodom do adresára so súbormi PostgreSQL vykonáme inštaláciu postupným zadaním nasledujúcich príkazov:

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.debd.debd11. bal -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.1C_amdd

11.Hotovo. Distribučná súprava PostgreSQL DBMS je nainštalovaná.

Inštalácia distribúcií PostgreSQL-Pro

Ak chcete nainštalovať server, musíte postupne spustiť nasledujúce príkazy:

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

Ak chcete získať prístup k serveru, upravte parametre v súbore 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 md5" >> pg_hba.conf"

Samotný súbor má nasledujúcu štruktúru:

Spis je dobre zdokumentovaný, ale anglický jazyk. Pozrime sa stručne na hlavné parametre:

• Miestne lokálne pripojenie len cez unix
• Hostiteľ TCP/IP pripojenie
• Hostsslšifrované pripojenie SSL cez TCP/IP (server musí byť zostavený s podporou SSL, musí byť nastavený aj parameter ssl)
• Hostnossl nešifrované pripojenie cez TCP/IP

• dôverovať priznať bez overenia
• odmietnuť odmietnuť bez overenia
• hesložiadosť o heslo vo forme čistého textu
• md5žiadosť o heslo vo forme MD5
• ldap overenie používateľského mena a hesla pomocou servera LDAP
• polomer Overenie používateľského mena a hesla pomocou servera RADIUS
• pam overenie používateľského mena a hesla pomocou služby pluginu

Podrobnejšie a podrobnejšie informácie nájdete v dokumentácii k produktu PostgreSQL.

root@NODE2:/home/asd# služba --status-all |grep postgres [ - ] postgresql root@NODE2:/home/asd# služba postgresql spustiť root@NODE2:/home/asd# služba --status-all | grep postgres [ + ] postgresql

Po dokončení základnej inštalácie je potrebné nakonfigurovať konfiguračný súbor server postgresql.conf, podľa špecifík PostgreSQL, konfigurácie servera 1C a servera Ubuntu.

Optimalizácia 1C pre MS SQL Server

Inštalácia Najnovšie aktualizácie pre SQL Sever.

Operačný systém si vyhradzuje miesto a zaplní ho nulami, čo pri nasledujúcich udalostiach trvá pomerne dlho:

• Tvorba databázy;
• Pridávanie dátových súborov, protokolu transakcií, do existujúcej databázy;
• Zväčšenie veľkosti existujúceho súboru (vrátane operácií Autogrow);
• Obnovujeme databázy alebo skupiny súborov.

Rozhoduje sa tento problém pridanie roly (pod ktorou server beží) k položke miestnej politike zabezpečenie "Vykonávanie úloh údržby objemu."

Ak je to možné, je potrebné distribuovať databázu TempDB (využíva sa obzvlášť intenzívne v režime RCSI riadeného zamykania) a transakčný protokol na rôzne disky.

Na serveri, kde to funguje SQL server, režim úspory energie by mal byť nastavený na „Vysoký výkon“.

Priečinok s databázovými súbormi by nemal byť komprimovaný.

Na karte „Pamäť“ pre server nastavíme minimálnu úroveň na 50 % celkovej pamäte. Maximum vypočítame pomocou jedného zo vzorcov:

• Maximálna pamäť = celkový objem - veľkosť podľa OS - veľkosť pre 1C (ak existuje, po predchádzajúcom zmeraní pamäte použitej s počítadlami) alebo
• Maximálna pamäť = Celková veľkosť – (1024* Celková veľkosť/16384).

Obmedzíme parameter DOP „Maximálny stupeň paralelizmu“ a nastavíme ho na „1“.

Štatistiky aktualizujeme podľa plánu. Počnúc serverom SQL Server 2008 aktualizácia štatistiky spôsobuje opätovné skompilovanie dotazov, a preto vymaže vyrovnávaciu pamäť procedúr, takže na vymazanie vyrovnávacej pamäte procedúr nie je potrebné vykonávať samostatnú procedúru.

Pravidelne reindexujeme tabuľku a defragmentujeme indexy.

Stanovujeme správnu politiku rezervácie. Ak sa nepotrebujete obnoviť do posledného bodu v čase pred zlyhaním systému a posledných 5 minút alebo viac nie je pre vaše podnikanie kritických, nastavte model obnovy na „Jednoduché“. To výrazne zrýchli rýchlosť nahrávania. Hlavná vec je, že diferencovaná záloha môže byť dokončená v stanovenom čase.

Zlepšenie práce s TempDB počas I/O dosahujeme vytváraním ďalších dátových súborov. Ak existuje menej ako 8 logických procesorov, odporúča sa vytvoriť dátový súbor pre každý logický procesor. Ak existuje viac ako 8 logických procesorov, odporúča sa vytvoriť 8 dátových súborov a po zvýšení o jeden na násobok 4 nezabudnite odhadnúť zaťaženie TempDB.

1. nov 2012 Výhody používania voľne distribuované softvér zrejmé. Bohužiaľ, nevýhody sú tiež zrejmé - neexistuje žiadna oficiálna podpora, dokumentácia je často protichodná, neúplná a roztrúsená rôzne zdroje. Tento článok vám pomôže pochopiť proces inštalácie PosgreSQL pre 1C:Enterprise 8 a vyhnúť sa nástrahám, ktoré nie sú popísané v oficiálnej dokumentácii.

Komponenty potrebné na inštaláciu

PostgreSQL DBMS je distribuovaný bezplatne a je súčasťou dodávky aplikačného servera 1C. Aplikačný server 1C:Enterprise 8 sa dodáva v dvoch verziách: 32-bit a 64-bit. Postgre zvládne oboje.

Takže máme po ruke distribučné súpravy:

• Postgre: postgresql-9_1_2-1_1Cx64.zip, láskavo poskytol 1C.
• Distribúcia aplikačného servera 1C:Enterprise pre Windows x64, verzia 8.2.16.368.

Zdalo by sa, že to už nemôže byť jednoduchšie - stačí spustiť a nainštalovať. Jednoducho! Inštalácia v štandardnom režime však prinesie jedno malé obmedzenie: klaster sa bude nachádzať v priečinku „Program Files“. Nie každému sa to bude páčiť. Zvážme dve možnosti inštalácie, jednoduchú a pokročilú.

Článok je rozdelený do 5 sekcií:

1) Inštalácia servera 1C.

2) Nainštalujte PostgreSQL v štandardnej forme, postačujúcej na spustenie 1C bez ďalších nastavení.

3) Nainštalujte PostgreSQL a vyberte priečinok úložiska klastra.

4) Vytvorenie novej informačnej základne 1C.

5) Určenie priečinka na ukladanie databázových súborov na serveri DBMS.

Pred inštaláciou si určite prečítajte celý článok!

Inštalácia aplikačného servera 1C

Spustíme setup.exe z priečinka s distribučnou súpravou servera 1C.

Ak aplikačný server nainštalujete nie ako službu, budete ho musieť zakaždým spustiť manuálne. Táto možnosť je zriedka potrebná. Nainštalujeme ju ako službu a rozhodneme, pod ktorým používateľom bude spustená. Z bezpečnostných dôvodov je lepšie vytvoriť samostatného používateľa USR1CV82, ako povoliť službe bežať s plnými právami.

Po nainštalovaní aplikačného servera vás systém vyzve na inštaláciu ovládača ochranného kľúča HASP. Súhlasíme:

Čakáme na správu:

Ak je správa odlišná, s najväčšou pravdepodobnosťou v systéme zostali „chvosty“. predchádzajúce inštalácie Ovládače HASP. Odstráňte ich všetky a skúste to znova.

Hotovo, úspešne sme nainštalovali aplikačný server 1C:Enterprise 8.

Inštalácia PostgreSQL v štandardnej forme, postačujúcej na spustenie 1C bez ďalších nastavení

Spustite "postgresql-9.1.2-1.1C(x64).msi"

Nemusíte meniť možnosti inštalácie, 1C bude fungovať. Ďalej.

Postgre, podobne ako server 1C, môže sám vytvoriť používateľa, pod ktorým budete službu spúšťať. Dávam do pozornosti, že ak uvediete účtu s právami správcu nebude služba fungovať správne. Nezabudnite vytvoriť nového používateľa.

Ďalšie okno inštalácie.

Inicializujeme klaster. Ak sa nachádza náš databázový server a aplikačný server 1C rôzne počítače a potom začiarknite políčko „Podporovať pripojenia z ľubovoľnej adresy IP“, inak sa ho nedotkneme. Nezabudnite zadať kódovanie UTF8. Vytvorte superužívateľa DBMS. Ďalej…

Na úvodnú prácu nepotrebujeme nič navyše, zrušte začiarknutie políčka a dokončite inštaláciu.

Výsledkom nášho snaženia je PostgreSQL pripravený na použitie. Ak sme spokojní, že databázy sa budú nachádzať v Program Files\PostgreSQL\9.1.2-1.1C\data, končíme, otvárame databázy a užívame si proces. Častejšie však databázy „ležia“ na špeciálne navrhnutých diskových poliach a nie na nich systémový disk. Ak chcete nakonfigurovať umiestnenie údajov, pred inštaláciou si prečítajte nasledujúcu časť.

Inštalácia Postgre s výberom umiestnenia klastra

Pokračujeme v inštalácii Postgre a vykonávame všetky kroky, kým sa nám nezobrazí výzva na inicializáciu klastra:

Zrušte začiarknutie políčka „Inicializovať klaster databázy“ a kliknite na tlačidlo „Ďalej“.

Áno, sme si istí.

Zrušte začiarknutie políčka „Spustiť nástroj na tvorbu zásobníkov pri ukončení“ a dokončite inštaláciu.

1. Je potrebné dať plné práva priečinku, do ktorého sme nainštalovali PostgreSQL, zvyčajne je to C:\Program Files\PostgreSQL

2. Spustite cmd ako správca. Ak to urobíte vo win7, spustite ho ako správca.

3. Vytvorte priečinok, do ktorého bude klaster uložený. Napríklad d:\postgredata.

md d:\postgredata

4. Klaster inicializujeme manuálne s uvedením cesty, kde sa bude nachádzať.

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

5. Odstráňte službu PostgreSQL, ktorá bola nainštalovaná počas inštalácie.

sc odstrániť pgsql-9.1.2-1.1C-x64

Kde pgsql-9.1.2-1.1C-x64 je názov služby. Ak nepoznáte presný názov, môžete sa pozrieť na vlastnosti služby „Databázový server PostgreSQL...“ (Štart - Ovládací panel - Nástroje na správu - Služby)

6. Vytvorte nová služba označujúci náš zhluk

Register „C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\pg_ctl“ -N pgsql -U postgresql -P heslo -D d:/postgredata

7. Teraz poďme k službám. Štart – Ovládací panel – Správa – Služby a spustite našu službu.

Vytvorenie novej databázy 1C na serveri s PostgreSQL

Existuje niekoľko možností na vytvorenie databázy. Môžete skúsiť vytvoriť databázu cez pgAdmin3, konzolu správy servera 1C. Tu však na vás čaká množstvo nepochopiteľných otázok a kopa chýb, ktorých odpovede budete dlho hľadať. Nechajte to na odborníkov. Naším cieľom je získať fungujúcu základňu s minimálnym úsilím. Poďme si popísať najjednoduchší spôsob, ako to dosiahnuť.

Spúšťame klienta 1C.

Kliknite na „Pridať...“.

Prichádzame s názvom databázy, označte „Na serveri 1C: Enterprise“.

Serverový klaster 1C:Enterprise– localhost, ak vytvárame databázu na tom istom počítači, kde je nainštalovaný server 1C, alebo názov aplikačného servera 1C, ak je na inom.

Názov informačnej bázy v klastri- v budúcnosti sa tento názov bude zobrazovať pri pripájaní z iných počítačov.

Typ DBMS– Vyberte PostgreSQL.

Databázový server- uveďte názov servera PostgreSQL. Ak vytvárame databázu na serveri, zadáme aj localhost.

Názov databázy– s týmto názvom sa vytvorí databáza v PostgreSQL.

Používateľ, heslo– meno používateľa, ktorého sme zadali ako superužívateľa pri inštalácii PostgreSQL. Nezabudnite začiarknuť políčko „Vytvoriť databázu, ak neexistuje“.

Vynára sa otázka – kde bude databáza fyzicky uložená? V základnej zložke zadaného klastra. Čo ak nechceme, aby ležal tam, kde sú všetky základne? Zatiaľ s tým nemôžeme nič robiť, len si vytvoríme základňu a ideme ďalej. Ďalej…

Určenie priečinka úložiska databázy

Takže sme vytvorili základňu. Vo väčšine prípadov tu inštalácia končí. Ak však existuje veľa databáz a existuje niekoľko diskových polí pre rôzne skupiny databáz, musíte uviesť, kde by sa databázy mali fyzicky nachádzať. Ak to chcete urobiť, spustite pgAdmin3 zo Štart – Programy – PostgreSQL. Pripojte sa k nášmu serveru.

Pri prvom pripojení si Postgre vypýta heslo pre používateľa postgres (ktoré sme vytvorili počas inštalácie).

Vytvoríme nový TableSpace, toto bude priečinok, v ktorom budú uložené naše databázy.

Zadané miesto uloženia databázových súborov. OK.

Teraz otvoríme vlastnosti predtým vytvorenej databázy, ktorej umiestnenie chceme zmeniť.

Zmeňte vlastnosť Tablespace. Po kliknutí na „OK“ sa súbory databázy automaticky presunú. Pripravený! Dúfame, že článok bol pre vás užitočný. Ak áno, zanechajte komentáre a zdieľajte odkazy na túto stránku. Ďakujem!