نصب 1c و postgres در ویندوز. PostgreSQL را نصب کنید. اتصال یک منبع داده خارجی

این مقاله ادعا نمی کند که ارائه کاملی از تمام گزینه های پیکربندی PostgreSQL است، و در آزمایش مقایسه ای، من همه حالت های عملیات پایگاه داده را پوشش نمی دهم. به علاقه مندان توصیه می کنم کتاب را در لینک مطالعه کنند

معرفی

من خیلی با PostgreSQL کار کرده ام و فکر می کنم یک DBMS عالی است. من یک پایگاه داده چند گیگابایتی دارم (نه 1C) که فوراً حجم عظیمی از داده را پردازش می کند. PostgreSQL به خوبی از فهرست ها استفاده می کند، به خوبی با بارهای کاری موازی کنار می آید، عملکرد رویه های ذخیره شده عالی است، ابزارهای مدیریت و عملکرد خوب خارج از جعبه وجود دارد، و جامعه ایجاد کرده است. ابزارهای مفید. اما وقتی فهمیدم بسیاری از مدیران 1C نظر ضعیفی درباره PostgreSQL دارند، متعجب شدم، که کند است و به سختی از نسخه فایل پایگاه داده بهتر است و فقط MSSQL می تواند وضعیت را نجات دهد.

پس از بررسی این سوال، مقالات زیادی در مورد نصب گام به گام PostgreSQL برای Dummies، هم در لینوکس و هم در ویندوز پیدا کردم. اما اکثریت قریب به اتفاق مقالات نصب را تا زمانی که "نصب - بیایید یک پایگاه داده ایجاد کنیم" را توصیف می کنند و به هیچ وجه به موضوع پیکربندی اشاره نمی کنند. در بقیه موارد، پیکربندی فقط در سطح "مشخص کردن چنین مقادیر" ذکر شده است، بدون هیچ توضیحی برای علت.

و اگر رویکرد "نصب با یک دکمه" برای MSSQL و بسیاری از محصولات به طور کلی برای ویندوز قابل اجرا باشد، متأسفانه برای PostgreSQL اعمال نمی شود. تنظیمات پیش فرض استفاده از حافظه آن را تا حد زیادی محدود می کند، به طوری که می توانید آن را حتی بر روی ماشین حساب نصب کنید و در عملکرد بقیه نرم افزارها اختلال ایجاد نمی کند. PostgreSQL باید برای یک سیستم خاص پیکربندی شود و تنها در این صورت می تواند بهترین عملکرد خود را نشان دهد. در موارد شدید، می توانید تنظیمات PostgreSQL، پایگاه داده و سیستم فایلیکدیگر، اما این به میزان بیشتری در مورد سیستم های لینوکس صدق می کند، جایی که فرصت های بیشتری برای سفارشی کردن همه چیز وجود دارد.

لازم به یادآوری است که برای 1C مونتاژ PostgreSQL از توسعه دهندگان DBMS مناسب نیست، فقط از کدهای منبع 1C وصله شده مونتاژ شده است. مجموعه های سازگار آماده توسط 1C (از طریق دیسک های ITS و یک حساب کاربری برای کسانی که دارای اشتراک پشتیبانی هستند) و EterSoft ارائه می شوند.

آزمایش در انجام شد محیط ویندوز، اما همه توصیه های پیکربندی مختص پلتفرم نیستند و برای هر سیستم عاملی اعمال می شوند.

تست و مقایسه

هنگام آزمایش، من تصمیم به انجام آزمایش در همه حالت‌ها و سناریوهای عملیاتی نداشتم، فقط یک بررسی تقریبی از پیکربندی موفقیت آمیز بود.

برای تست از پیکربندی زیر استفاده کردم:
دستگاه میزبان: Win7، Core i5-760 2.8 مگاهرتز، 4 هسته، 12 گیگابایت رم، VMWare 10
مجازی: Win7 x64، 2 هسته، 4 گیگابایت رم، فیزیکی مجزا HDDبرای میزبانی پایگاه داده (نه SSD)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
1C 8.3.5 1383

یک پایگاه داده استفاده شد، dt-upload 780MB.
پس از بازیابی پایگاه داده:
اندازه فایل 1CD در نسخه فایل - 10 گیگابایت،
اندازه پایگاه داده PostgreSQL - 8 گیگابایت،
حجم پایگاه داده MSSQL 6.7 گیگابایت است.

برای آزمایش، من از یک درخواست برای نمونه قراردادهای طرف مقابل (21k) با انتخاب جزئیات اضافی از رجیسترهای مختلف استفاده کردم؛ برای هر توافق، یک نمونه جداگانه در واقع از رجیسترها ساخته شد. من پیکربندی را که در دسترس بود انتخاب کردم - به شدت بر اساس حسابداری 3.0 اصلاح شد.

در طول آزمایش، من درخواست را با یک و دو مشتری چندین بار اجرا کردم تا اینکه نتایج پایدار به دست آمد. اولین دویدن ها را نادیده گرفتم.

تست با یک مشتری:

نمونه برداری روی هاست از نسخه فایل با پایگاه داده قرار داده شده بر روی SSD - 31c
انتخاب از یک نوع فایل در ماشین مجازی(با هارد دیسک) - 46s
نمونه برداری از پایگاه داده MSSQL - پاس اول - 25 ثانیه یا 9 ثانیه (ظاهراً بسته به ارتباط حافظه پنهان DBMS) (مصرف حافظه توسط فرآیند DBMS تقریباً 1.3 گیگابایت بود)
نمونه برداری از PostgreSQL با تنظیمات پیش فرض - 43 ثانیه (مصرف حافظه در هر اتصال از 80 مگابایت تجاوز نمی کند)
نمونه برداری از PostgreSQL بهینه شده - 21s (مصرف حافظه 120 مگابایت در هر اتصال بود)

تست با دو مشتری:

نمونه برداری روی هاست از نسخه فایل با پایگاه داده قرار داده شده بر روی یک SSD - هر کدام 34 ثانیه
نمونه برداری از نسخه فایل در ماشین مجازی (از هارد دیسک) - هر کدام 56 ثانیه
نمونه برداری از پایگاه داده MSSQL - 50s یا 20s (ظاهرا بسته به ارتباط حافظه پنهان DBMS)
نمونه برداری از PostgreSQL با تنظیمات پیش فرض - هر کدام 60 ثانیه
نمونه برداری از PostgreSQL بهینه - هر کدام 40 ثانیه

نکات تست:

  1. پس از افزودن هسته سوم، انواع PostgreSQL و MSSQL در تست "دو مشتری" تقریباً با عملکرد تست "یک مشتری" شروع به کار کردند. با موفقیت موازی شد. چه چیزی آنها را از موازی کاری روی دو هسته باز داشت برای من یک راز باقی ماند.
  2. MSSQL به طور همزمان مقدار زیادی از حافظه را اشغال کرد، PostgreSQL به میزان قابل توجهی در همه حالت ها نیاز کمتری داشت و تقریباً همه آن را بلافاصله پس از تکمیل پرس و جو منتشر کرد.
  3. MSSQL به عنوان یک فرآیند واحد اجرا می شود. PostgreSQL یک فرآیند جداگانه در هر اتصال + فرآیندهای سرویس راه اندازی می کند. این امر حتی به نوع 32 بیتی اجازه می دهد تا هنگام پردازش درخواست های چندین مشتری، از حافظه به طور موثر استفاده کند.
  4. افزایش حافظه برای PostgreSQL در تنظیمات بالاتر از مقادیر نشان داده شده در زیر منجر به افزایش قابل توجهی در عملکرد نشد.
  5. اولین آزمایش ها در همه موارد بیشتر از اندازه گیری های بعدی طول کشید؛ من هیچ اندازه گیری خاصی انجام ندادم، اما MSSQL به طور ذهنی سریعتر شروع شد.

پیکربندی PostgreSQL

یک کتاب عالی به زبان روسی در مورد پیکربندی و بهینه سازی PostgreSQL وجود دارد: برای هر دوستدار فیل منطقی است که این پیوند را نشانه گذاری کند. این کتاب تکنیک‌های زیادی را برای بهینه‌سازی DBMS، ایجاد سیستم‌های متحمل خطا و توزیع شده توضیح می‌دهد. اما اکنون به چیزی نگاه خواهیم کرد که برای همه مفید خواهد بود - پیکربندی استفاده از حافظه. PostgreSQL بیش از حد مجاز تنظیمات از حافظه استفاده نمی کند و با تنظیمات پیش فرض PostgreSQL از حداقل حافظه استفاده می کند. در عین حال، نباید حافظه بیشتری از آنچه برای استفاده در دسترس است مشخص کنید - سیستم شروع به استفاده از فایل swap با تمام عواقب ناگوار بعدی برای عملکرد سرور خواهد کرد. تعدادی نکته برای راه اندازی PostgreSQL در دیسک ITS ارائه شده است.

در ویندوز، فایل های پیکربندی PostgreSQL در پوشه نصب در پوشه Data قرار دارند:

  • postgresql.conf- فایل اصلی با تنظیمات DBMS
  • pg_hba.conf- یک فایل با تنظیمات دسترسی برای مشتریان. به طور خاص، در اینجا می توانید مشخص کنید که کدام کاربران از چه آدرس های IP می توانند به پایگاه داده های خاص متصل شوند و آیا لازم است رمز عبور کاربر بررسی شود و اگر چنین است، با چه روشی.
  • pg_ident.conf- یک فایل با تبدیل نام کاربری از سیستم به داخلی (بعید است اکثر کاربران به آن نیاز داشته باشند)

فایل ها متنی هستند، می توانید آنها را با دفترچه یادداشت ویرایش کنید. خطوطی که با # نظر تلقی می شوند و نادیده گرفته می شوند.

پارامترهای مربوط به ظرفیت حافظه را می توان با پسوندهای kB، MB، GB تکمیل کرد - کیلوبایت، مگابایت، گیگابایت، به عنوان مثال، 128 مگابایت. پارامترهایی که فواصل زمانی را توصیف می کنند را می توان با پسوندهای ms، s، min، h، d - میلی ثانیه، ثانیه، دقیقه، ساعت، روز، به عنوان مثال، 5 دقیقه تکمیل کرد.

اگر رمز عبور Postgress را فراموش کرده اید، مشکلی نیست، می توانید آن را در آن بنویسید pg_hba.confخط:

میزبان همه 127.0.0.1/32 Trust

