Šis raksts nepretendē uz pilnīgu visu PostgreSQL konfigurācijas opciju prezentāciju, un salīdzinošajā testēšanā es neaptveru visus datu bāzes darbības režīmus. Interesentiem iesaku izpētīt grāmatu saitē

Ievads

Esmu daudz strādājis ar PostgreSQL un domāju, ka tā ir lieliska DBVS. Man ir vairāku gigabaitu darba datu bāze (nevis 1C), kas uzreiz apstrādā milzīgus datu apjomus. PostgreSQL lieliski izmanto indeksus, lieliski tiek galā ar paralēlām darba slodzēm, saglabāto procedūru funkcionalitāte ir lieliska, ir pieejami labi administrēšanas un veiktspējas rīki, un kopiena ir izveidojusi noderīgi komunālie pakalpojumi. Bet es biju pārsteigts, uzzinot, ka daudziem 1C administratoriem ir slikts viedoklis par PostgreSQL, ka tas ir lēns un tikko pārspēj datu bāzes faila versiju, un tikai MSSQL var glābt situāciju.

Pēc jautājuma izpētes es atradu daudzus rakstus par PostgreSQL soli pa solim instalēšanu manekeniem gan operētājsistēmā Linux, gan operētājsistēmā Windows. Bet lielākajā daļā rakstu ir aprakstīta instalēšana līdz "instalēšanai - izveidosim datu bāzi" un vispār neskar konfigurācijas jautājumu. Pārējos konfigurācija ir minēta tikai "norādīt šādas vērtības" līmenī, praktiski bez paskaidrojuma, kāpēc.

Un, ja “vienas pogas instalēšanas” pieeja ir piemērojama MSSQL un daudziem Windows produktiem kopumā, tad diemžēl tā neattiecas uz PostgreSQL. Noklusējuma iestatījumi ievērojami ierobežo tā atmiņas izmantošanu, lai to varētu instalēt pat kalkulatorā un tas netraucēs pārējās programmatūras darbībai. PostgreSQL ir jākonfigurē noteiktai sistēmai, un tikai tad tas var parādīt labāko. Īpaši smagos gadījumos varat noregulēt PostgreSQL, datu bāzes un failu sistēma viens otru, bet tas lielākā mērā attiecas uz Linux sistēmām, kur ir vairāk iespēju visu pielāgot.

Jāatgādina, ka 1C DBVS izstrādātāju PostgreSQL montāža nav piemērota, tikai samontēta no ielāpiem 1C pirmkodiem. Gatavus saderīgus komplektus piedāvā 1C (izmantojot ITS diskus un kontu tiem, kam ir atbalsta abonements) un EterSoft

Pārbaude tika veikta gadā Windows vide, taču visi konfigurācijas ieteikumi neattiecas uz platformu un attiecas uz jebkuru OS.

Testēšana un salīdzināšana

Pārbaudot, es neplānoju veikt testus visos darbības režīmos un scenārijos, tikai aptuvenu veiksmīgas konfigurācijas pārbaudi.

Testēšanai izmantoju šādu konfigurāciju:
Resursdatora mašīna: Win7, Core i5-760 2.8MHz, 4 kodoli, 12GB RAM, VMWare 10
Virtuālais: Win7 x64, 2 kodoli, 4 GB RAM, atsevišķa fiziska HDD datu bāzes mitināšanai (nevis SSD)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
1C 8.3.5 1383

Tika izmantota datubāze, dt-upload 780MB.
Pēc datu bāzes atjaunošanas:
faila lielums 1 CD faila versijā - 10 GB,
PostgreSQL datu bāzes lielums - 8 GB,
MSSQL datu bāzes izmērs ir 6,7 GB.

Pārbaudei izmantoju pieprasījumu pēc darījuma partnera līgumu parauga (21k) ar papildu rekvizītu atlasi no dažādiem reģistriem, katram līgumam faktiski tika izveidots atsevišķs paraugs no reģistriem. Es paņēmu konfigurāciju, kas bija pie rokas - stipri pārveidota, pamatojoties uz grāmatvedības 3.0.

Pārbaudes laikā es vairākas reizes izpildīju pieprasījumu ar vienu un diviem klientiem, līdz tika iegūti stabili rezultāti. Pirmos braucienus es ignorēju.

Testēšana ar vienu klientu:

Izlases ņemšana uz saimniekdatora no faila versijas ar datubāzi, kas ievietota SSD — 31c
Izvēloties no faila varianta iekšā virtuālā iekārta(Ar cietais disks) - 46s
Iztveršana no MSSQL datu bāzes — pirmā piegājiens — 25 s vai 9 s (acīmredzot atkarībā no DBVS kešatmiņas atbilstības) (DBVS procesa atmiņas patēriņš bija aptuveni 1,3 GB)
Iztveršana no PostgreSQL ar noklusējuma iestatījumiem - 43 s (atmiņas patēriņš nepārsniedza 80 MB vienam savienojumam)
Iztveršana no optimizētā PostgreSQL — 21 s (atmiņas patēriņš bija 120 MB uz vienu savienojumu)

Testēšana ar diviem klientiem:

Izlases ņemšana resursdatorā no faila versijas ar datubāzi, kas ievietota SSD — katrs 34 s
Paraugu ņemšana no faila versijas virtuālajā mašīnā (no cietā diska) - 56 s katrs
Izlase no MSSQL datu bāzes — 50 s vai 20 s (acīmredzot atkarībā no DBVS kešatmiņas atbilstības)
Izlase no PostgreSQL ar noklusējuma iestatījumiem - 60s katrs
Izlase no optimizēta PostgreSQL — katra 40 s

Testēšanas piezīmes:

1. Pēc trešā kodola pievienošanas PostgreSQL un MSSQL varianti sāka darboties “divu klientu” testā gandrīz ar “viena klienta” testa izpildi, t.i. veiksmīgi paralēli. Kas viņiem neļāva paralēli veikt darbu pie diviem kodoliem, man palika noslēpums.
2. MSSQL uzreiz aizņēma daudz atmiņas, PostgreSQL visos režīmos prasīja ievērojami mazāk, un gandrīz visu to atbrīvoja uzreiz pēc vaicājuma aizpildīšanas.
3. MSSQL darbojas kā viens process. PostgreSQL palaiž atsevišķu procesu katram savienojumam + pakalpojumu procesiem. Tas ļauj pat 32 bitu variantam efektīvi izmantot atmiņu, apstrādājot pieprasījumus no vairākiem klientiem.
4. PostgreSQL atmiņas palielināšana iestatījumos, kas pārsniedz tālāk norādītās vērtības, neizraisīja ievērojamu veiktspējas pieaugumu.
5. Pirmie testi visos gadījumos aizņēma ilgāku laiku nekā turpmākajos mērījumos, speciālus mērījumus neveicu, bet MSSQL subjektīvi sāka ātrāk.

PostgreSQL konfigurēšana

Krievu valodā ir lieliska grāmata par PostgreSQL konfigurēšanu un optimizēšanu: ikvienam ziloņu mīļotājam ir jēga pievienot šo saiti grāmatzīmē. Grāmatā ir aprakstīti daudzi paņēmieni DBVS optimizēšanai, kļūmju izturīgas un sadalītas sistēmas izveidei. Bet tagad apskatīsim kaut ko, kas noderēs ikvienam – atmiņas lietojuma konfigurēšanu. PostgreSQL neizmantos vairāk atmiņas, nekā pieļauj iestatījumi, un ar noklusējuma iestatījumiem PostgreSQL izmanto minimālu atmiņu. Tajā pašā laikā nevajadzētu norādīt vairāk atmiņas, nekā ir pieejams lietošanai - sistēma sāks izmantot mijmaiņas failu ar visām no tā izrietošajām drausmīgajām sekām servera veiktspējai. ITS diskā ir sniegti vairāki padomi PostgreSQL iestatīšanai.

Operētājsistēmā Windows PostgreSQL konfigurācijas faili atrodas datu direktorija instalācijas direktorijā:

• postgresql.conf- galvenais fails ar DBVS iestatījumiem
• pg_hba.conf- fails ar piekļuves iestatījumiem klientiem. Jo īpaši šeit varat norādīt, kuri lietotāji, no kurām IP adresēm var izveidot savienojumu ar noteiktām datu bāzēm, un vai ir nepieciešams pārbaudīt lietotāja paroli, un, ja jā, ar kādu metodi.
• pg_ident.conf- fails ar lietotājvārdu konvertēšanu no sistēmas uz iekšējo (lielākajai daļai lietotāju tas, visticamāk, nebūs vajadzīgs)

Faili ir teksta, tos var rediģēt, izmantojot notepad. Rindas, kas sākas ar # tiek uzskatīti par komentāriem un tiek ignorēti.

Ar atmiņas ietilpību saistītos parametrus var papildināt ar sufiksiem kB, MB, GB - kilobaiti, megabaiti, gigabaiti, piemēram, 128MB. Laika intervālus aprakstošos parametrus var papildināt ar sufiksiem ms, s, min, h, d - milisekundes, sekundes, minūtes, stundas, dienas, piemēram, 5min

Ja esat aizmirsis Postgress paroli, tā nav problēma, varat to ierakstīt pg_hba.conf rinda:

Uzstādiet visu 127.0.0.1/32 uzticību

Un izveidot savienojumu ar jebkuru lietotāju (piemēram, postgres) uz DBVS vietējā datorā 127.0.0.1, nepārbaudot paroli.

Optimizācija atmiņas lietojums

Atmiņas izmantošanas iestatījumi atrodas postgresql.conf

