Энэ нийтлэл нь PostgreSQL-ийн бүх тохиргооны сонголтуудын бүрэн танилцуулга биш бөгөөд харьцуулсан тестийн хувьд би мэдээллийн сангийн бүх үйлдлийн горимыг хамруулаагүй болно. Сонирхсон хүмүүст линкээр орж номыг судлахыг зөвлөж байна

Оршил

Би PostgreSQL-тэй маш их ажилласан бөгөөд үүнийг маш сайн DBMS гэж боддог. Би маш их хэмжээний өгөгдлийг шууд боловсруулдаг олон гигабайтын мэдээллийн сантай (1С биш). PostgreSQL нь индексүүдийг маш сайн ашигладаг, зэрэгцээ ачааллыг даван туулдаг, хадгалагдсан процедурын ажиллагаа маш сайн, удирдлага, гүйцэтгэлийн сайн хэрэгслүүд байдаг бөгөөд олон нийтийн зүгээс үүнийг бий болгосон. ашигтай хэрэгслүүд. Гэхдээ 1С-ийн олон администраторууд PostgreSQL-ийн талаар муу бодолтой байдаг, энэ нь удаан бөгөөд өгөгдлийн сангийн файлын хувилбараас бараг давж гардаггүй, зөвхөн MSSQL л нөхцөл байдлыг аварч чадна гэдгийг мэдээд би гайхсан.

Асуултыг судалсны дараа би Линукс болон Windows дээр даммидад зориулж PostgreSQL-ийг алхам алхмаар суулгах талаар олон нийтлэл олсон. Гэхдээ нийтлэлүүдийн дийлэнх нь "суулгах - мэдээллийн бааз үүсгэцгээе" хүртэл суулгацыг тайлбарласан бөгөөд тохиргооны асуудлыг огт хөндөхгүй. Үлдсэн хэсэгт тохиргоог зөвхөн "ийм утгыг зааж өгөх" түвшинд дурдсан бөгөөд яагаад гэдгийг бараг тайлбарлаагүй болно.

Хэрэв "нэг товчлуураар суулгах" арга нь MSSQL болон ерөнхийдөө Windows-д зориулсан олон бүтээгдэхүүнд хамааралтай бол харамсалтай нь PostgreSQL-д хамаарахгүй. Анхдагч тохиргоо нь санах ойн хэрэглээг ихээхэн хязгаарладаг тул та үүнийг тооцоолуур дээр ч суулгаж болох бөгөөд энэ нь бусад програм хангамжийн үйл ажиллагаанд саад учруулахгүй. PostgreSQL нь тодорхой системд тохируулагдсан байх ёстой бөгөөд зөвхөн тэр үед л хамгийн сайнаараа харуулах боломжтой. Ялангуяа хүнд тохиолдолд та PostgreSQL, мэдээллийн баазын тохиргоог тааруулж болно Файлын систембие биенээ, гэхдээ энэ нь Линукс системд илүү хамаатай бөгөөд бүх зүйлийг өөрчлөх боломж илүү байдаг.

1С-ийн хувьд DBMS хөгжүүлэгчдийн PostgreSQL угсралт нь тохиромжгүй, зөвхөн засварласан 1C эх кодуудаас угсардаг гэдгийг санах нь зүйтэй. Бэлэн нийцтэй угсралтыг 1С (ITS диск болон дэмжлэгийн захиалгатай хүмүүсийн дансаар) болон EterSoft санал болгодог.

Туршилтыг онд хийсэн Windows орчин, гэхдээ бүх тохиргооны зөвлөмжүүд нь платформд хамаарахгүй бөгөөд аливаа үйлдлийн системд хамаарна.

Туршилт ба харьцуулалт

Туршилт хийхдээ би бүх үйлдлийн горим, хувилбарт туршилт хийхээр зорьсонгүй, зөвхөн амжилттай тохируулсан эсэхийг шалгасан.

Туршилтын хувьд би дараах тохиргоог ашигласан:
Хост машин: Win7, Core i5-760 2.8MHz, 4 цөм, 12GB RAM, VMWare 10
Виртуал: Win7 x64, 2 цөм, 4 ГБ RAM, тусдаа физик HDDөгөгдлийн санг байршуулах (SSD биш)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
1С 8.3.5 1383

Өгөгдлийн санг ашигласан, dt-upload 780MB.
Өгөгдлийн санг сэргээсний дараа:
Файлын хувилбар дахь файлын хэмжээ 1CD - 10 ГБ,
PostgreSQL мэдээллийн сангийн хэмжээ - 8 ГБ,
MSSQL мэдээллийн сангийн хэмжээ 6.7 ГБ.

Туршилтын хувьд би янз бүрийн бүртгэлээс нэмэлт дэлгэрэнгүй мэдээлэл бүхий эсрэг талын гэрээний түүвэр (21к) хүсэлтийг ашигласан; гэрээ тус бүрийн хувьд бүртгэлээс тусдаа дээж хийсэн. Би Нягтлан бодох бүртгэлийн 3.0-ийн үндсэн дээр маш их өөрчлөгдсөн тохиргоог авсан.

Туршилтын явцад тогтвортой үр дүнд хүрэх хүртэл би нэг болон хоёр үйлчлүүлэгчтэй хүсэлтийг хэд хэдэн удаа явуулсан. Би эхний гүйлтүүдийг үл тоомсорлов.

Нэг үйлчлүүлэгчтэй туршилт хийх:

SSD - 31c дээр байрлуулсан мэдээллийн сан бүхий файлын хувилбараас хост дээр түүвэрлэлт
Файлын хувилбараас сонгож байна виртуал машин(хамт хатуу диск) - 46с
MSSQL мэдээллийн сангаас дээж авах - эхний дамжуулалт - 25 секунд эсвэл 9 секунд (DBMS кэшийн хамаарлаас хамааран) (DBMS процессын санах ойн хэрэглээ ойролцоогоор 1.3 ГБ байсан)
Өгөгдмөл тохиргоотой PostgreSQL-ээс дээж авах - 43 секунд (санах ойн хэрэглээ нь холболт бүрт 80 МБ-аас хэтрэхгүй)
Оновчтой PostgreSQL-ээс дээж авах - 21 секунд (санах ойн хэрэглээ нь холболт бүрт 120 МБ байсан)

Хоёр үйлчлүүлэгчтэй туршилт хийх:

SSD дээр байрлуулсан мэдээллийн баазтай файлын хувилбараас хост дээр түүвэрлэх - тус бүр 34 секунд
Виртуал машин дахь файлын хувилбараас дээж авах (хатуу дискнээс) - тус бүр 56 секунд
MSSQL мэдээллийн сангаас дээж авах - 50 эсвэл 20 секунд (DBMS кэшийн хамаарлаас хамааран)
PostgreSQL-ээс анхдагч тохиргоотой дээж авах - тус бүр нь 60 секунд
Оновчтой PostgreSQL-ээс дээж авах - тус бүр нь 40 сек

Туршилтын тэмдэглэл:

1. Гурав дахь цөмийг нэмсний дараа PostgreSQL болон MSSQL хувилбарууд нь "хоёр үйлчлүүлэгч" тестэд бараг "нэг үйлчлүүлэгч" тестийн гүйцэтгэлээр ажиллаж эхэлсэн, жишээлбэл. амжилттай зэрэгцүүлсэн. Хоёр цөм дээр зэрэгцэн ажиллахад юу саад болсон нь миний хувьд нууц хэвээр үлдэв.
2. MSSQL нэг дор их хэмжээний санах ой эзэлдэг, PostgreSQL нь бүх горимд хамаагүй бага шаарддаг бөгөөд асуулга бөглөсний дараа бараг бүгдийг нь гаргасан.
3. MSSQL нь нэг процесс хэлбэрээр ажилладаг. PostgreSQL нь холболт + үйлчилгээний процесс бүрт тусдаа процессыг эхлүүлдэг. Энэ нь 32 битийн хувилбарт хүртэл олон үйлчлүүлэгчийн хүсэлтийг боловсруулахдаа санах ойг үр ашигтай ашиглах боломжийг олгодог.
4. Доор үзүүлсэн утгуудаас дээш тохиргоонд PostgreSQL-ийн санах ойг нэмэгдүүлэх нь гүйцэтгэлийн мэдэгдэхүйц өсөлтөд хүргэсэнгүй.
5. Бүх тохиолдолд эхний туршилтууд дараагийн хэмжилтээс илүү удаан үргэлжилсэн; Би ямар ч тусгай хэмжилт хийгээгүй боловч MSSQL субьектив байдлаар илүү хурдан эхэлсэн.

PostgreSQL-г тохируулж байна

PostgreSQL-ийг тохируулах, оновчтой болгох талаар орос хэл дээр маш сайн ном бий: Заанд дурлагч хүн бүр энэ холбоосыг хавчуурга хийх нь утгагүй юм. Энэ номонд DBMS-ийг оновчтой болгох, алдааг тэсвэрлэх чадвартай, тархсан системийг бий болгох олон арга техникийг тайлбарласан болно. Харин одоо бид хүн бүрт хэрэг болох зүйлийг авч үзэх болно - санах ойн ашиглалтыг тохируулах. PostgreSQL нь тохиргооны зөвшөөрснөөс илүү санах ой ашиглахгүй бөгөөд өгөгдмөл тохиргоотой PostgreSQL хамгийн бага санах ой ашигладаг. Үүний зэрэгцээ та ашиглах боломжтой хэмжээнээс илүү санах ойг зааж өгөх ёсгүй - систем нь серверийн гүйцэтгэлд үзүүлэх бүх сөрөг үр дагавар бүхий своп файлыг ашиглаж эхэлнэ. PostgreSQL-ийг тохируулах хэд хэдэн зөвлөмжийг ITS диск дээр өгсөн болно.

Windows дээр PostgreSQL тохиргооны файлууд нь өгөгдлийн лавлах дахь суулгалтын санд байрладаг.

• postgresql.conf- DBMS тохиргоо бүхий үндсэн файл
• pg_hba.conf- үйлчлүүлэгчдэд зориулсан хандалтын тохиргоо бүхий файл. Ялангуяа, эндээс та ямар хэрэглэгчид ямар IP хаягаар тодорхой мэдээллийн санд холбогдох боломжтой, хэрэглэгчийн нууц үгийг шалгах шаардлагатай эсэх, хэрэв байгаа бол ямар аргаар зааж өгч болно.
• pg_ident.conf- хэрэглэгчийн нэрийг системээс дотоод руу хөрвүүлэх файл (ихэнх хэрэглэгчдэд хэрэггүй байх магадлалтай)

Файлууд нь текст бөгөөд та тэдгээрийг тэмдэглэлийн дэвтэр ашиглан засах боломжтой. -ээр эхэлсэн мөрүүд # сэтгэгдэл гэж тооцогдох ба үл тоомсорлодог.

Санах ойн багтаамжтай холбоотой параметрүүдийг кБ, МБ, ГБ дагаваруудаар нэмж болно - килобайт, мегабайт, гигабайт, жишээлбэл, 128 МБ. Цагийн интервалыг тодорхойлсон параметрүүдийг ms, s, min, h, d - миллисекунд, секунд, минут, цаг, хоног, жишээлбэл, 5мин дагавараар нэмж болно.

Хэрэв та Postgress-ийн нууц үгээ мартсан бол энэ нь ямар ч асуудалгүй, та үүнийг бичиж болно pg_hba.confмөр:

Бүх 127.0.0.1/32 итгэлийг хүлээн авна уу

Мөн дурын хэрэглэгчээр холбогдоно (жишээ нь, postgres) нууц үгээ шалгахгүйгээр 127.0.0.1 утсан дээрх дотоод машин дээрх DBMS руу.

Оновчлолсанах ойн хэрэглээ

Санах ойн ашиглалтын тохиргоонууд дотор байрладаг postgresql.conf

