Consumul maxim de memorie de server a fost depășit. Capacitate hardware crescută

11.05.2020 Știri

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 sarcini de fiabilitate.

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 „overflow”, să nu blocheze întregul proces de lucru, ci doar o singură sesiune „cu ratatul”. „Cantitatea de memorie pentru procesele 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”.

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ă. nega procesele lucrătorilor a acestui server gestionează conexiunile clientului.

Ș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 avea o sarcină de fundal „închiderea lunii” prin „Valoare parametru suplimentar" rulează pe un computer, iar jobul de fundal "Actualizarea indexului text integral" pe altul. Clarificarea are loc prin specificarea "Valoarea parametrului 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 codul specific.

Este clar că nu are rost să repovestim documentația. Dar dacă cineva dă niște sfaturi utile, voi extinde articolul.

Î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 „Insuficient memorie libera 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ă apelul folosește mai multa memorie decât era de așteptat, 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, clusterul 1C curent a fost setat la „ 8 „, dar pe parcursul mai multor ore de funcționare, serverul s-a comportat 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- valoare implicită " 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 simultan și 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 sarcini de fiabilitate.

Acest lucru reduce probabilitatea setare incorectă server și reduce cerințele de calificare pentru administratori.

A fost dezvoltat un mecanism de echilibrare a sarcinii, care poate fi folosit 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 și sarcina de fundal „Actualizarea indexului de text integral” pe altul. Clarificarea are loc prin indicația „Valoarea 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.

Vă rugăm să rețineți că setările clusterului sunt responsabile pentru setările tuturor serverelor care aparțin clusterului configurat. Un cluster presupune operarea mai multor servere fizice sau virtuale care lucrează cu aceleași baze de date de informații.

Intervalul de repornire– este responsabil pentru frecvența repornirii proceselor de lucru în cluster. Acest parametru trebuie setat atunci când serverul rulează non-stop. Se recomandă asocierea frecvenței de repornire cu ciclul tehnologic al bazelor de info cluster. De obicei, aceasta este la fiecare 24 de ore (86400 de secunde). După cum știți, procesele de lucru ale serverelor 1C procesează și stochează datele de lucru.

Repornirea automată a fost proiectată în platformă „pentru a minimiza efectele negative ale fragmentării și scurgerilor de memorie în fluxurile de lucru”. ITS are chiar și informații despre cum să organizeze repornirea proceselor de lucru pe baza altor parametri (dimensiunea memoriei, resursele ocupate etc.).

Dimensiunea memoriei permisă– protejează serverele 1C de suprasolicitarea memoriei. Dacă procesul depășește acest volum în interval de depășire a volumului admis, procesul este repornit. Poate fi calculată ca dimensiunea maximă de memorie ocupată de procesele „rphost” în perioadele de vârf de încărcare a serverului. De asemenea, merită să setați un interval mic pentru depășirea volumului permis.

Abaterea permisă a numărului de erori de server. Platforma calculează numărul mediu de erori de server în raport cu numărul de apeluri către server în decurs de 5 minute. Dacă acest raport depășește valoarea permisă, atunci fluxul de lucru este considerat „problematic” și poate fi încheiat de sistem dacă steag-ul este setat „Începe forțat procesele problematice.”

Opriți procesele dezactivate după. Dacă este depășită cantitatea permisă de memorie, procesul de lucru nu se încheie imediat, ci devine „dezactivat”, astfel încât să existe timp pentru a „transfera” datele de lucru fără pierderi către noul proces de lucru care rulează. Dacă acest parametru este specificat, atunci procesul „dezactivat” se va încheia în orice caz după expirarea acestui timp. Dacă observați procese de lucru „înghețate” în funcționarea serverului 1C, atunci puteți seta acest parametru la 2-5 minute.
Aceste setări sunt setate individual pentru fiecare server 1C.

Memorie maximă pentru fluxul de lucru– acesta este volumul total memorie care poate fi ocupată de procesele de lucru (rphost) pe clusterul curent. Dacă parametrul este setat la „0”, acesta ocupă 80% din memoria RAM a serverului. „-1” - fără restricții. Când un DBMS și un server 1C rulează pe același server, trebuie să partajeze RAM. Dacă în timpul funcționării se dovedește că serverul DBMS nu are suficientă memorie, atunci puteți limita memoria alocată serverului 1C folosind acest parametru. Dacă DBMS și 1C sunt separate de servere, atunci este logic să calculați acest parametru folosind formula:

„Volum maxim” = „RAM totală” – „ RAM OS";

„OS RAM” se calculează pe principiul a 1 GB pentru fiecare 16 GB de RAM de server

