Adesea, alte servicii rulează pe mașină împreună cu serverul 1C:Enterprise - un server terminal, un server SQL etc. Și la un moment dat, serverul 1C:Enterprise, sau mai degrabă procesul de lucru rphost, consumă mai multă memorie decât era planificat sau toată memoria. Ceea ce duce la o încetinire a altor servicii și zombi ai serverului. Pentru a evita astfel de situații, trebuie să configurați repornirea automată a fluxurilor de lucru ale serverului 1C:Enterprise

Soluţie

1. Deschideți consola de administrare a serverelor 1C Enterprise;
2. Extindeți arborele serverului central la clustere și selectați clusterul care ne interesează. În exemplu există un singur cluster;
3. Deschideți proprietățile clusterului selectat și vedeți următorul formular

Proprietățile clusterului de servere 1C:Enterprise 8.3

Să ne uităm la exemplul prezentat în imagine:

Interval de repornire— timp după care procesul rphost va fi forțat să repornească. Înainte ca procesul să se încheie, este lansat un nou proces rphost, la care sunt transferate toate conexiunile și numai atunci vechiul proces se va termina. Acest lucru nu va afecta în niciun fel experiența utilizatorului. Intervalul este indicat în secunde, în exemplu sunt indicate 24 de ore.

Dimensiunea memoriei permisă— cantitatea de memorie în care fluxul de lucru poate funcționa fără probleme. Volumul este indicat în kiloocteți, în exemplu valoarea este de 20 gigaocteți (de fapt, cifra este prea mare și trebuie să începeți de la sistemul specific, dar cifra medie este de 4 GB). De îndată ce memoria ocupată de procesul de lucru depășește valoarea specificată, începe numărătoarea inversă.

Interval pentru depășirea cantității permise de memorie— după ce temporizatorul lansat după depășirea cantității permise de memorie numără invers timpul specificat, va fi lansat un nou proces de lucru, la care sunt transferate toate conexiunile, procesul vechi este marcat ca dezactivat. Intervalul este specificat în secunde, în exemplu sunt indicate 30 de secunde.

Opriți procesele dezactivate după— timpul după care fluxul de lucru marcat ca dezactivat va fi oprit dacă valoarea este 0, procesul nu va fi finalizat; Intervalul este specificat în secunde, în exemplu sunt indicate 60 de secunde.

După aplicarea setărilor, nu trebuie să reporniți serviciul de server, acestea sunt aplicate dinamic.

Total

Acesta este modul în care setăm repornirea automată a proceselor de lucru ale serverului 1C:Enterprise și obținem un sistem mai stabil dacă are loc o scurgere de memorie, activitatea unei anumite sesiuni va fi încheiată.

De asemenea, în unele situații, poți să te joci cu setările și să previi o posibilă prăbușire a serverului dacă faci greșeli.

DECI CE S-A SCHIMBAT ÎN CLUSTERUL 1C 8.3:

În primul rând, după instalarea clusterului 1C, a fost necesar să se creeze fluxuri de lucru. După cum sa dovedit,procesele clustera început să fie creat automat în funcție de încărcarea bazei de date.

O rulare de testare a joburilor de fundal ale bazei de date principale a făcut ca clusterul 1C să supraîncarce la nesfârșit rphost.exe și rphost.exe suplimentar nu a dorit să fie creat. După ce am săpat prin setări, totul a devenit clar.

Memorie maximă pentru fluxul de lucru este cantitatea de memorie pe care procesele de lucru o pot folosi împreună. Trebuie să fiți foarte atenți când setați parametrul, măsurat în octeți. Dacă setați o valoare greșită (insuficient pentru funcționarea normală a utilizatorului) utilizatorii o eroare va fi aruncată "Nu există suficientă memorie liberă pe serverul 1C„. Puteți obține această eroare și când cota de memorie de pe serverul 1C s-a epuizat.