و توسط هر کاربری وصل شوید (به عنوان مثال، postgres) به DBMS در ماشین محلی در 127.0.0.1 بدون بررسی رمز عبور.

بهينه سازياستفاده از حافظه

تنظیمات استفاده از حافظه در آن قرار دارد postgresql.conf

مقادیر پارامتر بهینه به حجم آزاد بستگی دارد حافظه دسترسی تصادفی، اندازه پایگاه داده و عناصر جداگانه پایگاه داده (جدول ها و نمایه ها)، پیچیدگی پرس و جوها (در اصل، باید فرض کنید که پرس و جوها کاملاً پیچیده خواهند بود - اتصالات متعدد در پرس و جوها یک سناریوی معمولی هستند) و تعداد مشتریان فعال همزمان به هر حال، PostgreSQL جداول و فهرست های پایگاه داده را در آن ذخیره می کند فایل های جداگانه (<каталог установки PG>\داده\پایه\<идентификатор БД>\)، و اندازه اشیا را می توان تخمین زد. همچنین می‌توانید از ابزار pgAdmin برای اتصال به پایگاه داده، گسترش «Schemas» - «public» و ایجاد گزارش آماری برای عنصر «Tables» استفاده کنید.

در مرحله بعد، من مقادیر تقریبی را ارائه می دهم که از آنها می توانید تنظیم را شروع کنید. بعد از راه اندازی اولیهتوصیه می شود سرور را در حالت های عملیاتی اجرا کنید و مصرف حافظه را نظارت کنید. بسته به نتایج به دست آمده، ممکن است نیاز به تنظیم مقادیر پارامتر باشد.

هنگام تنظیم سرور برای آزمایش، من به محاسبات زیر اتکا کردم:
فقط 4 گیگابایت رم. مصرف کنندگان - سیستم عامل ویندوز، سرور 1C، PostgreSQL و حافظه پنهان دیسک سیستم. من فرض کردم که حداکثر 2.5 گیگابایت رم می تواند برای DBMS اختصاص یابد

مقادیر را می توان با پسوندهای kB، MB، GB (مقادیر بر حسب کیلو بایت، مگابایت یا گیگابایت) مشخص کرد. پس از تغییر مقادیر، باید سرویس PostgreSQL را مجددا راه اندازی کنید.

shared_buffers - بافر سرور مشترک

اندازه حافظه پنهان خواندن و نوشتن PostgreSQL که توسط همه اتصالات به اشتراک گذاشته شده است. اگر داده ها در حافظه پنهان نباشد، از دیسک خوانده می شود (احتمالاً توسط سیستم عامل ذخیره شده است)

اگر اندازه بافر برای ذخیره داده‌های کاری که اغلب استفاده می‌شود کافی نباشد، به طور مداوم از حافظه پنهان سیستم‌عامل یا دیسک نوشته و خوانده می‌شود، که تأثیر بسیار منفی بر عملکرد خواهد داشت.

اما این تمام حافظه مورد نیاز برای عملکرد نیست، شما نباید بیش از حد مشخص کنید پراهمیت، در غیر این صورت هیچ حافظه ای هم برای اجرای واقعی درخواست های مشتری (و هرچه بیشتر باشد، مصرف حافظه بیشتر است) و هم برای سیستم عامل و سایر برنامه ها، به عنوان مثال، فرآیند سرور 1C باقی نمی ماند. سرور همچنین به کش سیستم عامل متکی است و سعی می کند آنچه را که به احتمال زیاد توسط سیستم ذخیره می شود در بافر خود نگه ندارد.

تست استفاده شده

shared_buffers = 512 مگابایت

work_mem- حافظه برای مرتب سازی، تجمیع داده ها و غیره

برای هر درخواست، احتمالاً چندین بار برای درخواست های پیچیده اختصاص داده می شود. اگر حافظه کافی وجود نداشته باشد، PostgreSQL از فایل های موقت استفاده می کند. اگر مقدار خیلی بزرگ باشد، ممکن است از RAM بیش از حد استفاده شود و سیستم عامل شروع به استفاده از فایل swap با کاهش عملکرد مربوطه کند.

هنگام محاسبه توصیه می شود که مقدار حافظه موجود را منهای در نظر بگیرید shared_buffers، و بر تعداد درخواست هایی که به طور همزمان اجرا می شوند تقسیم کنید. در مورد پرس و جوهای پیچیده، تقسیم کننده باید افزایش یابد، یعنی. نتیجه را کاهش دهد. برای مورد مورد بررسی، بر اساس 5 کاربر فعال (2.5GB-0.5GB (shared_buffers))/5=400MB. اگر DBMS پرس و جوها را کاملاً پیچیده در نظر بگیرد، یا اگر کاربران بیشتری ظاهر شوند، مقدار باید کاهش یابد.

برای پرس و جوهای ساده، مقادیر کوچک کافی است - تا چند مگابایت، اما برای پرس و جوهای پیچیده (و این یک سناریوی معمولی برای 1C است) بیشتر مورد نیاز است. توصیه - برای حافظه 1-4 گیگابایت می توانید از مقادیر 32-128 مگابایت استفاده کنید. من از آن در آزمون استفاده کردم

work_mem = 128 مگابایت

maintenance_work_mem- حافظه برای دستورات جمع آوری زباله، آمار، ایجاد فهرست.

توصیه می شود مقدار را 50-75 درصد از اندازه بزرگترین جدول یا شاخص تنظیم کنید، اما به اندازه ای که حافظه برای اجرای سیستم و برنامه ها وجود داشته باشد. توصیه می شود مقادیری بیشتر از work_mem تنظیم کنید. من از آن در آزمون استفاده کردم
maintenance_work_mem = 192 مگابایت

temp_buffers- یک بافر برای اشیاء موقت، عمدتاً برای جداول موقت.

شما می توانید حدود 16 مگابایت نصب کنید. من از آن در آزمون استفاده کردم
temp_buffers = 32 مگابایت

effect_cache_size- اندازه تقریبی حافظه پنهان دیسک سیستم فایل.

بهینه ساز از این مقدار در هنگام ساخت یک طرح پرس و جو برای تخمین احتمال یافتن داده ها در حافظه پنهان (با دسترسی تصادفی سریع) یا روی یک دیسک آهسته استفاده می کند. در ویندوز، مقدار فعلی حافظه اختصاص داده شده برای کش را می توان در مدیر وظیفه مشاهده کرد.

اتو وکیوم - "جمع آوری زباله"

PostgreSQL، به عنوان یک نماینده معمولی DBMS های "نسخه شده" (برخلاف موارد مسدود کننده)، جداول و سوابق را به طور مستقل از خواندن تراکنش ها هنگام تغییر داده مسدود نمی کند (در مورد 1C، ​​خود سرور 1C این کار را انجام می دهد). در عوض، یک کپی از رکورد اصلاح شده ایجاد می‌شود که برای تراکنش‌های بعدی قابل مشاهده می‌شود، در حالی که تراکنش‌های موجود همچنان داده‌هایی را می‌بینند که در ابتدای تراکنش جاری بوده است. در نتیجه، جداول داده های قدیمی را جمع آوری می کنند - نسخه های قبلی رکوردهای تغییر یافته. برای اینکه DBMS از فضای آزاد شده استفاده کند، باید "جمع آوری زباله" را انجام داد - تا مشخص شود کدام یک از رکوردها دیگر استفاده نمی شود. این را می توان به صراحت با یک دستور SQL انجام داد خلاء، یا صبر کنید تا جدول توسط زباله جمع کننده خودکار پردازش شود - AUTOVACUUM. همچنین، تا یک نسخه خاص، جمع‌آوری زباله با جمع‌آوری آمار همراه بود (برنامه‌ریز از داده‌های تعداد رکوردها در جداول و توزیع مقادیر فیلدهای نمایه‌شده برای ساخت یک طرح پرس و جو بهینه استفاده می‌کند). از یک طرف، جمع آوری زباله باید انجام شود تا جداول رشد نکنند و به طور موثر از فضای دیسک استفاده نکنند. از طرف دیگر، جمع آوری زباله به طور ناگهانی شروع به بار اضافی روی دیسک و جداول می کند که منجر به افزایش زمان اجرای پرس و جو می شود. یک اثر مشابه با جمع‌آوری آمار خودکار ایجاد می‌شود (بدیهی است که می‌توان آن را با دستور راه‌اندازی کرد تجزیه و تحلیلیا همراه با جمع آوری زباله آنالیز خلاء). و اگرچه PostgreSQL این مکانیسم ها را از نسخه ای به نسخه دیگر بهبود می بخشد تا به حداقل برسد تاثیر منفیدر مورد عملکرد (به عنوان مثال، در نسخه های قبلی، مجموعه زباله دسترسی به جدول را به طور کامل مسدود کرد، از نسخه 9.0 کار خلاءتسریع شده)، چیزی برای پیکربندی در اینجا وجود دارد.

می توانید با پارامتر زیر کاملاً خلاء خودکار را غیرفعال کنید:

autovacuum = خاموش

همچنین برای کارکرد Autovacuum پارامتر track_counts = on لازم است در غیر این صورت کار نمی کند.

به طور پیش فرض هر دو گزینه فعال هستند. در واقع، autovacuum را نمی توان به طور کامل غیرفعال کرد - حتی با autovacuum = خاموش، گاهی اوقات (پس از تعداد زیادی تراکنش) autovacuum شروع می شود.

اظهار نظر: خلاءمعمولاً اندازه فایل جدول را کاهش نمی دهد، فقط مناطق آزاد موجود برای استفاده مجدد را علامت گذاری می کند. اگر می خواهید فضای اضافی را به صورت فیزیکی آزاد کنید و فضای اشغال شده دیسک را به حداقل برسانید، به دستور نیاز دارید VACUUM FULL. این گزینه دسترسی به جدول را در حین اجرا مسدود می کند و معمولاً مورد نیاز نیست. اطلاعات بیشتر در مورد استفاده از دستور VACUUM را می توان در مستندات (به زبان انگلیسی) یافت.

اگر Autovacuum به طور کامل غیرفعال نیست، می‌توانید با استفاده از پارامترهای زیر تأثیر آن را بر اجرای کوئری پیکربندی کنید:

autovacuum_max_workers- حداکثر تعداد به صورت موازی فرآیندهای در حال اجراتمیز کردن

