05.04.2017 |

1C klasteris 8.3

Visų pirma, įdiegus 1C klasterį, reikėjo sukurti darbo eigas. Kaip paaiškėjo, klasterių procesai buvo pradėti kurti automatiškai, priklausomai nuo duomenų bazės apkrovos.

Bandomasis pagrindinės duomenų bazės foninių užduočių vykdymas privertė 1C klasterį be galo perkrauti rphost.exe, o papildomos rphost.exe kurti nenorėjo. Pasigilinus po nustatymus viskas paaiškėjo.

Maksimali darbo eigos atmintis yra atminties kiekis, kurį darbuotojų procesai gali naudoti kartu. Nustatydami parametrą, matuojamą baitais, turite būti labai atsargūs. Jei nustatysite neteisingą reikšmę (nepakanka normaliam vartotojo darbui), vartotojai gaus klaidą „Nepakanka laisvos atminties 1C serveryje“. Šią klaidą taip pat galite gauti, kai baigiasi 1C serverio atminties kvota.

Saugus atminties suvartojimas vienam skambučiui- leidžia valdyti atminties suvartojimą serverio skambučio metu, matuojant baitais. Jei skambutis naudoja daugiau atminties nei tikėtasi, šis skambutis bus baigtas 1C klasteryje nepaleidus darbuotojo proceso iš naujo (rphost.exe). Atitinkamai, serverio skambutį atlikęs „pralaimėtojas“ praras seansą su 1C duomenų baze, nepaveikdamas kitų vartotojų darbo.

viename GB - 1073741824 baitai, todėl 2 GB - 2147483648 baitai

Darbo procesų atminties kiekis, iki kurio serveris laikomas produktyviu - viršijus šį parametrą, 1C klasteryje esantis serveris nustos priimti naujus ryšius.

Informacijos saugumo skaičius vienam procesui- leidžia išskirti darbo procesų informacines bazes. Pagal numatytuosius nustatymus dabartinis 1C klasteris buvo nustatytas į „8“, tačiau per kelias darbo valandas serveris tapo labai nestabilus, vartotojų sesijos užstrigo. Po kiekvieno išskyrimo informacinė bazė(reikšmė - "1") problemos išnyko.

Ryšių skaičius per procesą- numatytoji reikšmė yra "128". Kadangi dabartinė duomenų bazė turi labai didelę apkrovą foniniai darbai(logistikos skaičiavimai, kainų analizė, konkurentų analizė ir kt.) nuspręsta skaičių sumažinti iki „25“.

Paties 1C klasterio nustatymai šiek tiek pasikeitė:

Gedimų tolerancijos lygis- tiek veikiančių serverių, kurie gali sugesti tuo pačiu metu, ir tai nesukels neįprasto vartotojų nutraukimo. Atsarginės kopijos paslaugos paleidžiamos automatiškai tiek, kiek reikia nurodytam gedimų tolerancijai užtikrinti. IN realus režimas laiko, aktyvioji paslauga pakartojama atsarginėms.

Įkėlimo bendrinimo režimas- yra dvi parametro parinktys: „Prioritetas pagal našumą“ - išleidžiama daugiau serverio atminties ir didesnis našumas, „Prioritetas pagal atmintį“ - 1C klasteris taupo serverio atmintį.

Serveris 8.3 pasižymi naujai pertvarkytu vidiniu kodu, nors „iš išorės“ gali atrodyti, kad tai šiek tiek pakeistas 8.2.

Serveris tapo labiau „automatiškai konfigūruojamas“, kai kurie parametrai, pavyzdžiui, darbuotojų procesų skaičius, nebekuriami rankiniu būdu, o skaičiuojami pagal gedimų tolerancijos ir patikimumo užduočių reikalavimų aprašymus.

Tai sumažina tikimybę neteisingas nustatymas serverio ir mažina kvalifikacinius reikalavimus administratoriams.

Sukurtas apkrovos balansavimo mechanizmas, kuris gali būti naudojamas arba visos sistemos veikimui pagerinti, arba naudoti naujas režimas„atminties taupymas“, leidžiantis dirbti „su ribota atmintimi“ tais atvejais, kai naudojama konfigūracija „mėgsta sunaudoti atmintį“.