Consum de memorie sigur per apel- vă permite să controlați consumul de memorie în timpul unui apel de server, măsurat în octeți. Dacă un apel utilizează mai multă memorie decât se aștepta, acest apel va fi finalizat în clusterul 1C fără a reporni procesul de lucru (rphost.exe). În consecință, „perdantul” care a efectuat apelul pe server își va pierde sesiunea cu baza de date 1C fără a afecta munca altor utilizatori.

Cantitatea de memorie de proces de lucru până la care serverul este considerat productiv- la Dacă acest parametru este depășit, serverul din clusterul 1C nu va mai accepta conexiuni noi.

Numărul de securitate a informațiilor per proces- vă permite să izolați bazele de informații pentru procesele de lucru. În mod implicit, clusterul 1C curent a fost setat la- „8”, dar pe parcursul mai multor ore de funcționare serverul a devenit foarte instabil, sesiunile utilizatorilor au înghețat. După izolarea fiecărei baze de informații (valoare- „1”) problemele au dispărut.

Numărul de conexiuni per proces- valoarea implicită este „128”. Deoarece baza de date actuală are o încărcătură foarte mare de sarcini de fundal (calcule logistice, analiza listei de prețuri, analiza concurenților etc.), s-a decis reducerea numărului la „25”.

Setările clusterului 1C în sine s-au schimbat ușor:

Nivel de toleranță la erori- Acest numărul de servere funcționale care pot eșua simultan fără a provoca blocarea utilizatorilor. Serviciile de backup sunt lansate automat în cantitatea necesară pentru a asigura toleranța specificată la erori. În timp real, serviciul activ este replicat celor de rezervă.

Modul de partajare a încărcării - există două opțiuni pentru parametru: „Prioritate în funcție de performanță” - este cheltuită mai multă memorie de server și performanța este mai mare, „Prioritate în funcție de memorie” - clusterul 1C salvează memoria serverului.

În loc de o postfață. Clusterul 1C 8.3 funcționează vizibil mai rapid și mai fiabil, crearea unei sesiuni de utilizator cu baza de informații este de multe ori mai rapidă, se poate spune că interfața în modul de compatibilitate cu 1C 8.2.16 zboară. Desigur, există nuanțe, dar unde am fi noi fără ele? Succes în configurarea noului cluster 1C 8.3.

05.04.2017 |

Clusterul 1C 8.3

În primul rând, după instalarea clusterului 1C, a fost necesar să se creeze fluxuri de lucru. După cum sa dovedit, procesele cluster au început să fie create automat, în funcție de încărcarea bazei de date.

O rulare de testare a joburilor de fundal ale bazei de date principale a făcut ca clusterul 1C să supraîncarce la nesfârșit rphost.exe și rphost.exe suplimentar nu a dorit să fie creat. După ce am săpat prin setări, totul a devenit clar.

Memorie maximă pentru fluxul de lucru este cantitatea de memorie pe care procesele de lucru o pot folosi împreună. Trebuie să fiți foarte atenți când setați parametrul, măsurat în octeți. Dacă setați o valoare greșită (insuficientă pentru funcționarea normală a utilizatorului), utilizatorii vor primi eroarea „Nu este suficientă memorie liberă pe serverul 1C”. Puteți obține această eroare și atunci când cota de memorie de pe serverul 1C s-a epuizat.

Consum de memorie sigur per apel- vă permite să controlați consumul de memorie în timpul unui apel de server, măsurat în octeți. Dacă un apel utilizează mai multă memorie decât se aștepta, acest apel va fi finalizat în clusterul 1C fără a reporni procesul de lucru (rphost.exe). În consecință, „perdantul” care a efectuat apelul pe server își va pierde sesiunea cu baza de date 1C fără a afecta munca altor utilizatori.

într-un GB - 1073741824 octeți, deci în 2 GB - 2147483648 octeți

Cantitatea de memorie pentru procesele de lucru până la care serverul este considerat productiv - dacă acest parametru este depășit, serverul din clusterul 1C nu va mai accepta conexiuni noi.