Оновчтой параметрийн утга нь чөлөөт эзэлхүүнээс хамаарна санамсаргүй хандалт санах ой, мэдээллийн баазын хэмжээ болон мэдээллийн сангийн бие даасан элементүүд (хүснэгт ба индексүүд), асуулгын нарийн төвөгтэй байдал (зарчмын хувьд асуулга нь нэлээд төвөгтэй байх болно гэж үзэх хэрэгтэй - асуулгад олон холболт хийх нь ердийн хувилбар юм) болон тоо. нэгэн зэрэг идэвхтэй үйлчлүүлэгчид. Дашрамд хэлэхэд PostgreSQL нь мэдээллийн сангийн хүснэгт, индексүүдийг хадгалдаг тусдаа файлууд (<каталог установки PG>\өгөгдлийн\бааз\<идентификатор БД>\), объектын хэмжээг тооцоолж болно. Та мөн багтсан pgAdmin хэрэгслийг ашиглан өгөгдлийн санд холбогдож, "Схемүүд" - "нийтийн" хэсгийг өргөжүүлж, "Хүснэгтүүд" элементийн статистикийн тайланг үүсгэж болно.

Дараа нь би тааруулж эхлэх боломжтой ойролцоо утгыг өгөх болно. Дараа нь анхны тохиргооСерверийг үйлдлийн горимд ажиллуулж, санах ойн зарцуулалтыг хянахыг зөвлөж байна. Хүлээн авсан үр дүнгээс хамааран параметрийн утгыг тохируулах шаардлагатай байж болно.

Серверийг туршихаар тохируулахдаа би дараах тооцоонд тулгуурласан.
Зөвхөн 4 ГБ RAM. Хэрэглэгчид - Windows үйлдлийн систем, 1С сервер, PostgreSQL болон системийн дискний кэш. DBMS-д 2.5 ГБ хүртэлх RAM-г хуваарилж болно гэж би таамагласан

Утгыг kB, MB, GB (килобайт, мегабайт эсвэл гигабайт дахь утга) дагавараар зааж өгч болно. Утгыг өөрчилсний дараа та PostgreSQL үйлчилгээг дахин эхлүүлэх хэрэгтэй.

shared_buffers - Хуваалцсан серверийн буфер

Бүх холболтын хуваалцсан PostgreSQL унших, бичих кэшийн хэмжээ. Хэрэв өгөгдөл кэшэд байхгүй бол түүнийг дискнээс уншина (OS-д хадгалсан байж магадгүй)

Хэрэв буферийн хэмжээ нь байнга ашиглагддаг ажлын өгөгдлийг хадгалахад хангалтгүй бол үүнийг үйлдлийн системийн кэш эсвэл дискнээс байнга бичиж, унших бөгөөд энэ нь гүйцэтгэлд маш сөрөг нөлөө үзүүлэх болно.

Гэхдээ энэ нь ажиллахад шаардагдах бүх санах ой биш, та хэт их зүйлийг зааж өгөх ёсгүй их ач холбогдол, эс тэгвээс үйлчлүүлэгчийн хүсэлтийг бодитоор гүйцэтгэх (мөн олон байх тусам санах ойн хэрэглээ их байх болно), OS болон бусад програмууд, жишээлбэл, 1С серверийн процесст санах ой үлдэхгүй. Сервер нь мөн үйлдлийн системийн кэш дээр тулгуурладаг бөгөөд системд хадгалагдсан хамгийн их магадлалтай зүйлийг буферт хадгалахгүй байхыг хичээдэг.

Ашигласан тест

хуваалцсан_буфер = 512 МБ

ажлын_ми- эрэмбэлэх, өгөгдлийг нэгтгэх гэх мэт санах ой.

Хүсэлт бүрт хуваарилагдсан, магадгүй нарийн төвөгтэй хүсэлтийн хувьд хэд хэдэн удаа. Хэрэв хангалттай санах ой байхгүй бол PostgreSQL түр зуурын файлуудыг ашиглах болно. Хэрэв утга нь хэтэрхий том байвал RAM-г хэтрүүлэн ашиглаж, үйлдлийн систем нь гүйцэтгэлийн бууралтаар своп файлыг ашиглаж эхэлнэ.

Тооцоолохдоо санах ойн хэмжээг хасах зөвлөмж байдаг хуваалцсан_буфер, мөн нэгэн зэрэг гүйцэтгэсэн хүсэлтийн тоонд хуваана. Нарийн төвөгтэй асуулгын хувьд хуваагчийг нэмэгдүүлэх хэрэгтэй, i.e. үр дүнг багасгах. Хэлэлцэж буй хэргийн хувьд 5 идэвхтэй хэрэглэгч (2.5ГБ-0.5ГБ (хуваалцсан_буфер))/5=400МБ дээр үндэслэсэн. Хэрэв DBMS нь асуулгыг нэлээд төвөгтэй гэж үзвэл эсвэл нэмэлт хэрэглэгчид гарч ирвэл утгыг багасгах шаардлагатай болно.

Энгийн асуулгын хувьд жижиг утгууд хангалттай байдаг - хоёр мегабайт хүртэл, гэхдээ нарийн төвөгтэй асуулгад (мөн энэ нь 1С-ийн ердийн хувилбар) илүү их зүйл шаардагдана. Зөвлөмж - 1-4 ГБ санах ойн хувьд та 32-128 МБ-ын утгыг ашиглаж болно. Би үүнийг туршилтанд ашигласан

ажлын_мем = 128MB

засвар үйлчилгээний_ажлын_сан- хог цуглуулах команд, статистик, индекс үүсгэх санах ой.

Энэ утгыг хамгийн том хүснэгт эсвэл индексийн хэмжээнээс 50-75% -д тохируулахыг зөвлөж байна, гэхдээ систем болон програмуудыг ажиллуулах хангалттай санах ойтой болно. work_mem-ээс их утгыг тохируулахыг зөвлөж байна. Би үүнийг туршилтанд ашигласан
засвар үйлчилгээний_мем = 192MB

temp_buffers- түр зуурын объектуудад зориулсан буфер, голчлон түр зуурын хүснэгтэд зориулагдсан.

Та ойролцоогоор 16 MB суулгаж болно. Би үүнийг туршилтанд ашигласан
temp_buffers = 32MB

үр дүнтэй_кэшийн_хэмжээ- файлын системийн дискний кэшийн ойролцоо хэмжээ.

Оновчлогч нь кэш (хурдан санамсаргүй хандалттай) эсвэл удаан диск дээр өгөгдөл олдох магадлалыг тооцоолохын тулд асуулгын төлөвлөгөөг бүтээхдээ энэ утгыг ашигладаг. Windows-д кэшэд хуваарилагдсан санах ойн одоогийн хэмжээг ажлын менежерээс харж болно.

Автовакуум - "хог цуглуулах"

PostgreSQL нь "хувилбартай" DBMS-ийн ердийн төлөөлөгчийн хувьд (блоклохоос ялгаатай нь) өгөгдлийг өөрчлөх үед хүснэгт, бүртгэлийг унших гүйлгээг бие даан хориглодоггүй (1С-ийн хувьд 1С сервер өөрөө үүнийг хийдэг). Үүний оронд өөрчилсөн бичлэгийн хуулбарыг үүсгэсэн бөгөөд энэ нь дараагийн гүйлгээнд харагдах бөгөөд одоо байгаа нь гүйлгээний эхэнд байсан өгөгдлийг үргэлжлүүлэн хардаг. Үүний үр дүнд хуучирсан өгөгдөл хүснэгтэд хуримтлагддаг - өмнөх хувилбаруудбичлэгүүдийг өөрчилсөн. DBMS суллагдсан зайг ашиглахын тулд аль бүртгэлийг ашиглахаа больсоныг тодорхойлохын тулд "хог цуглуулах" ажлыг хийх шаардлагатай. Үүнийг SQL командын тусламжтайгаар тодорхой хийж болно ВАКУМ, эсвэл автомат хог цуглуулагчаар хүснэгтийг боловсруулахыг хүлээх - АВТО ВАКУМ. Мөн тодорхой хувилбар гарах хүртэл хог цуглуулах нь статистик цуглуулахтай холбоотой байсан (төлөвлөгч нь асуулгын оновчтой төлөвлөгөөг бий болгохын тулд хүснэгт дэх бичлэгийн тоо, индексжүүлсэн талбаруудын утгын тархалтын талаархи мэдээллийг ашигладаг). Нэг талаас, хүснэгтүүд ургахгүй, дискний зайг үр ашигтай ашиглахын тулд хог цуглуулах ёстой. Нөгөөтэйгүүр, гэнэт эхэлсэн хог цуглуулах нь диск болон хүснэгтэд нэмэлт ачаалал өгдөг бөгөөд энэ нь асуулга гүйцэтгэх хугацааг нэмэгдүүлэхэд хүргэдэг. Үүнтэй төстэй нөлөөг автомат статистик цуглуулах замаар бий болгодог (мэдээж үүнийг тушаалаар эхлүүлж болно ШИНЖИЛГЭЭэсвэл хог цуглуулахтай хамт ВАКУМ ШИНЖИЛГЭЭ). PostgreSQL нь эдгээр механизмыг аль болох багасгахын тулд хувилбараас хувилбар болгон сайжруулдаг Сөрөг нөлөөгүйцэтгэлийн талаар (жишээлбэл, өмнөх хувилбаруудад хог цуглуулах нь 9.0 хувилбараас хойш хүснэгтэд хандах хандалтыг бүрэн хаасан. ВАКУМхурдасгасан), энд тохируулах зүйл байна.

Та дараах параметрээр автомат вакуумыг бүрэн идэвхгүй болгож болно.

autovacuum = унтраах

Мөн Autovacuum ажиллахын тулд track_counts = on параметр шаардлагатай, эс тэгвээс ажиллахгүй.

Анхдагч байдлаар, хоёр сонголт идэвхжсэн байна. Үнэн хэрэгтээ автовакуумыг бүрэн идэвхгүй болгох боломжгүй - autovacuum = унтраалттай байсан ч заримдаа (олон тооны гүйлгээний дараа) автовакуум эхлэх болно.

Сэтгэгдэл: ВАКУМихэвчлэн хүснэгтийн файлын хэмжээг багасгадаггүй, зөвхөн дахин ашиглах боломжтой чөлөөт хэсгийг тэмдэглэдэг. Хэрэв та илүүдэл зайг биечлэн чөлөөлж, эзэлсэн дискний зайг багасгахыг хүсвэл тушаал хэрэгтэй болно ВАКУМ ДҮҮРЭН. Энэ сонголт нь хүснэгтийг ажиллаж байх үед түүнд хандах хандалтыг блоклодог бөгөөд ихэвчлэн шаардлагагүй байдаг. VACUUM командыг ашиглах талаар дэлгэрэнгүй мэдээллийг баримтаас (англи хэл дээр) олж болно.

Хэрэв Autovacuum бүрэн идэвхгүй бол та дараах параметрүүдийг ашиглан асуулгын гүйцэтгэлд үзүүлэх нөлөөг тохируулж болно.

autovacuum_max_workers- зэрэгцээ ажиллаж байгаа цэвэрлэх үйл явцын хамгийн их тоо.

autovacuum_naptime - автовакуум эхлэхгүй байх хугацаанаас бага хамгийн бага интервал. Өгөгдмөл нь 1 минут. Та үүнийг нэмэгдүүлэх боломжтой, хэрэв өгөгдөл байнга өөрчлөгдвөл дүн шинжилгээ хийх нь бага байх болно.

автовакуум_вакуум_босго, - Хог цуглуулах үйл явцыг эхлүүлэхэд шаардагдах хүснэгтэд байгаа өөрчилсөн эсвэл устгасан бичлэгийн тоо ВАКУМэсвэл статистик мэдээлэл цуглуулах ШИНЖИЛГЭЭ. Өгөгдмөл нь 50.

autovacuum_vacuum_scale_factor , автовакуум_шинжилгээний_масштаб_хүчин зүйл - нэмэгдсэн бүртгэл дэх хүснэгтийн хэмжээсийн коэффициент автовакуум_вакуум_босгоТэгээд автовакуум_шинжилгээний босготус тус. Өгөгдмөл утга нь тус тус 0.2 (жишээ нь бичлэгийн 20%) ба 0.1 (10%) байна.

10,000 бичлэг бүхий хүснэгтийн жишээг авч үзье. Дараа нь өгөгдмөл тохиргоотойгоор 50+10000*0.1=1050 өөрчилсөн эсвэл устгасан бичлэгийн дараа статистик цуглуулах ажлыг эхлүүлнэ. ШИНЖИЛГЭЭ, 2050 оны өөрчлөлтийн дараа - хог цуглуулах ВАКУМ.