Darbo stabilumą naudojant didelius atminties kiekius lems nauji gamybos serverio parametrai.

Ypač įdomus parametras „saugus atminties suvartojimas vienam skambučiui“. Tiems, kurie mažai supranta, kas tai yra, geriau nesitreniruoti „produktyviai“. Parametras „Maksimalus darbo procesų atminties dydis“ leidžia „perpildymo“ atveju nesugriauti viso darbo proceso, o tik vieną seansą „su nevykėliu“. „Darbo proceso atminties kiekis, iki kurio serveris laikomas produktyviu“ leidžia blokuoti naujus ryšius, kai tik ši atminties riba viršijama.

Darbo procesus rekomenduoju išskirti pagal informacinę bazę, pavyzdžiui, nurodant parametrą „Informacijos saugumo skaičius vienam procesui = 1“. Su keliomis labai apkrautomis duomenų bazėmis tai sumažins abipusę įtaką tiek patikimumui, tiek našumui.

Atskiras indėlis prie sistemos stabilumo yra licencijų/raktų „išlaidos“. 8.3 tapo įmanoma naudoti „vadybininką programinės įrangos licencijos“ primena „aladin“ vadybininką. Tikslas yra galimybė įdėti raktą ant atskiros mašinos.

Ji įdiegta kaip dar viena klasterio valdytojo „paslauga“. Galite naudoti, pavyzdžiui, „nemokamą“ nešiojamąjį kompiuterį. Pridėkite jį prie 1C 8.3 klasterio, sukurkite atskirą tvarkyklę naudodami „licencijavimo paslaugos“ paslaugą. Į nešiojamąjį kompiuterį galite įterpti aparatinės įrangos raktą arba suaktyvinti programinės įrangos licencijas.

Programuotojus labiausiai domina „Funkcijų priskyrimo reikalavimai“.

Reikalavimai priskirtam 1c funkcionalumui

Taigi nešiojamajame kompiuteryje su saugos raktu, kad nepaleistumėte vartotojų klasterio serveryje, reikia pridėti „reikalavimus“ reikalavimo objektui „Kliento ryšys su informacijos saugumu“ - „Nepriskirti“, t.y. neigti darbuotojų procesus šio serverio tvarkyti klientų ryšius.

Dar įdomiau yra galimybė paleisti „tik fonines užduotis“ klasterio gamybos serveryje be vartotojo seansų. Tokiu būdu galite perkelti labai apkrautas užduotis (kodą) į atskirą mašiną. Be to, viename kompiuteryje galite vykdyti vieną foninę užduotį „uždaryti mėnesį“ naudodami „Papildomo parametro reikšmę“, o kitame – „Atnaujinti viso teksto indeksą“. papildomas parametras“. Pavyzdžiui, jei kaip reikšmę nurodote BackgroundJob.CommonModule, galite apriboti klasteryje esančio darbuotojo serverio darbą tik foninėmis užduotimis su bet kokiu turiniu. BackgroundJob.CommonModule reikšmė.<Имя модуля>.<Имя метода>- nurodys konkretų kodą.

1C klasteris 8.2

Seansai įgalina apkrovos balansavimą ir gedimų toleranciją valdomoje programoje.

Dabar klasterio valdytojas tapo sudėtingesnis. Kai kurias funkcijas dabar galima atskirti į atskirą procesą ir netgi įdėti į kitą veikiančią klasterio serverį. Tai leidžia subalansuoti serverio apkrovą.

Serverio 8.2 gedimų tolerancija pasiekiama šiais būdais:

Informacijos apie vartotojo seansą saugojimas.
Vartotojas nebėra susietas su darbo eiga.
Darbo procesų rezervavimas klasteryje.
Turėtų būti keli darbuotojų procesai, įskaitant nereikalingus
Klasterio rezervavimas.

Nurodomas atsarginis klasteris; prijungus jie yra išvardyti ryšio eilutėje

Tai leidžia užtikrinti darbų tęstinumą!