Numărul de securitate a informațiilor per proces- vă permite să izolați bazele de informații pentru procesele de lucru. În mod implicit, actualul cluster 1C a fost setat la „8”, dar pe parcursul mai multor ore de funcționare serverul a devenit foarte instabil, sesiunile utilizatorilor au înghețat. După izolarea fiecărei baze de informații (valoare - „1”) problemele au dispărut.

Numărul de conexiuni per proces- valoarea implicită este „128”. Deoarece baza de date actuală are o încărcătură foarte mare de sarcini de fundal (calcule logistice, analiza listei de prețuri, analiza concurenților etc.), s-a decis reducerea numărului la „25”.

Setările clusterului 1C în sine s-au schimbat ușor:

Nivel de toleranță la erori- acesta este numărul de servere care funcționează care pot eșua în același timp, iar acest lucru nu va duce la încetarea anormală a utilizatorilor. Serviciile de backup sunt lansate automat în cantitatea necesară pentru a asigura toleranța specificată la erori. În timp real, serviciul activ este replicat celor de rezervă.

Modul de partajare a încărcării- există două opțiuni pentru parametru: „Prioritate în funcție de performanță” - este cheltuită mai multă memorie de server și performanța este mai mare, „Prioritate în funcție de memorie” - clusterul 1C salvează memoria serverului.

Serverul 8.3 se caracterizează printr-un cod intern nou reproiectat, deși „din exterior” poate părea că este un 8.2 ușor modificat.

Serverul a devenit mai „auto-configurabil” unii parametri, cum ar fi numărul de procese de lucru, nu mai sunt creați manual, ci sunt calculati pe baza descrierilor cerințelor de toleranță la erori și a sarcinilor de fiabilitate.

Acest lucru reduce probabilitatea unei configurări greșite a serverului și scade cerințele de calificare pentru administratori.

A fost dezvoltat un mecanism de echilibrare a sarcinii, care poate fi utilizat fie pentru a crește performanța sistemului în ansamblu, fie pentru a utiliza un nou mod de „economisire a memoriei”, care vă permite să lucrați „cu memorie limitată” în cazurile în care configurația folosit „îi place să mănânce memoria”.

Stabilitatea funcționării atunci când se utilizează cantități mari de memorie va fi determinată de noii parametri ai serverului de producție.

Parametrul „consum de memorie sigură per apel” este deosebit de interesant. Pentru cei care nu au idee despre ce este, este mai bine să nu se antreneze pe o bază „productivă”. Parametrul „Dimensiunea maximă a memoriei proceselor de lucru” permite, în caz de „depășire”, să nu blocheze întregul proces de lucru, ci doar o singură sesiune „cu ratat”. „Cantitatea de memorie de proces de lucru până la care serverul este considerat productiv” vă permite să blocați noile conexiuni de îndată ce acest prag de memorie este depășit.

Recomand izolarea proceselor de lucru pe baza de informații, de exemplu, specificarea parametrului „Număr de securitate a informațiilor per proces = 1”. Cu mai multe baze de date foarte încărcate, acest lucru va reduce influența reciprocă atât în ​​ceea ce privește fiabilitatea, cât și performanța.

O contribuție separată la stabilitatea sistemului o are „cheltuiala” licențelor/cheilor. În 8.3, a devenit posibilă utilizarea unui „manager de licență software”, care amintește de managerul „aladin”. Scopul este de a putea plasa cheia pe o mașină separată.

Este implementat ca un alt „serviciu” în managerul clusterului. Puteți folosi, de exemplu, un laptop „gratuit”. Adăugați-l la clusterul 1C 8.3, creați un manager separat pe el cu serviciul „serviciu de licențiere”. Puteți introduce o cheie hardware hap în laptop sau puteți activa licențe software.

De cel mai mare interes pentru programatori ar trebui să fie „Cerințe de atribuire a funcționalității”.

Cerințe pentru funcționalitatea atribuită a 1c