Хэрэв та босго болон масштабын_факторыг нэмэгдүүлбэл засвар үйлчилгээний үйл явц бага ажиллах боловч жижиг хүснэгтүүд мэдэгдэхүйц өсөх болно. Хэрэв мэдээллийн сан нь үндсэндээ жижиг хүснэгтүүдээс бүрддэг бол дискний зайны хэрэглээний нийт өсөлт нь мэдэгдэхүйц байж болох тул та эдгээр утгыг нэмэгдүүлэх боломжтой, гэхдээ ухаалгаар.

Тиймээс автовакуум_унтах хугацааны интервалыг нэмэгдүүлж, босго болон масштабын_факторыг бага зэрэг нэмэгдүүлэх нь зүйтэй болов уу. Ачаалагдсан өгөгдлийн санд энэ нь scale_factor-ийг (1-ийн утга нь хүснэгтийг хоёр удаа "хавах" боломжийг олгоно) мэдэгдэхүйц өсгөж, өдөр тутмын гүйцэтгэлийг хуваарьт тохируулах хувилбар байж болно. ВАКУМ ШИНЖИЛГЭЭмэдээллийн баазын хамгийн бага ачаалалтай үед.

default_statistics_target - командаар цуглуулсан статистикийн хэмжээг онооно ШИНЖИЛГЭЭ. Өгөгдмөл утга нь 100. Том утга нь ANALYZE командыг гүйцэтгэх хугацааг ихэсгэх боловч хуваарь гаргагчид илүү үр дүнтэй асуулгын төлөвлөгөө гаргах боломжийг олгоно. 300 хүртэл нэмэгдүүлэх зөвлөмж байгаа.

Гүйцэтгэлийг хянах боломжтой АВТО ВАКУМ, уртасгах боловч системд стресс багатай болгодог.

вакуум_зардлын_хуудас_цохилт- shared_buffers-д байрлах блокыг боловсруулах "торгуулийн" хэмжээ. Буферт хандах хандалтыг хаах хэрэгцээтэй холбоотой. Өгөгдмөл утга 1

vacuum_cost_page_miss - дискэн дээрх блок боловсруулах "торгуулийн" хэмжээ. Буферийг хаах, буфер доторх өгөгдлийг хайх, дискнээс өгөгдлийг уншихтай холбоотой. Өгөгдмөл утга 10

вакуум_зардлын_хуудас бохир- блокийн өөрчлөлтийн "торгуулийн" хэмжээ. Өөрчлөгдсөн өгөгдлийг диск рүү дахин тохируулах хэрэгцээтэй холбоотой. Өгөгдмөл утга 20

вакуум_зардлын_хязгаар- вакуум_зардлын саатлын хугацаанд угсрах үйл явцыг "царцаах" боломжтой "торгуулийн" дээд хэмжээ. Өгөгдмөл 200

вакуум_зардлын саатал- вакуум_зардлын_хязгаарт хүрэхэд хог цуглуулах үйл явцыг "царцаах" хугацаа. Өгөгдмөл утга 0мс

автовакуум_вакуум_зардлын саатал- автовакуумд зориулж хог цуглуулах үйл явцыг "хөлдөөх" цаг. Өгөгдмөл нь 20 мс. Хэрэв -1 гэж тохируулсан бол вакуум_зардлын_хоцролтыг ашиглана

автовакуум_вакуум_зардлын_хязгаар- автовакуумд зориулсан "торгуулийн" дээд хэмжээ. Өгөгдмөл утга -1 - vacuum_cost_limit утгыг ашигласан

Мэдээлсэн ашиглалт вакуум_зардлын_хуудас_цохилт = 6, вакуум_зардлын_хязгаар = 100, autovacuum_vacuum_cost_delay = 200ms AUTOVACUUM-ийн нөлөөллийг 80% хүртэл бууруулдаг боловч гүйцэтгэлийн хугацааг гурав дахин нэмэгдүүлдэг.

Дискний бичлэгийг тохируулж байна

Гүйлгээ дууссаны дараа PostgreSQL эхлээд тусгай гүйлгээний бүртгэлд WAL (Урьдчилан бичих бүртгэл) өгөгдлийг бичиж, дараа нь бүртгэлийн өгөгдөл диск рүү бичигдэх баталгаатай болсны дараа мэдээллийн санд бичдэг. Анхдагч механизм нь fsync, PostgreSQL нь үйлдлийн системийн дискний кэшээс өгөгдлийг (лог) диск рүү хүчээр устгаж, амжилттай бичиж (лог) хийсний дараа гүйлгээ амжилттай дууссан тухай үйлчлүүлэгчид мэдэгддэг. Гүйлгээний бүртгэлийг ашигласнаар өгөгдөл бичих явцад алдаа гарсан тохиолдолд гүйлгээг дуусгах эсвэл мэдээллийн санг сэргээх боломжтой.

Их хэмжээний бичих хэмжээ бүхий завгүй системүүдэд гүйлгээний бүртгэлийг тусдаа физик диск рүү шилжүүлэх нь зүйтэй болов уу (гэхдээ нэг дискний өөр хэсэг рүү биш!). Үүнийг хийхийн тулд та DBMS-ийг зогсоож, pg_xlog санг өөр байршил руу зөөж, хуучин байршилд симбол холбоос үүсгэх хэрэгтэй, жишээлбэл, уулзвар хэрэгслийг ашиглан. Far Manager (Alt-F6) нь мөн холбоос үүсгэх боломжтой. Энэ тохиолдолд та шинэ байршил нь PostgreSQL (ихэвчлэн postgres) ажиллаж байгаа хэрэглэгчдэд хандах эрхтэй эсэхийг шалгах хэрэгтэй.

Хэрэв олон тооны өгөгдөл өөрчлөх үйлдлүүд байгаа бол бүртгэлээс мэдээллийн сан руу шилжүүлэхийг хүлээх өгөгдлийн хэмжээг хянадаг checkpoint_segments утгыг нэмэгдүүлэх шаардлагатай. Өгөгдмөл утга нь 3. Бүртгэлд зайг (checkpoint_segments * 2 + 1) * 16 MB томъёогоор тооцдог бөгөөд 32-ын утга нь 1 ГБ-аас илүү диск шаардагдах болно. зай.

PostgreSQL нь бичих гүйлгээ бүрийн дараа OS файлын кэшээс өгөгдлийг диск рүү устгадаг. Нэг талаас, энэ нь диск дээрх өгөгдөл байнга шинэчлэгдэж байх баталгаа болж өгдөг бол нөгөө талаас олон тооны гүйлгээ хийснээр гүйцэтгэл буурдаг. Бүрэн идэвхгүй болгох fsyncзааж өгснөөр боломжтой

fsync=унтраах
бүтэн_хуудас_бичих = унтраах

Хэрэв та тоног төхөөрөмж болон UPS-д 100% итгэдэг бол үүнийг хийх боломжтой тасралтгүй цахилгаан хангамж). Үгүй бол систем эвдэрсэн тохиолдолд устгагдсан мэдээллийн санг авах эрсдэлтэй. Ямар ч тохиолдолд бичигдээгүй өгөгдлийн санах ойг цэнэглэх зайтай RAID хянагч бас гэмтэхгүй.

Тодорхой хувилбар бол параметрийг ашиглах явдал юм

synchronous_commit = унтраах

Энэ тохиолдолд гүйлгээг амжилттай хийж дуусгасны дараа гүйлгээг дискэнд аюулгүйгээр бичих хүртэл хэсэг хугацаа шаардагдана. Гэнэт унтарсан тохиолдолд мэдээллийн сан устахгүй, харин сүүлийн үеийн гүйлгээний өгөгдөл алдагдах магадлалтай.

Хэрэв та fsync-ийг бүрэн идэвхгүй болгохгүй бол синхрончлолын аргыг параметрт зааж өгч болно. ITS дискний нийтлэл нь pg_test_fsync хэрэглүүрийг хэлж байгаа боловч миний PostgreSQL-д олдсонгүй. 1С-ийн үзэж байгаагаар тэдний хувьд Windows-д энэ арга нь хамгийн оновчтой болохыг харуулсан нээлттэй_өгөгдлийн синк(энэ нь анхдагч байдлаар ашиглагддаг арга юм бололтой).

Хэрэв олон жижиг бичих гүйлгээг ашиглаж байгаа бол (1С-ийн хувьд энэ нь гүйлгээний гадна байгаа лавлахыг бөөнөөр нь шинэчлэх байж болно), commit_delay (гүйлгээг дуусгах саатлын хугацаа микросекунд, анхдагч 0) болон commit_siblings (анхдагч 5) параметрүүдийн хослол. туслаж чадна. Сонголтуудыг идэвхжүүлсэн үед гүйлгээг дуусгах нь commit_delay тохиолдолд хойшлогдож болзошгүй Энэ мөчЯдаж commit_siblings гүйлгээ хийгдсэн. Энэ тохиолдолд бүх дууссан гүйлгээний үр дүнг дискний бичлэгийг оновчтой болгохын тулд хамт бичнэ.

Гүйцэтгэлд нөлөөлдөг бусад үзүүлэлтүүд

Wal_buffers- гүйлгээний бүртгэл хөтлөх хуваалцсан_буфер дэх санах ойн хэмжээ. Зөвлөмж: 1-4ГБ санах ойтой бол 256KB-1MB-ын утгыг ашиглана уу. Баримт бичигт "-1" утгыг ашиглах нь share_buffers-ийн утгаас хамааран утгыг автоматаар тохируулдаг гэж заасан.

санамсаргүй_хуудасны_зардал- индекс ашиглан өгөгдөл хайхад ашигладаг санамсаргүй унших "зардал". Өгөгдмөл нь 4.0. Нэгж нь өгөгдөлд дараалсан хандалтын хугацаа юм. Хурдан дискний массив, ялангуяа SSD-ийн хувьд утгыг бууруулах нь зүйтэй бөгөөд энэ тохиолдолд PostgreSQL индексүүдийг илүү идэвхтэй ашиглах болно.

Холбоос дээрх номонд тохируулж болох бусад параметрүүд байна. Мөн тодорхой параметрүүдийг хуваарилах PostgreSQL баримт бичгийг уншихыг зөвлөж байна.

QUERY TUNING хэсгээс параметрүүдийг өөрчлөхийг зөвлөж байна, ялангуяа хуваарь гаргагчийг хайлтын тодорхой аргуудыг ашиглахыг хориглохтой холбоотой параметрүүдийг зөвхөн юу хийж байгаа талаар бүрэн ойлголттой бол өөрчлөхийг зөвлөж байна. Нэг төрлийн асуулгыг оновчтой болгож, бусад бүх асуултын гүйцэтгэлийг сүйтгэх нь маш хялбар юм. Энэ хэсгийн ихэнх параметрүүдийг өөрчлөх үр нөлөө нь мэдээллийн сан дахь өгөгдөл, энэ өгөгдлийн хүсэлт (жишээлбэл, ашигласан 1С хувилбар гэх мэт) болон DBMS-ийн хувилбараас хамаарна.

Дүгнэлт

PostgreSQL бол чадварлаг гарт байгаа хүчирхэг DBMS боловч нарийн тохиргоо шаарддаг. Үүнийг 1С-тэй хамт хэрэглэж, зохих гүйцэтгэлийг олж авах боломжтой бөгөөд түүний үнэгүй шинж чанар нь маш сайхан урамшуулал болно.

Энэ нийтлэлд шүүмжлэл, нэмэлт өөрчлөлт оруулахыг урьж байна.

хэрэгтэй холбоосууд

http://postgresql.leopard.in.ua/ - номын вэбсайт " PostgreSQL тохиргоо болон масштабтай ажиллах ", миний бодлоор PostgreSQL-ийг тохируулах, удирдахад зориулсан хамгийн бүрэн гүйцэд бөгөөд ойлгомжтой гарын авлага.

http://etersoft.ru/products/postgre - эндээс та Windows-д зориулсан PostgreSQL-ийн 1С-тэй нийцтэй хувилбар болон Linux-ийн төрөл бүрийн түгээлт, хувилбаруудыг татаж авах боломжтой. ITS-д бүртгүүлээгүй эсвэл хувилбар шаарддаг хүмүүст зориулагдсан Линукс хувилбар, үүнийг v8.1c.ru дээр танилцуулаагүй болно.

