Товаров:
Як толькі памер файлавай базы дадзеных 1С: Прадпрыемства аднаго з нашых кліентаў дасягнуў памеру ў 32Гб (так, 32Гб), у выніку чаго ўсё паступова пачатак тармазіць, а потым і ўстала намёртва, нашы кліенты папрасілі нас вырашыць гэтую праблемы. SSD Enterprise класа ненадоўга падсаладзіць пілюлю, але праз некаторы час усё вярнулася ў зыходную кропку. Ну што ж, тут і да бабкі не хадзі - пераходзім на SQL версію БД.
Паколькі мы заўзятыя карыстальнікі Windows, даступна нам толькі два варыянты СКБД - гэта MSSql і PostgreSQL. Першы добры да вар'яцтва, але кошт не парадавала. А яшчэ больш не парадавала навіна аб дадатковых ліцэнзіях 1С для працы з MSSQL. Таму PostgreSQL.
Падрабязная інструкцыя з відэа даступная тут . У гэтым артыкуле мы пройдземся па ключавых момантах.
Не забываемся пра рэзервовае капіраванне баз дадзеных 1С!
Зыходныя дадзеныя:
- АС Windows Server 2008R2,
- Intel Core i7-2600K 3.40GHz,
- 32Gb RAM,
- Intel SSD DC3700 100Gb (толькі пад БД, АС на асобным SSD),
- ад 10 да 20 карыстальнікаў у БД штодня,
- абмен з 5 вузламі размеркаванай БД ў фоне.
Злавесна, ці не праўда? Непасрэдна да справы.
1. Усталёўка PostgreSQL і pgAdmin.
Ніякіх адкрыццяў з нагоды таго, адкуль пампаваць PostgreSQL не будзе - гэта наш любімы сайт https://releases.1c.ru , Раздзел «Тэхналагічныя дыстрыбутывы». Спампоўваем, ставім. Не забываем ўсталяваць MICROSOFT VISUAL C ++ 2010 RUNTIME LIBRARIES WITH SERVICE PACK 1, які ідзе ў архіве з дыстрыбутывам. Самі папаліся на гэта: не ўсталявалі, выпрабавалі шмат болю.
Ставім усё на далей, далей, акрамя наступных момантаў. Ўсталёўваем, як сэрвіс (галачка) і задаём параметры ўліковага запісу Windows, ня PostgreSQL.
Ініцыялізуючы кластар базы дадзеных (галачка). А вось тут задаём параметры ўліковага запісу для PostgreSQL! Важна: у Вас павінна быць запушчана служба «Secondary Logon» (або на лакалізаваць АС: «Другасны ўваход у сістэму»). Кадоўка UTF8 - гэта таксама важна!
Далей нічога цікавага. Далей ...
pgAdmin ў гэтай зборцы застары. ідзем на https://www.postgresql.org/ftp/pgadmin3/release/ . На момант напісання артыкула самая свежая версія 1.22.1. Качаем яе, ставім. Заходзім.
На працэсе ўстаноўкі аснасткі «Адміністраванне сервераў 1С Прадпрыемствы» не будзем спыняцца. Гэта зусім іншая тэма. Ды і складанага там нічога няма.
Ствараем SQL БД у гэтай аснастцы, правяраем у pgAdmin - БД там з'явіцца, калі ўсё паказана дакладна.
2. Цюнінг PostgreSQL 9.4.2.
Далей ўбіваем сабе ў галаву наступнае: перад любым захаваннем новых налад, рабіце рэзервовыя копіі файлаў:
- pg_hba.conf
- postgresql.conf
- pgpass.conf
якія ляжаць тут:
C: \ Program Files \ PostgreSQL \ 9.4.2-1.1C \ data
Калі Вы памыліцеся хоць у адной літары, пасля абнаўлення канфігурацыі PostgreSQL ня запусціцца. Высветліць што ж стала прычынай будзе складана, нават гледзячы ў часопісы Windows. Таму не мяняйце шмат параметраў адразу і рабіце рэзервовыя копіі.
Для праўкі конфігу ёсць зручны інструмент, даступны прама з галоўнага акна pgAdmin. Вось ён:
Што мы тут мяняем:
- shared_buffers - Колькасць памяці, выдзеленай PgSQL для сумеснага кэша старонак. Гэтая памяць падзяляецца паміж усімі працэсамі PgSQL. Дзелім даступную АЗП на 4. У нашым выпадку гэта 8Gb.
- effective_cache_size - Ацэнка памеру кэша файлавай сістэмы. Лічыцца так: АЗП - shared_buffers. У нашым выпадку гэта 32Gb - 8Gb = 24Gb. Але асабіста я пакідаю гэты параметр яшчэ ніжэй, дзесьці 20Gb - усё-ткі АЗП патрэбна не толькі для PostgreSQL.
- random_page_cost = 1.5 - 2.0 для RAID, 1.1 - 1.3 для SSD. Кошт чытання рандомные старонкі (па-змаўчанню 4). Чым менш seek time дыскавай сістэмы тым менш (але> 1.0) павінен быць гэты параметр. Залішне вялікае значэнне параметру павялічвае схільнасць PgSQL да выбару планаў з сканаваннем ўсёй табліцы (PgSQL лічыць, што танней паслядоўна чытаць усю табліцу, чым рандомные індэкс). І гэта дрэнна.
- temp_buffers = 256Mb. Максімальную колькасць старонак для часовых табліц. То бок, гэта верхні ліміт памеру часовых табліц у кожнай сесіі.
- work_mem - Лічыцца так: АЗП / 32..64 - у нашым выпадку атрымліваецца 1Gb. Ліміт памяці для апрацоўкі аднаго запыту. Гэтая памяць індывідуальная для кожнай сесіі. Тэарэтычна, максімальна патрэбная памяць роўная max_connections * work_mem, на практыцы такога не сустракаецца таму што большая частка сесій амаль заўсёды вісіць у чаканні.
- bgwrite_delay - 20ms. Час сну паміж цыкла запісу на дыск фонавага працэсу запісу. Дадзены працэс адказны за сінхранізацыю старонак, размешчаных у shared_buffers з дыскам. Занадта вялікае значэнне гэтага параметру прывядзе да ўзрастання нагрузкі на checkpoint працэс і працэсы, якія абслугоўваюць сесіі (backend). Малое значэнне прывядзе да поўнай загрузцы аднаго з ядраў.
- synchronous_commit - off. ОПАСНО! Выключэнне сінхранізацыі з дыскам у момант камітаў. Стварае рызыку страты апошніх некалькіх транзакцый (у плыні 0.5-1 секунды), але гарантуе цэласнасць базы дадзеных, у ланцужку камітаў гарантавана адсутнічаюць пропускі. Але значна павялічвае прадукцыйнасць.
Гэта далёка не ўсё, што ўдалося даведацца з Інтэрнэту і артыкулаў на https://its.1c.ru . АЛЕ! Нават гэтых налад хопіць, каб мабыць паскорыць працу 1С: Прадпрыемства на PostgreSQL.
У гэтым канкрэтным выпадку пасля пераходу на PostgreSQL карыстальнікі сталі скардзіцца, што 1С пачатку тармазіць яшчэ мацней, чым у файлавым варыянце. Але пасля гэтага цюнінгу база «паляцела». Зараз усе атрымліваюць асалоду ад хуткай працай. Аднак ёсць і свае мінусы ў выглядзе блокаў зараз. Спыняцца на гэта мы не плануем, будзем капаць далей і выкладваць карысныя змены канфігурацыі PostgreSQL сюды.
Калі з базай дадзеных паўсталі нейкія праблемы, магчыма, Вам дапаможа ўнутранае або знешняе тэставанне .
Базы дадзеных 1С можна публікаваць на вэб-серверах !
Злавесна, ці не праўда?