Deci, pe un laptop cu o cheie de securitate, pentru a nu lansa utilizatorii pe serverul cluster, trebuie să adăugați „cerințe” pentru obiectul de cerințe „Conexiune client la securitatea informațiilor” - „Nu atribuiți”, adică. împiedică procesele de lucru de pe acest server să proceseze conexiunile client.

Și mai interesantă este capacitatea de a rula „numai joburi de fundal” pe serverul de producție al clusterului fără sesiuni de utilizator. În acest fel, puteți muta sarcinile foarte încărcate (cod) pe o mașină separată. Mai mult, puteți rula o sarcină de fundal de „închidere a lunii” folosind „Valoarea unui parametru suplimentar” pe un computer, iar sarcina de fundal „Actualizarea indexului textului integral” pe altul are loc prin indicația „Valoare de un parametru suplimentar”. De exemplu, dacă specificați BackgroundJob.CommonModule ca valoare, puteți limita munca serverului de lucru din cluster la numai joburi de fundal cu orice conținut. Valoarea BackgroundJob.CommonModule.<Имя модуля>.<Имя метода>- va indica un cod specific.

Clusterul 1C 8.2

Sesiunile permit echilibrarea sarcinii și toleranța la erori în cadrul unei aplicații gestionate.

Managerul clusterului a devenit acum mai complex. Unele funcții pot fi acum separate într-un proces separat și chiar plasate pe un alt server de lucru din cluster. Acest lucru vă permite să echilibrați încărcarea serverului.

Toleranța la erori Server 8.2 se realizează prin:

• Stocarea informațiilor despre sesiunea utilizatorului.
• Utilizatorul nu mai este legat de fluxul de lucru.
• Rezervarea proceselor de lucru într-un cluster.
• Ar trebui să existe mai multe procese de lucru, inclusiv cele redundante
• Rezervare cluster.

Este indicat un cluster de rezervă atunci când sunt conectați, acestea sunt listate în linia de conectare

Acest lucru vă permite să asigurați continuitatea muncii!

Dacă conexiunea fizică a clientului la cluster este întreruptă (doamna de curățenie a scos cablul, alimentarea echipamentului de rețea a fost oprită, a existat o problemă cu furnizorul), nu este nevoie să vă reconectați la baza de informații și să porniți totul munca din nou. După ce conexiunea fizică este restabilită, utilizatorul poate continua să lucreze din punctul în care a fost întreruptă.

Dacă este necesară întreținerea computerelor cluster, acestea pot fi oprite în timpul funcționării fără a opri utilizatorii să lucreze cu baza de informații.

Dacă orice server din cluster eșuează, lucrul utilizatorului nu se va opri, acesta va fi transferat automat în clusterul de rezervă și/sau în procesele de lucru de rezervă. Pentru utilizatori, o astfel de tranziție va fi invizibilă.

Dacă unul dintre procesele de lucru ale clusterului eșuează, utilizatorii conectați la acesta vor fi transferați automat la alte procese de lucru sau de rezervă. O astfel de tranziție va fi, de asemenea, invizibilă pentru utilizatori.

Imprimare (Ctrl+P)

În acest articol, trec în revistă principalele activități care trebuie efectuate pentru a crește performanța 1C în versiunea client-server a 1C:

1. Creșterea capacității hardware.
2. Configurarea unui server 1C:Enterprise
3. Configurarea serverului SQL
4. Optimizarea codului și a algoritmilor în 1C.

1. Creșterea capacității hardware

Cerințe minime pentru calculatoarele depuse pentru certificare la compania „C” pentru a primi certificatul „Compatibil! 1C: Sistem software de întreprindere” scris

Performanța serverului 1C: o întreprindere este destul de dependentă de frecvența procesorului, iar pentru un server de baze de date, caracteristicile computerului trebuie să îndeplinească cerințele Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database.

2. Configurarea serverului 1C:Enterprise

Instrucțiunile pentru configurarea serverelor de lucru cu platforma tehnologică 1C:Enterprise pot fi găsite pe discul ITS

În versiunea 8.3, au fost adăugați câțiva parametri noi pentru a configura serverele de producție:

• Memorie maximă pentru fluxul de lucru. Setarea vă permite să reglați cantitatea de memorie care poate fi ocupată de toate procesele de lucru ale unui anumit cluster pe un anumit server de lucru.
• Consum de memorie sigur per apel. Setarea vă permite să limitați cantitatea de memorie care va fi ocupată atunci când efectuați un apel de server pe un anumit server de lucru.
• Numărul de securitate a informațiilor per proces și numărul de conexiuni per proces. Aceste setări vă permit să reglați indirect numărul de procese de lucru pe un anumit server de lucru.
• Manager pentru fiecare serviciu. Configurația vă permite să rulați fiecare serviciu de manager de cluster ca proces separat.

3. Configurarea serverului SQL

Caracteristicile de reglare a Microsoft Sql Server pentru a crește performanța pot fi vizualizate pe discul ITS

Folosind Planul de întreținere din secțiunea Management, trebuie să efectuați următoarele sarcini de rutină pentru a îmbunătăți productivitatea:

• Defragmentarea indicilor și actualizarea statisticilor trebuie făcute zilnic, pentru că dacă fragmentarea indexului este > 25%, aceasta reduce dramatic performanța serverului.
• Defragmentarea și actualizarea statisticilor se face rapid și nu necesită deconectarea utilizatorilor. De asemenea, este recomandat să o faceți zilnic.
• Reindexare completă – făcută cu baza de date blocată, se recomandă să o faceți cel puțin o dată pe săptămână. Desigur, după reindexarea completă, indicii sunt imediat defragmentați și statisticile sunt actualizate.

3.1 Analiza gradului de fragmentare a indicilor

Fragmentarea excesivă a indexului creează probleme pentru operațiuni mari I/O. După efectuarea unor operațiuni intensive de modificare a datelor din tabelele bazei de date, timpul de execuție al interogărilor și al operațiunilor de modificare a datelor crește.

Acest lucru se datorează faptului că astfel de operațiuni modifică indecșii, ceea ce duce la fragmentarea acestora și la o creștere a numărului de operațiuni I/O atunci când se folosesc indici în timpul operațiunilor de citire și scriere a datelor.

Pentru utilizarea eficientă a indicilor Este necesar Microsoft SQL Server

• Reindexați în mod regulat tabelele bazei de date folosind comanda DBCC DBREINDEX ( nume_tabel ) .
• Defragmentați în mod regulat indexurile bazei de date folosind comanda DBCC INDEXDEFRAG (numele bazei de date, table_name, nume_index) .

Alegerea metodei de rezolvare a acestei probleme depinde de intensitatea operațiunilor de modificare a tabelelor bazei de date.

MS SQL Server 2005 are noi instrumente pentru a controla acest parametru.

Funcția tabelului de control dinamic sys.dm_db_index_physical_stats returnează procentul de fragmentare într-o coloană medie_fragmentare_în_procent. Dacă valoarea din această coloană este mai mare de 25%, vă recomandăm să defragmentați acest index pentru a restabili performanța inițială. Operațiunile de scanare cu o gamă largă comune în aplicațiile de depozitare și raportare de date pot beneficia de fragmentarea redusă a indexului.

Folosirea acestor informații poate reduce semnificativ încărcarea sistemului și poate evita operațiunile inutile de defragmentare pentru indecșii care nu o necesită.

3.2 Utilizarea memoriei fizice mai mare de 2 GB în Microsoft SQL Server

Microsoft SQL Server 2000 Standard Edition și Microsoft SQL Server 2005 Workgroup Edition poate folosi până la 2 GB de memorie fizică, care este alocată și eliberată dinamic în funcție de volumul de lucru. Pe măsură ce dimensiunea bazei de date crește, această cantitate de RAM devine insuficientă pentru a stoca în cache datele în mod eficient și pentru a menține o performanță acceptabilă.

3.3 Reducerea dimensiunii jurnalului de tranzacții Microsoft SQL Server