http://www.postgresql.org/docs/9.2/static/ - PostgreSQL дээрх албан ёсны баримт бичиг (англи хэл дээр)

PostgreSQL-ийг тохируулах тухай ITS дискний нийтлэлүүд

Нийтлэл засварласан түүх

• 01/29/2015 - анхны хувилбарыг нийтэлсэн
• 2015 оны 01-р сарын 31 - нийтлэлийг AUTOVACUUM-ийн тухай хэсэгт нэмж, анхны баримт бичгийн холбоосыг нэмж оруулсан болно.

Цаашид DBMS-ийн ажиллагааг өгөгдөл нэмэх, өөрчлөх горимд туршиж үзэх бодолтой байна.

Бид Postgres Professional компаниас угсралт суурилуулах болно. 1C: Enterprise-ийн хувилбартай хуудаснаас бид PostgreSQL-ийн хамгийн сүүлийн хувилбарыг CentOS 7 дээр суулгах тухай мэдээллийг олж авах болно.

Хадгалах газруудыг холбож, PostgreSQL 9.6-г суулгацгаая:

Sudo rpm -ivh http://1c.postgrespro.ru/keys/postgrespro-1c-centos96.noarch.rpm sudo yum makecache sudo yum postgresql-pro-1c-9.6 суулгах

PostgreSQL-н үндсэн тохиргоо

Бид Оросын нутагшуулалттай үйлчилгээний мэдээллийн санг эхлүүлдэг.

Su postgres /usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data --locale=ru_RU.UTF-8 гарах үйлчилгээ postgresql-9.6 initdb

PostgreSQL үйлчилгээг эхлүүлж, эхлүүлэхэд нэмнэ үү:

Systemctl postgresql-9.6-г идэвхжүүлнэ systemctl postgresql-9.6-г эхлүүлэх systemctl статус postgresql-9.6

Бид серверт алсаас холбогдохын тулд postgres хэрэглэгчдэд нууц үг тохируулсан:

Su - postgres psql ALTER USER postgres WITH INCRYPT PASWORD "yourpassword"; \q гарах

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

нээгдэх файлд тайлбарыг арилгаж, мөрүүдийг өөрчил:

бүх хост 127.0.0.1/32 таних дээр бүх хост 127.0.0.1/32 md5

бүх 0.0.0.0/0 таних бүх хост дээр бүх хост 0.0.0.0/0 md5

1C: Enterprise-д зориулсан PostgreSQL тохиргоог (postgresql.conf) оновчтой болгох

ESXi 6.5 виртуал машин дээр ажилладаг PostgreSQL-ийн тохиргоонууд энд байна.

VM-д хуваарилагдсан нөөцүүд:

процессор - 8 vCPU;

санах ой - 48 ГБ;

үйлдлийн системд зориулсан диск - SAS HDD-ийн RAID1 LUN тоног төхөөрөмж дээр 50 ГБ;

мэдээллийн санд зориулсан диск - SSD-ээс RAID1 програм хангамж дээр 170 ГБ

бүртгэлд зориулсан диск - SSD-ээс RAID1 програм хангамж дээр 100 ГБ

Тохиргоог засахын тулд дараах тушаалыг ажиллуулна уу:

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

Бидний өөрчлөх гэж буй параметрүүдийг идэвхжүүлсэн байх ёстой.

CPU

autovacuum_max_workers = 4

autovacuum_max_workers = NCores/4..2 гэхдээ 4-өөс багагүй байна

Автовакуум процессын тоо. Ерөнхий дүрэм бол бичих хүсэлт их байх тусам процесс илүү их байдаг. Зөвхөн унших боломжтой мэдээллийн сан дээр нэг процесс хангалттай.

ssl=унтраах

Шифрлэлтийг унтраа. Аюулгүй мэдээллийн төвүүдийн хувьд шифрлэлт нь утгагүй боловч CPU-ийн ачаалал нэмэгдэхэд хүргэдэг

Санах ой

хуваалцсан_буфер = 12 ГБ

хуваалцсан_буфер = RAM/4

Хуваалцсан хуудасны кэшэд PgSQL-ээс хуваарилсан санах ойн хэмжээ. Энэ санах ойг бүх PgSQL процессуудад хуваалцдаг. үйлдлийн системЭнэ нь өгөгдлийг өөрөө кэш болгодог тул кэшэд байгаа бүх RAM-г хуваарилах шаардлагагүй болно.

temp_buffers = 256MB

Түр хүснэгтийн хуудасны дээд тоо. Тэдгээр. Энэ нь сесс бүрийн түр зуурын хүснэгтүүдийн дээд хязгаар юм.

ажлын_мем = 64MB

work_mem = RAM/32..64 эсвэл 32MB..128MB

Нэг хүсэлтийг боловсруулах санах ойн хязгаар. Энэ санах ой нь сесс бүрийн хувьд хувь хүн юм. Онолын хувьд хамгийн их шаардагдах санах ой нь max_connections * work_mem-тэй тэнцүү бөгөөд практикт энэ нь тохиолддоггүй, учир нь ихэнх сессүүд бараг үргэлж хүлээж байдаг. Энэ зөвлөмжийн утгыг оновчтой болгоход ашигладаг: энэ нь асуулгад шаардагдах санах ойн хэмжээг урьдчилан таамаглахыг оролддог бөгөөд хэрэв энэ утга work_mem-ээс их байвал тэр даруй түр хүснэгт үүсгэхийг гүйцэтгэгчид хэлдэг. work_mem нь бүрэн утгаараа хязгаар биш юм: оновчлогч алдаж магадгүй бөгөөд хүсэлт нь илүү их санах ой, магадгүй хэд дахин их байх болно. Үүсгэсэн түр зуурын файлуудын тоог хянах замаар энэ утгыг бууруулж болно:

засвар үйлчилгээний_ажлын_мем = 2ГБ

засвар үйлчилгээ_ажлын_сан санах ой = RAM/16..32 эсвэл ажлын_мем * 4 эсвэл 256MB..4GB

Статистик мэдээлэл цуглуулах (ШИНЖИЛГЭЭ), хог цуглуулах (VACUUM), индекс үүсгэх (CREATE INDEX), гадаад түлхүүр нэмэх зэрэг засвар үйлчилгээний ажлын санах ойн хязгаар. Эдгээр үйлдлүүдэд зориулсан санах ойн хэмжээ нь ижил хэмжээтэй байх ёстой физик хэмжээдиск дээрх хамгийн том индекс.

үр дүнтэй_кэш_хэмжээ = 36 ГБ

үр дүнтэй_кэш_хэмжээ = RAM - хуваалцсан_буфер

Файлын системийн кэшийн хэмжээг тооцоолох. Параметрийг нэмэгдүүлэх нь системийн IndexScan төлөвлөгөөг сонгох хандлагыг нэмэгдүүлдэг. Мөн энэ сайн байна.

Дискнүүд

үр дүнтэй_io_concurrency = 5

Дискний системд нэгэн зэрэг үйлчлэх боломжтой нэгэн зэрэг хүсэлтийн тооцоо. Нэг дискний хувьд = 1, RAID-ийн хувьд - 2 ба түүнээс дээш.

санамсаргүй_хуудасны_зардал = 1.3

санамсаргүй_хуудасны_зардал = RAID-д 1.5-2.0, SSD-д 1.1-1.3

Санамсаргүй хуудсыг унших зардал (анхдагч 4). Дискний системийн хайх хугацаа бага байх тусам энэ параметр бага байх ёстой (гэхдээ > 1.0). Хэт их параметрийн утга нь PgSQL-ийн хүснэгтийг бүхэлд нь сканнердах төлөвлөгөөг сонгох хандлагыг нэмэгдүүлдэг (PgSQL нь индексийг санамсаргүй уншихаас илүүтэйгээр хүснэгтийг бүхэлд нь дараалан унших нь хямд гэж үздэг). Тэгээд ч муу.

автовакуум=асаалттай

Автовакуумыг асааж байна.

autovacuum_naptime = 20 секунд

Автовакуум процессын унтах хугацаа. Хэрэв утга нь хэтэрхий том бол хүснэгтүүд тоос соруулах цаг гарахгүй бөгөөд үүний үр дүнд хүснэгт, индексийн хэмжээ нэмэгдэх болно. Бага хэмжээний үнэ цэнэ нь шаардлагагүй халаалтыг бий болгоно.

bgwriter_delay = 20мс

Арын бичих процессын дискний бичих мөчлөгийн хоорондох унталтын хугацаа. Энэ процесс нь shared_buffers дотор байрлах хуудсыг дисктэй синхрончлох үүрэгтэй. Энэ параметрийн хэт том утга нь хяналтын цэгийн процесс болон сесс (арын төгсгөл) үйлчилдэг процессуудын ачааллыг нэмэгдүүлнэ. Бага утга нь цөмүүдийн аль нэгийг бүрэн ачаалахад хүргэдэг.

bgwriter_lru_multiplier = 4.0

bgwriter_lru_maxpages = 400

Арын дэвсгэр бичлэгийн процессын бичлэгийн эрчмийг хянадаг сонголтууд. Нэг мөчлөгт bgwriter сүүлийн циклд бичсэнээс илүүг бичдэггүй, bgwriter_lru_multiplier-ээр үржүүлсэн, харин bgwriter_lru_maxpages-ээс ихгүй байна.

synchronous_commit = унтраах

Үйлдэл хийх үед дискний синхрончлолыг идэвхгүй болго. Сүүлийн хэдэн гүйлгээг (0.5-1 секундын дотор) алдах эрсдэлийг бий болгодог боловч мэдээллийн баазын бүрэн бүтэн байдлыг баталгаажуулдаг; гинжин хэлхээнд цоорхой байхгүй. Гэхдээ энэ нь бүтээмжийг ихээхэн нэмэгдүүлдэг.

wal_keep_segments = 256

wal_keep_segments = 32..256

Шалгах цэгүүдийн хоорондох WAL сегментийн хамгийн их тоо. Хэт олон удаа шалгах цэгүүд нь дискний дэд системд ихээхэн хэмжээний бичих ачаалал үүсгэдэг. Сегмент бүр нь 16 МБ хэмжээтэй

wal_buffers = 16 MB

Дискэнд хараахан бичигдээгүй байгаа WAL өгөгдлийг буферлахад ашиглах хуваалцсан санах ойн хэмжээ. -1-ийн өгөгдмөл утга нь -ын 1/32 (ойролцоогоор 3%) хэмжээтэй тэнцүү, гэхдээ 64 КБ-аас багагүй, нэг WAL сегментийн (ихэвчлэн 16 МБ) хэмжээнээс ихгүй хэмжээг заадаг. Хэрэв автоматаар сонгосон нь хэтэрхий жижиг эсвэл том бол энэ утгыг гараар тохируулах боломжтой боловч 32 КБ-аас бага эерэг тоог 32 КБ гэж үзнэ. Энэ параметрийг зөвхөн серверийг эхлүүлэх үед тохируулах боломжтой.

Гүйлгээ бүрийг хийх үед WAL буферийн агуулгыг дискэнд бичдэг тул маш том утгууд нь тийм ч их ашиг өгөхгүй байх магадлалтай. Гэсэн хэдий ч дор хаяж хэдэн мегабайтын үнэ цэнэ нь олон үйлчлүүлэгч нэгэн зэрэг гүйлгээ хийх үед завгүй сервер дээр бичих гүйцэтгэлийг сайжруулж чадна. Анхдагч утга (-1) дээр ажилладаг автомат тохируулга нь ихэнх тохиолдолд боломжийн утгыг сонгодог.

анхдагч_статистикийн_зорилт = 1000

ALTER TABLE SET STATISTICS нь тус тусын хязгаарыг заагаагүй баганад хамаарах өгөгдмөл статистикийн зорилтот хязгаарыг тогтооно. Тодорхойлсон утга өндөр байх тусам ANALYZE-г ажиллуулахад удаан хугацаа шаардагдах боловч төлөвлөгчийн тооцооны чанар өндөр байх болно. Энэ параметрийн өгөгдмөл утга нь 100 байна.

шалгах_бөглөх_зорилт = 0.9