Optimālās parametru vērtības ir atkarīgas no brīvā apjoma brīvpiekļuves atmiņa, datu bāzes lielums un atsevišķie datu bāzes elementi (tabulas un indeksi), vaicājumu sarežģītība (principā jāpieņem, ka vaicājumi būs diezgan sarežģīti - vairāki savienojumi vaicājumos ir tipisks scenārijs) un vaicājumu skaits. vienlaicīgi aktīvi klienti. Starp citu, PostgreSQL saglabā datu bāzu tabulas un indeksus atsevišķi faili (<каталог установки PG>\dati\bāze\<идентификатор БД>\), un objektu izmērus var novērtēt. Varat arī izmantot iekļauto utilītu pgAdmin, lai izveidotu savienojumu ar datu bāzi, izvērstu "Shēmas" - "publisks" un ģenerētu statistikas pārskatu elementam "Tabulas".

Tālāk es sniegšu aptuvenās vērtības, no kurām jūs varat sākt skaņošanu. Pēc sākotnējā iestatīšana Ieteicams darbināt serveri darba režīmos un uzraudzīt atmiņas patēriņu. Atkarībā no iegūtajiem rezultātiem var būt nepieciešams pielāgot parametru vērtības.

Iestatot serveri testēšanai, es paļāvos uz šādiem aprēķiniem:
Tikai 4 GB RAM. Patērētāji - Windows OS, 1C serveris, PostgreSQL un sistēmas diska kešatmiņa. Pieņēmu, ka DBVS var atvēlēt līdz 2,5 GB RAM

Vērtības var norādīt ar sufiksiem kB, MB, GB (vērtības kilobaitos, megabaitos vai gigabaitos). Pēc vērtību maiņas jums ir jārestartē PostgreSQL pakalpojums.

share_buffers — koplietots servera buferis

PostgreSQL lasīšanas un rakstīšanas kešatmiņas lielums, ko koplieto visi savienojumi. Ja dati nav kešatmiņā, tie tiek nolasīti no diska (iespējams, OS kešatmiņā).

Ja bufera lielums nav pietiekams, lai uzglabātu bieži izmantotos darba datus, tie tiks pastāvīgi rakstīti un lasīti no OS kešatmiņas vai diska, kas ārkārtīgi negatīvi ietekmēs veiktspēju.

Bet šī nav visa darbībai nepieciešamā atmiņa, jums nevajadzētu norādīt pārāk daudz liela nozīme, pretējā gadījumā nepaliks atmiņas gan klienta pieprasījumu faktiskai izpildei (un jo vairāk to ir, jo lielāks atmiņas patēriņš), gan OS un citām lietojumprogrammām, piemēram, 1C servera procesam. Serveris arī paļaujas uz OS kešatmiņu un cenšas nesaglabāt savā buferī to, kas, visticamāk, ir kešatmiņā sistēmā.

Izmantotais tests

share_buffers = 512 MB

darba_atmiņa- atmiņa šķirošanai, datu apkopošanai utt.

Piešķirts katram pieprasījumam, iespējams, vairākas reizes sarežģītiem pieprasījumiem. Ja nav pietiekami daudz atmiņas, PostgreSQL izmantos pagaidu failus. Ja vērtība ir pārāk liela, RAM var tikt pārmērīgi izmantota un OS sāks izmantot mijmaiņas failu ar atbilstošu veiktspējas samazināšanos.

Ir ieteikums, veicot aprēķinus, atņemt pieejamās atmiņas apjomu share_buffers, un dala ar vienlaicīgi izpildīto pieprasījumu skaitu. Sarežģītu vaicājumu gadījumā dalītājs jāpalielina, t.i. samazināt rezultātu. Aplūkojamajam gadījumam, pamatojoties uz 5 aktīviem lietotājiem (2,5 GB–0,5 GB (shared_buffers))/5 =400 MB. Ja DBVS uzskata, ka vaicājumi ir diezgan sarežģīti vai parādās papildu lietotāji, vērtība būs jāsamazina.

Vienkāršiem vaicājumiem pietiek ar mazām vērtībām - līdz pāris megabaitiem, bet sarežģītiem vaicājumiem (un tas ir tipisks 1C scenārijs) būs nepieciešams vairāk. Ieteikums - atmiņai 1-4GB varat izmantot vērtības no 32-128MB. Es to izmantoju testā

darba_atmiņa = 128 MB

apkopes_darba_atmiņa- atmiņa atkritumu savākšanas komandām, statistikai, indeksu izveidei.

Ieteicams iestatīt vērtību 50-75% no lielākās tabulas vai indeksa lieluma, bet tā, lai būtu pietiekami daudz atmiņas sistēmas un lietojumprogrammu palaišanai. Ieteicams iestatīt vērtības, kas ir lielākas par work_mem. Es to izmantoju testā
apkopes_darba_atmiņa = 192 MB

temp_buffers- buferis pagaidu objektiem, galvenokārt pagaidu tabulām.

Varat instalēt apmēram 16 MB. Es to izmantoju testā
temp_buffers = 32 MB

efektīvas_kešatmiņas_izmērs- aptuvenais failu sistēmas diska kešatmiņas lielums.

Optimizētājs izmanto šo vērtību, veidojot vaicājumu plānu, lai novērtētu iespējamību, ka dati tiks atrasti kešatmiņā (ar ātru nejaušu piekļuvi) vai lēnā diskā. Operētājsistēmā Windows pašreizējo kešatmiņai atvēlētās atmiņas apjomu var skatīt uzdevumu pārvaldniekā.

Autovakuums - "atkritumu savākšana"

PostgreSQL kā tipisks “versiju” DBVS pārstāvis (pretstatā bloķētajām), mainot datus, neatkarīgi nebloķē tabulas un ierakstus no transakciju nolasīšanas (1C gadījumā to dara pats 1C serveris). Tā vietā tiek izveidota modificētā ieraksta kopija, kas kļūst redzama turpmākajām transakcijām, savukārt esošie turpina redzēt datus, kas bija aktuāli to darījuma sākumā. Tā rezultātā tabulās uzkrājas novecojuši dati - iepriekšējās versijas mainīti ieraksti. Lai DBVS izmantotu atbrīvoto vietu, ir jāveic “atkritumu savākšana” - jānosaka, kuri no ierakstiem vairs netiek izmantoti. To var izdarīt tieši ar SQL komandu VAKUUMS vai gaidiet, kamēr tabulu apstrādās automātiskais atkritumu savācējs - AUTOVAKUUMS. Tāpat līdz noteiktai versijai atkritumu savākšana bija saistīta ar statistikas apkopošanu (optimāla vaicājumu plāna sastādīšanai plānotājs izmanto datus par ierakstu skaitu tabulās un indeksēto lauku vērtību sadalījumu). No vienas puses, atkritumu savākšana jāveic tā, lai tabulas neaugtu un efektīvi neizmantotu diska vietu. No otras puses, pēkšņi sākta atkritumu savākšana rada papildu slodzi diskam un tabulām, kas noved pie vaicājuma izpildes laika palielināšanās. Līdzīgu efektu rada automātiska statistikas apkopošana (protams, to var palaist ar komandu ANALIZĒT vai kopā ar atkritumu savākšanu VAKUUMA ANALĪZE). Un, lai gan PostgreSQL uzlabo šos mehānismus no versijas uz versiju, lai samazinātu Negatīvā ietekme par veiktspēju (piemēram, iepriekšējās versijās atkritumu savākšana pilnībā bloķēja piekļuvi tabulai, kopš versijas 9.0 darbojas VAKUUMS paātrināts), šeit ir kaut kas jākonfigurē.

Autovakuumu var pilnībā atspējot ar šādu parametru:

autovakuums = izslēgts

Turklāt, lai Autovacuum darbotos, ir nepieciešams parametrs track_counts = on, pretējā gadījumā tas nedarbosies.

Pēc noklusējuma abas opcijas ir iespējotas. Patiesībā autovakuumu nevar pilnībā atslēgt - pat ar autovakuumu = izslēgts, dažreiz (pēc liela darījumu skaita) sāksies autovakuums.

komentēt: VAKUUMS parasti nesamazina tabulas faila lielumu, tikai atzīmē brīvās zonas, kas pieejamas atkārtotai izmantošanai. Ja vēlaties fiziski atbrīvot lieko vietu un samazināt aizņemto vietu diskā, jums būs nepieciešama komanda VAKUUMS PILNS. Šī opcija bloķē piekļuvi tabulai, kamēr tā darbojas, un parasti tā nav nepieciešama. Plašāku informāciju par komandas VACUUM lietošanu var atrast dokumentācijā (angļu valodā).

Ja automātiskais vakuums nav pilnībā atspējots, varat konfigurēt tā ietekmi uz vaicājuma izpildi, izmantojot šādus parametrus:

autovacuum_max_workers- maksimālais paralēli notiekošo tīrīšanas procesu skaits.

autovacuum_naptime - minimālais intervāls, par kuru mazāks autovakuums nesāksies. Noklusējums ir 1 minūte. Varat to palielināt, tad, ja dati mainās bieži, analīze tiks veikta retāk.

autovacuum_vacuum_threshold, - mainīto vai dzēsto ierakstu skaits tabulā, kas nepieciešams, lai sāktu atkritumu savākšanas procesu VAKUUMS vai vācot statistiku ANALIZĒT. Pēc noklusējuma ir 50.

autovacuum_vacuum_scale_factor , autovacuum_analyze_scale_factor - tabulas lieluma koeficients ierakstos, kas pievienoti autovacuum_vacuum_threshold Un autovacuum_analyze_threshold attiecīgi. Noklusējuma vērtības ir attiecīgi 0,2 (t.i., 20% no ierakstu skaita) un 0,1 (10%).

Apskatīsim piemēru ar tabulu ar 10 000 ierakstiem. Pēc tam ar noklusējuma iestatījumiem pēc 50+10000*0.1=1050 mainītiem vai dzēstiem ierakstiem tiks sākta statistikas vākšana ANALIZĒT, un pēc 2050. gada izmaiņām - atkritumu izvešana VAKUUMS.

Ja palielināsiet slieksni un scale_factor, uzturēšanas procesi darbosies retāk, bet mazas tabulas var ievērojami palielināties. Ja datubāze galvenokārt sastāv no mazām tabulām, kopējais diska vietas patēriņa pieaugums var būt ievērojams, tāpēc varat palielināt šīs vērtības, bet saprātīgi.