autovacuum_naptime - حداقل فاصله کمتر از زمانی که autovacuum شروع نمی شود. پیش فرض 1 دقیقه است. می توانید آن را افزایش دهید، سپس اگر داده ها به طور مکرر تغییر کنند، تجزیه و تحلیل کمتر انجام می شود.

autovacuum_vacuum_threshold, - تعداد رکوردهای تغییر یافته یا حذف شده در جدول مورد نیاز برای شروع فرآیند جمع آوری زباله خلاءیا جمع آوری آمار تجزیه و تحلیل. پیش فرض 50 است.

autovacuum_vacuum_scale_factor , autovacuum_analyze_scale_factor - ضریب اندازه جدول در رکوردهای اضافه شده به autovacuum_vacuum_thresholdو autovacuum_analyze_thresholdبه ترتیب. مقادیر پیش فرض به ترتیب 0.2 (یعنی 20٪ از تعداد رکوردها) و 0.1 (10٪) هستند.

بیایید یک مثال با یک جدول با 10000 رکورد در نظر بگیریم. سپس با تنظیمات پیش فرض، پس از 50+10000*0.1=1050 تغییر یا حذف رکوردها، جمع آوری آمار شروع می شود. تجزیه و تحلیل، و پس از تغییرات 2050 - جمع آوری زباله خلاء.

اگر آستانه و scale_factor را افزایش دهید، فرآیندهای تعمیر و نگهداری کمتر اجرا می شوند، اما جداول کوچک می توانند رشد قابل توجهی داشته باشند. اگر پایگاه داده عمدتاً از جداول کوچک تشکیل شده باشد، افزایش کلی در مصرف فضای دیسک می تواند قابل توجه باشد، بنابراین می توانید این مقادیر را افزایش دهید، اما عاقلانه.

بنابراین، ممکن است منطقی باشد که فاصله autovacuum_naptime را افزایش دهیم و آستانه و ضریب مقیاس را کمی افزایش دهیم. در پایگاه داده های بارگذاری شده، ممکن است جایگزینی برای افزایش قابل توجه scale_factor باشد (مقدار 1 به جداول اجازه می دهد تا دو بار متورم شوند) و اجرای روزانه را به زمان بندی تنظیم کنید. آنالیز خلاءدر دوره هایی با حداقل بارگذاری پایگاه داده

default_statistics_target - مقدار آمار جمع آوری شده توسط دستور را تعیین می کند تجزیه و تحلیل. مقدار پیش‌فرض 100 است. مقادیر بزرگ‌تر زمان اجرای دستور ANALYZE را افزایش می‌دهد، اما به زمان‌بند اجازه می‌دهد تا طرح‌های پرس و جو کارآمدتری بسازد. توصیه هایی برای افزایش به 300 وجود دارد.

عملکرد قابل کنترل است AUTOVACUUM، آن را طولانی تر می کند اما استرس کمتری روی سیستم ایجاد می کند.

vacuum_cost_page_hit- اندازه "جریمه" برای پردازش یک بلوک واقع در shared_buffers. مرتبط با نیاز به مسدود کردن دسترسی به بافر. مقدار پیش فرض 1

vacuum_cost_page_miss - اندازه "جریمه" برای پردازش یک بلوک روی دیسک. با مسدود کردن بافر، جستجوی داده در بافر، خواندن داده ها از دیسک مرتبط است. مقدار پیش فرض 10

vacuum_cost_page_dirty- اندازه "جریمه" برای اصلاح بلوک. با نیاز به بازنشانی داده های اصلاح شده به دیسک مرتبط است. مقدار پیش فرض 20

خلاء_هزینه_حد - حداکثر اندازه"جریمه"، پس از آن فرآیند مونتاژ می تواند برای مدت زمان خلاء_هزینه_تاخیر "منجمد" شود. پیش فرض 200

خلاء_هزینه_تاخیر- زمان "انجماد" فرآیند جمع آوری زباله پس از رسیدن به vacuum_cost_limit. مقدار پیش فرض 0ms

autovacuum_vacuum_cost_delay- زمان "یخ زدن" فرآیند جمع آوری زباله برای اتو وکیوم. پیش فرض 20 میلی ثانیه است. اگر روی -1 تنظیم شود، مقدار vacuum_cost_delay استفاده خواهد شد

autovacuum_vacuum_cost_limit- حداکثر اندازه "جریمه" برای autovacuum. مقدار پیش‌فرض -1 - مقدار vacuum_cost_limit استفاده می‌شود

استفاده گزارش شده vacuum_cost_page_hit = 6, vacuum_cost_limit = 100, autovacuum_vacuum_cost_delay = 200ms تاثیر AUTOVACUUM را تا 80% کاهش می دهد، اما زمان اجرای آن را سه برابر می کند.

تنظیم ضبط دیسک

هنگامی که یک تراکنش کامل می شود، PostgreSQL ابتدا داده ها را در یک گزارش تراکنش ویژه WAL (Log پیش از نوشتن) می نویسد و سپس پس از تضمین نوشتن داده های گزارش روی دیسک، در پایگاه داده می نویسد. مکانیزم پیش فرض است fsync، زمانی که PostgreSQL به اجبار داده ها (log) را از حافظه پنهان دیسک سیستم عامل به دیسک پاک می کند و تنها پس از نوشتن موفقیت آمیز (log) به مشتری اطلاع داده می شود که تراکنش با موفقیت انجام شده است. استفاده از گزارش تراکنش به شما این امکان را می دهد که در صورت بروز مشکل در هنگام نوشتن داده ها، تراکنش را تکمیل کنید یا پایگاه داده را بازیابی کنید.

در سیستم‌های شلوغ با حجم نوشتن زیاد، ممکن است منطقی باشد که گزارش تراکنش را به یک دیسک فیزیکی جداگانه منتقل کنید (اما نه به پارتیشن دیگری از همان دیسک!). برای انجام این کار، باید DBMS را متوقف کنید، دایرکتوری pg_xlog را به مکان دیگری منتقل کنید، و یک پیوند نمادین در مکان قدیمی ایجاد کنید، به عنوان مثال، با استفاده از ابزار اتصال. Far Manager (Alt-F6) همچنین می تواند پیوند ایجاد کند. در این مورد، باید مطمئن شوید که مکان جدید دارای حقوق دسترسی برای کاربری است که PostgreSQL (معمولا postgres) را اجرا می کند.

اگر تعداد زیادی عملیات اصلاح داده وجود دارد، ممکن است لازم باشد مقدار checkpoint_segments را افزایش دهید، که مقدار داده‌هایی را که می‌توانند منتظر انتقال از گزارش به خود پایگاه داده باشند، کنترل می‌کند. مقدار پیش‌فرض 3 است. باید در نظر گرفت که فضا برای گزارش تخصیص داده شده است که با فرمول محاسبه می‌شود (قطعات_بررسی * 2 + 1) * 16 مگابایت که با مقدار 32 در حال حاضر به بیش از 1 گیگابایت دیسک نیاز دارد. فضا.

PostgreSQL پس از اتمام هر تراکنش نوشتن، داده‌ها را از حافظه پنهان فایل سیستم عامل به دیسک پاک می‌کند. از یک طرف، این تضمین می کند که داده های روی دیسک همیشه به روز هستند، از طرف دیگر، با تعداد زیادی از تراکنش ها، عملکرد کاهش می یابد. کاملا غیر فعال کنید fsyncبا مشخص کردن امکان پذیر است

fsync=خاموش
full_page_writes = خاموش

این تنها در صورتی انجام می شود که 100% به تجهیزات و UPS اعتماد داشته باشید (منبع منبع تغذیه اضطراری). در غیر این صورت، در صورت خرابی سیستم، خطر خراب شدن پایگاه داده وجود دارد. و در هر صورت، یک کنترلر RAID با یک باتری برای تغذیه حافظه داده های نانوشته نیز ضرری نخواهد داشت.

یک جایگزین قطعی ممکن است استفاده از پارامتر باشد

synchronous_commit = خاموش

در این حالت، پس از پاسخ موفقیت آمیز برای تکمیل تراکنش، ممکن است مدتی طول بکشد تا تراکنش به طور ایمن روی دیسک نوشته شود. در صورت خاموش شدن ناگهانی، پایگاه داده از بین نمی رود، اما داده های تراکنش های اخیر ممکن است از بین بروند.

اگر fsync را به طور کامل غیرفعال نکنید، می توانید روش همگام سازی را در پارامتر مشخص کنید. مقاله از دیسک ITS به ابزار pg_test_fsync اشاره دارد، اما در ساخت PostgreSQL من یافت نشد. به گفته 1C، در مورد آنها در ویندوز، این روش خود را بهینه نشان داد open_datasync(ظاهراً این روشی است که به طور پیش فرض استفاده می شود).

اگر بسیاری از تراکنش‌های نوشتن کوچک استفاده می‌شود (در مورد 1C ممکن است به‌روزرسانی انبوه دایرکتوری خارج از تراکنش باشد)، ترکیبی از پارامترهای commit_delay (زمان تاخیر تکمیل تراکنش در میکروثانیه، پیش‌فرض 0) و commit_siblings (پیش‌فرض 5) می تواند کمک کند. هنگامی که گزینه ها فعال هستند، ممکن است تکمیل تراکنش با commit_delay if به تاخیر بیفتد این لحظهحداقل تراکنش های commit_siblings اجرا می شوند. در این حالت، نتیجه تمام تراکنش‌های انجام‌شده با هم برای بهینه‌سازی نوشتن دیسک نوشته می‌شود.

سایر پارامترهای موثر بر عملکرد

wal_buffers- مقدار حافظه در shared_buffers برای نگهداری گزارش تراکنش ها. توصیه: با 1-4 گیگابایت حافظه در دسترس، از مقادیر 256 کیلوبایت تا 1 مگابایت استفاده کنید. مستندات بیان می کند که با استفاده از مقدار "-1" به طور خودکار مقدار را بسته به مقدار shared_buffers تنظیم می کند.

random_page_cost- "هزینه" خواندن تصادفی که هنگام جستجوی داده ها با استفاده از شاخص ها استفاده می شود. پیش فرض 4.0 است. واحد زمان دسترسی متوالی به داده است. برای آرایه های دیسک های سریع، به ویژه SSD ها، منطقی است که مقدار را کاهش دهیم؛ در این حالت، PostgreSQL از ایندکس ها استفاده فعال تری خواهد کرد.