Kai lūžta fizinis ryšys klientas su grupe (valytoja ištraukė laidą, maitinimas dingo tinklo įranga, problemos su teikėju), jums nereikia iš naujo prisijungti prie informacijos bazės ir pradėti visų darbų iš naujo. Atkūrus fizinį ryšį, vartotojas gali tęsti darbą nuo tos vietos, kur jis buvo nutrauktas.

Jeigu nori Priežiūra klasteriniai kompiuteriai, juos galima išjungti tiesiogiai veikimo metu, netrukdant vartotojams dirbti su informacine baze.

Jei kuris nors klasteryje esantis serveris sugenda, vartotojo darbas nesustos, jis bus automatiškai perkeltas į atsarginį klasterį ir (arba) atsarginių kopijų darbo procesus. Vartotojams toks perėjimas bus nematomas.

Jei vienas iš klasterio darbo procesų sugenda, prie jo prisijungę vartotojai bus automatiškai perkelti į kitus arba atsarginio darbuotojo procesus. Toks perėjimas taip pat bus nematomas vartotojams.

Dažnai įrenginyje kartu su 1C:Enterprise serveriu veikia ir kitos paslaugos - terminalo serveris, SQL serveris ir kt. Ir tam tikru momentu 1C:Enterprise serveris, tiksliau rphost darbuotojo procesas, sunaudoja daugiau atminties nei planuota arba visą atmintį. Dėl to sulėtėja kitų paslaugų ir serverio zombiai. Norėdami išvengti tokių situacijų, turite sukonfigūruoti automatinį 1C:Enterprise serverio darbo eigos paleidimą iš naujo.

Sprendimas

1. Atidarykite 1C Enterprise serverių administravimo konsolę;
2. Išplėskite centrinio serverio medį iki grupių ir pasirinkite mus dominantį klasterį. Pavyzdyje yra tik vienas klasteris;
3. Atidarykite pasirinkto klasterio ypatybes ir peržiūrėkite šią formą

1C:Enterprise 8.3 serverio klasterio ypatybės

Pažvelkime į pavyzdį, parodytą paveikslėlyje:

Iš naujo paleisties intervalas— laikas, po kurio rphost procesas bus priverstas paleisti iš naujo. Prieš pasibaigiant procesui, paleidžiamas naujas rphost procesas, į kurį perkeliami visi ryšiai ir tik tada baigiasi senasis procesas. Tai jokiu būdu neturės įtakos vartotojo patirčiai. Intervalas nurodomas sekundėmis, pavyzdyje nurodomos 24 valandos.

Leidžiamas atminties dydis— atminties kiekis, kuriame darbo eiga gali veikti be problemų. Apimtis nurodoma kilobaitais, pavyzdyje reikšmė yra 20 gigabaitų (iš tikrųjų skaičius per didelis ir reikia pradėti nuo konkrečios sistemos, bet vidutinis skaičius yra 4 GB). Kai tik darbo proceso užimta atmintis viršija nurodytą reikšmę, prasideda atgalinis skaičiavimas.

Leidžiamo atminties kiekio viršijimo intervalas— laikmačiui, paleistam viršijus leistiną atminties kiekį, skaičiuojant nurodytą laiką, bus paleistas naujas darbinis procesas, į kurį perkeliami visi ryšiai, senasis procesas pažymimas kaip išjungtas. Intervalas nurodomas sekundėmis, pavyzdyje nurodoma 30 sekundžių.

Po to sustabdykite išjungtus procesus— laikas, po kurio bus sustabdyta darbo eiga, pažymėta kaip išjungta; jei reikšmė yra 0, procesas nebus baigtas. Intervalas nurodomas sekundėmis, pavyzdyje nurodoma 60 sekundžių.

Pritaikius nustatymus, serverio paslaugos iš naujo paleisti nereikia, jie taikomi dinamiškai.

Iš viso

Taip sukonfigūruojame automatinį 1C:Enterprise serverio darbo procesų paleidimą ir gauname stabilesnę sistemą; jei įvyks atminties nutekėjimas, konkrečios sesijos darbas bus nutrauktas.

Be to, kai kuriose situacijose galite žaisti su nustatymais ir išvengti galimos serverio gedimo, jei padarysite klaidų.