Efectuarea de operațiuni intensive de modificare a datelor din baza de date duce la creșterea dimensiunii fișierelor de date și a jurnalului de tranzacții. La un moment dat, vechile intrări din jurnalul de tranzacții nu mai sunt necesare pentru recuperarea bazei de date și pot fi șterse, eliberând astfel spațiu pentru noi intrări. Dacă nu ștergeți cu promptitudine intrările vechi din jurnalul de tranzacții, atunci după ceva timp fișierul jurnal de tranzacții poate ocupa tot spațiul liber pe disc și lucrul cu baza de date va deveni imposibil.

Pentru a reduce dimensiunea fișierului jurnal, trebuie mai întâi să ștergeți intrările inactive din jurnalul de tranzacții folosind comanda Jurnalul de backup, apoi folosind comanda DBCC SHRINKFILE reduceți dimensiunea fișierului jurnal de tranzacții. Secvența de comenzi în care trebuie executată Analizor de interogări, după cum urmează:

Jurnalul de backup Numele bazei de date CU TRUNCATE_DOAR

DBCC SHRINKFILE(Transaction_Log_File_Name)

3.4 Mutarea bazei de date TEMPDB pe un alt disc mai mare.

TEMPDB este o bază de date de sistem Microsoft SQL Server care stochează tabele temporare create atât de server însuși, cât și de utilizatori. Această bază de date este recreată de fiecare dată când Microsoft SQL Server este repornit. În mod implicit, dimensiunea acestei baze de date este nelimitată și este mărită automat, dacă este necesar, în porțiuni de 10% din dimensiunea curentă TEMPDB. Cu toate acestea, acești parametri pot fi suprascriși de către utilizator. În mod implicit, dimensiunea minimă a acestei baze de date, care este setată la pornirea Microsoft SQL Server, este determinată de dimensiunea bazei de date a sistemului MODEL. Curățarea jurnalului de tranzacții din această bază de date este automată și șterge numai intrările inactive din jurnalul de tranzacții.

Când rulați 1C:Enterprise 8 în modul client-server, tabelele temporare sunt utilizate pe scară largă . În plus, TEMPDB este utilizat de Microsoft SQL Server atunci când execută interogări care utilizează instrucțiunile A SE GRUPA CU, UNIUNE, DISTINCTși așa mai departe.

În timpul funcționării 1C:Enterprise 8, este posibilă o creștere semnificativă a dimensiunii bazei de date TEMPDB. Dacă dimensiunea discului pe care se află baza de date TEMPDB este insuficientă, 1C:Enterprise 8 se poate bloca.

Dacă această problemă apare în mod regulat, atunci este recomandat să mutați TEMPDB pe un alt disc mai mare.

Această operație poate fi efectuată în felul următor:

1. determinați numele logice ale fișierelor bazei de date TEMPDB (coloana „NUME” a rezultatului procedurii). Pentru a face acest lucru, trebuie să rulați următoarea comandă în Query Analyzer:

USE tempdb GO EXEC sp_helpfile GO 2.schimbați locația fișierelor bazei de date TEMPDB folosind comanda ALTERA BAZA DE DATE. Pentru a face acest lucru, trebuie să rulați următoarea secvență de comenzi în Query Analyzer: USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev,FILENAME= „New_Disk:\New_Directory\tempdb.mdf”) GO ALTER DATABASE tempdb MODIFY FILE (NUME = templog,FILENAME= „New_Disk:\New_Directory\templog.ldf”) GO 3. Reporniți Microsoft SQL Server.

4. Optimizarea codului și a algoritmilor în 1C

4.1 Optimizarea interogărilor

O parte semnificativă a problemelor care determină performanța suboptimă a interogărilor pot fi detectate prin analiza codului de configurare și a structurii metadatelor. Există o listă de erori tipice în structura codului și a datelor, ale căror consecințe sunt destul de bine studiate și ușor de previzibil. Analiza codului folosind această listă de verificare vă permite să rezolvați majoritatea problemelor de performanță a interogărilor fără a explora informații tehnice detaliate (text de interogare SQL, plan de interogare etc.).