کتاب موجود در پیوند دارای پارامترهای دیگری است که می توان آنها را پیکربندی کرد. همچنین اکیداً توصیه می شود که اسناد PostgreSQL را در مورد تخصیص پارامترهای خاص مطالعه کنید.

توصیه می‌شود پارامترها را از بخش QUERY TUNING تغییر دهید، به‌ویژه مواردی که مربوط به منع استفاده از روش‌های جستجوی خاص زمان‌بند است، تنها در صورتی که درک کاملی از کاری که انجام می‌دهید داشته باشید. بهینه سازی یک نوع پرس و جو و خراب کردن عملکرد بقیه بسیار آسان است. اثربخشی تغییر اکثر پارامترها در این بخش به داده های موجود در پایگاه داده، پرس و جوهای مربوط به این داده ها (به عنوان مثال، نسخه 1C استفاده شده، از جمله موارد دیگر) و نسخه DBMS بستگی دارد.

نتیجه

PostgreSQL یک DBMS قدرتمند در دستان توانمند است، اما نیاز به پیکربندی دقیق دارد. می توان از آن در ارتباط با 1C استفاده کرد و عملکرد مناسبی داشت و ماهیت رایگان آن یک امتیاز بسیار خوشایند خواهد بود.

نقد و اضافات این مقاله پذیرفته می شود.

لینک های مفید

http://postgresql.leopard.in.ua/ - وب سایت کتاب " کار با پیکربندی و مقیاس بندی PostgreSQL "، کامل ترین و قابل فهم ترین راهنمای، به نظر من، برای پیکربندی و مدیریت PostgreSQL

http://etersoft.ru/products/postgre - در اینجا می توانید بیلد PostgreSQL سازگار با 1C را برای ویندوز و توزیع ها و نسخه های مختلف لینوکس دانلود کنید. برای کسانی که اشتراک ITS ندارند یا به نسخه ای برای آن نیاز دارند نسخه لینوکس، که در v8.1c.ru ارائه نشده است.

http://www.postgresql.org/docs/9.2/static/ - اسناد رسمی در PostgreSQL (به زبان انگلیسی)

مقالاتی از دیسک ITS در مورد راه اندازی PostgreSQL

تاریخچه ویرایش مقاله

  • 1394/01/29 - نسخه اولیه منتشر شد
  • 2015/01/31 - مقاله با بخشی در AUTOVACUUM تکمیل شد، پیوندی به مستندات اصلی اضافه شد.

در آینده قصد دارم عملکرد DBMS را در حالت افزودن و تغییر داده آزمایش کنم.

ما یک مونتاژ از شرکت Postgres Professional نصب خواهیم کرد. در صفحه با نسخه 1C: Enterprise اطلاعاتی در مورد نصب آخرین نسخه PostgreSQL در CentOS 7 پیدا خواهیم کرد.

بیایید مخازن را به هم متصل کنیم و PostgreSQL 9.6 را نصب کنیم:

سودو دور در دقیقه -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 start postgresql-9.6 systemctl وضعیت postgresql-9.6

ما یک رمز عبور برای کاربر postgres تعیین می کنیم تا بتواند از راه دور به سرور متصل شود:

Su - postgres psql ALTER USER postgres با رمز عبور رمزگذاری شده "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

بهینه سازی تنظیمات PostgreSQL (postgresql.conf) برای 1C: Enterprise

در اینجا تنظیمات PostgreSQL در ماشین مجازی ESXi 6.5 اجرا می شود.

منابع اختصاص داده شده برای VM:

پردازنده - 8 vCPU؛

حافظه - 48 گیگابایت؛

دیسک برای سیستم عامل - 50 گیگابایت در سخت افزار LUN RAID1 از SAS HDD.

دیسک برای پایگاه داده - 170 گیگابایت در نرم افزار RAID1 از SSD

دیسک برای سیاهههای مربوط - 100 گیگابایت در نرم افزار RAID1 از SSD

برای ویرایش تنظیمات، دستور زیر را اجرا کنید:

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

پارامترهای نظر داده شده که ما تغییر خواهیم داد باید فعال شوند.

CPU

autovacuum_max_workers = 4

autovacuum_max_workers = NCores/4..2 اما نه کمتر از 4

تعداد فرآیندهای اتو وکیوم. قاعده کلی این است که هر چه درخواست های نوشتن بیشتر باشد، فرآیندهای بیشتری نیز خواهد داشت. در یک پایگاه داده فقط خواندنی، یک فرآیند کافی است.

ssl=خاموش

رمزگذاری را خاموش کنید برای مراکز داده ایمن، رمزگذاری بی معنی است، اما منجر به افزایش بار CPU می شود

حافظه

shared_buffers = 12 گیگابایت

shared_buffers = RAM/4

مقدار حافظه اختصاص داده شده توسط PgSQL برای کش صفحه مشترک. این حافظه در بین تمام فرآیندهای PgSQL مشترک است. سیستم عاملخود داده ها را کش می کند، بنابراین نیازی به تخصیص تمام RAM موجود برای کش نیست.

temp_buffers = 256 مگابایت

حداکثر تعداد صفحات برای جداول موقت. آن ها این حد بالایی در اندازه جداول موقت در هر جلسه است.

work_mem = 64 مگابایت

work_mem = RAM/32..64 یا 32MB..128MB

محدودیت حافظه برای پردازش یک درخواست این حافظه برای هر جلسه فردی است. از نظر تئوری، حداکثر حافظه مورد نیاز برابر با max_connections * work_mem است، در عمل این اتفاق نمی افتد زیرا اکثر جلسات تقریبا همیشه در انتظار هستند. این مقدار مشاوره توسط بهینه ساز استفاده می شود: سعی می کند اندازه حافظه مورد نیاز برای پرس و جو را پیش بینی کند و اگر این مقدار از work_mem بیشتر باشد، به مجری می گوید که فوراً یک جدول موقت ایجاد کند. work_mem به معنای کامل یک محدودیت نیست: بهینه ساز ممکن است از دست بدهد و درخواست حافظه بیشتری را اشغال کند، شاید چندین برابر بیشتر. این مقدار را می توان با نظارت بر تعداد فایل های موقت ایجاد شده کاهش داد:

maintenance_work_mem = 2 گیگابایت

maintenance_work_mem = RAM/16..32 یا work_mem * 4 یا 256 مگابایت..4 گیگابایت

محدودیت حافظه برای کارهای تعمیر و نگهداری، مانند جمع آوری آمار (ANALYZE)، جمع آوری زباله (VACUUM)، ایجاد نمایه ها (CREATE INDEX) و افزودن کلیدهای خارجی. اندازه حافظه اختصاص داده شده برای این عملیات باید قابل مقایسه باشد اندازه فیزیکیبزرگترین شاخص روی دیسک

effect_cache_size = 36 گیگابایت

effect_cache_size = RAM - shared_buffers

تخمین اندازه کش سیستم فایل افزایش پارامتر تمایل سیستم را برای انتخاب طرح های IndexScan افزایش می دهد. و این خوب است.

دیسک ها

effect_io_concurrency = 5

تخمینی از درخواست های همزمان به یک سیستم دیسکی که می تواند در یک زمان سرویس دهد. برای یک دیسک واحد = 1، برای RAID - 2 یا بیشتر.

random_page_cost = 1.3

random_page_cost = 1.5-2.0 برای RAID، 1.1-1.3 برای SSD

هزینه خواندن یک صفحه تصادفی (پیش فرض 4). هر چه زمان جستجوی سیستم دیسک کمتر باشد، این پارامتر باید کوچکتر (اما > 1.0) باشد. یک مقدار پارامتر بسیار بزرگ، تمایل PgSQL را برای انتخاب طرح هایی که کل جدول را اسکن می کنند افزایش می دهد (PgSQL خواندن متوالی کل جدول را ارزان تر از خواندن تصادفی فهرست می داند). و این بد است.

autovacuum=روشن

روشن کردن جارو برقی

autovacuum_naptime = 20 ثانیه

زمان خواب فرآیند اتو وکیوم. اگر مقدار بیش از حد بزرگ باشد، جداول زمان جاروبرقی نخواهند داشت و در نتیجه نفخ و اندازه جداول و ایندکس ها افزایش می یابد. مقدار کمی باعث گرمایش غیر ضروری می شود.

bgwriter_delay = 20ms

زمان خواب بین چرخه‌های نوشتن دیسک فرآیند نوشتن پس‌زمینه. این فرآیند مسئول همگام سازی صفحات واقع در shared_buffers با دیسک است. مقدار بیش از حد بزرگ برای این پارامتر، بار روی فرآیند ایست بازرسی و فرآیندهای سرویس دهی جلسات را افزایش می دهد. یک مقدار کوچک باعث می شود یکی از هسته ها به طور کامل بارگذاری شود.

bgwriter_lru_multiplier = 4.0

bgwriter_lru_maxpages = 400

گزینه هایی که شدت ضبط فرآیند ضبط پس زمینه را کنترل می کنند. در یک چرخه، bgwriter بیشتر از آنچه در آخرین چرخه نوشته شده بود، ضرب در bgwriter_lru_multiplier نمی‌نویسد، اما بیش از bgwriter_lru_maxpages نمی‌نویسد.

synchronous_commit = خاموش

همزمان سازی دیسک را در زمان commit غیرفعال کنید. خطر از دست دادن چند تراکنش آخر را ایجاد می کند (در عرض 0.5-1 ثانیه)، اما یکپارچگی پایگاه داده را تضمین می کند؛ هیچ شکافی در زنجیره commit وجود ندارد. اما بهره وری را به میزان قابل توجهی افزایش می دهد.

wal_keep_segments = 256

wal_keep_segments = 32..256

حداکثر تعداد بخش های WAL بین پست های بازرسی. نقاط بازرسی خیلی مکرر منجر به بار نوشتن قابل توجهی در زیرسیستم دیسک می شود. هر بخش 16 مگابایت حجم دارد

wal_buffers = 16 مگابایت

مقدار حافظه مشترکی که برای بافر کردن داده های WAL که هنوز روی دیسک نوشته نشده است استفاده می شود. مقدار پیش‌فرض -1 اندازه‌ای برابر با 1/32 (حدود 3 درصد) را مشخص می‌کند، اما نه کمتر از 64 کیلوبایت و نه بیشتر از اندازه یک بخش WAL (معمولاً 16 مگابایت). اگر مقدار انتخاب شده به طور خودکار خیلی کوچک یا بزرگ باشد، می توان این مقدار را به صورت دستی تنظیم کرد، اما هر عدد مثبت کمتر از 32 کیلوبایت به عنوان 32 کیلوبایت در نظر گرفته می شود. این پارامتر فقط در هنگام راه اندازی سرور قابل تنظیم است.