Serveris 8.3 pasižymi naujai pertvarkytu vidiniu kodu, nors „iš išorės“ gali atrodyti, kad tai šiek tiek pakeistas 8.2.

Sukurtas apkrovos balansavimo mechanizmas, kuris gali būti naudojamas arba siekiant padidinti visos sistemos našumą, arba naudoti naują „atminties taupymo“ režimą, leidžiantį dirbti „su ribota atmintimi“ tais atvejais, kai konfigūracija naudojamas „mėgsta suvalgyti atmintį“.

Darbo stabilumą naudojant didelius atminties kiekius lems nauji gamybos serverio parametrai.

Ypač įdomus parametras „saugus atminties suvartojimas vienam skambučiui“. Tiems, kurie mažai supranta, kas tai yra, geriau nesitreniruoti „produktyviai“. Parametras „Maksimalus darbo procesų atminties dydis“ leidžia „perpildymo“ atveju nesugriauti viso darbo proceso, o tik vieną seansą „su nevykėliu“. „Darbo procesų atminties kiekis, iki kurio serveris laikomas produktyviu“ leidžia blokuoti naujus ryšius, kai tik viršijama ši atminties riba.

Atskiras indėlis prie sistemos stabilumo yra licencijų/raktų „išlaidos“. 8.3 versijoje tapo įmanoma naudoti „programinės įrangos licencijų tvarkyklę“, primenančią „aladin“ tvarkyklę. Tikslas yra galimybė įdėti raktą ant atskiros mašinos.

Programuotojus labiausiai domina „Funkcijų priskyrimo reikalavimai“.

Taigi, nešiojamajame kompiuteryje su saugos raktu, kad nepaleistumėte vartotojų klasterio serveryje, reikia pridėti „reikalavimus“ reikalavimo objektui „Kliento ryšys su informacijos sauga“ - „Nepriskirti“, t.y. neleisti šio serverio darbuotojų procesams apdoroti kliento ryšių.

Aišku, kad nėra prasmės perpasakoti dokumentų. Bet jei kas nors duos naudingų patarimų, išplėsiu straipsnį.

Spausdinti (Ctrl+P)

Šiame straipsnyje apžvelgsiu pagrindines veiklas, kurias reikia atlikti norint padidinti 1C našumą 1C kliento-serverio versijoje:

Aparatinės įrangos pajėgumų padidėjimas.
1C:Enterprise serverio nustatymas
SQL serverio nustatymas
Kodo ir algoritmų optimizavimas 1C.

1. Techninės įrangos pajėgumų padidėjimas

Minimalūs reikalavimai kompiuteriams, pateiktiems sertifikuoti įmonei „C“, norint gauti „Suderinamas! 1C: Įmonių programinės įrangos sistema“ parašyta

1C serverio veikimas: įmonė labai priklauso nuo procesoriaus dažnio, o duomenų bazės serverio kompiuterio charakteristikos turi atitikti Microsoft reikalavimus SQL serveris, PostgreSQL, IBM DB2, Oracle duomenų bazė.

2. 1C:Enterprise serverio nustatymas

Instrukcijas, kaip nustatyti veikiančius serverius naudojant 1C:Enterprise technologijų platformą, galite rasti ITS diske

8.3 versijoje buvo pridėti keli nauji parametrai gamybos serveriams konfigūruoti:

Maksimali darbo eigos atmintis. Šis nustatymas leidžia reguliuoti atminties kiekį, kurį gali užimti visi tam tikro klasterio darbuotojų procesai tam tikrame veikiančiame serveryje.
Saugus atminties suvartojimas vienam skambučiui. Šis nustatymas leidžia apriboti atminties kiekį, kuris bus užimtas skambinant serveriui tam tikrame veikiančiame serveryje.
Informacijos saugumo skaičius viename procese ir jungčių skaičius viename procese. Šie parametrai leidžia netiesiogiai reguliuoti darbuotojų procesų skaičių tam tikrame veikiančiame serveryje.
Kiekvienos paslaugos vadovas. Konfigūracija leidžia paleisti kiekvieną klasterio tvarkyklės paslaugą kaip atskirą procesą.