Consum de memorie sigur per apel. În general, apelurile individuale nu ar trebui să ocupe toată memoria RAM alocată unui proces de lucru. Dacă parametrul este setat la „0”, atunci debitul sigur va fi egal cu 5% din „ Capacitate maximă de memorie pentru procesele de lucru". „-1” - fără limitare, ceea ce nu este foarte recomandat. În cele mai multe cazuri, este mai bine să lăsați acest parametru la „0”.

Utilizarea parametrilor „Numărul de securitate a informațiilor per proces” și „Numărul de conexiuni per proces” puteți controla distribuția muncii serverului 1C între procesele de lucru. De exemplu, alergați pentru fiecare baza de informatii un „rphost” separat, astfel încât, în caz de blocare a procesului, numai utilizatorii unei baze de date sunt deconectați. Acești parametri ar trebui selectați individual pentru fiecare configurație de server.

Limitarea utilizării RAM de către serverul DBMS– Serverul MS SQL DBMS are o caracteristică remarcabilă - îi place să încarce baze de date cu care lucrează activ complet în RAM. Dacă nu îl limitați, va lua toată memoria RAM posibilă.

  • Dacă serverul 1C:Enterprise este instalat cu Microsoft SQL Server, atunci pragul superior de memorie trebuie redus cu o cantitate suficientă pentru funcționarea serverului 1C.
  • Dacă numai DBMS rulează pe server, atunci pentru DBMS conform formulei:

„Memorie DBMS” = „RAM generală” – „RAM OS”;

Memorie partajată– se știu multe despre acest parametru, dar totuși se întâmplă ca oamenii să uite de el. Îl setăm la „1” dacă serverul 1C și DBMS funcționează pe același sistem fizic sau server virtual. Apropo, funcționează începând de la platforma 8.2.17.

Gradul maxim de paralelism– determină câte procesoare sunt folosite la executarea unei cereri. SGBD paralelizează regăsirea datelor atunci când execută interogări complexe pe mai multe fire. Pentru 1C este recomandat să îl setați la „1”, adică într-un fir.

Extensia automată a fișierelor bazei de date- determinăm pasul în MB cu care fișierul bazei de date este „extins”. Dacă pasul este mic, atunci cu creșterea activă a bazei de date, extinderile frecvente vor duce la încărcare suplimentară sistem de discuri. Este mai bine să-l setați la 500 – 1000 MB.

Reindexarea și defragmentarea indecșilor– se recomandă defragmentarea/reindexarea cel puțin o dată pe săptămână. Reindexarea blochează mesele, așa că cel mai bine este să rulați în timpul orelor de lucru sau în perioadele de încărcare minimă. Nu are rost să faci defragmentare după reconstruirea indexului (reindexare). Conform recomandării Microsoft, defragmentarea se face dacă fragmentarea indexului nu depășește 30%. Dacă este mai mare, se recomandă reindexarea.

Planul de alimentare– în setările de putere sistem de operare setată la performanță ridicată.

Vă rugăm să rețineți că setările clusterului sunt responsabile pentru setările tuturor serverelor care aparțin clusterului configurat. Un cluster presupune operarea mai multor servere fizice sau virtuale care lucrează cu aceleași baze de date de informații.

Intervalul de repornire– este responsabil pentru frecvența repornirii proceselor de lucru în cluster. Acest parametru trebuie setat atunci când serverul rulează non-stop. Se recomandă asocierea frecvenței de repornire cu ciclul tehnologic al bazelor de info cluster. De obicei, aceasta este la fiecare 24 de ore (86400 de secunde). După cum știți, procesele de lucru ale serverelor 1C procesează și stochează datele de lucru.

Repornirea automată a fost proiectată în platformă „pentru a minimiza efectele negative ale fragmentării și scurgerilor de memorie în fluxurile de lucru”. ITS are chiar și informații despre cum să organizeze repornirea proceselor de lucru pe baza altor parametri (dimensiunea memoriei, resursele ocupate etc.).

Dimensiunea memoriei permisă– protejează serverele 1C de suprasolicitarea memoriei. Dacă procesul depășește acest volum în interval de depășire a volumului admis, procesul este repornit. Poate fi calculată ca dimensiunea maximă de memorie ocupată de procesele „rphost” în perioadele de vârf de încărcare a serverului. De asemenea, merită să setați un interval mic pentru depășirea volumului permis.

Abaterea permisă a numărului de erori de server. Platforma calculează numărul mediu de erori de server în raport cu numărul de apeluri către server în decurs de 5 minute. Dacă acest raport depășește valoarea permisă, atunci fluxul de lucru este considerat „problematic” și poate fi încheiat de sistem dacă steag-ul este setat „Începe forțat procesele problematice.”