Tādējādi var būt lietderīgi palielināt intervālu autovacuum_naptime un nedaudz palielināt slieksni un skalas_faktoru. Ielādētās datu bāzēs var būt alternatīva ievērojami palielināt skalas_faktoru (vērtība 1 ļaus tabulām “uzbriest” divas reizes) un iestatīt plānotājam ikdienas izpildi. VAKUUMA ANALĪZE minimālas datu bāzes noslodzes periodos.

default_statistics_target - piešķir komandas savāktās statistikas apjomu ANALIZĒT. Noklusējuma vērtība ir 100. Lielākas vērtības palielina komandas ANALYZE izpildes laiku, bet ļauj plānotājam izveidot efektīvākus vaicājumu plānus. Ir ieteikumi palielināt līdz 300.

Veiktspēju var kontrolēt AUTOVAKUUMS, padarot to garāku, bet mazāk noslogojot sistēmu.

vacuum_cost_page_hit- “naudas soda” lielums bloka apstrādei, kas atrodas Share_buffers. Saistīts ar nepieciešamību bloķēt piekļuvi buferim. Noklusējuma vērtība 1

vacuum_cost_page_miss — "naudas soda" lielums bloka apstrādei diskā. Saistīts ar bufera bloķēšanu, datu meklēšanu buferī, datu nolasīšanu no diska. Noklusējuma vērtība 10

vacuum_cost_page_dirty- “naudas soda” lielums par bloka modifikāciju. Saistīts ar nepieciešamību atiestatīt modificētos datus diskā. Noklusējuma vērtība 20

Vacuum_cost_limit- maksimālais “naudas sodu” apjoms, pēc kura montāžas procesu var “iesaldēt” uz vakuuma_izmaksas_aizkavēšanās laiku. Noklusējums 200

vakuuma_izmaksu_aizkavēšanās- laiks “iesaldēt” atkritumu savākšanas procesu, sasniedzot vacuum_cost_limit. Noklusējuma vērtība 0ms

autovacuum_vacuum_cost_delay- laiks “iesaldēt” atkritumu savākšanas procesu autovakuumam. Noklusējums ir 20 ms. Ja iestatīts uz -1, tiks izmantota vērtība vacuum_cost_delay

autovacuum_vacuum_cost_limit- autovakuuma "naudas soda" maksimālais lielums. Noklusējuma vērtība -1 — tiek izmantota vacuum_cost_limit vērtība

Ziņots par lietošanu vacuum_cost_page_hit = 6, Vacuum_cost_limit = 100, autovacuum_vacuum_cost_delay = 200 ms samazina AUTOVACUUM ietekmi līdz pat 80%, bet trīskāršo tā izpildes laiku.

Diska ierakstīšanas iestatīšana

Kad transakcija ir pabeigta, PostgreSQL vispirms ieraksta datus īpašā transakciju žurnālā WAL (Write-ahead log), un pēc tam datu bāzē pēc tam, kad tiek garantēta žurnāla datu ierakstīšana diskā. Noklusējuma mehānisms ir fsync, kad PostgreSQL piespiedu kārtā izskalo datus (žurnālu) no OS diska kešatmiņas diskā, un tikai pēc veiksmīgas rakstīšanas (žurnāla) klients tiek informēts, ka transakcija ir veiksmīgi pabeigta. Darījumu žurnāla izmantošana ļauj pabeigt darījumu vai atjaunot datu bāzi, ja datu rakstīšanas laikā rodas kļūme.

Noslogotās sistēmās ar lielu rakstīšanas apjomu var būt lietderīgi pārvietot darījumu žurnālu uz atsevišķu fizisko disku (bet ne uz citu tā paša diska nodalījumu!). Lai to izdarītu, ir jāaptur DBVS, jāpārvieto pg_xlog direktorijs uz citu vietu un jāizveido simboliska saite vecajā vietā, piemēram, izmantojot utilītu junction. Far Manager (Alt-F6) var arī izveidot saites. Šajā gadījumā jums ir jāpārliecinās, vai jaunajai atrašanās vietai ir piekļuves tiesības lietotājam, kurš izmanto PostgreSQL (parasti postgres).

Ja ir daudz datu modifikācijas darbību, iespējams, būs jāpalielina vērtība checkpoint_segments, kas kontrolē datu apjomu, kas var gaidīt, līdz tie tiks pārsūtīti no žurnāla uz pašu datu bāzi. Noklusējuma vērtība ir 3. Jāņem vērā, ka žurnālam tiek atvēlēta vieta, kas aprēķināta pēc formulas (checkpoint_segments * 2 + 1) * 16 MB, kam ar vērtību 32 jau būs nepieciešams vairāk nekā 1 GB diska telpa.

PostgreSQL izskalo datus no OS failu kešatmiņas diskā pēc katra rakstīšanas transakcijas pabeigšanas. No vienas puses, tas garantē, ka dati diskā vienmēr ir atjaunināti, no otras puses, ar lielu darījumu skaitu, veiktspēja samazinās. Pilnībā atspējot fsync iespējams, norādot

fsync=off
full_page_writes = izslēgts

To var izdarīt tikai tad, ja 100% uzticaties aprīkojumam un UPS (avots nepārtrauktās barošanas avots). Pretējā gadījumā sistēmas avārijas gadījumā pastāv risks iegūt iznīcinātu datu bāzi. Un jebkurā gadījumā nenāktu par ļaunu arī RAID kontrolieris ar akumulatoru nerakstīto datu atmiņas barošanai.

Noteikta alternatīva varētu būt parametra izmantošana

synchronous_commit = izslēgts

Šādā gadījumā pēc veiksmīgas atbildes, lai pabeigtu darījumu, var paiet zināms laiks, līdz darījums tiek droši ierakstīts diskā. Pēkšņas izslēgšanas gadījumā datu bāze netiks iznīcināta, bet dati no nesenajiem darījumiem var tikt zaudēti.

Ja pilnībā neatspējojat fsync, parametrā varat norādīt sinhronizācijas metodi. Raksts no ITS diska attiecas uz utilītu pg_test_fsync, taču tas netika atrasts manā PostgreSQL būvējumā. Saskaņā ar 1C, viņu gadījumā operētājsistēmā Windows šī metode izrādījās optimāla open_datasync(acīmredzot, šī ir metode, kas tiek izmantota pēc noklusējuma).

Ja tiek izmantotas daudzas nelielas rakstīšanas transakcijas (1C gadījumā tas var būt direktorija masveida atjaunināšana ārpus darījuma), parametru commit_delay (darījuma pabeigšanas aizkaves laiks mikrosekundēs, noklusējuma 0) un commit_siblings (noklusējuma 5) kombinācija. var palīdzēt. Ja opcijas ir iespējotas, transakcijas pabeigšana var tikt aizkavēta ar commit_delay if Šis brīdis Ir izpildīti vismaz commit_siblings darījumi. Šajā gadījumā visu pabeigto darījumu rezultāts tiks rakstīts kopā, lai optimizētu ierakstīšanu diskā.

Citi parametri, kas ietekmē veiktspēju

wal_buffers- atmiņas apjoms share_buffers darījumu žurnālu uzturēšanai. Ieteikums: ja ir 1–4 GB pieejamās atmiņas, izmantojiet vērtības 256 KB–1 MB. Dokumentācijā teikts, ka, izmantojot vērtību "-1", vērtība tiek automātiski pielāgota atkarībā no share_buffers vērtības.

random_page_cost- nejaušas nolasīšanas “izmaksas”, ko izmanto, meklējot datus, izmantojot indeksus. Noklusējums ir 4.0. Vienība ir secīgas datu piekļuves laiks. Ātriem disku masīviem, īpaši SSD, ir lietderīgi samazināt vērtību; šajā gadījumā PostgreSQL aktīvāk izmantos indeksus.

Grāmatai saitē ir daži citi parametri, kurus var konfigurēt. Ir arī ļoti ieteicams izlasīt PostgreSQL dokumentāciju par konkrētu parametru piešķiršanu.

Ir ieteicams mainīt parametrus no sadaļas QUERY TUNING, īpaši tos, kas saistīti ar aizliegumu plānotājam izmantot noteiktas meklēšanas metodes, tikai tad, ja jums ir pilnīga izpratne par to, ko jūs darāt. Ir ļoti vienkārši optimizēt viena veida vaicājumus un sabojāt visu pārējo veiktspēju. Vairuma parametru maiņas efektivitāte šajā sadaļā ir atkarīga no datubāzē esošajiem datiem, šo datu vaicājumiem (t.i., cita starpā izmantotās 1C versijas) un DBVS versijas.

Secinājums

PostgreSQL ir jaudīga DBVS prasmīgās rokās, taču tai nepieciešama rūpīga konfigurēšana. To var izmantot kopā ar 1C un iegūt pienācīgu veiktspēju, un tā brīvais raksturs būs ļoti patīkams bonuss.

Apsveicami ir kritika un papildinājumi šim rakstam.

Noderīgas saites

http://postgresql.leopard.in.ua/ - grāmatu vietne " Darbs ar PostgreSQL konfigurāciju un mērogošanu ", manuprāt, vispilnīgākais un saprotamākais ceļvedis PostgreSQL konfigurēšanai un administrēšanai

http://etersoft.ru/products/postgre — šeit varat lejupielādēt ar 1C saderīgu PostgreSQL versiju operētājsistēmai Windows un dažādus Linux izplatījumus un versijas. Tiem, kuriem nav ITS abonementa vai kuriem nepieciešama versija Linux versija, kas nav parādīta vietnē v8.1c.ru.

http://www.postgresql.org/docs/9.2/static/ - oficiālā PostgreSQL dokumentācija (angļu valodā)

Raksti no ITS diska par PostgreSQL iestatīšanu