محتویات بافرهای WAL هنگام انجام هر تراکنش بر روی دیسک نوشته می شود، بنابراین مقادیر بسیار بزرگ بعید است که سود زیادی به همراه داشته باشد. با این حال، مقدار حداقل چند مگابایت می تواند عملکرد نوشتن را در یک سرور شلوغ بهبود بخشد، زمانی که بسیاری از مشتریان همزمان تراکنش ها را انجام می دهند. تنظیم خودکار که در مقدار پیش فرض (-1) عمل می کند، در اکثر موارد مقادیر معقولی را انتخاب می کند.

default_statistics_target = 1000

حد هدف پیش‌فرض آمار را تنظیم می‌کند که برای ستون‌هایی اعمال می‌شود که ALTER TABLE SET STATISTICS محدودیت‌های فردی را برای آن‌ها مشخص نکرده است. هر چه مقدار تنظیم شده بیشتر باشد، زمان بیشتری برای اجرای ANALYZE طول می کشد، اما کیفیت تخمین های زمان بندی می تواند بالاتر باشد. مقدار پیش فرض این پارامتر 100 است.

checkpoint_completion_target = 0.9

درجه "لکه گیری" ایست بازرسی. سرعت ضبط در طول یک ایست بازرسی به گونه ای تنظیم می شود که زمان ایست بازرسی برابر با زمان سپری شده از گذشته باشد، ضربدر هدف checkpoint_completion_.

min_wal_size = 4G
max_wal_size = 8G

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

حداقل و حداکثر اندازه فایل های WAL. مشابه checkpoint_segments

fsync=روشن

غیرفعال کردن این گزینه منجر به افزایش عملکرد می شود، اما در صورت قطع ناگهانی برق، خطر از دست دادن تمام داده ها وجود دارد. توجه: اگر RAID دارای کش است و در حالت نوشتن بازگشت است، وجود و عملکرد باتری کش کنترلر RAID را بررسی کنید! در غیر این صورت، داده های نوشته شده در حافظه نهان RAID ممکن است با قطع برق از بین بروند و در نتیجه، PgSQL یکپارچگی داده ها را تضمین نمی کند.

row_security = خاموش

غیرفعال کردن کنترل وضوح سطح ضبط

enable_nestloop = خاموش

استفاده زمانبند از طرح های اتصال حلقه تودرتو را فعال یا غیرفعال می کند. حذف کامل حلقه‌های تودرتو امکان‌پذیر نیست، اما اگر این گزینه را خاموش کنید، زمان‌بند استفاده نمی‌کند. این روش، اگر می توان دیگران را اعمال کرد. به طور پیش فرض، این تنظیم روشن است.

قفل

max_locks_per_transaction = 256

حداکثر تعداد قفل ایندکس/جدول در یک تراکنش

تنظیمات پلتفرم 1C

standard_conforming_strings = خاموش

اجازه دهید از کاراکتر \ برای فرار استفاده شود

escape_string_warning = خاموش

در مورد استفاده از کاراکتر \ برای فرار هشدار ندهید

تنظیمات امنیتی

بیایید مطمئن شویم که سرور PostgreSQL فقط برای سرور 1C: Enterprise نصب شده در همان دستگاه قابل مشاهده است.

listen_addresses = 'localhost'

اگر سرور 1C: Enterprise روی دستگاه دیگری نصب شده است یا نیاز به اتصال به سرور DBMS با استفاده از Snap-in PGAdmin وجود دارد، در عوض میزبان محلی باید آدرس این دستگاه را مشخص کنید.

ذخیره سازی پایگاه داده

PostgreSQL، مانند تقریباً هر DBMS، برای زیرسیستم دیسک حیاتی است، بنابراین، برای افزایش عملکرد DBMS، سیستم PostgreSQL، گزارش‌ها و خود پایگاه‌های داده را روی دیسک‌های مختلف قرار می‌دهیم.

توقف سرور

Systemctl postgresql-9.6 را متوقف می کند

ما گزارش ها را به یک SSD 120 گیگابایتی منتقل می کنیم:

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 status postgresql-9.6

استفاده از case به عنوان سرور پایگاه داده PostgreSQL در پلت فرم ویندوزخیلی محبوب نیست، اما معمولاً زمانی اتفاق می افتد که باید به نحوی در هزینه محصولات MS صرفه جویی کنید. همچنین برنامه های تخصصی وجود دارند که با PostgreSQL بهترین کار را دارند. برای 1c یک ساخت تغییر یافته از PostgreSQL وجود دارد که همانطور که توسعه دهندگان اطمینان می دهند، سطحی از عملکرد و تحمل خطا قابل مقایسه با MSSQL را ارائه می دهد. آیا واقعا اینطور است، بیایید آن را در عمل بررسی کنیم :)

1. PostgreSQL را نصب کنید

آخرین بیلد PostgreSQL 64-bit 9.1.2-1.1C را از وب سایت 1c دانلود کنید، آرشیو را باز کنید، بسته msi را اجرا کنید، آن بدون int حجم فایل بالایی ندارد.

روی Start کلیک کنید.
گزینه های نصب را به عنوان پیش فرض بگذارید.

یک رمز عبور برای کاربر تعیین کنید postgresکه خدمات از آن شروع خواهد شد . روی Next کلیک کنید. اگر برای اولین بار PostgreSQL را نصب می کنید، جادوگر از شما می خواهد که یک کاربر ایجاد کنید. postgres

در مرحله اولیه سازی پایگاه داده، رمزگذاری UTF8 را انتخاب کنید. ورود و رمز عبور را برای کاربر داخلی postgres تنظیم کنید. توجه! رمز عبور کاربر سرویس PostgreSQL و رمز عبور کاربر پایگاه داده داخلی PostgreSQL نباید یکسان باشد. رمز عبور باید حداقل چهار کاراکتر باشد. اگر قصد دارید سرور 1C و PostgreSQL را بر روی ماشین های مختلف اجرا کنید، باید چک باکس "پشتیبانی از اتصالات از هر IP، نه فقط localhost" را علامت بزنید. دوباره روی Next و Next کلیک کنید. :)

دو بار دیگر روی Next کلیک کنید و منتظر بمانید تا نصب کامل شود.

سپس به Start\All Programs\PostgreSQL 9.1.2-1.1C(x64) بروید. ابزار مدیریت pgAdmin III را راه اندازی کنید. بیایید سعی کنیم به پایگاه داده متصل شویم. رمز عبوری را که در هنگام نصب مشخص کرده اید وارد کنید.
و خطای زیر را دریافت می کنیم: خطا در اتصال به سرور: FATAL: احراز هویت رمز عبور برای "postgres" کاربر ناموفق بود.

با توجه به اینکه رمز عبور به درستی تایپ شده است، کاملا غیرمنتظره است. تصمیم گرفتم با pg_hba.conf سرهم کنم، اما در نگاه اول همه چیز در آنجا خوب است.

# TYPE DATABASE USER ADDRESS METHOD # IPv4 Local Connections: host all postgres::1/128 md5 host all postgres 127.0.0.1/32 md5 host all postgres 192.168.1.0/24 md5

تصمیم گرفتم روش مجوز را از md5 به Trust تغییر دهم. سرویس را ریستارت می کنم و دوباره سعی می کنم به دیتابیس متصل شوم. این بار این پیام را دریافت کردم.
در واقع، بیش از یک مورد در وب سایت pgAdmin موجود است یک نسخه جدید. بعد از اون اتصال به دیتابیس با موفقیت انجام میشه!!؟!! یادمه قبلا md5 همچین مشکلی نداشت ظاهرا این ایراد واقعا مربوط به نسخه قدیمی pgAdmin.
اکنون می توانیم برای نیازهای 1C یک پایگاه داده ایجاد کنیم یا با استفاده از خود 1C این کار را انجام دهیم :)

2. نصب 1C enterprise 8.2.

برای نصب، ما اجزای زیر را یادداشت می کنیم: 1C: Enterprise، 1C: Enterprise Server، ماژول های برنامه افزودنی وب سرور، 1C: مدیریت سرور سازمانی.
در مرحله نصب «Install 1C Enterprise as a Service»، رمز عبور کاربر USR1C82 را تعیین می کنیم.
روی next کلیک کنید و پیشرفت نصب را نظارت کنید :) به کاربر USR1CV82حقوق زیر باید در حین نصب اختصاص داده شود:

به عنوان یک سرویس وارد شوید (به عنوان یک سرویس وارد شوید)،به عنوان کار دسته ای وارد شوید (به عنوان یک کار دسته ای وارد شوید). می توانید آن را در آن مشاهده کنید خط‌مشی رایانه محلی\پیکربندی رایانه\تنظیمات ویندوز\تنظیمات امنیتی\سیاست‌های محلی\تکالیف راست کاربر.

بریم سراغ تجهیزات مدیریت سرورهای 1C Enterprise،می بینیم که خوشه بالا آمده و در پورت 1541 آویزان است. سرور ما نیز در برگه "سرورهای کار" وجود دارد. اکنون می توانید پایگاه داده را به سرور 1C اضافه کنید. برای انجام این کار، به برگه " پایگاه های اطلاع رسانی"راست کلیک کنید و انتخاب کنید جدید - پایگاه اطلاع رسانی. پارامترهای لازم برای اتصال به سرور PostgreSQL را تنظیم کنید. روی OK کلیک کنید. بیایید 1C: Enterprise را راه اندازی کنیم. ما انتخاب می کنیم که یک پایگاه اطلاعاتی موجود را روی سرور اضافه کنیم.
بعد، پارامترهای اتصال را تنظیم کنید. روی "Next" و در نهایت "Finish" کلیک کنید.
عملیات ایجاد پایگاه داده را می توان مستقیماً از 1C: Enterprise انجام داد. برای انجام این کار، هنگام راه اندازی، «ایجاد یک جدید» را انتخاب کنید پایگاه اطلاع رسانی».

برای اتصال کلاینت های 1C به سرور از بیرون و کارکرد سرور پایگاه داده روی فایروال، پورت های زیر باید باز باشند:

عامل سرور ( شعله ور) - tcp:1540 مدیر ارشد خوشه ( rmngr) - tcp:1541 محدوده پورت های شبکه برای توزیع پویا فرآیندهای کارگر - tcp:1560-1591، tcp:5432 - Postgresql. بیایید یک قانون از طریق رابط استاندارد یا با استفاده از دستور ایجاد کنیم:

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

اکنون می‌توانیم به راحتی کلاینت 1C: Enterprise را از رایانه دیگری راه‌اندازی کنیم و پایگاه اطلاعاتی موجود را اضافه کنیم newdb. مجوزها و حفاظت از نرم افزار/سخت افزار را فراموش نکنید. اکنون می توانیم تست Gilev را دانلود کرده و عملکرد سیستم خود را اندازه گیری کنیم.

در VirtualBox با 1 گیگابایت حافظه، دو هسته ای 2.6 گیگاهرتز، 319 انتشار 1c، تست Gilev 11.42 امتیاز می دهد، تقریباً مشابه CentOS. در 16.362 اندکی بیشتر از 11.60 امتیاز وجود دارد. بهینه سازی تنظیمات با استفاده از EnterpriseDB Tuning Wizard افزایش قابل توجهی را به همراه نداشت (11.66 و 11.62)، اگرچه ممکن است به طور کلی مفید باشد. :)

3. کار روتین روی سرور PostgreSQL.

پشتیبان گیری.

ابزار مدیریت pgAdmin III را اجرا کنید و روی پایگاه داده مورد نظر کلیک راست کنید. "پشتیبان گیری" را انتخاب کنید.
قالب را انتخاب کنید (سفارشی (سطح فشرده سازی از 0 تا 9)، تار، ساده، کاتالوگ). از نظر سطح فشرده سازی، "فرمت سفارشی" هر سطح فشرده سازی به بهترین وجه فشرده می شود، سپس "دایرکتوری"، سپس "ساده" و در نهایت "تار". رمزگذاری UTF8 را مشخص می کنیم، نام نقش postgresql است. همه گزینه های اضافی را به عنوان پیش فرض می گذاریم. روی دکمه "پشتیبان گیری" کلیک کنید. فیلد "پیام ها" لیستی از تمام عملیات انجام شده را با یک کد تکمیل نمایش می دهد. اگر 0، پس موفقیت. در اینجا همچنین می توانید نحوه اجرای عملیات مشابه را از خط فرمان مشاهده کنید.

F)\pgAdmin III\1.16\pg_dump.exe" - میزبان 192.168.1.200 - پورت 5432 - نام کاربری "postgres" - نقش "postgres" - بدون رمز عبور - فرمت سفارشی - blobs - فشرده سازی 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump.backup" "newdb"

بر این اساس، اسکریپت خودکار کپی رزرو کنید، که ما به زمانبندی اضافه می کنیم ممکن است چیزی شبیه به این باشد:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_dump.exe" - میزبان 192.168.1.200 - پورت 5432 - نام کاربری "postgres" - نقش "postgres" - بدون رمز عبور - فرمت سفارشی --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump_%date:~0.2%_%date:~3.2%_%date:~6.4% .backup" "newdb"

بهبود.

برای بازیابی، پایگاه داده ای را انتخاب کنید که می خواهیم داده ها را در آن بازیابی کنیم نسخه پشتیبان، ترجیحا خالی راست کلیک کرده و "Recovery" را انتخاب کنید. فایل پشتیبان را تنظیم کنید، نام نقش: postgres، روی "بازیابی" کلیک کنید
با استفاده از خط فرمان:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_restore.exe" --host 192.168.1.200 --port 5432 --نام کاربری "postgres" --dbname "testdb" --role "postgres" --no -password -کلمه "G:\Backups\gilev_dump_26_09_2012.backup"

که در آن testdb یک پایگاه داده خالی است که آرشیو پشتیبان در آن بازیابی می شود.

عملیات تعمیر و نگهداری:

دستور VACUUM:

به طور متوالی تمام جداول پایگاه داده متصل فعلی را پاک می کند، داده های موقت را حذف می کند و فضای دیسک را آزاد می کند. بیشتر اوقات، دستور VACUUM دقیقاً برای به دست آوردن حداکثر فضای خالی دیسک روی دیسک و افزایش سرعت دسترسی به داده ها اجرا می شود.

خلاء- فضای اشغال شده توسط نسخه های قدیمی رکوردها را به عنوان رایگان علامت گذاری می کند. استفاده از این نوع دستور، به عنوان یک قاعده، اندازه فایل حاوی جدول را کاهش نمی دهد، اما به شما امکان می دهد از رشد غیرقابل کنترل آن جلوگیری کنید، آن را در سطح قابل قبولی ثابت کنید. هنگام اجرای VACUUM، دسترسی موازی به جدول در حال پردازش امکان پذیر است. چند وجود دارد گزینه های اضافیبا استفاده از VACUUM: VACUUM FULL، VACUUM FREEZE، VACUUM ANALYZE.

VACUUM FULLتلاش می کند تمام نسخه های قدیمی رکوردها را حذف کند و بر این اساس، حجم فایل حاوی جدول را کاهش دهد. این گزینه دستوری جدول در حال پردازش را به طور کامل قفل می کند.

انجماد در خلاء -اگر VACUUM FULL "آشغال" را از جداول حذف کند و رکوردها را به گونه ای جابجا کند که جداول به طور فشرده روی دیسک قرار گیرند و از کمترین تعداد قطعات تشکیل شده باشند، در حالی که فشرده سازی زمان زیادی طول می کشد و رکوردها را مسدود می کند، VACUUM FREEZE به سادگی "زباله" را از روی دیسک حذف می کند. جداول، اما خود رکوردها حرکت نمی کنند، بنابراین سریعتر است و نوشتن را مسدود نمی کند. در حال حاضر، این گزینه با autovacuum - جمع آوری خودکار زباله در جایگزین شده است postgresql.confبه علاوه چندین گزینه اضافی که عملکرد را گسترش می دهد:

autovacuum=روشن# جمع آوری خودکار زباله را فعال می کند.
log_autovacuum_min_duration = -1# تنظیم آن بر روی صفر، همه اقدامات autovacuum را ثبت می کند. منهای یک (به طور پیش فرض) خروجی را به گزارش ممنوع می کند. به عنوان مثال، اگر مقدار را تنظیم کنید
برابر با 250 میلی‌ثانیه، سپس تمام اقدامات خلاء خودکار و تجزیه و تحلیل که برای 250 میلی‌ثانیه یا بیشتر اجرا می‌شوند، ثبت خواهند شد. فعال کردن این تنظیم ممکن است برای ردیابی خلاء خودکار مفید باشد.
این گزینه را فقط می توان در فایل postgresql.conf یا در تنظیم کرد خط فرمانسرور
autovacuum_naptime = 10 دقیقه# زمان در ثانیه که پس از آن پایگاه داده برای نیاز به جمع آوری زباله بررسی می شود. به طور پیش فرض این یک بار در دقیقه اتفاق می افتد.
autovacuum_vacuum_threshold= 1800 # آستانه برای تعداد رکوردهای حذف شده و اصلاح شده در هر جدول، پس از فراتر رفتن از آن جمع آوری زباله (VACUUM).
autovacuum_analyze_threshold= 900 # آستانه برای تعداد رکوردهای درج شده، حذف شده و اصلاح شده در هر جدولی که پس از فراتر رفتن از آن، فرآیند تحلیل (ANALYZE) شروع می شود.
autovacuum_vacuum_scale_factor= 0.2 # درصد رکوردهای تغییر یافته و حذف شده در رابطه با جدولی که در بالای آن جمع آوری زباله فعال می شود.
autovacuum_analyze_scale_factor= 0.1 # مانند متغیر قبلی، اما نسبت به تجزیه و تحلیل.
آنالیز خلاء— اگر پایگاه داده دارای جداولی است که داده ها در آنها تغییر یا حذف نشده اند، بلکه فقط اضافه می شوند، برای چنین جداولی می توانید از دستور ANALYZE جداگانه استفاده کنید. همچنین پس از افزودن تعداد زیادی رکورد به آن، استفاده از این دستور برای یک جدول جداگانه نیز ارزش دارد.

دستور ANALYZE:

به روز رسانی اطلاعات در مورد توزیع داده ها در جدول است. این اطلاعات توسط بهینه ساز برای انتخاب سریعترین طرح اجرای پرس و جو استفاده می شود. معمولاً این دستور همراه با استفاده می شود آنالیز خلاء.

دستور REINDEX (شاخص مجدد):

برای بازسازی نمایه های موجود استفاده می شود. منطقی است که از آن در مورد استفاده کنید

- آسیب به شاخص؛

- افزایش مداوم اندازه آن.

مورد دوم نیاز به توضیح دارد. یک فهرست، مانند یک جدول، حاوی بلوک هایی با نسخه های قدیمی رکوردها است. PostgreSQL همیشه نمی تواند از این بلوک ها استفاده مجدد کند و بنابراین حجم فایل ایندکس به تدریج افزایش می یابد. اگر داده های جدول به طور مکرر تغییر کند، می تواند به سرعت رشد کند. اگر متوجه این رفتار یک شاخص شدید، باید آن را طوری پیکربندی کنید که به صورت دوره ای دستور REINDEX را اجرا کند. لطفا توجه داشته باشید: دستور REINDEX، مانند VACUUM FULL، جدول را به طور کامل قفل می کند، بنابراین باید زمانی اجرا شود که بار سرور حداقل است.

این سوال که کدام DBMS - Postgresql یا MS SQL برای 1C بهینه ترین است - موضوع بسیاری از مقالات بوده است. در این مقاله مراحل بهینه سازی هر دو را بررسی می کنیم. DBMS هر فروشنده دارای توصیه‌های پیکربندی و توصیه‌هایی از 1C است. لازم به ذکر است که بسته به تجهیزات، پیکربندی سرور و تعداد کاربرانی که بارهای مختلف را تنظیم می کنند، جزئیات فرآیند بهینه سازی DBMS برای 1C و اجرای توصیه ها ممکن است تغییر کند.

راه اندازی PostgreSQL برای 1C