Principalele motive pentru performanța neoptimală a interogării, diagnosticate la nivelul codului de configurare și al structurii metadatelor, sunt discutate pe discul ITS:

• se alătură cu subinterogări
• conexiuni la mese virtuale
• nepotrivire între indici și condițiile de interogare
• folosind SAU logic în condiții
• folosind subinterogări într-o condiție de îmbinare
• primirea datelor printr-un punct din câmpuri de tip compus
• filtrarea tabelelor virtuale fără a utiliza parametri

4.2 Utilizarea contorizării performanței

1C:Enterprise 8 vă permite să depanați și să măsurați performanța codului în limbajul încorporat, executat atât pe client, cât și pe server. O caracteristică specială a măsurării performanței pentru o bază de informații client-server în 1C:Enterprise 8 este că rezultatele măsurării performanței sunt combinate într-un singur fișier. Acestea includ date despre progresul execuției codului în limbajul încorporat atât pe client, cât și pe server. Pentru a obține o astfel de măsurare, este suficient să porniți serverul 1C:Enterprise 8 în modul de depanare (folosind comutatorul din linia de comandă /debug) și în Configurator, la momentul potrivit, pur și simplu activați modul de măsurare a performanței.

Modul de măsurare a performanței în 1C:Enterprise 8 vă permite să optimizați cu succes funcționarea aplicațiilor client-server. Pentru a efectua o astfel de optimizare, este suficient să efectuați doar câțiva pași, apoi să analizați rezultatele măsurătorilor de performanță și să treceți la îmbunătățirea codului în limbajul încorporat.

Mai multe detalii despre utilizarea măsurătorilor de performanță pot fi găsite pe discul ITS.

Înainte de a începe munca de optimizare a sistemului, ar trebui să obțineți întotdeauna o evaluare inițială a performanței utilizând „Evaluarea performanței sistemului integrat APDEX”.

4.3 Instrumente de refactorizare a codului

Funcțiile de refactorizare a codului implementate în configuratorul platformei 8.3.5, 1068, precum și funcțiile pentru conversia automată a metodelor modale și a secțiunilor de cod sunt prezentate în Figura 1.

Fig 1 Instrumente de refactorizare a codului în configurator

Dezvoltatorii platformei explică necesitatea acestor instrumente prin faptul că codul soluțiilor aplicației trebuie să fie de înțeles, mai ales atunci când un grup de mai mulți dezvoltatori lucrează la configurare. Apoi codul programului este ușor de întreținut și modificat.

Victoria nu a fost ușoară...
Voi încerca să descriu totul în detaliu, deși a trecut destul de mult timp. Sper că informațiile pe care le-am adunat vor ajuta administratorii de sistem și să-mi dea ceva la care să mă gândesc.
Am mutat bazele de date la 1 școală și am realocat utilizatorul pentru agentul 8.3 - nu a ajutat...

Am parcurs RuNet-ul nostru și am găsit două articole interesante, pe care vă sugerez să le citiți și dumneavoastră.

Pentru prima dată, un test destul de detaliat între două platforme: versiunea PS-middle și serverul dual-core. Apar puncte destul de interesante care au fost subliniate de mine în timp ce lucram în alte companii.
efsol.ru/articles/tuning-1c.html

Al doilea se referă la testele 1c pe mașini virtuale. Aici am văzut motivul întârzierii lansării configurației:
efsol.ru/articles/performance-comparison-1c.html

După ce am săpat aproximativ o săptămână și am încercat mai multe metode, nu am putut rezolva problema cu prima lansare. Dar am observat un model interesant... Când clientul subțire rulează, a doua pornire a sistemului are loc aproape instantaneu. Am schimbat setările pentru numărul de sisteme de securitate a informațiilor pe proces: 8 (sunt 5 baze de date pe 8.3 până acum). Ca rezultat, din moment ce serverul a încetat să mai piardă timpul creând RPHOST la intrarea pe traseu. a cheltuit baza și restul doar pentru a descărca conferința din scâncete. S-a redus timpul de pornire al bazei secunde cu 10-7 secunde.