Raksta rediģēšanas vēsture

• 29.01.2015 - publicēta sākotnējā versija
• 31.01.2015 - raksts papildināts ar sadaļu AUTOVACUUM, pievienota saite uz oriģinālo dokumentāciju.

Nākotnē esmu iecerējis pārbaudīt DBVS darbību datu pievienošanas un maiņas režīmā.

Uzstādīsim kompāniju no Postgres Professional firmas. Lapā ar 1C:Enterprise versiju mēs atradīsim informāciju par jaunākās PostgreSQL versijas instalēšanu operētājsistēmā CentOS 7.

Savienosim krātuves un instalēsim PostgreSQL 9.6:

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

PostgreSQL pamata iestatīšana

Mēs inicializējam pakalpojumu datu bāzes ar lokalizāciju krievu valodā:

Su postgres /usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data --locale=ru_RU.UTF-8 izejas pakalpojuma postgresql-9.6 initdb

Palaidiet PostgreSQL pakalpojumu un pievienojiet to startēšanai:

Systemctl iespējot postgresql-9.6 systemctl start postgresql-9.6 systemctl statuss postgresql-9.6

Mēs uzstādījām postgres lietotāja paroli, lai varētu attālināti izveidot savienojumu ar serveri:

Su - postgres psql ALTER USER postgres AR KRIPTĒTU PAROLI "jūsu parole"; \q iziet

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

Atvērtajā failā atņemiet komentārus un mainiet rindas:

mitināt visu visu 127.0.0.1/32 ident ieslēgts mitināt visu 127.0.0.1/32 md5

mitināt visu visu 0.0.0.0/0 ident ieslēgts mitināt visu visu 0.0.0.0/0 md5

PostgreSQL iestatījumu optimizēšana (postgresql.conf) 1C:Enterprise

Šeit būs iestatījumi PostgreSQL, kas darbojas ESXi 6.5 virtuālajā mašīnā.

VM piešķirtie resursi:

procesors - 8 vCPU;

atmiņa - 48 GB;

disks operētājsistēmai - 50 GB uz LUN aparatūras RAID1 no SAS HDD;

disks datu bāzei - 170 GB programmatūras RAID1 no SSD

disks žurnāliem - 100 GB programmatūras RAID1 no SSD

Lai rediģētu iestatījumus, palaidiet komandu:

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

Komentētie parametri, kurus mainīsim, ir jāaktivizē.

Procesors

autovacuum_max_workers = 4

autovacuum_max_workers = NCore/4..2, bet ne mazāk kā 4

Autovakuuma procesu skaits. Vispārējais noteikums ir tāds, ka jo vairāk rakstīšanas pieprasījumu, jo vairāk procesu. Tikai lasāmā datu bāzē pietiek ar vienu procesu.

ssl=off

Izslēdziet šifrēšanu. Drošajos datu centros šifrēšana ir bezjēdzīga, taču tā palielina CPU slodzi

Atmiņa

Shared_buffers = 12 GB

Shared_buffers = RAM/4

Atmiņas apjoms, ko PgSQL atvēl koplietotajai lapas kešatmiņai. Šī atmiņa tiek koplietota starp visiem PgSQL procesiem. operētājsistēma Tas pats saglabā datus kešatmiņā, tāpēc kešatmiņai nav jāpiešķir visa pieejamā RAM.

temp_buffers = 256 MB

Maksimālais lappušu skaits pagaidu tabulām. Tie. šī ir augšējā robeža pagaidu tabulu izmēram katrā sesijā.

work_mem = 64 MB

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

Atmiņas ierobežojums viena pieprasījuma apstrādei. Šī atmiņa ir individuāla katrai sesijai. Teorētiski maksimālā nepieciešamā atmiņa ir vienāda ar max_connections * work_mem, praksē tas nenotiek, jo lielākā daļa sesiju gandrīz vienmēr gaida. Šo konsultatīvo vērtību izmanto optimizētājs: tas mēģina paredzēt vaicājumam nepieciešamās atmiņas lielumu, un, ja šī vērtība ir lielāka par work_mem, tas liek izpildītājam nekavējoties izveidot pagaidu tabulu. work_mem nav ierobežojums pilnā nozīmē: optimizētājs var palaist garām, un pieprasījums aizņems vairāk atmiņas, iespējams, daudzkārt vairāk. Šo vērtību var samazināt, pārraugot izveidoto pagaidu failu skaitu:

apkopes_darba_atmiņa = 2 GB

apkopes_darba_atmiņa = RAM/16..32 vai work_mem * 4 vai 256 MB..4 GB

Atmiņas ierobežojums uzturēšanas uzdevumiem, piemēram, statistikas apkopošanai (ANALĪZE), atkritumu savākšanai (VACUUM), indeksu izveidei (CREATE INDEX) un ārējo atslēgu pievienošanai. Šīm operācijām atvēlētās atmiņas apjomam jābūt salīdzināmam ar fiziskais izmērs lielākais indekss diskā.

efektīvas_kešatmiņas_izmērs = 36 GB

Effective_cache_size = RAM — share_buffers

Failu sistēmas kešatmiņas lieluma noteikšana. Parametra palielināšana palielina sistēmas tieksmi atlasīt IndexScan plānus. Un tas ir labi.

Diski

efektīvā_io_vienlaicība = 5

Vienlaicīgu pieprasījumu aprēķins diska sistēmai, ko tā var apkalpot vienā reizē. Vienam diskam = 1, RAID - 2 vai vairāk.

random_page_cost = 1,3

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

Maksa par nejaušas lapas lasīšanu (noklusējums — 4). Jo mazāks ir diska sistēmas meklēšanas laiks, jo mazākam (bet > 1.0) šim parametram jābūt. Pārāk liela parametra vērtība palielina PgSQL tendenci atlasīt plānus, kas skenē visu tabulu (PgSQL uzskata, ka ir lētāk lasīt visu tabulu secīgi, nevis nejauši lasīt indeksu). Un tas ir slikti.

autovacuum=ieslēgts

Autovakuuma ieslēgšana.

autovacuum_naptime = 20 s

Autovakuuma procesa miega laiks. Ja vērtība ir pārāk liela, tabulām nebūs laika vakuumā, un rezultātā palielināsies uzpūšanās un tabulu un indeksu lielums. Neliela vērtība radīs nevajadzīgu apkuri.

bgwriter_delay = 20 ms

Miega laiks starp fona rakstīšanas procesa diska rakstīšanas cikliem. Šis process ir atbildīgs par to lapu sinhronizēšanu ar disku, kas atrodas share_buffers. Pārāk liela šī parametra vērtība palielinās slodzi uz kontrolpunkta procesu un procesiem, kas apkalpo sesijas (aizmugursistēma). Neliela vērtība novedīs pie tā, ka viens no serdeņiem tiks pilnībā noslogots.

bgwriter_lru_multiplier = 4,0

bgwriter_lru_maxpages = 400

Opcijas, kas kontrolē fona ierakstīšanas procesa ierakstīšanas intensitāti. Vienā ciklā bgwriter raksta ne vairāk par to, kas tika uzrakstīts pēdējā ciklā, reizināts ar bgwriter_lru_multiplier, bet ne vairāk kā bgwriter_lru_maxpages.

synchronous_commit = izslēgts

Atspējot diska sinhronizāciju izpildes laikā. Rada risku zaudēt pēdējos darījumus (0,5-1 sekundes laikā), bet garantē datu bāzes integritāti, izpildes ķēdē nav spraugu. Bet tas ievērojami palielina produktivitāti.

wal_keep_segments = 256

wal_keep_segments = 32...256

Maksimālais WAL segmentu skaits starp kontrolpunktiem. Pārāk biežas kontrolpunkti rada ievērojamu rakstīšanas slodzi diska apakšsistēmā. Katrs segments ir 16 MB liels

wal_buffers = 16 MB

Koplietojamās atmiņas apjoms, kas tiks izmantots, lai buferētu WAL datus, kas vēl nav ierakstīti diskā. Noklusējuma vērtība -1 norāda izmēru, kas vienāds ar 1/32 (apmēram 3%) no , bet ne mazāk kā 64 KB un ne vairāk kā viena WAL segmenta lielums (parasti 16 MB). Šo vērtību var iestatīt manuāli, ja automātiski atlasītā vērtība ir pārāk maza vai liela, taču jebkurš pozitīvs skaitlis, kas mazāks par 32 KB, tiks uzskatīts par 32 KB. Šo parametru var iestatīt tikai servera startēšanas laikā.

WAL buferu saturs tiek ierakstīts diskā, kad tiek veikts katrs darījums, tāpēc ļoti lielas vērtības, visticamāk, nesniegs lielu labumu. Tomēr vismaz dažu megabaitu vērtība var uzlabot rakstīšanas veiktspēju aizņemtā serverī, kad daudzi klienti vienlaikus veic darījumus. Automātiskā noregulēšana, kas darbojas pēc noklusējuma vērtības (-1), vairumā gadījumu izvēlas saprātīgas vērtības.

noklusējuma_statistikas_mērķis = 1000

Iestata noklusējuma statistikas mērķa ierobežojumu, kas attiecas uz kolonnām, kurām ALTER TABLE SET STATISTICS nav norādījis atsevišķus ierobežojumus. Jo augstāka ir iestatītā vērtība, jo ilgāks laiks nepieciešams, lai palaistu ANALĪZI, taču jo augstāka var būt plānotāja aprēķinu kvalitāte. Šī parametra noklusējuma vērtība ir 100.

checkpoint_completion_target = 0,9

Kontrolpunkta “izsmērēšanas” pakāpe. Ierakstīšanas ātrums kontrolpunkta laikā tiek noregulēts tā, lai kontrolpunkta laiks būtu vienāds ar laiku, kas pagājis kopš pagātnes, reizināts ar kontrolpunkta_pabeigšanas_ mērķi.

min_wal_size = 4G
max_wal_size = 8G

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