تجربه کارکردن پایگاه‌های داده 1C در PostgreSQL نشان داده است که بالاترین عملکرد و عملکرد بهینه 1C و PostgreSQL در لینوکس به دست آمده است، بنابراین استفاده از آن توصیه می‌شود. اما صرف نظر از سیستم عامل، مهم است که به یاد داشته باشید که تنظیمات پیش فرض مشخص شده هنگام نصب PostgreSQL فقط برای راه اندازی سرور DBMS در نظر گرفته شده است. از بهره برداری صنعتی نمی توان صحبت کرد! مرحله بعدی پس از راه اندازی بهینه سازی PostgreSQL برای 1C است:

  • اول، ذخیره انرژی را غیرفعال می کنیم (در غیر این صورت تاخیر در پاسخ ها از پایگاه داده ممکن است به طور غیرقابل پیش بینی افزایش یابد) و تعویض حافظه مشترک را ممنوع می کنیم.
  • ما پارامترهای اصلی سرور DBMS را پیکربندی می کنیم (توصیه های پیکربندی با جزئیات کافی، هم در وب سایت رسمی فروشنده و هم توسط 1C توضیح داده شده است، بنابراین ما فقط بر روی مهمترین آنها تمرکز خواهیم کرد).
  • توصیه‌های استاندارد شرکت 1C غیرفعال کردن مکانیسم‌های HyperThreading را پیشنهاد می‌کند. اما آزمایش Postgres-pro بر روی سرورهایی که SMT (هم‌زمان چند رشته‌بندی) فعال است، نتایج متفاوتی را نشان داد.