Шалгах цэгийн "т рхэц"-ийн зэрэг. Шалгах цэгийн бичлэгийн хурдыг шалгах цэгийн хугацааг өнгөрсөн цагаас хойш өнгөрсөн хугацаатай тэнцүү байхаар тохируулж, шалган нэвтрүүлэх цэгийн_дуусгах_ зорилтоор үржүүлнэ.

мин_валийн_хэмжээ = 4G
хамгийн их_валийн_хэмжээ = 8G

мин_валь_хэмжээ = 512MB .. 4G
max_wal_size = 2 * мин_wal_size

WAL файлуудын хамгийн бага ба дээд хэмжээ. Checkpoint_segments-тэй төстэй

fsync=асаалттай

Сонголтыг идэвхгүй болгосноор гүйцэтгэл нэмэгдэх боловч цахилгаан гэнэт унтарвал бүх өгөгдөл алдагдах эрсдэлтэй. Анхаар: Хэрэв RAID нь кэштэй бөгөөд буцааж бичих горимд байгаа бол RAID хянагчийн кэш батерей байгаа эсэх, ажиллагааг шалгана уу! Үгүй бол цахилгаан унтарсан үед RAID кэшэд бичигдсэн өгөгдөл алдагдах магадлалтай бөгөөд үүний үр дүнд PgSQL мэдээллийн бүрэн бүтэн байдлыг баталгаажуулахгүй.

мөрийн_аюулгүй байдал = унтраалттай

Бичлэгийн түвшний нарийвчлалын хяналтыг идэвхгүй болгож байна

enable_nestloop = унтраах

Хуваарьлагчийн үүрлэсэн давталтын нэгдлийн төлөвлөгөөг ашиглахыг идэвхжүүлдэг эсвэл идэвхгүй болгодог. Энэ нь үүрлэсэн гогцоог бүрэн арилгах боломжгүй боловч хэрэв та энэ сонголтыг унтраавал хуваарь гаргагч ашиглахгүй. энэ арга, хэрэв бусад нь хэрэглэх боломжтой бол. Өгөгдмөлөөр энэ тохиргоо асаалттай байна.

Түгжээ

гүйлгээ бүрт хамгийн их_түгжээ = 256

Нэг гүйлгээнд индекс/хүснэгт түгжих хамгийн их тоо

1С платформын тохиргоо

стандарт_тохирох_мөр = унтраах

Оргохын тулд \ тэмдэгтийг ашиглахыг зөвшөөрнө үү

escape_string_warning = унтраах

Зугтахын тулд \ тэмдэгтийг ашиглах талаар бүү анхааруулаарай

Аюулгүй байдлын тохиргоо

PostgreSQL сервер нь зөвхөн нэг машин дээр суулгасан 1С: Enterprise серверт харагдах эсэхийг шалгацгаая.

сонсох_хаяг = 'localhost'

Хэрэв 1C: Enterprise серверийг өөр машин дээр суулгасан эсвэл PGAdmin-ийн нэмэлт хэрэгслийг ашиглан DBMS серверт холбогдох шаардлагатай бол оронд нь localhost та энэ машины хаягийг зааж өгөх хэрэгтэй.

Өгөгдлийн сангийн хадгалалт

PostgreSQL нь бараг ямар ч DBMS шиг дискний дэд системд чухал үүрэг гүйцэтгэдэг тул DBMS-ийн гүйцэтгэлийг нэмэгдүүлэхийн тулд бид PostgreSQL систем, бүртгэлүүд болон мэдээллийн сангуудыг өөр өөр диск дээр байрлуулах болно.

Серверийг зогсоож байна

Systemctl postgresql-9.6 зогсооно

Бид логуудыг 120 ГБ 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/ pgsql/9.6/data/pg_log

Бид мөн мэдээллийн сантай лавлахыг шилжүүлэх болно:

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

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

Серверийг эхлүүлж, статусыг нь шалгацгаая

Systemctl эхлэх postgresql-9.6 systemctl статус postgresql-9.6

PostgreSQL өгөгдлийн сангийн сервер болгон ашиглах windows платформтийм ч алдартай биш, гэхдээ энэ нь ихэвчлэн MS-ийн бүтээгдэхүүнд мөнгө хэмнэх шаардлагатай үед тохиолддог. PostgreSQL-тэй хамгийн сайн ажилладаг тусгай програмууд бас байдаг. 1c-ийн хувьд PostgreSQL-ийн өөрчилсөн бүтэц байдаг бөгөөд хөгжүүлэгчид MSSQL-тэй харьцуулж болохуйц гүйцэтгэл, алдааг тэсвэрлэх чадварыг өгдөг. Энэ үнэхээр тийм үү, практик дээр шалгацгаая :)

1. PostgreSQL суулгана уу

PostgreSQL-ийн 64 битийн 9.1.2-1.1C-ийн хамгийн сүүлийн хувилбарыг 1c вэб сайтаас татаж аваад, архивыг задалж, msi багцыг ажиллуулаарай, int-гүй хувилбар нь том файлгүй байна.

Start дарна уу.
Суулгах сонголтыг анхдагч байдлаар үлдээнэ үү.

Хэрэглэгчийн нууц үгийг тохируулна уу postgresүүнээс үйлчилгээ эхлэх болно . Дараах товчийг дарна уу. Хэрэв та PostgreSQL-г анх удаа суулгаж байгаа бол шидтэн таныг хэрэглэгч үүсгэхийг хүсэх болно. postgres.

Өгөгдлийн санг эхлүүлэх үе шатанд UTF8 кодчилолыг сонгоно уу. Дотоод postgres хэрэглэгчийн нэвтрэх болон нууц үгээ тохируулна уу. Анхаар! PostgreSQL үйлчилгээний хэрэглэгчийн нууц үг болон PostgreSQL мэдээллийн сангийн дотоод хэрэглэгчийн нууц үг ижил байж болохгүй. Нууц үг дор хаяж дөрвөн тэмдэгтээс бүрдэх ёстой. Хэрэв та 1С сервер болон PostgreSQL-ийг өөр өөр машин дээр ажиллуулахаар төлөвлөж байгаа бол "Зөвхөн localhost биш, дурын IP-ээс холболтыг дэмжих" нүдийг шалгах хэрэгтэй. Next болон Next товчийг дахин дарна уу. :)

"Дараах" товчийг дахин хоёр удаа товшоод суулгалт дуусах хүртэл хүлээнэ үү.

Дараа нь Start\All Programs\PostgreSQL 9.1.2-1.1C(x64) руу очно уу. pgAdmin III удирдлагын хэрэгслийг ажиллуул. Өгөгдлийн сантай холбогдохыг оролдъё. Суулгах явцад заасан нууц үгээ оруулна уу.
Мөн бид дараах алдааг олж авна: Сервертэй холбогдоход алдаа гарлаа: FATAL: "postgres" хэрэглэгчийн нууц үгийн баталгаажуулалт амжилтгүй боллоо.

Нууц үгийг зөв оруулсан гэж үзвэл гэнэтийн зүйл. Би pg_hba.conf-тэй танилцахаар шийдсэн боловч эхлээд харахад бүх зүйл сайхан байна.

# ТӨРӨЛ ӨГӨГДЛИЙН САН ХЭРЭГЛЭГЧИЙН ХАЯГИЙН АРГА # IPv4 локал холболтууд: бүх postgres хост::1/128 md5 бүх postgres 127.0.0.1/32 md5 хост бүх postgres 192.168.1.0/24 md5

Би md5-аас итгэмжлэлийн аргыг өөрчлөхөөр шийдсэн. Би үйлчилгээг дахин эхлүүлж, мэдээллийн сан руу дахин холбогдохыг оролдоно уу. Энэ удаад би энэ мессежийг хүлээн авлаа.
Үнэн хэрэгтээ, pgAdmin вэбсайт дээр нэгээс илүүг ашиглах боломжтой шинэ хувилбар. Үүний дараа өгөгдлийн сантай холбогдох амжилттай болно!!!?!!! Өмнө нь md5 ийм асуудал үүсгэдэггүй гэдгийг санаж байна, энэ алдаа нь үнэхээр холбоотой юм шиг санагдаж байна хуучин хувилбар pgAdmin.
Одоо бид 1С-ийн хэрэгцээнд зориулж мэдээллийн сан үүсгэх эсвэл 1С-г өөрөө ашиглан хийх боломжтой :)

2. Суурилуулалт 1С аж ахуйн нэгж 8.2.

Суулгахын тулд бид дараах бүрэлдэхүүн хэсгүүдийг анхаарна уу: 1C: Enterprise, 1C: Enterprise Server, вэб серверийн өргөтгөлийн модулиуд, 1C: Enterprise серверийн удирдлага.
"1С Enterprise-г үйлчилгээ болгон суулгах" суулгах үе шатанд бид USR1C82 хэрэглэгчийн нууц үгийг тохируулсан.
Дараах дээр дарж суулгацын явцыг хянах :) Хэрэглэгчид USR1CV82Суулгах явцад дараахь эрхийг олгох ёстой.

Үйлчилгээгээр нэвтэрнэ үү (Үйлчилгээгээр нэвтэрнэ үү),Багц ажил хэлбэрээр нэвтэрнэ үү (Багц ажил хэлбэрээр нэвтэрнэ үү). Та үүнийг үзэх боломжтой Орон нутгийн компьютерийн бодлого\Компьютерийн тохиргоо\Windows тохиргоо\Аюулгүй байдлын тохиргоо\Орон нутгийн бодлого\Хэрэглэгчийн эрхийн даалгавар.

Тоног төхөөрөмж рүүгээ явцгаая 1С Enterprise серверүүдийн удирдлага,Бид кластер өсч, 1541 порт дээр өлгөөтэй байгааг харж байна. Манай сервер мөн "Ажлын серверүүд" таб дээр байдаг. Одоо та мэдээллийн санг 1С серверт нэмж болно. Үүнийг хийхийн тулд таб руу очно уу " Мэдээллийн үндэс"Хулганы баруун товчийг дараад сонгоно уу Шинэ - Мэдээллийн бааз. PostgreSQL серверт холбогдохын тулд шаардлагатай параметрүүдийг тохируулна уу. OK дарна уу. 1С: Аж ахуйн нэгжийг ажиллуулцгаая. Бид сервер дээр байгаа мэдээллийн баазыг нэмэхээр сонгосон.
Дараа нь холболтын параметрүүдийг тохируулна уу. "Дараах" дээр дарж, эцэст нь "Дуусгах" дээр дарна уу.
Мэдээллийн сан үүсгэх үйлдлийг 1С: Enterprise-ээс шууд хийж болно. Үүнийг хийхийн тулд эхлүүлэх үед "Шинэ үүсгэх" -ийг сонгоно уу мэдээллийн бааз».

1С клиентүүдийг гаднаас сервертэй холбож, мэдээллийн сангийн серверийг галт хананд ажиллуулахын тулд дараах портууд нээлттэй байх ёстой.

Серверийн төлөөлөгч ( бодис) - tcp:1540 Кластерийн ахлах менежер ( rmngr) - tcp:1541 Ажилчдын процессыг динамикаар түгээх сүлжээний портуудын хүрээ - tcp:1560-1591, tcp:5432 - Postgresql. Стандарт интерфейс эсвэл тушаалыг ашиглан дүрэм үүсгэцгээе.

netsh advfirewall галт хана нэмэх дүрмийн нэр="1Cv8-Server" dir=in action=allow protocol=TCP localport=1540,1541,5432,1560-1590 идэвхжүүлэх=тийм профайл=АНY remoteip=Ямар ч интерфейсийн төрөл=LAN

Одоо бид 1С: Enterprise клиентийг өөр компьютерээс хялбархан ажиллуулж, одоо байгаа мэдээллийн баазыг нэмж болно newdb. Лиценз, програм хангамж/техник хангамжийн хамгаалалтын талаар бүү мартаарай. Одоо бид Гилев тестийг татаж аваад системийн гүйцэтгэлийг хэмжих боломжтой.

1 ГБ санах ойтой, Dual-Core 2.6 GHz, 319-release 1c бүхий VirtualBox дээр Gilev тест нь CentOS-тэй ижилхэн 11.42 оноо өгдөг. 16.362 цэгт 11.60 цэгээс арай илүү байна. EnterpriseDB Tuning Wizard ашиглан тохиргоог оновчтой болгох нь мэдэгдэхүйц өсөлтийг өгөөгүй (11.66 ба 11.62), гэхдээ энэ нь ерөнхийдөө ашигтай байж болох юм. :)