Minimālais un maksimālais WAL failu lielums. Līdzīgi kā checkpoint_segments

fsync=on

Opcijas atspējošana palielina veiktspēju, taču pastāv ievērojams risks zaudēt visus datus, ja pēkšņi tiek izslēgta barošana. Uzmanību: ja RAID ir kešatmiņa un tas ir atpakaļrakstīšanas režīmā, pārbaudiet RAID kontrollera kešatmiņas akumulatora klātbūtni un funkcionalitāti! Pretējā gadījumā, izslēdzot barošanu, RAID kešatmiņā ierakstītie dati var tikt zaudēti, kā rezultātā PgSQL negarantē datu integritāti.

row_security = izslēgts

Ieraksta līmeņa izšķirtspējas kontroles atspējošana

enable_nestloop = izslēgts

Iespējo vai atspējo plānotāja ligzdotu cilpas pievienošanās plānu izmantošanu. Nav iespējams pilnībā novērst ligzdotās cilpas, taču, ja izslēgsit šo opciju, plānotājs to neizmantos šī metode, ja var piemērot citus. Pēc noklusējuma šis iestatījums ir ieslēgts.

Slēdzenes

max_locks_per_transaction = 256

Maksimālais indeksa/tabulas bloķēšanas skaits vienā darījumā

1C platformas iestatījumi

standard_conforming_strings = izslēgts

Atļaut \ rakstzīmi izmantot aizbēgšanai

escape_string_warning = izslēgts

Nebrīdiniet par rakstzīmes \ izmantošanu aizbēgšanai

Drošības iestatījumi

Pārliecināsimies, ka PostgreSQL serveris ir redzams tikai 1C: Enterprise serverim, kas instalēts tajā pašā mašīnā.

listen_addresses = 'localhost'

Ja 1C: Enterprise serveris ir instalēts citā mašīnā vai ir nepieciešams izveidot savienojumu ar DBMS serveri, izmantojot PGAdmin pievienojumprogrammu, tad tā vietā vietējais saimnieks jums jānorāda šīs iekārtas adrese.

Datu bāzes krātuve

PostgreSQL, tāpat kā gandrīz jebkura DBVS, ir kritiska diska apakšsistēmai, tāpēc, lai palielinātu DBVS veiktspēju, PostgreSQL sistēmu, žurnālus un pašas datu bāzes izvietosim dažādos diskos.

Servera apturēšana

Systemctl stop postgresql-9.6

Mēs pārsūtām žurnālus uz 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

Mēs arī pārsūtīsim direktoriju ar datu bāzēm:

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

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

Sāksim serveri un pārbaudīsim tā statusu

Systemctl start postgresql-9.6 systemctl statuss postgresql-9.6

Izmantot gadījumu kā PostgreSQL datu bāzes serveri Windows platforma nav īpaši populārs, bet tas parasti notiek, ja jums ir nepieciešams kaut kā ietaupīt naudu par produktiem no MS. Ir arī specializētas lietojumprogrammas, kas vislabāk darbojas ar PostgreSQL. 1c ir modificēts PostgreSQL būvējums, kas, kā apliecina izstrādātāji, nodrošina veiktspējas un kļūdu tolerances līmeni, kas ir salīdzināms ar MSSQL. Vai tiešām tā, pārbaudīsim praksē :)

1. Instalējiet PostgreSQL

Lejupielādējiet jaunāko PostgreSQL 64-bit 9.1.2-1.1C būvējumu no 1c vietnes, izpakojiet arhīvu, palaidiet msi pakotni, tai, kurai nav int, nav liela faila izmēra.

Noklikšķiniet uz Sākt.
Atstājiet instalēšanas opcijas kā noklusējuma iestatījumus.

Iestatiet lietotāja paroli postgres no kura sāksies pakalpojums . Noklikšķiniet uz Tālāk. Ja PostgreSQL instalējat pirmo reizi, vednis liks jums izveidot lietotāju postgres.

Datu bāzes inicializācijas posmā atlasiet UTF8 kodējumu. Iestatiet iekšējā postgres lietotāja pieteikumvārdu un paroli. Uzmanību! PostgreSQL pakalpojuma lietotāju paroles un iekšējā PostgreSQL datu bāzes lietotāja parole nedrīkst būt vienādas. Parolei jābūt vismaz četrām rakstzīmēm garai. Ja plānojat palaist 1C serveri un PostgreSQL dažādās iekārtās, jums ir jāatzīmē izvēles rūtiņa “Atbalstīt savienojumus no jebkura IP, nevis tikai vietējā resursdatora”. Noklikšķiniet uz Tālāk un vēlreiz vēlreiz. :)

Vēl divas reizes noklikšķiniet uz Tālāk un gaidiet, līdz instalēšana tiks pabeigta.

Pēc tam dodieties uz Sākt\Visas programmas\PostgreSQL 9.1.2-1.1C(x64). Palaidiet pgAdmin III administrēšanas utilītu. Mēģināsim izveidot savienojumu ar datu bāzi. Ievadiet paroli, ko norādījāt instalēšanas laikā.
Un mēs saņemam šādu kļūdu: Kļūda, veidojot savienojumu ar serveri: FATAL: paroles autentifikācija neizdevās lietotājam “postgres”.

Diezgan negaidīti, ņemot vērā, ka parole tika ievadīta pareizi. Nolēmu pasmelties ar pg_hba.conf, bet no pirmā acu uzmetiena tur viss ir kārtībā.

# TIPA DATU BĀZES LIETOTĀJA ADRESES METODE # IPv4 lokālie savienojumi: mitināt visus postgres::1/128 md5 mitināt visus postgres 127.0.0.1/32 md5 mitināt visus postgres 192.168.1.0/24 md5

Es nolēmu mainīt autorizācijas metodi no md5 uz uzticību. Es restartēju pakalpojumu un mēģinu vēlreiz izveidot savienojumu ar datu bāzi. Šoreiz es saņemu šo ziņu.
Patiešām, pgAdmin vietnē ir pieejams vairāk nekā viens jauna versija. Pēc kura savienojums ar datu bāzi ir veiksmīgs!!?!! Atceros, ka iepriekš md5 šādas problēmas nesagādāja, acīmredzot šis gļuks tiešām ir saistīts ar vecā versija pgAdmin.
Tagad mēs varam izveidot datubāzi 1C vajadzībām vai darīt to, izmantojot pašu 1C :)

2. Uzstādīšana 1C uzņēmums 8.2.

Instalēšanai mēs ņemam vērā šādus komponentus: 1C: Enterprise, 1C: Enterprise Server, Web servera paplašinājumu moduļi, 1C: Enterprise servera administrēšana.
Instalēšanas posmā “Instalēt 1C uzņēmumu kā pakalpojumu” mēs iestatījām lietotāja USR1C82 paroli.
Spied tālāk un seko instalācijas gaitai :) Lietotājam USR1CV82 Instalēšanas laikā ir jāpiešķir šādas tiesības:

Pieteikšanās kā pakalpojums (Pieteikties kā pakalpojumu), Pieteikties kā pakešu darbs (Piesakieties kā pakešu darbs). Jūs varat to apskatīt vietnē Lokālā datora politika\Datora konfigurācija\Windows iestatījumi\Drošības iestatījumi\Vietējās politikas\Lietotāja tiesību piešķīrumi.

Dosimies uz aprīkojumu 1C Enterprise serveru administrēšana, Mēs redzam, ka klasteris ir pieaudzis un karājas 1541. portā. Mūsu serveris atrodas arī cilnē “Darba serveri”. Tagad jūs varat pievienot datu bāzi 1C serverim. Lai to izdarītu, dodieties uz cilni " Informācijas bāzes"Ar peles labo pogu noklikšķiniet un atlasiet Jaunums - Informācijas bāze. Iestatiet nepieciešamos parametrus, lai izveidotu savienojumu ar PostgreSQL serveri. Noklikšķiniet uz Labi. Palaidīsim 1C: Enterprise. Mēs izvēlamies serverī pievienot esošu informācijas bāzi.
Pēc tam iestatiet savienojuma parametrus. Noklikšķiniet uz "Tālāk" un visbeidzot uz "Pabeigt".
Darbību, lai izveidotu datubāzi, var veikt tieši no 1C: Enterprise. Lai to izdarītu, startēšanas laikā atlasiet “Izveidot jaunu informācijas bāze».

Lai savienotu 1C klientus ar serveri no ārpuses un darbinātu datu bāzes serveri ugunsmūrī, ir jābūt atvērtiem šādiem portiem:

Servera aģents ( nikns) - tcp:1540 Galvenais klastera vadītājs ( rmngr) - tcp:1541 Tīkla portu klāsts dinamiskai darbinieku procesu izplatīšanai - tcp:1560-1591, tcp:5432 - Postgresql. Izveidosim noteikumu, izmantojot standarta saskarni vai izmantojot komandu:

netsh advfirewall ugunsmūris pievienot kārtulas nosaukums="1Cv8-Server" dir=in action=allow protocol=TCP localport=1540,1541,5432,1560-1590 enable=yes profile=JEBKURS remoteip=Jebkurš interfeisa tips=LAN

Tagad mēs varam viegli palaist 1C:Enterprise klientu no cita datora un pievienot esošo informācijas bāzi newdb. Neaizmirstiet par licencēm un programmatūras/aparatūras aizsardzību. Tagad mēs varam lejupielādēt Gilev testu un izmērīt mūsu sistēmas veiktspēju.

VirtualBox ierīcē ar 1 GB atmiņu, divkodolu 2,6 GHz, 319 izlaidumu 1c Gilev tests dod 11,42 punktus, kas ir aptuveni tikpat, cik CentOS. Uz 16.362 ir nedaudz vairāk par 11.60 punktiem. Iestatījumu optimizēšana, izmantojot EnterpriseDB Tuning Wizard, nedeva ievērojamu pieaugumu (11,66 un 11,62), lai gan kopumā tas var būt izdevīgi. :)