تنظیم shared_buffers به ​​RAM/4 توصیه پیش فرض است، اما نمونه Sqlسرور می گوید که هرچه حافظه بیشتری به آن اختصاص داده شود، عملکرد بهتری دارد (با غیرفعال شدن فلاشینگ صفحه). یعنی هرچه صفحات داده در حافظه رم بیشتر باشد، دسترسی به دیسک کمتر می شود. این سوال مطرح می شود: چرا چنین کش کوچک؟ پاسخ ساده است: اگر shared_buffers بزرگ باشد، برخی از صفحات استفاده نشده به دیسک مبادله می شوند. اما چگونه می توان لحظه ای را که تنظیم مجدد متوقف می شود و نشانگر پارامتر بهینه است ردیابی کرد؟ برای دستیابی و رسیدن به شاخص shared_buffers بهینه، مقدار آن باید در تولید روزانه (در صورت امکان) با یک افزایش معین افزایش یابد و مراقب باشید که در چه لحظه ای صفحات شروع به شستشو به دیسک می کنند (swap افزایش می یابد).
  • علاوه بر این، "پارامتر بزرگ" با کار با بسیاری از صفحات کوچک که به طور پیش فرض دارای اندازه 8 کیلوبایت هستند تأثیر منفی می گذارد. کار با آنها هزینه های سربار را افزایش می دهد. برای بهینه سازی 1C با این چه کاری می توان انجام داد؟ PostgreSQL 9.4 پارامتر large_pages را معرفی کرد که می تواند فعال شود، اما فقط در لینوکس. به طور پیش فرض، صفحات بزرگ با اندازه پیش فرض 2048 کیلوبایت گنجانده شده است. علاوه بر این، پشتیبانی از این صفحات باید در سیستم عامل فعال باشد. بنابراین، با بهینه سازی ساختار ذخیره سازی، می توانید به یک نشانگر shared_buffers بزرگتر دست پیدا کنید.
  • work_mem = RAM/32..64 یا 32MB..128MB مقدار حافظه را برای هر جلسه تنظیم می کند که برای عملیات مرتب سازی داخلی، ادغام و غیره قبل از استفاده از فایل های موقت استفاده شود. اگر از این حجم بیشتر شود، سرور از فایل های موقت روی دیسک استفاده می کند که می تواند سرعت پردازش درخواست ها را به میزان قابل توجهی کاهش دهد. این پارامتر هنگام اجرای عملگرها استفاده می شود: ORDER BY، DISTINCT، ادغام پیوندها و غیره.
  • محاسبه اضافی این پارامترمی توان به صورت زیر انجام داد: (حافظه اشتراکی shared_buffers - حافظه برای سایر برنامه ها) / تعداد اتصالات فعال. این مقدار را می توان با نظارت بر تعداد فایل های موقت ایجاد شده کاهش داد. چنین آماری در مورد اندازه و تعداد فایل های موقت را می توان از نمای سیستم pg_stat_database به دست آورد.
  • effect_cache_size = RAM - shared_buffers هدف اصلی این پارامتر این است که به بهینه ساز پرس و جو بگوید کدام روش را برای بازیابی داده ها انتخاب کند: اسکن کامل یا اسکن فهرست. هر چه مقدار پارامتر بالاتر باشد، احتمال استفاده از اسکن شاخص بیشتر است. در این حالت، سرور در نظر نمی گیرد که داده ها می توانند در هنگام اجرای یک درخواست در حافظه باقی بمانند و درخواست بعدی نیازی به بازیابی آن از دیسک ندارد.

    • نصب PostgreSQL

    نصب 1C در PostgreSQL تحت ویندوز یک فرآیند نسبتاً ساده است. هنگام اجرای بسته نصبی، باید رمزگذاری UTF-8 را مشخص کنید. در واقع، این تنها نکته جالب توجه است و نیازی به پیکربندی بیشتر PostgreSQL برای 1C 8.3 از ویندوز نیست. نصب و پیکربندی PostgreSQL برای 1C در سیستم عامل لینوکس می تواند مشکلات زیادی ایجاد کند. برای غلبه بر آنها، به عنوان مثال، اجازه دهید اجرا (با استفاده از کیت های توزیع از فروشنده پیشرو روسی PostgreSQL-Pro و شرکت 1C) PostgreSQL را روی سرور اوبونتو 16.04 x64 در نظر بگیریم.

    نصب کیت های توزیع 1C برای PostgreSQL DBMS

    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، نصب را با تایپ متوالی دستورات زیر انجام می دهیم:

    سی دی<Путь к папке с файлами>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.1.1.1.1.1.1. 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-2-d1.

    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 install postgresql-pro-1c-9.4

    برای دسترسی به سرور، پارامترهای موجود در فایل را ویرایش کنید pg_hba.conf

    سی دی<Путь до каталога 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"

    خود فایل دارای ساختار زیر است:


    فایل به خوبی مستند است، اما زبان انگلیسی. بیایید به طور خلاصه به پارامترهای اصلی نگاه کنیم:

    • محلیاتصال محلی فقط از طریق یونیکس
    • میزباناتصال TCP/IP
    • Hostsslاتصال SSL رمزگذاری شده از طریق TCP/IP (سرور باید با پشتیبانی SSL ساخته شود، پارامتر ssl نیز باید تنظیم شود)
    • Hostnosslاتصال رمزگذاری نشده از طریق TCP/IP
    • اعتمادبدون احراز هویت اعتراف کنید
    • رد کردنرد کردن بدون احراز هویت
    • کلمه عبوردرخواست رمز عبور متنی را پاک کنید
    • md5درخواست رمز عبور در فرم MD5
    • ldapتایید نام کاربری و رمز عبور با استفاده از سرور 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.conf، با توجه به مشخصات PostgreSQL، سرور 1C و پیکربندی سرور اوبونتو.

    بهینه سازی 1C برای MS SQL Server

    نصب آخرین به روزرسانی هابرای SQL Sever.

    سیستم عامل فضا را رزرو می کند و آن را با صفر پر می کند که در رویدادهای زیر زمان بسیار زیادی طول می کشد:

    • ایجاد پایگاه داده؛
    • افزودن فایل های داده، گزارش تراکنش، به پایگاه داده موجود.
    • افزایش اندازه یک فایل موجود (از جمله عملیات Autogrow)؛
    • ما پایگاه داده ها یا گروه هایی از فایل ها را بازیابی می کنیم.

    در حال تصمیم گیری است این مشکلاضافه کردن نقش (که سرور تحت آن در حال اجرا است) به آیتم سیاست محلیامنیت "انجام وظایف نگهداری حجم."

    در صورت امکان، لازم است پایگاه داده TempDB (به ویژه در حالت قفل مدیریت شده RCSI استفاده می شود) و گزارش تراکنش در دیسک های مختلف توزیع شود.

    روی سروری که در آن کار می کند سرور SQL، حالت صرفه جویی در انرژی باید روی "عملکرد بالا" تنظیم شود.

    پوشه حاوی فایل های پایگاه داده نباید فشرده شود.

    در برگه "Memory" برای سرور، حداقل سطح را 50٪ از کل حافظه تنظیم می کنیم. ما حداکثر را با استفاده از یکی از فرمول ها محاسبه می کنیم:

    • حداکثر حافظه = حجم کل - اندازه بر اساس سیستم عامل - اندازه برای 1C (اگر وجود داشته باشد، قبلاً حافظه مورد استفاده را با شمارنده اندازه گیری کرده باشید) یا
    • حداکثر حافظه = حجم کل – (1024* حجم کل/16384).

    ما پارامتر DOP "Max درجه موازی" را محدود می کنیم و آن را روی "1" تنظیم می کنیم.

    ما آمار را طبق برنامه به روز می کنیم. با شروع SQL Server 2008، به روز رسانی آمار باعث می شود پرس و جوها دوباره کامپایل شوند و بنابراین حافظه پنهان رویه ای پاک می شود، بنابراین نیازی به انجام یک رویه جداگانه برای پاک کردن کش رویه ای نیست.

    ما به صورت دوره ای جدول را دوباره فهرست می کنیم و نمایه ها را یکپارچه می کنیم.

    ما خط مشی صحیح رزرو را تعیین می کنیم. اگر نیازی به بازیابی تا آخرین نقطه از زمان قبل از خرابی سیستم ندارید، و 5 دقیقه آخر یا بیشتر برای کسب و کار شما حیاتی نیست، مدل بازیابی را روی "Simple" تنظیم کنید. این کار سرعت ضبط شما را به میزان قابل توجهی افزایش می دهد. نکته اصلی این است که پشتیبان گیری متمایز را می توان در مدت زمان مشخص شده تکمیل کرد.

    ما در کار با TempDB در حین I/O با ایجاد فایل های داده اضافی به پیشرفت هایی دست پیدا می کنیم. اگر کمتر از 8 پردازنده منطقی وجود دارد، توصیه می شود که یک فایل داده برای هر پردازنده منطقی ایجاد کنید. اگر بیش از 8 پردازنده منطقی وجود دارد، توصیه می شود 8 فایل داده ایجاد کنید و با افزایش یک در مضربی از 4، مطمئن شوید که بار TempDB را تخمین بزنید.

    1 نوامبر 2012 مزایای استفاده از توزیع رایگان نرم افزارواضح. متأسفانه، معایب نیز آشکار است - هیچ پشتیبانی رسمی وجود ندارد، اسناد اغلب متناقض، ناقص و پراکنده هستند. منابع مختلف. این مقاله به شما کمک می کند تا فرآیند نصب PosgreSQL را برای 1C:Enterprise 8 درک کنید و از مشکلاتی که در اسناد رسمی توضیح داده نشده است اجتناب کنید.

    قطعات مورد نیاز برای نصب

    PostgreSQL DBMS به صورت رایگان توزیع می شود و در بسته تحویل سرور برنامه 1C گنجانده شده است. سرور برنامه 1C: Enterprise 8 در دو نسخه ارائه می شود: 32 بیتی و 64 بیتی. Postgre می تواند هر دو را اداره کند.

    بنابراین، ما کیت های توزیع را در دست داریم:

    • Postgre: postgresql-9_1_2-1_1Cx64.zip، لطفاً توسط 1C ارائه شده است.
    • توزیع سرور برنامه 1C: Enterprise برای Windows x64، نسخه 8.2.16.368.

    به نظر می رسد که نمی تواند ساده تر باشد - فقط راه اندازی و نصب کنید. به آسانی! اما نصب در حالت استاندارد یک محدودیت کوچک ایجاد می کند: خوشه در پوشه "Program Files" قرار خواهد گرفت. همه آن را دوست نخواهند داشت. بیایید دو گزینه نصب ساده و پیشرفته را در نظر بگیریم.

    مقاله به 5 بخش تقسیم شده است:

    1) نصب سرور 1C.

    2) PostgreSQL را در یک فرم استاندارد نصب کنید که برای اجرای 1C بدون تنظیمات اضافی کافی است.

    3) PostgreSQL را نصب کرده و پوشه ذخیره سازی کلاستر را انتخاب کنید.

    4) ایجاد یک پایگاه اطلاعاتی جدید 1C.

    5) تعیین پوشه برای ذخیره فایل های پایگاه داده در سرور DBMS.

    قبل از نصب حتما مقاله را کامل بخوانید!

    نصب سرور اپلیکیشن 1C

    ما setup.exe را از پوشه با کیت توزیع سرور 1C راه اندازی می کنیم.

    اگر سرور برنامه را نه به عنوان سرویس نصب کنید، باید هر بار آن را به صورت دستی راه اندازی کنید. این گزینه به ندرت مورد نیاز است. ما آن را به عنوان یک سرویس نصب می کنیم و تصمیم می گیریم که تحت چه کاربری راه اندازی شود. به دلایل امنیتی، بهتر است به جای اینکه اجازه دهید سرویس با حقوق کامل اجرا شود، یک کاربر جداگانه USR1CV82 ایجاد کنید.

    پس از نصب سرور برنامه، سیستم از شما می خواهد که درایور کلید حفاظتی HASP را نصب کنید. ما موافقیم:

    منتظر پیام هستیم:

    اگر پیام متفاوت باشد، به احتمال زیاد «دم» در سیستم باقی مانده است نصب های قبلیدرایورهای HASP همه آنها را حذف کنید و دوباره امتحان کنید.

    انجام شد، ما سرور برنامه 1C:Enterprise 8 را با موفقیت نصب کردیم.

    نصب PostgreSQL در فرم استاندارد، برای اجرای 1C بدون تنظیمات اضافی کافی است

    "postgresql-9.1.2-1.1C(x64).msi" را اجرا کنید

    لازم نیست گزینه های نصب را تغییر دهید، 1C کار خواهد کرد. به علاوه.

    Postgre، مانند سرور 1C، خود می تواند کاربری ایجاد کند که تحت آن سرویس را اجرا کنید. توجه شما را به این نکته جلب می کنم که اگر اشاره کنید حساببا حقوق مدیر، سرویس به درستی کار نخواهد کرد. حتما یک کاربر جدید ایجاد کنید.

    پنجره نصب بعدی

    خوشه را مقدار دهی اولیه می کنیم. اگر سرور پایگاه داده ما و سرور برنامه کاربردی 1C روی آن قرار دارند کامپیوترهای مختلف، سپس کادر «پشتیبانی از اتصالات از هر IP» را علامت بزنید، در غیر این صورت آن را لمس نمی کنیم. حتما رمزگذاری UTF8 را مشخص کنید. یک ابرکاربر DBMS ایجاد کنید. به علاوه…

    برای کار اولیه به هیچ چیز اضافی نیاز نداریم، علامت کادر را بردارید و نصب را کامل کنید.

    نتیجه تلاش ما PostgreSQL آماده برای استفاده است. اگر راضی باشیم که پایگاه‌های داده در Program Files\PostgreSQL\9.1.2-1.1C\data قرار می‌گیرند، به همین جا ختم می‌کنیم، پایگاه‌های داده را باز می‌کنیم و از فرآیند لذت می‌بریم. با این حال، اغلب پایگاه‌های داده روی آرایه‌های دیسکی که مخصوص طراحی شده‌اند قرار می‌گیرند، نه روی آرایه‌های دیسک دیسک سیستم. برای پیکربندی مکان داده، لطفاً قسمت زیر را قبل از نصب مطالعه کنید.

    نصب Postgre با انتخاب مکان ذخیره سازی خوشه ای

    ما به نصب Postgre ادامه می دهیم و تمام مراحل را انجام می دهیم تا زمانی که از ما خواسته شود که خوشه را مقداردهی اولیه کنیم:

    تیک "Initialize database cluster" را بردارید و روی "Next" کلیک کنید.

    بله، ما مطمئن هستیم.

    تیک Run Stack Builder را پس از خروج بردارید و نصب را کامل کنید.

    1. باید به پوشه ای که PostgreSQL را در آن نصب کرده ایم، حقوق کامل بدهیم، معمولاً این C:\Program Files\PostgreSQL است.

    2. cmd را به عنوان مدیر راه اندازی کنید. اگر این کار را در win7 انجام دادید، آن را به عنوان Administrator اجرا کنید.

    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 Database Server..." (شروع - کنترل پنل - ابزارهای مدیریتی - خدمات) نگاه کنید.

    6. ایجاد کنید سرویس جدیدخوشه ما را نشان می دهد

    ثبت "C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\pg_ctl" -N pgsql -U postgresql -P رمز عبور -D d:/postgredata

    7. حالا بریم سراغ خدمات. شروع – کنترل پنل – مدیریت – خدمات و شروع سرویس ما.

    ایجاد یک پایگاه داده 1C جدید روی سرور با PostgreSQL

    چندین گزینه برای ایجاد پایگاه داده وجود دارد. می توانید یک پایگاه داده از طریق pgAdmin3، کنسول مدیریت سرور 1C ایجاد کنید. اما در اینجا با انبوهی از سوالات نامفهوم و انبوهی از خطاها مواجه خواهید شد که زمان زیادی را برای یافتن پاسخ آنها صرف خواهید کرد. آن را به متخصصان بسپارید. هدف ما دستیابی به یک پایگاه کاری با حداقل تلاش است. بیایید ساده ترین راه برای رسیدن به این هدف را شرح دهیم.

    ما کلاینت 1C را راه اندازی می کنیم.

    روی "افزودن..." کلیک کنید.

    ما یک نام برای پایگاه داده پیدا می کنیم، سپس "در سرور 1C: Enterprise" را نشان می دهیم.

    خوشه سرور 1C: Enterprise– لوکال هاست، اگر در حال ایجاد یک پایگاه داده در همان رایانه ای هستیم که سرور 1C در آن نصب شده است، یا نام سرور برنامه 1C، اگر روی دیگری است.

    نام پایگاه اطلاعاتی در خوشه- در آینده، این نام هنگام اتصال از رایانه های دیگر نشان داده می شود.

    نوع DBMS– PostgreSQL را انتخاب کنید.

    سرور پایگاه داده- نام سرور PostgreSQL را مشخص کنید. اگر روی سرور پایگاه داده ایجاد کنیم، localhost را نیز مشخص می کنیم.

    نام پایگاه داده– با این نام یک پایگاه داده در PostgreSQL ایجاد می شود.

    کاربر، رمز عبور– نام کاربری که هنگام نصب PostgreSQL به عنوان superuser مشخص کردیم. مطمئن شوید که چک باکس "ایجاد پایگاه داده در صورت عدم وجود" را علامت بزنید.

    این سوال مطرح می شود - پایگاه داده به صورت فیزیکی در کجا ذخیره می شود؟ در پوشه Base خوشه مشخص شده. اگر نخواهیم در جایی که همه پایه ها هستند دروغ بگوییم چه؟ هنوز کاری نمی توانیم در مورد آن انجام دهیم، ما فقط یک پایگاه ایجاد می کنیم و ادامه می دهیم. به علاوه…

    مشخص کردن پوشه ذخیره سازی پایگاه داده

    بنابراین، ما یک پایگاه ایجاد کرده ایم. در بیشتر موارد، این جایی است که نصب به پایان می رسد. با این حال، اگر پایگاه‌های اطلاعاتی زیادی وجود دارد، و چندین آرایه دیسک برای گروه‌های مختلف پایگاه‌های داده وجود دارد، باید مشخص کنید که پایگاه‌های داده باید از نظر فیزیکی در کجا قرار گیرند. برای انجام این کار، pgAdmin3 را از Start – Programs – PostgreSQL اجرا کنید. به سرور ما متصل شوید

    هنگامی که برای اولین بار متصل می شوید، Postgre برای کاربر postgres یک رمز عبور می خواهد (که در هنگام نصب ایجاد کردیم).

    ما یک TableSpace جدید ایجاد می کنیم، این پوشه ای است که پایگاه داده های ما در آن ذخیره می شود.

    محل ذخیره سازی فایل های پایگاه داده را مشخص کرد. خوب.

    اکنون ویژگی های دیتابیس ایجاد شده قبلی را که می خواهیم مکان آن را تغییر دهیم باز می کنیم.

    ویژگی Tablespace را تغییر دهید. پس از کلیک بر روی "OK"، فایل های پایگاه داده به طور خودکار منتقل می شوند. آماده! امیدواریم مقاله برای شما مفید بوده باشد. اگر چنین است، نظرات خود را بگذارید و پیوندهای این صفحه را به اشتراک بگذارید. متشکرم!