În principiu, această opțiune mi se potrivește pe deplin, având în vedere că la fiecare bază de date lucrează 7-10 utilizatori, conf-ul este menținut constant în RPHOSTe și timpul de conectare este de 4-8 secunde cu autentificare împreună.

Dacă aveți probleme că baza de date nu este deschisă des, atunci ca opțiune vă pot sugera tăierea unui mic reg. sarcină de introducere a utilizatorului la fiecare bază de date și configurați serviciul să repornească seara (fie prin servicii, fie printr-un interval de repornire). Cred că acest lucru ar trebui să ajute, deși aici suntem limitați de disponibilitatea unei licențe, așa că trebuie să ne gândim)))

Dar un alt moment neplăcut a apărut pe unul dintre forumuri am primit acest răspuns:
Offtop. Aveți licențe CORP?

Capacități extinse ale serverului de nivel CORP „1C:Enterprise 8.3” în comparație cu serverul de nivel PROF pe 64 de biți:
* consum de memorie sigur per apel;
* numărul de securitate a informațiilor pe proces;
* cantitatea de memorie a proceselor de lucru până la care serverul este considerat productiv;
* capacitatea maximă de memorie a proceselor de lucru;
*strategia de echilibrare (memorie, performanță);

Utilizarea funcționalității enumerate folosind produsele „1C:Enterprise 8. Server License (x86-64)” de nivel PROF, adică cele care nu au denumirea CORP în nume, este ilegală.

Am decis să verific cu băieții de la trei companii diferite dacă știau că există o platformă corporativă și prof. La care răspunsul a fost primit sub forma unui deget care se învârte la tâmplă și a unei trimiteri către forumul 1c. Și mai jos este răspunsul de la suportul 1c:

1) >>> Aș dori să clarific diferențele dintre platforma 8.3 Corp și 8.3 Prof.
https://partners.v8.1c.ru/forum/message/1301566#m_...
www.1c.ru/news/info.jsp?id=16733

De fapt, atunci când utilizați Platforma PROF, conform licenței, puteți utiliza doar setările implicite ale clusterului.

Dacă întâmpinați probleme cu setările „implicite” ale clusterului (lipsa memoriei, incapacitatea de a actualiza configurația etc.), atunci
acest comportament este o eroare (fie al platformei, fie al acestei soluții de aplicație).
Creați cereri de corectare cu exemple specifice.
În timp ce eroarea este corectată, se poate emite permisiunea în scris (semnată de directorul JSC 1C) pentru a utiliza funcționalitatea licenței Corp.
2) >>> Vă rugăm să clarificați, i.e. există două platforme 8.3?
Nu. Platforma nu este momentan singură.
Cu toate acestea, dreptul de a utiliza funcționalitatea CORP apare numai la achiziționarea licenței corespunzătoare.
De asemenea, nu există un control software pentru această licență în acest moment.
Astfel, licența CORP este mai mult un concept legal.

Sincer, nu cred în diverse tipuri de conspirații, dar atunci când o companie are un monopol aproape 100% pe piața întreprinderilor mici și mijlocii, îmi vin în minte gânduri diferite.
„Va fi o actualizare a unui fel de configurație pentru depunerea rapoartelor, care va necesita actualizarea platformei, în care controlul software-ului va fi deja implementat... Și apoi ne veți plăti (1c) integral... copii. ”
P.S. Aș dori să clarific că serverul meu se bazează pe 2008r2 și pot exista diferențe față de 2012. Totuși, kernel-ul a fost tăiat în detaliu, iar hyper-v 3.0 este, de asemenea, un bonus pentru creștere. Dar cum se spune „Este viu!!!” iar rularea 1C pe mașini virtuale nu este doar posibilă, ci și încurajată. Ca rezultat, avem 30 8.2 utilizatori și 20 8.3 utilizatori. Succes tuturor, aveți răbdare și nu renunțați niciodată)))