3. Regulārs darbs PostgreSQL serverī.

Dublējums.

Palaidiet pgAdmin III administrēšanas utilītu un ar peles labo pogu noklikšķiniet uz vajadzīgās datu bāzes. Izvēlieties "Dublēt".
Izvēlieties formātu (Pielāgots (saspiešanas līmenis no 0 līdz 9), Darva, Vienkāršs, Katalogs). Runājot par saspiešanas līmeni, vislabāk tiek saspiests jebkura saspiešanas līmeņa “pielāgots formāts”, pēc tam “direktorijs”, tad “vienkāršais” un visbeidzot “darva”. Mēs norādām UTF8 kodējumu, lomas nosaukums ir postgresql. Visas papildu opcijas atstājam kā noklusējuma iestatījumus. Noklikšķiniet uz pogas "Dublēt". Laukā “Ziņojumi” tiek parādīts visu veikto darbību saraksts ar pabeigšanas kodu. Ja 0, tad veiksme. Šeit jūs varat arī redzēt, kā no komandrindas palaist līdzīgu darbību.

F)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --ports 5432 --lietotājvārds "postgres" --role "postgres" --bez paroles --format custom --blobs --compress 9 --encoding UTF8 --verbose --fails "G:\Backups\gilev_dump.backup" "newdb"

Attiecīgi automātiskais skripts Rezerves kopija, ko pievienojam plānotājam, varētu izskatīties šādi:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --lietotājvārds "postgres" --role "postgres" --bez paroles --format custom --blobs --compress 9 --encoding UTF8 --verbose --fails "G:\Backups\gilev_dump_%date:~0.2%_%date:~3.2%_%date:~6.4% .backup" "newdb"

Atveseļošanās.

Lai atjaunotu, atlasiet datu bāzi, no kuras mēs vēlamies atjaunot datus rezerves kopija, vēlams tukšs. Ar peles labo pogu noklikšķiniet un atlasiet “Atkopšana”. Iestatiet dublējuma failu, lomas nosaukumu: postgres, noklikšķiniet uz “Atjaunot”
Izmantojot komandrindu:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_restore.exe" --host 192.168.1.200 --port 5432 --lietotājvārds "postgres" --dbname "testdb" --role "postgres" --nē -parole -- detalizēts "G:\Backups\gilev_dump_26_09_2012.backup"

kur testdb ir tukša datu bāze, kurā tiek atjaunots dublējuma arhīvs.

Apkopes darbības:

VAKUUMA komanda:

Secīgi attīra visas pašlaik pievienotās datu bāzes tabulas, dzēš pagaidu datus un atbrīvo vietu diskā. Visbiežāk komanda VACUUM tiek izpildīta precīzi, lai iegūtu maksimālu brīvas vietas diskā un palielinātu datu piekļuves ātrumu.

VAKUUMS— atzīmē vietu, ko aizņem ierakstu vecās versijas, kā brīvu. Šī komandas varianta izmantošana, kā likums, nesamazina tabulu saturošā faila lielumu, bet ļauj novērst tā nekontrolējamu augšanu, labojot to pieņemamā līmenī. Palaižot VACUUM, ir iespējama paralēla piekļuve apstrādātajai tabulai. Ir vairāki papildu opcijas izmantojot VAKUUMU: VACUUM FULL, VACUUM FREEZE, VACUUM ANALIZĒT.

VAKUUMS PILNS mēģina noņemt visas vecās ierakstu versijas un attiecīgi samazināt faila lielumu, kurā ir tabula. Šī komandas opcija pilnībā bloķē apstrādājamo tabulu.

VAKUUMSALSĒŠANA - Ja VACUUM FULL no tabulām noņem “atkritumus” un pārvieto ierakstus tā, lai tabulas kompakti novietotos diskā un sastāvētu no mazākā fragmentu skaita, savukārt saspiešana aizņem ilgu laiku un bloķē ierakstus, tad VACUUM FREEZE vienkārši noņem “atkritumus” no tabulas, bet paši ieraksti nepārvietojas, tāpēc tas ir ātrāk un nebloķē rakstīšanu. Šobrīd šo iespēju aizstāj autovakuums – automātiska atkritumu savākšana iekšā postgresql.conf kā arī vairākas papildu iespējas, kas paplašina funkcionalitāti:

autovacuum=ieslēgts# Iespējo automātisku atkritumu savākšanu.
log_autovacuum_min_duration = -1# Iestatot to uz nulli, tiek reģistrētas visas autovakuuma darbības. Mīnus viens (pēc noklusējuma) aizliedz izvadi žurnālā. Piemēram, ja iestatāt vērtību
vienāds ar 250 ms, tad visas automātiskās vakuuma un analīzes darbības, kas tiek veiktas 250 ms vai ilgāk, tiks reģistrētas. Šī iestatījuma iespējošana var būt noderīga autovakuuma izsekošanai.
Šo opciju var iestatīt tikai failā postgresql.conf vai failā komandrinda serveris.
autovacuum_naptime = 10 min# Laiks sekundēs, pēc kura datu bāzē tiek pārbaudīta atkritumu savākšanas nepieciešamība. Pēc noklusējuma tas notiek reizi minūtē.
autovacuum_vacuum_threshold= 1800 # Slieksnis dzēsto un modificēto ierakstu skaitam jebkurā tabulā, kuru pārsniedzot notiek atkritumu savākšana (VAKUUMS).
autovacuum_analyze_threshold= 900 # Slieksnis ievietoto, dzēsto un modificēto ierakstu skaitam jebkurā tabulā, kuru pārsniedzot tiek uzsākts analīzes process (ANALĪZE).
autovacuum_vacuum_scale_factor= 0,2 # Mainīto un dzēsto ierakstu procentuālā daļa attiecībā pret tabulu, virs kuras tiek aktivizēta atkritumu savākšana.
autovacuum_analyze_scale_factor= 0,1 # Tāds pats kā iepriekšējais mainīgais, bet attiecībā pret analīzi.
VAKUUMA ANALĪZE— Ja datu bāzē ir tabulas, kurās dati netiek mainīti vai dzēsti, bet tikai pievienoti, tad šādām tabulām var izmantot atsevišķu ANALYZE komandu. Šo komandu ir vērts izmantot arī atsevišķai tabulai pēc tam, kad tai ir pievienots liels skaits ierakstu.

ANALĪZĒT komanda:

Kalpo, lai atjauninātu informāciju par datu sadalījumu tabulā. Šo informāciju optimizētājs izmanto, lai atlasītu ātrāko vaicājumu izpildes plānu. Parasti komanda tiek izmantota kopā ar VAKUUMA ANALĪZE.

REINDEX komanda (pārindeksēšana):

Izmanto, lai atjaunotu esošos indeksus. Ir jēga to izmantot gadījumā

— indeksa bojājums;

- pastāvīgs tā lieluma pieaugums.

Otrais gadījums prasa zināmu skaidrojumu. Indekss, tāpat kā tabula, satur blokus ar vecām ierakstu versijām. PostgreSQL ne vienmēr var atkārtoti izmantot šos blokus, un tāpēc indeksa fails pakāpeniski palielinās. Ja dati tabulā bieži mainās, tie var pieaugt diezgan ātri. Ja pamanāt šādu indeksa darbību, jums tas jākonfigurē, lai periodiski palaistu komandu REINDEX. Lūdzu, ņemiet vērā: komanda REINDEX, tāpat kā VACUUM FULL, pilnībā bloķē tabulu, tāpēc tā ir jāizpilda, kad servera slodze ir minimāla.

Jautājums par to, kura DBVS - Postgresql vai MS SQL priekš 1C ir visoptimālākā - ir bijis daudzu rakstu temats. Šajā rakstā mēs apskatīsim abu optimizācijas darbības. Katra pārdevēja DBVS ir gan savi konfigurācijas ieteikumi, gan 1C ieteikumi. Jāņem vērā, ka atkarībā no aprīkojuma, servera konfigurācijas un lietotāju skaita, kas iestata dažādas slodzes, DBVS optimizācijas 1C un ieteikumu ieviešanas procesa detaļas var mainīties.

PostgreSQL iestatīšana operētājsistēmai 1C

Pieredze 1C datu bāzu darbībā PostgreSQL rāda, ka 1C un PostgreSQL visaugstākā veiktspēja un optimālā veiktspēja tika sasniegta operētājsistēmā Linux, tāpēc ieteicams to izmantot. Bet neatkarīgi no operētājsistēmas ir svarīgi atcerēties, ka PostgreSQL instalēšanas laikā norādītie noklusējuma iestatījumi ir paredzēti tikai DBVS servera palaišanai. Par jebkādu rūpniecisku ekspluatāciju nevar būt ne runas! Nākamais solis pēc palaišanas būs PostgreSQL optimizēšana 1C:

• Pirmkārt, mēs atspējojam enerģijas taupīšanu (pretējā gadījumā datu bāzes atbilžu aizkavēšanās var neparedzami palielināties) un aizliedzam koplietotās atmiņas apmaiņu.
• Mēs konfigurējam DBVS servera pamatparametrus (konfigurācijas ieteikumi ir pietiekami detalizēti aprakstīti gan pārdevēja oficiālajā vietnē, gan 1C, tāpēc mēs koncentrēsimies tikai uz svarīgākajiem).
• Uzņēmuma 1C standarta ieteikumi iesaka atspējot HyperThreading mehānismus. Taču Postgres-pro testēšana serveros ar iespējotu SMT (vienlaicīga vairāku pavedienu veidošana) uzrādīja dažādus rezultātus.