3. SQL serverio nustatymas

Ypatingumas „Microsoft“ nustatymai Sql serverį galima peržiūrėti ITS diske, kad padidintumėte našumą

Naudodami priežiūros planą, esantį skyriuje „Valdymas“, turite atlikti šias įprastas užduotis, kad pagerintumėte našumą:

Indeksų defragmentavimas ir statistikos atnaujinimas turi būti atliekamas kasdien, nes jei indekso suskaidymas yra > 25%, tai labai sumažina serverio našumą.
Defragmentavimas ir statistikos atnaujinimas atliekamas greitai ir nereikia atjungti vartotojų. Taip pat rekomenduojama tai daryti kasdien.
Pilnas pakartotinis indeksavimas – atliekamas su užblokuota duomenų baze, rekomenduojama tai daryti bent kartą per savaitę. Natūralu, kad po pilno pakartotinio indeksavimo indeksai iš karto defragmentuojami ir atnaujinama statistika.

3.1 Indekso suskaidymo laipsnio analizė

Per didelis indekso suskaidymas sukelia didelių I/O operacijų problemų. Atlikus intensyvias duomenų modifikavimo operacijas duomenų bazių lentelėse, pailgėja užklausų ir duomenų modifikavimo operacijų vykdymo laikas.

Taip yra dėl to, kad tokios operacijos modifikuoja indeksus, o tai lemia jų suskaidymą ir įvesties/išvesties operacijų skaičiaus padidėjimą naudojant indeksus duomenų skaitymo ir rašymo operacijų metu.

Efektyviam indeksų naudojimui Reikalingas Microsoft SQL serveris

Reguliariai perindeksuokite duomenų bazės lenteles naudodami komandą DBCC DBREINDEKSAS ( lentelės_pavadinimas ) .
Reguliariai defragmentuokite duomenų bazės indeksus naudodami komandą DBCC INDEXDEFRAG (duomenų bazės_pavadinimas, lentelės_pavadinimas, indekso_pavadinimas) .

Šios problemos sprendimo būdo pasirinkimas priklauso nuo duomenų bazių lentelių modifikavimo operacijų intensyvumo.

MS SQL Server 2005 turi naujų įrankių šiam parametrui valdyti.

Dinaminio valdymo stalo funkcija sys.dm_db_index_physical_stats grąžina suskaidymo procentą stulpelyje avg_fragmentation_in_procent. Jei šio stulpelio reikšmė didesnė nei 25 %, rekomenduojame defragmentuoti šį indeksą, kad būtų atkurtas pradinis našumas. Didelio diapazono nuskaitymo operacijos, įprastos duomenų saugojimo ir ataskaitų teikimo programose, gali būti naudingos sumažinus indekso suskaidymą.

Naudojant šią informaciją galima žymiai sumažinti sistemos apkrovą ir išvengti nereikalingų indeksų, kuriems to nereikia, defragmentavimo operacijų.

3.2 „Microsoft SQL Server“ fizinės atminties naudojimas didesnis nei 2 GB

Microsoft SQL Server 2000 Standartinis leidimas ir Microsoft SQL Server 2005 Workgroup Edition gali naudoti iki 2 GB Fizinė atmintis, kuris dinamiškai paskirstomas ir išleidžiamas priklausomai nuo darbo krūvio. Kai duomenų bazės apimtis padidėja tokiu dydžiu laisvosios kreipties atmintis tampa nepakankama, kad būtų galima efektyviai išsaugoti duomenis talpykloje ir palaikyti priimtino lygio našumą.

3.3 „Microsoft SQL Server“ operacijų žurnalo dydžio sumažinimas

Atliekant intensyvias informacijos bazės duomenų modifikavimo operacijas, padidėja duomenų failų ir operacijų žurnalo dydis. Tam tikru metu duomenų bazei atkurti nebereikia senų operacijų žurnalo įrašų ir juos galima ištrinti, taip atlaisvinant vietos naujiems įrašams. Jei seni operacijų žurnalo įrašai iš karto neištrinami, po kurio laiko operacijų žurnalo failas gali užimti visą laisvą vietą. disko talpa ir dirbti su duomenų baze taps neįmanoma.