3. PostgreSQL сервер дээр тогтмол ажиллах.

Нөөц.

pgAdmin III удирдлагын хэрэгслийг ажиллуулаад хүссэн мэдээллийн сан дээрээ хулганы баруун товчийг дарна уу. "Нөөцлөх" -ийг сонгоно уу.
Форматыг сонгоно уу (Захиалгат (0-ээс 9 хүртэлх шахалтын түвшин), Тар, Энгийн, Каталог). Шахалтын түвшний хувьд аливаа шахалтын түвшний "захиалгат формат" нь хамгийн сайн шахагддаг, дараа нь "сан", дараа нь "энгийн", эцэст нь "tar". Бид UTF8 кодчиллыг зааж өгдөг, дүрийн нэр нь postgresql. Бид бүх нэмэлт сонголтуудыг анхдагч байдлаар үлдээдэг. "Нөөцлөх" товчийг дарна уу. "Мессеж" талбарт гүйцэтгэсэн бүх үйлдлийн жагсаалтыг дуусгах кодтой харуулна. 0 бол амжилт. Энд та тушаалын мөрөөс ижил төстэй үйлдлийг хэрхэн ажиллуулахыг харж болно.

F)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --хэрэглэгчийн нэр "postgres" --role "postgres" --no-password --format custom --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump.backup" "newdb"

Үүний дагуу автомат скрипт Нөөц хуулбар, бидний хуваарьт нэмэх нь дараах байдалтай харагдаж болно:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --хэрэглэгчийн нэр "postgres" --role "postgres" --no-password --format custom --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump_%date:~0.2%_%date:~3.2%_%date:~6.4% .backup" "newdb"

Сэргээх.

Сэргээхийн тулд бид өгөгдлийг сэргээхийг хүсч буй мэдээллийн санг сонгоно уу нөөц хуулбар, хоосон байвал зохимжтой. Хулганы баруун товчийг дараад "Сэргээх" гэснийг сонгоно уу. Нөөц файл, үүргийн нэрийг тохируулна уу: postgres, "Сэргээх" дээр дарна уу.
Тушаалын мөрийг ашиглан:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_restore.exe" --host 192.168.1.200 --port 5432 --username "postgres" --dbname "testdb" --role "postgres" --үгүй -нууц үг --дэлгэрэнгүй "G:\Backups\gilev_dump_26_09_2012.backup"

Энд testdb нь нөөц архивыг сэргээдэг хоосон мэдээллийн сан юм.

Засвар үйлчилгээ:

ВАКУМ команд:

Одоо холбогдсон өгөгдлийн сангийн бүх хүснэгтийг дараалан цэвэрлэж, түр зуурын өгөгдлийг устгаж, дискний зайг чөлөөлнө. Ихэнх тохиолдолд VACUUM команд нь диск дээрх хамгийн их зайг олж авах, өгөгдөлд нэвтрэх хурдыг нэмэгдүүлэхийн тулд яг нарийн гүйцэтгэдэг.

ВАКУМ— бичлэгийн хуучин хувилбаруудын эзэлдэг зайг үнэ төлбөргүй гэж тэмдэглэнэ. Дүрмээр бол тушаалын энэ хувилбарыг ашиглах нь хүснэгтийг агуулсан файлын хэмжээг багасгахгүй, харин түүнийг хяналтгүй өсөхөөс урьдчилан сэргийлэх, зөвшөөрөгдсөн түвшинд засах боломжийг олгодог. VACUUM ажиллуулах үед боловсруулж буй хүснэгтэд зэрэгцээ хандах боломжтой. Хэд хэдэн байдаг нэмэлт сонголтуудВАКУМ ашиглах: ВАКУМ БҮРЭН, ВАКУМ ХӨЛДӨХ, ВАКУМ ШИНЖИЛГЭЭ.

ВАКУМ ДҮҮРЭНбичлэгийн бүх хуучин хувилбаруудыг устгах оролдлого, үүний дагуу хүснэгт агуулсан файлын хэмжээг багасгах. Энэ командын сонголт нь боловсруулж буй хүснэгтийг бүрэн түгждэг.

вакуум хөлдөөх -Хэрэв VACUUM FULL нь хүснэгтүүдийн "хог"-ыг арилгаж, бичлэгүүдийг зөөж зөөвөрлөж, хүснэгтүүд нь дискэн дээр нягт байрлаж, хамгийн бага тооны фрагментээс бүрдэх бол шахалтад удаан хугацаа зарцуулж, бичлэгийг блоклодог бол VACUUM FREEZE нь "хог"-ыг зүгээр л зайлуулдаг. хүснэгтүүд, гэхдээ бичлэгүүд нь өөрөө хөдөлдөггүй тул илүү хурдан бөгөөд бичихийг хориглодоггүй. Одоогийн байдлаар энэ сонголтыг автовакуум - автомат хог цуглуулах замаар сольсон postgresql.confМөн функцийг өргөжүүлэх хэд хэдэн нэмэлт сонголтууд:

автовакуум=асаалттай# Автомат хог цуглуулах ажиллагааг идэвхжүүлнэ.
log_autovacuum_min_үргэлжлэх хугацаа = -1# Үүнийг тэг болгох нь бүх автомат вакуум үйлдлийг бүртгэдэг. Хасах нэг (анхдагчаар) бүртгэлд гарахыг хориглодог. Жишээлбэл, хэрэв та утгыг тохируулсан бол
250 мс-тэй тэнцүү бол 250 мс ба түүнээс дээш хугацаанд автоматаар вакуум хийх, дүн шинжилгээ хийх бүх үйлдлийг бүртгэх болно. Энэ тохиргоог идэвхжүүлснээр автомат вакуумыг хянахад тустай байж болох юм.
Энэ сонголтыг зөвхөн postgresql.conf файл эсвэл дотор нь тохируулах боломжтой тушаалын мөрсервер.
autovacuum_inptime = 10мин# Мэдээллийн санг хог цуглуулах шаардлагатай эсэхийг шалгах хугацаа секундээр. Анхдагчаар энэ нь минутанд нэг удаа тохиолддог.
автовакуум_вакуум_босго= 1800 # Хүснэгт дэх устгасан болон өөрчилсөн бичлэгийн тоо, түүнээс хэтэрсэн тохиолдолд хог цуглуулах босго (VACUUM).
автовакуум_шинжилгээний босго= 900 # Хүснэгтэд оруулсан, устгасан, өөрчилсөн бичлэгийн тооны босго, түүнээс дээш тоогоор дүн шинжилгээ хийх процесс (ШИНЖИЛГЭЭ) эхэлнэ.
autovacuum_vacuum_scale_factor= 0.2 # Хүснэгттэй холбоотой өөрчилсөн болон устгасан бичлэгүүдийн хувь, түүнээс дээш хог цуглуулах ажиллагаа идэвхждэг.
автовакуум_шинжилгээний_масштаб_хүчин зүйл= 0.1 # Өмнөх хувьсагчтай адил боловч шинжилгээтэй харьцуулахад.
ВАКУМ ШИНЖИЛГЭЭ— Хэрэв өгөгдлийн санд өгөгдөл нь өөрчлөгдөөгүй, устгагдаагүй, зөвхөн нэмсэн хүснэгтүүд байгаа бол ийм хүснэгтүүдэд та тусдаа ANALYZE командыг ашиглаж болно. Энэ тушаалыг олон тооны бичлэг нэмсний дараа тусдаа хүснэгтэд ашиглах нь зүйтэй.

ANALYZE тушаал:

Хүснэгт дэх өгөгдлийн тархалтын талаарх мэдээллийг шинэчлэхэд үйлчилдэг. Энэ мэдээллийг оновчтойч хамгийн хурдан асуулгын гүйцэтгэлийн төлөвлөгөөг сонгоход ашигладаг. Ихэвчлэн тушаалыг хамтад нь ашигладаг ВАКУМ ШИНЖИЛГЭЭ.

REINDEX тушаал (дахин индексжүүлэх):

Одоо байгаа индексүүдийг сэргээхэд ашигладаг. Тохиолдолд ашиглах нь утга учиртай

- индексийн гэмтэл;

- түүний хэмжээ байнга нэмэгдэх.

Хоёр дахь тохиолдол нь тодорхой тайлбар шаарддаг. Хүснэгттэй адил индекс нь бичлэгийн хуучин хувилбартай блокуудыг агуулдаг. PostgreSQL нь эдгээр блокуудыг дахин ашиглах боломжгүй тул индекс файлын хэмжээ аажмаар нэмэгддэг. Хүснэгт дэх өгөгдөл байнга өөрчлөгддөг бол энэ нь маш хурдан өсөх болно. Хэрэв та индексийн ийм үйлдлийг анзаарсан бол REINDEX командыг үе үе ажиллуулахаар тохируулах хэрэгтэй. Анхаарна уу: VACUUM FULL гэх мэт REINDEX команд нь хүснэгтийг бүрэн түгждэг тул серверийн ачаалал хамгийн бага үед ажиллах ёстой.

Аль DBMS - Postgresql эсвэл MS SQL for 1C нь хамгийн оновчтой вэ гэсэн асуулт олон нийтлэлийн сэдэв байсан. Энэ нийтлэлд бид хоёуланг нь оновчтой болгох алхмуудыг авч үзэх болно. Үйлдвэрлэгч бүрийн DBMS нь 1С-ээс өгсөн өөрийн тохиргооны зөвлөмж, зөвлөмжтэй байдаг. Тоног төхөөрөмж, серверийн тохиргоо, янз бүрийн ачааллыг тохируулж буй хэрэглэгчдийн тоо зэргээс хамааран 1С-д зориулсан DBMS-ийг оновчтой болгох, зөвлөмжийг хэрэгжүүлэх үйл явцын нарийвчилсан мэдээлэл өөрчлөгдөж болохыг тэмдэглэх нь зүйтэй.

1С-д зориулсан PostgreSQL-г тохируулж байна

PostgreSQL дээр 1С мэдээллийн баазыг ажиллуулж байсан туршлагаас харахад 1С болон PostgreSQL-ийн хамгийн өндөр гүйцэтгэл, оновчтой гүйцэтгэл нь Линукс дээр гарсан тул үүнийг ашиглахыг зөвлөж байна. Гэхдээ үйлдлийн системээс үл хамааран PostgreSQL-ийг суулгахад заасан анхдагч тохиргоо нь зөвхөн DBMS серверийг эхлүүлэхэд зориулагдсан гэдгийг санах нь чухал юм. Аж үйлдвэрийн мөлжлөгийн тухай яриа ч байж болохгүй! Эхлүүлсний дараах дараагийн алхам бол 1С-д зориулсан PostgreSQL-ийг оновчтой болгох явдал юм.

• Нэгдүгээрт, бид Эрчим хүч хэмнэлтийг идэвхгүй болгож (эсвэл мэдээллийн сангаас хариу өгөх саатал урьдчилан таамаглах аргагүй нэмэгдэж болзошгүй) болон хуваалцсан санах ой солихыг хориглоно.
• Бид DBMS серверийн үндсэн параметрүүдийг тохируулдаг (тохируулга хийх зөвлөмжийг үйлдвэрлэгчийн албан ёсны вэбсайт болон 1С-ийн аль алинд нь хангалттай нарийвчлан тайлбарласан тул бид зөвхөн хамгийн чухал зүйлд анхаарлаа хандуулах болно).
• 1С компанийн стандарт зөвлөмжүүд нь HyperThreading механизмыг идэвхгүй болгохыг санал болгож байна. Гэхдээ Postgres-pro-г SMT (нэгэн зэрэг олон урсгалтай) идэвхжүүлсэн серверүүд дээр туршиж үзэхэд өөр үр дүн гарсан.