Share_buffers iestatīšana uz RAM/4 ir noklusējuma ieteikums, taču Sql Server piemērs liecina, ka jo vairāk atmiņas tam tiek atvēlēts, jo labāka ir tā veiktspēja (ar atspējotu lapas skalošanu). Tas ir, jo vairāk datu lapu atrodas RAM, jo mazāk piekļuves diskam. Rodas jautājums: kāpēc tik maza kešatmiņa? Atbilde ir vienkārša: ja share_buffers ir liels, tad dažas neizmantotās lapas tiek nomainītas uz disku. Bet kā izsekot brīdim, kad atiestatīšana apstājas un parametru indikators ir optimāls? Lai sasniegtu un sasniegtu optimālo share_buffers indikatoru, tā vērtība ražošanā katru dienu (ja iespējams) ar noteiktu soli jāpaaugstina un jāskatās, kurā brīdī lapas sāks izskalot diskā (swap palielināsies).

Turklāt “lielo parametru” negatīvi ietekmē darbs ar daudzām mazām lapām, kuru izmērs pēc noklusējuma ir 8 Kb. Darbs ar viņiem palielina pieskaitāmās izmaksas. Ko ar to var darīt, lai optimizētu 1C? PostgreSQL 9.4 ieviesa parametru huge_pages, ko var iespējot, bet tikai operētājsistēmā Linux. Pēc noklusējuma ir iekļautas lielas lapas ar noklusējuma izmēru 2048 kB. Turklāt šo lapu atbalstam jābūt iespējotam operētājsistēmā. Tādējādi, optimizējot krātuves struktūru, jūs varat sasniegt lielāku share_buffers indikatoru.

work_mem = RAM/32..64 vai 32MB...128MB Iestata katras sesijas atmiņas apjomu, kas tiks izmantots iekšējām šķirošanas, sapludināšanas u.c. darbībām pirms pagaidu failu izmantošanas. Ja šis apjoms tiek pārsniegts, serveris izmantos pagaidu failus diskā, kas var ievērojami samazināt pieprasījumu apstrādes ātrumu. Šis parametrs tiek izmantots, izpildot operatorus: ORDER BY, DISTINCT, merge joins utt.

Aprēķiniet papildus šis parametrs var izdarīt šādi: (Shared memory shared_buffers - atmiņa citām programmām) / aktīvo savienojumu skaits. Šo vērtību var samazināt, uzraugot izveidoto pagaidu failu skaitu. Šādu statistiku par pagaidu failu lielumu un skaitu var iegūt no pg_stat_database sistēmas skata.

Effective_cache_size = RAM — shared_buffers Šī parametra galvenais mērķis ir norādīt vaicājuma optimizētājam, kuru datu izguves metodi izvēlēties: pilnu skenēšanu vai indeksa skenēšanu. Jo augstāka ir parametra vērtība, jo lielāka ir indeksa skenēšanas izmantošanas iespējamība. Šajā gadījumā serveris neņem vērā, ka dati var palikt atmiņā, izpildot pieprasījumu, un nākamajam pieprasījumam nav nepieciešams tos izgūt no diska.

PostgreSQL instalēšana

1C instalēšana vietnē PostgreSQL operētājsistēmā Windows ir diezgan vienkāršs process. Palaižot instalācijas pakotni, jānorāda UTF-8 kodējums. Faktiski šī ir vienīgā interesantā nianse, un nav nepieciešama papildu PostgreSQL 1C 8.3 konfigurācija no Windows. PostgreSQL instalēšana un konfigurēšana operētājsistēmai 1C operētājsistēmā Linux OS var radīt vairākas grūtības. Lai tos pārvarētu, piemēram, apsveriet iespēju palaist (izmantojot izplatīšanas komplektus no vadošā Krievijas pārdevēja PostgreSQL-Pro un uzņēmuma 1C) PostgreSQL Ubuntu 16.04 x64 serverī.

1C izplatīšanas komplektu uzstādīšana PostgreSQL DBVS

1. Lejupielādējiet norādīto PostgreSQL DBMS izplatīšanas komplekta pozīciju:

2. Augšupielādēt PostgreSQL serverī;

3. Varat izpakot PostgreSQL DBVS instalēšanas programmu, izmantojot komandu:

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

4. Pirms PostgreSQL DBMS izplatīšanas komplekta instalēšanas pārbaudīsim, vai sistēmā ir vajadzīgā lokalizācija (pēc noklusējuma ru_RU.UTF-8):

5. Ja sistēma, ar kuru darbosies PostgreSQL, ir instalēta valodā, kas nav krievu valoda, jums ir jāizveido jaunas lokalizācijas:

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

6. Ja vajadzīgā lokalizācija joprojām ir pieejama, instalējiet to pēc noklusējuma:

locale –a nano /etc/default/locale Aizstāt saturu ar LANG=ru_RU.UTF-8

7. Pēc atsāknēšanas instalējiet mūsu PostgreSQL versijai nepieciešamās pakotnes:

apt-get install libxslt1.1 ssl-cert

8. PostgreSQL pakotnes versija 9.4.2-1.1C ir saistīta ar libicu pakotnes versiju libicu48. Nepieciešamās versijas repozitorijā vairs nav, bet jūs varat to lejupielādēt;

9.Lejupielādēt un ievietot direktorijā, kurā tiek glabāti lejupielādētie PostgreSQL faili;

10. Dodoties uz direktoriju ar PostgreSQL failiem, mēs veicam instalēšanu, secīgi ierakstot šādas komandas:

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.1Client-common_154.1.1C_all.de.com b 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-64.Cdeb_2-1.1.

11. Gatavs. PostgreSQL DBMS izplatīšanas komplekts ir instalēts.

PostgreSQL-Pro izplatījumu instalēšana

Lai instalētu serveri, jums ir jāizpilda šādas komandas pēc kārtas:

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

Lai piekļūtu serverim, rediģējiet failā esošos parametrus 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"

Pašam failam ir šāda struktūra:

Fails ir labi dokumentēts, bet angļu valoda. Īsi apskatīsim galvenos parametrus:

• Vietējais vietējais savienojums tikai caur unix
• Uzņēmēja TCP/IP savienojums
• Hostsslšifrēts SSL savienojums caur TCP/IP (serveris jāveido ar SSL atbalstu, jāiestata arī ssl parametrs)
• Hostnossl nešifrēts savienojums, izmantojot TCP/IP

• uzticēties atzīt bez autentifikācijas
• noraidīt atteikties bez autentifikācijas
• parole skaidras teksta paroles pieprasījums
• md5 paroles pieprasījums MD5 formā
• ldap lietotājvārda un paroles pārbaude, izmantojot LDAP serveri
• rādiuss Lietotājvārda un paroles pārbaude, izmantojot RADIUS serveri
• pam lietotājvārda un paroles pārbaude, izmantojot spraudņa pakalpojumu

Detalizētāku un detalizētāku informāciju var atrast PostgreSQL produkta dokumentācijā.

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

Pēc pamata instalēšanas pabeigšanas jums ir jākonfigurē konfigurācijas fails serveris postgresql.conf, atbilstoši PostgreSQL, 1C servera un Ubuntu servera konfigurācijas specifikai.

1C optimizācija MS SQL Server

Uzstādīt Jaunākie atjauninājumi SQL serverim.

Operētājsistēma rezervē vietu un aizpilda to ar nullēm, kas prasa diezgan ilgu laiku šādos gadījumos:

• Datu bāzes izveide;
• Datu failu, darījumu žurnāla pievienošana esošai datu bāzei;
• Esoša faila lieluma palielināšana (ieskaitot Autogrow darbības);
• Mēs atjaunojam datu bāzes vai failu grupas.

Tiek lemts šī problēma lomas (kurā darbojas serveris) pievienošana vienumam vietējā politika apsardze "Veikt apjoma uzturēšanas uzdevumus."

Ja iespējams, ir nepieciešams izplatīt TempDB datubāzi (īpaši intensīvi tā tiek izmantota RCSI pārvaldītajā bloķēšanas režīmā) un darījumu žurnālu dažādos diskos.

Serverī, kur tas darbojas SQL serveris, enerģijas taupīšanas režīmam jābūt iestatītam uz "High Performance".

Mape ar datu bāzes failiem nedrīkst būt saspiesta.

Servera cilnē “Atmiņa” mēs iestatījām minimālo līmeni uz 50% no kopējās atmiņas. Mēs aprēķinām maksimālo, izmantojot vienu no formulām:

• Maksimālā atmiņa = kopējais apjoms - izmērs atbilstoši OS - izmērs 1C (ja tāds ir, iepriekš mērot ar skaitītājiem izmantoto atmiņu) vai
• Maksimālā atmiņa = kopējais lielums – (1024* Kopējais lielums/16384).

Mēs ierobežojam DOP parametru “Maksimālā paralēlisma pakāpe” un iestatām to uz “1”.

Atjauninām statistiku saskaņā ar grafiku. Sākot ar SQL serveris 2008, statistikas atjaunināšana izraisa vaicājumu pārkompilēšanu un attiecīgi iztīra procesuālo kešatmiņu, tāpēc nav nepieciešams veikt atsevišķu procedūru, lai notīrītu procesuālo kešatmiņu.

Mēs periodiski pārindeksējam tabulu un defragmentējam indeksus.

Mēs izveidojam pareizu rezervēšanas politiku. Ja jums nav nepieciešams atkopties līdz pēdējam laika punktam pirms sistēmas avārijas un pēdējās 5 minūtes vai vairāk nav svarīgas jūsu uzņēmumam, iestatiet atkopšanas modeli uz “Vienkāršs”. Tas ievērojami paātrinās ierakstīšanas ātrumu. Galvenais ir tas, ka diferencēto dublēšanu var pabeigt noteiktajā laikā.

Mēs panākam uzlabojumus darbā ar TempDB I/O laikā, izveidojot papildu datu failus. Ja ir mazāk nekā 8 loģiskie procesori, ieteicams katram loģiskajam procesoram izveidot datu failu. Ja ir vairāk nekā 8 loģiskie procesori, ieteicams izveidot 8 datu failus un, palielinot par vienu reizinā ar 4, noteikti novērtējiet TempDB slodzi.