Norėdami sumažinti žurnalo failo dydį, pirmiausia turite ištrinti neaktyvius operacijų žurnalo įrašus naudodami komandą ATSARGINĖS KOPĖJIMO ŽURNALAS, tada naudokite komandą DBCC SHRINKFILE sumažinti operacijų žurnalo failo dydį.. Komandų, kurias reikia vykdyti, seka Užklausų analizatorius, taip:

ATSARGINĖS KOPĖJIMO ŽURNALAS Duomenų bazės_pavadinimas SU TRUNCATE_ONLY

DBCC SHRINKFILE(Transaction_Log_File_Name)

3.4 TEMPDB duomenų bazės perkėlimas į kitą didesnį diską.

TEMPDB yra sistemos duomenų bazė „Microsoft“ duomenys SQL serveris, kuriame saugomos laikinos lentelės, sukurtos tiek paties serverio, tiek vartotojų. Ši duomenų bazė sukuriama iš naujo kiekvieną kartą, kai Microsoft SQL Server paleidžiamas iš naujo. Pagal numatytuosius nustatymus šios duomenų bazės dydis yra neribotas ir, jei reikia, jis automatiškai padidinamas 10% dabartinio TEMPDB dydžio dalimis. Tačiau vartotojas gali nepaisyti šių parametrų. Pagal numatytuosius nustatymus minimalus šios duomenų bazės dydis, kuris nustatomas paleidus Microsoft SQL Server, nustatomas pagal dydį sistemos bazė MODEL duomenys. Operacijų žurnalo išvalymas šioje duomenų bazėje yra automatinis ir ištrina tik neaktyvius operacijų žurnalo įrašus.

Kai veikia 1C:Enterprise 8 kliento-serverio režimu, laikinosios lentelės yra plačiai naudojamos . Be to, TEMPDB naudoja Microsoft SQL Server vykdydamas užklausas, kuriose naudojami teiginiai GRUPUOTI PAGAL, SĄJUNGOS, ATSKIRTI ir taip toliau.

Veikiant 1C:Enterprise 8, galima žymiai padidinti TEMPDB duomenų bazės dydį. Jei disko, kuriame yra TEMPDB duomenų bazė, dydis yra nepakankamas, 1C:Enterprise 8 gali sugesti.

Jei ši problema kartojasi reguliariai, TEMPDB rekomenduojama perkelti į kitą didesnį diską.

Šią operaciją galima atlikti šiais būdais:

1. nustatyti loginius TEMPDB duomenų bazės failų pavadinimus (procedūros rezultato stulpelis „NAME“). Norėdami tai padaryti, užklausų analizatoriuje turite paleisti šią komandą:

NAUDOTI tempdb GO EXEC sp_helpfile GO 2.pakeiskite TEMPDB duomenų bazės failų vietą naudodami komandą PAKEISTI DUOMENŲ BAZĘ. Norėdami tai padaryti, Query Analyzer turite paleisti šią komandų seką: USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev,FILENAME= "New_Disk:\New_Directory\tempdb.mdf") GO ALTER DATABASE tempdb MODIFY FILE (NAME = templogas,FILENAME= "New_Disk:\New_Directory\templog.ldf") GO 3. Iš naujo paleiskite „Microsoft SQL Server“.

4. Kodo ir algoritmų optimizavimas 1C

4.1 Užklausos optimizavimas

Didelę dalį problemų, dėl kurių užklausos atlieka neoptimaliai, galima aptikti analizuojant konfigūracijos kodą ir metaduomenų struktūrą. Yra sąrašas tipines klaidas kodo ir duomenų struktūroje, kurių pasekmės yra gerai suprantamos ir lengvai nuspėjamos. Kodo analizė naudojant šį sąrašą gali išspręsti daugumą užklausų našumo problemų nesigilinant į detales. technine informacija(prašymo tekstas SQL kalba, užklausų planas ir kt.).

Pagrindinės neoptimalaus užklausos našumo priežastys, diagnozuotos konfigūracijos kodo ir metaduomenų struktūros lygiu, aptariamos ITS diske:

prisijungia prie antrinių užklausų
jungtys prie virtualių stalų
indeksų ir užklausos sąlygų neatitikimas
naudojant loginį ARBA sąlygomis
naudojant papildomas užklausas sujungimo sąlygoje
duomenų gavimas per tašką iš sudėtinio tipo laukų
virtualių lentelių filtravimas nenaudojant parametrų

4.2 Našumo matavimo naudojimas

1C:Enterprise 8 leidžia derinti ir išmatuoti kodo našumą integruota kalba, vykdomą tiek kliente, tiek serveryje. Ypatinga kliento-serverio informacinės bazės našumo matavimo ypatybė 1C:Enterprise 8 yra ta, kad našumo matavimo rezultatai sujungiami į vieną failą. Jie apima duomenis apie kodo vykdymo eigą įterptoje kalboje ir kliente, ir serveryje. Norint gauti tokį matavimą, pakanka paleisti 1C:Enterprise 8 serverį derinimo režimu (naudojant raktą komandinė eilutė /debug) ir konfigūratoriuje tinkamu laiku tiesiog įjunkite našumo matavimo režimą.

„1C:Enterprise 8“ našumo matavimo režimas leidžia sėkmingai optimizuoti kliento-serverio programų veikimą. Norint atlikti tokį optimizavimą, pakanka atlikti vos kelis veiksmus, tada išanalizuoti našumo matavimų rezultatus ir pereiti prie kodo tobulinimo įtaisytoje kalboje.

Daugiau informacijos apie našumo matavimų naudojimą rasite ITS diske.

Prieš pradėdami sistemos optimizavimo darbus, visada turėtumėte gauti pradinį našumo įvertinimą, naudodami „APDEX Integrated System Performance Assessment“.

4.3 Kodo keitimo įrankiai

Kodo keitimo funkcijos įdiegtos 8.3.5, 1068 platformos konfigūratoriuje, taip pat funkcijos automatinis konvertavimas modaliniai metodai ir kodo skyriai parodyti 1 paveiksle.

1 pav. Kodo keitimo įrankiai konfigūratoriuje

Platformos kūrėjai paaiškina šių įrankių poreikį sakydami, kad kodas taikymo sprendimai turėtų būti aiškus, ypač kai prie konfigūracijos dirba kelių kūrėjų grupė. Tada programos kodas lengva prižiūrėti ir modifikuoti.

Pergalė nebuvo lengva...
Pabandysiu viską aprašyti smulkiai, nors laiko praėjo gana daug. Tikiuosi, kad mano surinkta informacija padės sistemos administratoriai ir duok man peno apmąstymams.
Perkėliau duomenų bazes į 1 mokyklą ir perskyriau vartotoją 8.3 agentui – tai nepadėjo...

Apkeliavau visą mūsų „RuNet“ tinklą ir radau du įdomius straipsnius, kuriuos siūlau perskaityti ir jums.

Pirmą kartą gana išsamus testas tarp dviejų platformų: PS-vidutinės versijos ir dviejų branduolių serverio. Pasirodo gana įdomių taškų, kuriuos akcentavau dirbdamas kitose įmonėse.
efsol.ru/articles/tuning-1c.html

Antrasis yra susijęs su 1c bandymais virtualios mašinos. Štai čia aš pamačiau priežastį, kodėl vėluojama paleisti konfigūraciją:
efsol.ru/articles/performance-comparison-1c.html

Maždaug savaitę kasinėjęs ir išbandęs kelis metodus, nepavyko išspręsti problemos pirmą kartą paleidus. Bet pastebėjau vieną įdomų raštą... Dirbant plonas klientas, antrasis sistemos paleidimas įvyksta beveik akimirksniu. Pakeičiau informacijos apsaugos sistemų skaičiaus viename procese nustatymus: 8 (pagal 8.3 iki šiol 5). Dėl to serveris nustojo gaišti laiką kurdamas RPHOST įeidamas į pėdsaką. bazę, o likusią dalį jis išleido tik konferencijai iškrauti nuo verkšlenimo. Antrosios bazės pradžios laikas sumažintas 10-7 sekundėmis.