Opriți procesele dezactivate după. Dacă este depășită cantitatea permisă de memorie, procesul de lucru nu se încheie imediat, ci devine „dezactivat”, astfel încât să existe timp pentru a „transfera” datele de lucru fără pierderi către noul proces de lucru care rulează. Dacă acest parametru este specificat, atunci procesul „dezactivat” se va încheia în orice caz după expirarea acestui timp. Dacă observați procese de lucru „înghețate” în funcționarea serverului 1C, atunci puteți seta acest parametru la 2-5 minute.
Aceste setări sunt setate individual pentru fiecare server 1C.

Memorie maximă pentru fluxul de lucru– acesta este volumul total memorie care poate fi ocupată de procesele de lucru (rphost) pe clusterul curent. Dacă parametrul este setat la „0”, acesta ocupă 80% din memoria RAM a serverului. „-1” - fără restricții. Când un DBMS și un server 1C rulează pe același server, trebuie să partajeze RAM. Dacă în timpul funcționării se dovedește că serverul DBMS nu are suficientă memorie, atunci puteți limita memoria alocată serverului 1C folosind acest parametru. Dacă DBMS și 1C sunt separate de servere, atunci este logic să calculați acest parametru folosind formula:

„Volum maxim” = „RAM totală” – „RAM OS”;

„OS RAM” se calculează pe principiul a 1 GB pentru fiecare 16 GB de RAM de server

Consum de memorie sigur per apel. În general, apelurile individuale nu ar trebui să ocupe toată memoria RAM alocată unui proces de lucru. Dacă parametrul este setat la „0”, atunci debitul sigur va fi egal cu 5% din „ Capacitate maximă de memorie pentru procesele de lucru". „-1” - fără limitare, ceea ce nu este foarte recomandat. În cele mai multe cazuri, este mai bine să lăsați acest parametru la „0”.

Utilizarea parametrilor „Numărul de securitate a informațiilor per proces” și „Numărul de conexiuni per proces” puteți controla distribuția muncii serverului 1C între procesele de lucru. De exemplu, rulați un „rphost” separat pentru fiecare bază de informații, astfel încât, în caz de blocare a procesului, numai utilizatorii unei baze de date să fie deconectați. Acești parametri ar trebui selectați individual pentru fiecare configurație de server.

Limitarea utilizării RAM de către serverul DBMS– Serverul MS SQL DBMS are o caracteristică remarcabilă - îi place să încarce baze de date cu care lucrează activ complet în RAM. Dacă nu îl limitați, va lua toată memoria RAM posibilă.

  • Dacă serverul 1C:Enterprise este instalat împreună cu Microsoft SQL Server, atunci pragul superior de memorie trebuie redus cu o sumă suficientă pentru funcționarea serverului 1C.
  • Dacă numai DBMS rulează pe server, atunci pentru DBMS conform formulei:

„Memorie DBMS” = „RAM generală” – „RAM OS”;

Memorie partajată– se știu multe despre acest parametru, dar totuși se întâmplă ca oamenii să uite de el. Îl setăm la „1” dacă serverul 1C și DBMS rulează pe același server fizic sau virtual. Apropo, funcționează începând de la platforma 8.2.17.

Gradul maxim de paralelism– determină câte procesoare sunt folosite la executarea unei cereri. SGBD paralelizează regăsirea datelor atunci când execută interogări complexe pe mai multe fire. Pentru 1C este recomandat să îl setați la „1”, adică într-un fir.

Extensia automată a fișierelor bazei de date- determinăm pasul în MB cu care fișierul bazei de date este „extins”. Dacă pasul este mic, atunci cu creșterea activă a bazei de date, extinderile frecvente vor duce la încărcare suplimentară a sistemului de discuri. Este mai bine să-l setați la 500 – 1000 MB.

Reindexarea și defragmentarea indecșilor– se recomandă defragmentarea/reindexarea cel puțin o dată pe săptămână. Reindexarea blochează mesele, așa că cel mai bine este să rulați în timpul orelor de lucru sau în perioadele de încărcare minimă. Nu are rost să faci defragmentare după reconstruirea indexului (reindexare). Conform recomandării Microsoft, defragmentarea se face dacă fragmentarea indexului nu depășește 30%. Dacă este mai mare, se recomandă reindexarea.

Planul de alimentare– setați setările de putere ale sistemului de operare la performanță ridicată.

Adesea, alte servicii rulează pe mașină împreună cu serverul 1C:Enterprise - server terminal, 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:

Intervalul de repornire— timp după care procesul rphost va fi forțat să repornească. Înainte ca procesul să iasă, acesta începe proces nou rphost, la care sunt transferate toate conexiunile și numai atunci vechiul proces va fi încheiat. 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 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.