Shared_buffers-ийг RAM/4 болгон тохируулах нь өгөгдмөл зөвлөмж боловч Sql Server жишээ нь санах ойн хэмжээ их байх тусам түүний гүйцэтгэл сайжирна (хуудас угаахыг идэвхгүй болгосон). Өөрөөр хэлбэл, RAM-д өгөгдлийн хуудас их байх тусам дискний хандалт бага байх болно. Асуулт гарч ирдэг: яагаад ийм жижиг кэш байдаг вэ? Хариулт нь энгийн: хэрэв shared_buffers том бол ашиглагдаагүй зарим хуудсыг диск рүү шилжүүлнэ. Гэхдээ дахин тохируулах зогсох, параметрийн үзүүлэлт оновчтой байх мөчийг хэрхэн хянах вэ? Хуваалцсан_буферийн оновчтой үзүүлэлтэд хүрэхийн тулд түүний үнэ цэнийг өдөр бүр (боломжтой бол) тодорхой хэмжээгээр нэмэгдүүлэх шаардлагатай бөгөөд ямар үед хуудаснууд диск рүү шилжиж эхлэхийг ажиглах хэрэгтэй (солилцоо нэмэгдэх болно).

Нэмж дурдахад "том параметр" нь анхдагчаар 8Кб хэмжээтэй олон жижиг хуудастай ажиллахад сөргөөр нөлөөлдөг. Тэдэнтэй ажиллах нь нэмэлт зардлыг нэмэгдүүлдэг. 1С-ийг оновчтой болгохын тулд үүнийг юу хийж болох вэ? PostgreSQL 9.4 нь big_pages параметрийг нэвтрүүлсэн бөгөөд үүнийг зөвхөн Линукс дээр идэвхжүүлж болно. Анхдагч байдлаар, 2048 кБ хэмжээтэй том хуудсуудыг оруулсан болно. Нэмж дурдахад эдгээр хуудасны дэмжлэгийг үйлдлийн системд идэвхжүүлсэн байх ёстой. Тиймээс, хадгалах бүтцийг оновчтой болгосноор та илүү том share_buffers үзүүлэлтэд хүрч чадна.

work_mem = RAM/32..64 эсвэл 32MB..128MB Түр зуурын файлуудыг ашиглахаас өмнө дотоод эрэмбэлэх, нэгтгэх гэх мэт үйлдлүүдэд ашиглах сесс бүрийн санах ойн хэмжээг тохируулна. Хэрэв энэ хэмжээ хэтэрсэн бол сервер нь түр зуурын файлуудыг дискэн дээр ашиглах бөгөөд энэ нь хүсэлтийг боловсруулах хурдыг эрс багасгадаг. Энэ параметрийг операторуудыг гүйцэтгэхэд ашигладаг: ORDER BY, DISTINCT, нэгтгэх холболт гэх мэт.

Нэмэлт тооцоол энэ параметрдараах байдлаар хийж болно: (Shared memory shared_buffers - бусад програмын санах ой) / идэвхтэй холболтын тоо. Үүсгэсэн түр зуурын файлуудын тоог хянах замаар энэ утгыг бууруулж болно. Түр зуурын файлуудын хэмжээ, тооны талаарх статистик мэдээллийг pg_stat_database системийн харагдацаас авах боломжтой.

effect_cache_size = RAM - shared_buffers Энэ параметрийн гол зорилго нь асуулга оновчтой болгоход өгөгдөл сэргээх аль аргыг сонгохыг хэлэх явдал юм: бүрэн скан эсвэл индекс скан. Параметрийн утга өндөр байх тусам индекс сканнердах магадлал өндөр болно. Энэ тохиолдолд сервер нь хүсэлтийг гүйцэтгэх үед өгөгдөл санах ойд үлдэх боломжтой гэдгийг харгалзан үзэхгүй бөгөөд дараагийн хүсэлтийг дискнээс авах шаардлагагүй болно.

PostgreSQL суулгаж байна

Windows дээр PostgreSQL дээр 1С суулгах нь маш энгийн процесс юм. Суулгацын багцыг ажиллуулахдаа та UTF-8 кодчилолыг зааж өгөх ёстой. Үнэн хэрэгтээ энэ бол цорын ганц сонирхолтой нюанс бөгөөд Windows-ээс 1C 8.3-д PostgreSQL-ийн нэмэлт тохиргоо хийх шаардлагагүй юм. Linux үйлдлийн систем дээр 1C-д зориулсан PostgreSQL-ийг суулгаж, тохируулах нь хэд хэдэн хүндрэл учруулж болзошгүй юм. Тэдгээрийг даван туулахын тулд, жишээ болгон, Ubuntu 16.04 x64 сервер дээр PostgreSQL ажиллуулах (Оросын тэргүүлэх үйлдвэрлэгч PostgreSQL-Pro болон 1C компанийн түгээлтийн иж бүрдэл ашиглан) авч үзье.

PostgreSQL DBMS-д зориулсан 1С түгээлтийн иж бүрдэл суурилуулах

1. PostgreSQL DBMS түгээлтийн багцын заасан байрлалыг татаж авна уу:

2. PostgreSQL-г серверт байршуулах;

3. Та дараах тушаалаар PostgreSQL DBMS суулгагчийг задалж болно.

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

4. PostgreSQL DBMS түгээлтийн иж бүрдлийг суулгахын өмнө системд шаардлагатай локал тохиргоо байгаа эсэхийг шалгая (анхдагчаар ru_RU.UTF-8):

5.Хэрэв PostgreSQL-тэй ажиллах системийг орос хэлнээс өөр хэл дээр суулгасан бол та шинэ локал үүсгэх шаардлагатай:

locale-gen ru_RU update-locale LANG=ru_RU.UTF8 dpkg-орон нутгийн тохиргоог дахин тохируулах

6.Хэрэв шаардлагатай локал боломжтой хэвээр байвал үүнийг анхдагчаар суулгана уу:

locale –a nano /etc/default/locale Агуулгыг LANG=ru_RU.UTF-8 гэж солино.

7. Дахин ачаалсны дараа PostgreSQL-ийн манай хувилбарт шаардлагатай багцуудыг суулгана уу:

apt-get суулгах libxslt1.1 ssl-cert

8.PostgreSQL багцын хувилбар 9.4.2-1.1C нь libicu багцын libicu48 хувилбартай холбогдсон. Шаардлагатай хувилбар нь хадгалах газарт байхгүй, гэхдээ та татаж авах боломжтой;

9.Татаж аваад PostgreSQL-д зориулсан татаж авсан файлуудыг хадгалдаг лавлахад байрлуул;

10. PostgreSQL файл бүхий лавлах руу орсноор бид дараах командуудыг дараалан бичиж суулгацыг гүйцэтгэнэ.

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

11. Дууслаа. PostgreSQL DBMS түгээлтийн хэрэгслийг суулгасан.

PostgreSQL-Pro түгээлтүүдийг суулгаж байна

Серверийг суулгахын тулд та дараах тушаалуудыг дараалан ажиллуулах ёстой.

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 суулгах postgresql-pro-1c-9.4

Серверт хандахын тулд файл дахь параметрүүдийг засварлана уу 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"

Файл өөрөө дараах бүтэцтэй байна.

Файлыг сайн баримтжуулсан боловч Англи хэл. Үндсэн параметрүүдийг товчхон авч үзье.

• Орон нутгийнзөвхөн unix-ээр дамжуулан дотоод холболт
• Хөтлөгч TCP/IP холболт
• Hostssl TCP/IP-ээр шифрлэгдсэн SSL холболт (сервер нь SSL дэмжлэгтэйгээр бүтээгдсэн байх ёстой, ssl параметрийг мөн тохируулсан байх ёстой)
• Hostnossl TCP/IP-ээр шифрлэгдээгүй холболт

• итгэлбаталгаажуулалтгүйгээр хүлээн зөвшөөрөх
• татгалзахбаталгаажуулалтгүйгээр татгалзах
• нууц үгтекст нууц үгийн хүсэлтийг арилгах
• md5 MD5 хэлбэрээр нууц үгийн хүсэлт
• лдап LDAP сервер ашиглан хэрэглэгчийн нэр, нууц үгийг баталгаажуулах
• радиус RADIUS сервер ашиглан хэрэглэгчийн нэр, нууц үгийг баталгаажуулж байна
• памзалгаасын үйлчилгээг ашиглан хэрэглэгчийн нэр, нууц үгийг баталгаажуулах

Илүү нарийвчилсан, нарийвчилсан мэдээллийг PostgreSQL бүтээгдэхүүний баримт бичгээс авах боломжтой.

root@NODE2:/home/asd# үйлчилгээ --status-all |grep postgres [ - ] postgresql root@NODE2:/home/asd# үйлчилгээ postgresql start root@NODE2:/home/asd# үйлчилгээ --status-all | grep postgres [ + ] postgresql

Үндсэн суулгацыг дуусгасны дараа та тохируулах хэрэгтэй тохиргооны файл PostgreSQL, 1C сервер болон Ubuntu серверийн тохиргооны онцлогийн дагуу postgresql.conf сервер.

MS SQL серверт зориулсан 1С-ийг оновчтой болгох

Суулгах Хамгийн сүүлийн үеийн шинэчлэлтүүд SQL Sever-д зориулсан.

Үйлдлийн систем нь зайг нөөцөлж, тэгээр дүүргэдэг бөгөөд энэ нь дараах үйл явдлуудад нэлээд удаан хугацаа шаарддаг:

• Мэдээллийн сан үүсгэх;
• Өгөгдлийн файл, гүйлгээний бүртгэлийг одоо байгаа мэдээллийн санд нэмэх;
• Одоо байгаа файлын хэмжээг нэмэгдүүлэх (Autogrow үйлдлүүд орно);
• Бид мэдээллийн сан эсвэл файлуудын бүлгийг сэргээдэг.

Шийдвэрлэж байна энэ асуудалтухайн зүйлд үүрэг (сервер ажиллаж байгаа) нэмэх орон нутгийн улс төраюулгүй байдал "Эзлэхүүн засвар үйлчилгээний ажлыг гүйцэтгэх."

Боломжтой бол TempDB мэдээллийн сан (ялангуяа RCSI удирдлагатай түгжих горимд эрчимтэй ашиглагддаг) болон гүйлгээний бүртгэлийг өөр диск дээр тараах шаардлагатай.

Ажиллаж байгаа сервер дээр SQL сервер, эрчим хүч хэмнэх горимыг "Өндөр гүйцэтгэл" гэж тохируулсан байх ёстой.

Өгөгдлийн сангийн файл бүхий хавтсыг шахаж болохгүй.

Серверийн "Санах ой" таб дээр бид хамгийн бага түвшинг нийт санах ойн 50% болгон тохируулсан. Бид томъёоны аль нэгийг ашиглан дээд хэмжээг тооцоолно.

• Хамгийн их санах ой = Нийт эзэлхүүн - OS-ийн дагуу хэмжээ - 1С-ийн хэмжээ (хэрэв байгаа бол тоолууртай ашигласан санах ойг урьд нь хэмжсэн) эсвэл
• Хамгийн их санах ой = Нийт хэмжээ – (1024* Нийт хэмжээ/16384).

Бид DOP параметрийг "Зэрэгцээ байдлын дээд зэрэг" -ийг хязгаарлаж, "1" болгож тохируулна.

Бид статистик мэдээллийг хуваарийн дагуу шинэчилдэг. -аас эхлэн SQL сервер 2008 онд статистик мэдээллийг шинэчлэх нь асуулгыг дахин хөрвүүлэхэд хүргэдэг бөгөөд үүний дагуу процедурын кэшийг цэвэрлэдэг тул процедурын кэшийг цэвэрлэхийн тулд тусдаа процедур хийх шаардлагагүй болно.

Бид хүснэгтийг үе үе дахин индексжүүлж, индексүүдийг дефрагментация хийдэг.

Бид захиалгын зөв бодлогыг бий болгодог. Хэрэв та систем гацахаас өмнө эцсийн мөч хүртэл сэргээх шаардлагагүй бөгөөд сүүлийн 5 минут ба түүнээс дээш хугацаа нь таны бизнест чухал биш бол сэргээх загварыг "Энгийн" болгож тохируулна уу. Энэ нь таны бичлэгийн хурдыг мэдэгдэхүйц хурдасгах болно. Хамгийн гол нь ялгавартай нөөцлөлтийг заасан хугацаанд хийж болно.

Нэмэлт өгөгдлийн файлуудыг үүсгэснээр бид I/O үед TempDB-тэй ажиллахад сайжирсан. Хэрэв 8-аас цөөн тооны логик процессор байгаа бол логик процессор бүрт өгөгдлийн файл үүсгэхийг зөвлөж байна. Хэрэв 8-аас дээш логик процессор байгаа бол 8 өгөгдлийн файл үүсгэхийг зөвлөж байна, 4-ийн үржвэрээр нэгээр нэмэгдэж, TempDB дээрх ачааллыг тооцоолохоо мартуузай.