Iš principo ši parinktis man visiškai tinka, turint omenyje, kad su kiekviena duomenų baze dirba 7-10 vartotojų, conf nuolat palaikoma RPHOSTe ir prisijungimo laikas yra 4-8 sekundės kartu su autentifikavimu.

Jei turite problemų, kad duomenų bazė nėra dažnai atidaroma, tada galiu pasiūlyti iškirpti nedidelį reg. vartotojo įvedimo užduotis prie kiekvienos duomenų bazės ir sukonfigūruokite paslaugą, kad ji būtų paleista iš naujo vakare (per paslaugas arba per paleidimo intervalą). Manau, tai turėtų padėti, nors čia mus riboja licencijos prieinamumas, todėl turime pagalvoti)))

Tačiau iškilo dar vienas nemalonus momentas; viename iš forumų gavau tokį atsakymą:
Iš viršaus. Ar turite CORP licencijas?

Išplėstinės CORP lygio serverio „1C:Enterprise 8.3“ galimybės, palyginti su 64 bitų PROF lygio serveriu:
* saugus atminties suvartojimas vienam skambučiui;
* informacijos saugumo skaičius vienam procesui;
* darbo procesų atminties kiekis, iki kurio serveris laikomas produktyviu;
* maksimali darbo procesų atminties talpa;
*balansavimo strategija (atmintis, našumas);

Naudojant išvardintus funkcionalumą PROF lygio produktų naudojimas „1C:Enterprise 8. Server License (x86-64)“, ty be pavadinimo CORP, yra neteisėtas.

Nusprendžiau pasitikrinti su vaikinais iš trijų skirtingos įmonės, ar jie žino, kad yra korp ir prof. Į kurį buvo gautas atsakymas: besisukantis pirštas prie šventyklos ir siuntimas į 1c forumą. Ir žemiau yra atsakymas iš 1c palaikymo:

1) >>> Norėčiau paaiškinti skirtumus tarp 8.3 Corp ir 8.3 Prof platformų.
https://partners.v8.1c.ru/forum/message/1301566#m_...
www.1c.ru/news/info.jsp?id=16733

Tiesą sakant, naudojant PROF platformą, pagal licenciją galite naudoti tik numatytuosius klasterio nustatymus.

Jei kyla problemų dėl „numatytųjų“ klasterio nustatymų (atminties trūkumas, negalėjimas atnaujinti konfigūracijos ir pan.), tada
tai yra klaida (platformos arba šios programos sprendimo klaida).
Prašome s konkrečių pavyzdžių sukurti prašymus taisyti.
Klaidos taisymo metu gali būti išduotas raštiškas leidimas (pasirašytas UAB „1C“ direktoriaus) naudotis Corp. licencijos funkcionalumu.
2) >>> Prašau patikslinti, t.y. ar yra dvi 8.3 platformos?
Nr. Šiuo metu platforma nėra viena.
Tačiau teisė naudotis CORP funkcijomis atsiranda tik įsigijus atitinkamą licenciją.
Taip pat šiuo metu nėra šios licencijos programinės įrangos valdymo.
Taigi CORP licencija yra daugiau teisinė sąvoka.

Sąžiningai, aš netikiu įvairiais sąmokslais, bet kai įmonė turi beveik 100% monopolį smulkaus ir vidutinio verslo rinkoje, kyla įvairių minčių.
„Bus kažkokios ataskaitų pateikimo konfigūracijos atnaujinimas, kuriam reikės atnaujinti platformą, kurioje jau bus įdiegtas programinis valdymas... Ir tada jūs (1c) sumokėsite mums pilnai...jūs vaikai. “
P.S. Norėčiau paaiškinti, kad mano serveris yra pagrįstas 2008r2 ir gali būti skirtumų nuo 2012 m. Vis dėlto branduolys buvo detaliai iškirptas iš naujo, o hiper-v 3.0 taip pat yra augimo priedas. Bet kaip sakoma "IT's Alive!!!" 1C paleisti virtualiose mašinose ne tik įmanoma, bet ir skatinama. Dėl to turime 30 8.2 vartotojų ir 20 8.3 vartotojų. Sėkmės jums visiems, būkite kantrūs ir niekada nepasiduok)))