1 Nov 2012 Brīvi izplatītas izmantošanas priekšrocības programmatūra acīmredzams. Diemžēl arī trūkumi ir acīmredzami - nav oficiāla atbalsta, dokumentācija bieži ir pretrunīga, nepilnīga un izkaisīta. dažādi avoti. Šis raksts palīdzēs izprast PosgreSQL instalēšanas procesu 1C:Enterprise 8, izvairoties no kļūmēm, kas nav aprakstītas oficiālajā dokumentācijā.

Nepieciešamās sastāvdaļas uzstādīšanai

PostgreSQL DBVS tiek izplatīta bez maksas un ir iekļauta 1C lietojumprogrammu servera piegādes komplektā. 1C:Enterprise 8 lietojumprogrammu serverim ir divas versijas: 32 bitu un 64 bitu. Postgre var tikt galā ar abiem.

Tātad, mums ir pieejami izplatīšanas komplekti:

• Postgre: postgresql-9_1_2-1_1Cx64.zip, laipni nodrošina 1C.
• 1C:Enterprise lietojumprogrammu servera izplatīšana operētājsistēmai Windows x64, versija 8.2.16.368.

Šķiet, ka tas nevar būt vienkāršāk - vienkārši palaidiet un instalējiet. Viegli! Bet instalēšana standarta režīmā radīs nelielu ierobežojumu: klasteris atradīsies mapē “Programmu faili”. Ne visiem tas patiks. Apsvērsim divas instalēšanas iespējas — vienkāršu un progresīvu.

Raksts ir sadalīts 5 sadaļās:

1) 1C servera uzstādīšana.

2) Instalējiet PostgreSQL standarta formā, kas ir pietiekama, lai palaistu 1C bez papildu iestatījumiem.

3) Instalējiet PostgreSQL un atlasiet klastera krātuves mapi.

4) Jaunas 1C informācijas bāzes izveide.

5) Norāda mapi datu bāzes failu glabāšanai DBVS serverī.

Pirms instalēšanas noteikti izlasiet visu rakstu!

1C lietojumprogrammu servera uzstādīšana

Mēs palaižam setup.exe no mapes ar 1C servera izplatīšanas komplektu.

Ja lietojumprogrammu serveri instalējat nevis kā pakalpojumu, tas katru reizi būs jāsāk manuāli. Šī opcija ir nepieciešama reti. Mēs to instalējam kā pakalpojumu un izlemjam, kuram lietotājam tas tiks palaists. Drošības apsvērumu dēļ labāk ir izveidot atsevišķu lietotāju USR1CV82, nevis ļaut pakalpojumam darboties ar pilnām tiesībām.

Pēc lietojumprogrammu servera instalēšanas sistēma liks instalēt HASP aizsardzības atslēgas draiveri. Mēs piekrītam:

Gaidām ziņu:

Ja ziņojums atšķiras, visticamāk, sistēmā ir palikušas “astes” no iepriekšējām HASP draiveru instalācijām. Izdzēsiet tos visus un mēģiniet vēlreiz.

Gatavs, mēs esam veiksmīgi instalējuši 1C:Enterprise 8 lietojumprogrammu serveri.

PostgreSQL instalēšana standarta formā, kas ir pietiekama, lai palaistu 1C bez papildu iestatījumiem

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

Jums nav jāmaina instalēšanas opcijas, darbosies 1C. Tālāk.

Postgre, tāpat kā 1C serveris, pats var izveidot lietotāju, ar kuru jūs darbināsit pakalpojumu. Es vēršu jūsu uzmanību uz to, ka, ja norādāt konts ar administratora tiesībām pakalpojums nedarbosies pareizi. Noteikti izveidojiet jaunu lietotāju.

Nākamais instalācijas logs.

Mēs inicializējam klasteru. Ja mūsu datu bāzes serveris un 1C lietojumprogrammu serveris atrodas uz dažādi datori, pēc tam atzīmējiet izvēles rūtiņu “Atbalstīt savienojumus no jebkura IP”, pretējā gadījumā mēs tai nepieskaramies. Noteikti norādiet UTF8 kodējumu. Izveidojiet DBVS superlietotāju. Tālāk…

Sākotnējam darbam mums nekas nav nepieciešams, noņemiet atzīmi no izvēles rūtiņas un pabeidziet instalēšanu.

Mūsu pūļu rezultāts ir lietošanai gatavs PostgreSQL. Ja esam apmierināti, ka datu bāzes atradīsies programmā Program Files\PostgreSQL\9.1.2-1.1C\data, mēs tur beidzam, atveram datu bāzes un izbaudām procesu. Tomēr biežāk datu bāzes “guļ” uz īpaši izstrādātiem disku masīviem, nevis uz sistēmas disks. Lai konfigurētu datu atrašanās vietu, lūdzu, pirms instalēšanas izlasiet šo sadaļu.

Postgre instalēšana, izvēloties klastera krātuves vietu

Mēs turpinām instalēt Postgre un veicam visas darbības, līdz tiek piedāvāts inicializēt klasteru:

Noņemiet atzīmi no izvēles rūtiņas "Inicializēt datu bāzes kopu" un noklikšķiniet uz "Tālāk".

Jā, mēs esam pārliecināti.

Noņemiet atzīmi no izvēles rūtiņas “Palaist Stack Builder pēc iziešanas” un pabeidziet instalēšanu.

1. Ir nepieciešams piešķirt visas tiesības mapei, kurā mēs instalējām PostgreSQL, parasti tas ir C:\Program Files\PostgreSQL

2. Palaidiet cmd kā administratoru. Ja to darāt operētājsistēmā win7, palaidiet to kā administratoru.

3. Izveidojiet mapi, kurā tiks saglabāts klasteris. Piemēram, d:\postgredata.

md d:\postgredata

4. Mēs inicializējam klasteru manuāli, norādot ceļu, kur tas atradīsies.

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

5. Noņemiet PostgreSQL pakalpojumu, kas tika instalēts instalēšanas laikā.

sc izdzēst pgsql-9.1.2-1.1C-x64

Kur pgsql-9.1.2-1.1C-x64 ir pakalpojuma nosaukums. Ja precīzi nezināt nosaukumu, varat apskatīt pakalpojuma “PostgreSQL datu bāzes serveris...” rekvizītus (Sākt - Vadības panelis - Administratīvie rīki - Pakalpojumi)

6. Izveidot jauns pakalpojums norādot mūsu kopu

“C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\pg_ctl” reģistrs -N pgsql -U postgresql -P parole -D d:/postgredata

7. Tagad ejam uz servisiem. Sākt – Vadības panelis – Administrēšana – Pakalpojumi un sāciet mūsu pakalpojumu.

Jaunas 1C datu bāzes izveide serverī ar PostgreSQL

Ir vairākas datu bāzes izveides iespējas. Varat mēģināt izveidot datu bāzi, izmantojot pgAdmin3, 1C servera administrēšanas konsoli. Bet šeit jūs saskarsies ar daudz nesaprotamu jautājumu un kļūdu gūzmu, uz kurām atbildes ilgi meklēsiet. Atstājiet to ekspertiem. Mūsu mērķis ir iegūt darba bāzi ar minimālu piepūli. Aprakstīsim vienkāršāko veidu, kā to panākt.

Mēs palaižam 1C klientu.

Noklikšķiniet uz "Pievienot...".

Mēs izstrādājam datu bāzes nosaukumu, pēc tam norādiet “1C: Enterprise serverī”.

Serveru klasteris 1C:Uzņēmums– localhost, ja mēs veidojam datu bāzi tajā pašā datorā, kurā ir instalēts 1C serveris, vai 1C lietojumprogrammu servera nosaukums, ja tas ir citā.

Informācijas bāzes nosaukums klasterī- turpmāk šis nosaukums tiks norādīts, pieslēdzoties no citiem datoriem.

DBVS tips– Atlasiet PostgreSQL.

Datu bāzes serveris- norādiet PostgreSQL servera nosaukumu. Ja mēs izveidojam datu bāzi serverī, mēs norādām arī localhost.

Datu bāzes nosaukums– ar šo nosaukumu tiks izveidota datu bāze programmā PostgreSQL.

Lietotājs, parole– tā lietotāja vārds, kuru norādījām kā superlietotāju, instalējot PostgreSQL. Noteikti atzīmējiet izvēles rūtiņu “Izveidot datu bāzi, ja tā neeksistē”.

Rodas jautājums – kur fiziski tiks glabāta datubāze? Norādītā klastera mapē Base. Ko darīt, ja mēs nevēlamies, lai tas atrodas tur, kur atrodas visas bāzes? Mēs vēl neko nevaram darīt, mēs vienkārši izveidosim bāzi un turpināsim. Tālāk…

Datu bāzes krātuves mapes norādīšana

Tātad, mēs esam izveidojuši bāzi. Vairumā gadījumu šī ir vieta, kur instalēšana beidzas. Tomēr, ja datu bāzu ir daudz un ir vairāki disku masīvi dažādām datu bāzu grupām, ir jānorāda, kur datu bāzēm fiziski jāatrodas. Lai to izdarītu, palaidiet pgAdmin3 no Sākt - Programmas - PostgreSQL. Izveidojiet savienojumu ar mūsu serveri.

Kad pirmo reizi izveidojat savienojumu, Postgre prasīs paroli postgres lietotājam (to mēs izveidojām instalēšanas laikā).

Mēs izveidojam jaunu TableSpace, šī būs mape, kurā tiks glabātas mūsu datu bāzes.

Norādīja datu bāzes failu glabāšanas vietu. LABI.

Tagad atveram iepriekš izveidotās datu bāzes rekvizītus, kuru atrašanās vietu vēlamies mainīt.

Mainiet rekvizītu Tablespace. Pēc noklikšķināšanas uz "OK", datu bāzes faili tiks automātiski pārvietoti. Gatavs! Mēs ceram, ka raksts jums bija noderīgs. Ja tā, atstājiet komentārus un kopīgojiet saites uz šo lapu. Paldies!