2012 оны 11 сарын 1 Чөлөөт тараагдсан ашиглах давуу тал програм хангамжойлгомжтой. Харамсалтай нь сул талууд нь бас тодорхой байна - албан ёсны дэмжлэг байхгүй, баримт бичиг нь ихэвчлэн зөрчилтэй, бүрэн бус, тархсан байдаг. өөр өөр эх сурвалж. Энэ нийтлэл нь албан ёсны баримт бичигт заагаагүй бэрхшээлээс зайлсхийх, 1C: Enterprise 8-д зориулсан PosgreSQL-ийг суулгах үйл явцыг ойлгоход тусална.

Суулгахад шаардлагатай бүрэлдэхүүн хэсгүүд

PostgreSQL DBMS нь үнэ төлбөргүй тараагддаг бөгөөд 1С програмын серверийн хүргэх багцад багтсан болно. 1C: Enterprise 8 програмын сервер нь 32 бит ба 64 бит гэсэн хоёр хувилбартай. Postgre хоёуланг нь зохицуулж чадна.

Тиймээс, бидэнд түгээлтийн иж бүрдэл бэлэн байна:

• Postgre: postgresql-9_1_2-1_1Cx64.zip, 1С-ээс өгсөн.
• Windows x64, 8.2.16.368 хувилбарт зориулсан 1C: Enterprise програмын серверийн түгээлт.

Энэ нь илүү хялбар биш юм шиг санагдаж байна - зүгээр л эхлүүлээд суулгаарай. Амархан! Гэхдээ стандарт горимд суулгах нь нэг жижиг хязгаарлалтыг өгөх болно: кластер нь "Program Files" хавтсанд байрлана. Хүн болгонд таалагдахгүй байх. Энгийн болон дэвшилтэт суулгацын хоёр сонголтыг авч үзье.

Нийтлэл нь 5 хэсэгт хуваагдана:

1) 1С сервер суурилуулах.

2) PostgreSQL-ийг нэмэлт тохиргоогүйгээр 1С ажиллуулахад хангалттай стандарт хэлбэрээр суулгана уу.

3) PostgreSQL-г суулгаад кластер хадгалах хавтсыг сонгоно уу.

4) 1С мэдээллийн шинэ бааз бий болгох.

5) DBMS сервер дээр өгөгдлийн сангийн файлуудыг хадгалах хавтсыг зааж өгөх.

Суулгахаасаа өмнө нийтлэлийг бүхэлд нь уншихаа мартуузай!

1С програмын сервер суурилуулах

Бид setup.exe файлыг 1С серверийн түгээлтийн хэрэгсэл бүхий хавтсаас эхлүүлнэ.

Хэрэв та програмын серверийг үйлчилгээ болгон суулгаагүй бол үүнийг хийх бүрдээ гараар эхлүүлэх шаардлагатай болно. Энэ сонголт нь ховор тохиолддог. Бид үүнийг үйлчилгээ болгон суулгаж, аль хэрэглэгчийн доор ажиллуулахаа шийднэ. Аюулгүй байдлын үүднээс үйлчилгээг бүрэн эрхээр ажиллуулахыг зөвшөөрөхийн оронд USR1CV82 тусдаа хэрэглэгч үүсгэх нь дээр.

Програмын серверийг суулгасны дараа систем таныг HASP хамгаалалтын түлхүүр драйверийг суулгахыг хүсэх болно. Бид санал нэг байна:

Бид мессеж хүлээж байна:

Хэрэв мессеж өөр байвал HASP драйверуудын өмнөх суулгацуудаас системд "сүүл" үлдсэн байх магадлалтай. Бүгдийг устгаад дахин оролдоно уу.

Дууслаа, бид 1C: Enterprise 8 програмын серверийг амжилттай суулгалаа.

PostgreSQL-ийг стандарт хэлбэрээр суулгах нь нэмэлт тохиргоогүйгээр 1С-г ажиллуулахад хангалттай

"postgresql-9.1.2-1.1C(x64).msi"-г ажиллуул

Та суулгах сонголтыг өөрчлөх шаардлагагүй, 1С ажиллах болно. Цаашид.

Postgre нь 1С серверийн нэгэн адил та үйлчилгээгээ ажиллуулах хэрэглэгчийг өөрөө үүсгэж болно. Хэрэв та зааж өгвөл би таны анхаарлыг хандуулж байна дансадминистраторын эрхтэй бол үйлчилгээ зөв ажиллахгүй. Шинэ хэрэглэгч үүсгэхээ мартуузай.

Дараагийн суулгах цонх.

Бид кластерыг эхлүүлдэг. Хэрэв манай мэдээллийн баазын сервер болон 1С програмын сервер дээр байрладаг бол янз бүрийн компьютерууд, дараа нь "Аливаа IP-ээс холболтыг дэмжих" хайрцгийг чагтална уу, эс тэгвээс бид үүнд хүрэхгүй. UTF8 кодчиллыг зааж өгөхөө мартуузай. DBMS супер хэрэглэгч үүсгэх. Цааш нь…

Эхний ажлын хувьд бидэнд нэмэлт зүйл хэрэггүй, хайрцгийн тэмдэглэгээг арилгаад суулгацыг дуусгана уу.

Бидний хүчин чармайлтын үр дүн бол ашиглахад бэлэн PostgreSQL юм. Хэрэв бид өгөгдлийн сангууд нь Program Files\PostgreSQL\9.1.2-1.1C\data-д байрлана гэдэгт итгэлтэй байвал бид үүгээр дуусч, мэдээллийн санг нээж, үйл явцыг таашаална. Гэсэн хэдий ч ихэнх тохиолдолд мэдээллийн сан нь тусгайлан зохион бүтээсэн дискний массив дээр "худлаа" байдаг бөгөөд дээр биш системийн диск. Өгөгдлийн байршлыг тохируулахын тулд суулгахаасаа өмнө дараах хэсгийг уншина уу.

Кластер хадгалах байршлыг сонгох замаар Postgre-г суулгаж байна

Бид Postgre-г суулгаж, кластерыг эхлүүлэхийг хүсэх хүртэл бүх алхмуудыг гүйцэтгэнэ.

"Өгөгдлийн сангийн кластерийг эхлүүлэх" сонголтыг арилгаад "Дараах" дээр дарна уу.

Тийм ээ, бид итгэлтэй байна.

"Гарах үед Stack Builder-г ажиллуулах" гэснийг сонгоод суулгацыг дуусгана уу.

1. Бидний PostgreSQL суулгасан хавтсанд бүрэн эрхийг өгөх шаардлагатай бөгөөд энэ нь ихэвчлэн C:\Program Files\PostgreSQL юм.

2. cmd-г администратороор ажиллуул. Хэрэв та үүнийг win7 дээр хийвэл администратороор ажиллуулна уу.

3. Кластер хадгалагдах хавтас үүсгэ. Жишээ нь d:\postgredata.

md d:\postgredata

4. Бид кластерыг хаана байрлуулах замыг зааж, гараар эхлүүлдэг.

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

5. Суулгах явцад суулгасан PostgreSQL үйлчилгээг устгана уу.

sc устгах pgsql-9.1.2-1.1C-x64

pgsql-9.1.2-1.1C-x64 нь үйлчилгээний нэр юм. Хэрэв та нэрийг нь сайн мэдэхгүй байгаа бол "PostgreSQL мэдээллийн баазын сервер..." үйлчилгээний шинж чанарыг харж болно (Эхлүүлэх - Хяналтын самбар - Захиргааны хэрэгсэл - Үйлчилгээ)

6. Үүсгэх шинэ үйлчилгээманай кластерийг харуулж байна

“C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\pg_ctl” регистр -N pgsql -U postgresql -P нууц үг -D d:/postgredata

7. Одоо үйлчилгээ рүүгээ орцгооё. Эхлэх - Хяналтын самбар - Удирдлага - Үйлчилгээнүүд рүү ороод манай үйлчилгээг эхлүүлнэ үү.

PostgreSQL-тэй сервер дээр шинэ 1С мэдээллийн сан үүсгэх

Мэдээллийн сан үүсгэх хэд хэдэн сонголт байдаг. Та 1С серверийн удирдлагын консол болох pgAdmin3-ээр дамжуулан мэдээллийн сан үүсгэхийг оролдож болно. Гэхдээ энд та маш олон ойлгомжгүй асуулт, олон тооны алдаатай тулгарах болно, та хариултыг удаан хугацаанд хайж олох болно. Үүнийг мэргэжилтнүүдэд даатга. Бидний зорилго бол хамгийн бага хүчин чармайлтаар ажлын суурийг бий болгох явдал юм. Үүнд хүрэх хамгийн хялбар аргыг тайлбарлая.

Бид 1С үйлчлүүлэгчийг ажиллуулж байна.

"Нэмэх..." дээр дарна уу.

Бид мэдээллийн сангийн нэрийг гаргаж ирээд "1С: Enterprise сервер дээр" гэж зааж өгнө.

Серверийн кластер 1С: Аж ахуйн нэгж– localhost, хэрэв бид 1С сервер суулгасан ижил компьютер дээр мэдээллийн бааз үүсгэж байгаа бол, эсвэл өөр компьютер дээр байгаа бол 1С програмын серверийн нэр.

Кластер дахь мэдээллийн сангийн нэр- ирээдүйд бусад компьютерээс холбогдох үед энэ нэрийг зааж өгөх болно.

DBMS төрөл– PostgreSQL-г сонгоно уу.

Өгөгдлийн сангийн сервер- PostgreSQL серверийн нэрийг заана уу. Хэрэв бид сервер дээр мэдээллийн сан үүсгэвэл localhost-ийг мөн зааж өгнө.

Өгөгдлийн сангийн нэр– энэ нэрээр PostgreSQL дээр мэдээллийн сан үүсгэгдэнэ.

Хэрэглэгч, нууц үг– PostgreSQL-г суулгахдаа бидний супер хэрэглэгч гэж тодорхойлсон хэрэглэгчийн нэр. "Хэрэв байхгүй бол мэдээллийн сан үүсгэх" хайрцгийг шалгахаа мартуузай.

Асуулт гарч ирнэ - мэдээллийн сан хаана хадгалагдах вэ? Заасан кластерын үндсэн хавтсанд. Хэрэв бид бүх суурь нь байгаа газарт хэвтэхийг хүсэхгүй байвал яах вэ? Бидэнд одоохондоо хийж чадах зүйл алга, бид зүгээр л бааз байгуулаад цааш явах болно. Цааш нь…

Өгөгдлийн сангийн хадгалах хавтсыг тодорхойлж байна

Тиймээс бид бааз суурийг бий болгосон. Ихэнх тохиолдолд суулгац энд дуусдаг. Гэсэн хэдий ч, хэрэв олон мэдээллийн сан байгаа бол өөр өөр бүлгийн мэдээллийн санд зориулсан хэд хэдэн дискний массив байгаа бол мэдээллийн санг хаана байрлуулах ёстойг зааж өгөх хэрэгтэй. Үүнийг хийхийн тулд Start - Programs - PostgreSQL хэсгээс pgAdmin3-г ажиллуулна уу. Манай серверт холбогдоно уу.

Таныг анх холбогдох үед Postgre нь postgres хэрэглэгчээс нууц үг асуух болно (суулгах явцад бидний үүсгэсэн).

Бид шинэ TableSpace үүсгэсэн бөгөөд энэ нь бидний мэдээллийн сан хадгалагдах хавтас байх болно.

Өгөгдлийн сангийн файлуудыг хадгалах байршлыг зааж өгсөн. БОЛЖ БАЙНА УУ.

Одоо бид өмнө нь үүсгэсэн мэдээллийн сангийн шинж чанарыг нээж, байршлыг нь өөрчлөхийг хүсч байна.

Tablespace шинж чанарыг өөрчлөх. "OK" товчийг дарсны дараа мэдээллийн сангийн файлууд автоматаар зөөгдөнө. Бэлэн! Нийтлэл танд хэрэгтэй байсан гэж найдаж байна. Хэрэв тийм бол сэтгэгдлээ үлдээж, энэ хуудасны холбоосыг хуваалцаарай. Баярлалаа!