1s cantitate de memorie permisă pentru procesele de lucru. Rezolvarea eventualelor probleme de instalare

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.

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.

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țele 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ă. î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 codul specific.

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

Termeni, concepte

De ce ai nevoie de un server 1C?

Termenul „cluster de servere” se referă la mai multe computere (servere) care efectuează o sarcină comună.

Sarcinile rezolvate de clusterul de servere 1C:Enterprise 8 sunt prezentate în figura de mai jos.

Diferența dintre 8.1 și 8.2

Clusterul 1C 8.1

Clusterul de servere 1C:Enterprise 8.1 este o implementare a ideilor de distribuție a încărcăturii pe serverele care deservesc cererile clienților. Acest mecanism distribuie sarcina resurselor de calcul pe un server sau mai multe servere („Servere de lucru”), asigurând astfel scalarea aplicației. Clusterul de server dublează codul care servește conexiunile client. Codul executabil duplicat al clusterului se numește „Proces de lucru” (rphost). Când instalați un cluster, este creat un singur proces de lucru.
Mai multe procese de lucru pe un server fac posibilă utilizarea eficientă a cantității de RAM și a resurselor procesorului pentru a executa cereri, precum și conectarea unei sesiuni client la un alt proces de lucru dacă cel curent „se blochează”.
Programul Server Agent (ragent) este responsabil pentru înțelegerea a ceea ce rulează pe un anumit server. Oprirea agentului server va face ca serverul să nu fie disponibil pentru utilizare de către cluster. Agentul își stochează informațiile în fișierul srvribrg.lst.
Informațiile despre bazele de date de lucru și procesele de lucru implicate sunt deținute de „Managerul serverului” (rmngr). Stochează aceste informații în fișierul 1CV8Reg.lst. Oprirea managerului de server poate duce la repornirea aplicațiilor client dacă managerul repornește cu succes sau la oprirea completă a serverelor de lucru ale întregului cluster.
1C:Enterprise 8.1 permite posibilitatea de a crea mai multe clustere independente pe un server. Fiecare dintre ele este identificat în rețea printr-un „port IP” unic și un număr unic în fișierele de serviciu. Primul cluster primește implicit portul 1541.
Complementul Enterprise Servers este conceput pentru a gestiona un cluster.
Vă puteți conecta la servere după numele serverului sau adresa IP.

Agent server

Agentul server „știe” despre toate clusterele care rulează pe server. Aceste informații sunt stocate în fișierul srvribrg.lst cu o listă de clustere și lista de administratori. Portul principal al agentului este 1540. Pe fiecare server de lucru, poate fi lansat un singur agent, care deservește toate clusterele posibile de pe acest server.
Pentru a obține informații mai detaliate vizual, utilizați utilitarul Process Explorer (dezvoltat de Sysinternals). Programul vă permite să aruncați o privire mai profundă asupra oricăror procese care rulează, inclusiv a unui cluster de servere 1C:Enterprise 8.1.

Manager de cluster

Managerul clusterului este responsabil pentru funcționarea clusterului. Fiecare cluster are propriul manager. Managerul stochează informații despre cluster în fișierul 1CV8Reg.lst (registru cluster). Fiecare Cluster Manager are, de asemenea, propriul său port pe Work Server. Pentru primul cluster, portul implicit Manager este 1541. Acest port este afișat în snap-in-ul 1C:Enterprise Servers în ramura Clustere, identificând clusterul.
Managerul primește solicitări de la partea client a 1C:Enterprise 8.1 și ia o decizie căreia îi va trimite această solicitare de serviciu.

Managerul folosește portul de serviciu pentru a interacționa cu procesele de lucru.

Procesul de lucru

Procesul de lucru este responsabil pentru „lucrarea cu clienții”. Putem spune că în versiunea anterioară a 1C:Enterprise 8.0 a existat un singur „Flux de lucru”.
Pot exista mai multe procese de lucru într-un cluster 1C:Enterprise 8.1. Managerul serverului decide ce proces de lucru va servi conexiunea client. Pentru conexiunile client, proceselor de lucru le este alocată în mod implicit o gamă de porturi IP 1560 – 1591. În plus, fiecărui proces de lucru îi este atribuit un port de serviciu pentru comunicarea cu managerul de cluster. Fiecare proces de lucru utilizează până la 2 Gb de RAM într-un sistem de operare pe 32 de biți. Într-un sistem de operare pe 64 de biți, limitarea este impusă de cantitatea fizică de RAM

Clusterul 1C 8.2

Server cluster 1C:Enterprise 8.2 – dezvoltarea în continuare a tehnologiilor server 8.2.

Serverul poate funcționa „ca 8.1”, adică rămâne compatibil cu tehnologiile anterioare.

Și în plus, a fost implementată o nouă abordare a funcționării serverului. Acum, în loc de procese, sesiunile joacă un rol important.

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

Manager de cluster

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 permite continuitatea funcționării:

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.

Clusterul 1C 8.3

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.

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țele 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ă. împiedică procesele de lucru de pe acest server să proceseze conexiunile client.

Și mai interesantă este capacitatea de a rula „numai lucrări 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.

Rezolvarea eventualelor probleme de instalare

Când instalați partea de server 1C:Enterprise 8.1, puteți crea un utilizator nou sau puteți selecta un cont existent.

În cazul selectării unui cont existent, trebuie să furnizați parola corectă și confirmarea, altfel pornirea backend-ului va duce la o eroare.
Când rulați Cluster Agent pentru prima dată, este creat un cluster implicit.
Clusterul implicit are următoarele caracteristici:
· numărul portului – 1541;
· Interval de porturi IP – 1560:1591;
· suport pentru multe fluxuri de lucru – dezactivat;
· un proces de lucru, numărul portului este setat din intervalul specificat.
Dacă există probleme când porniți pentru prima dată Cluster Agent, este posibil ca clusterul implicit să nu fie creat. Acest lucru se manifestă prin faptul că atunci când agentul server (ragent) pornește, acesta pornește, dar nu pornește alte procese de cluster (rmngr, rphost). Lista de clustere srvribrg.lst arată astfel:
{
{0},
În acest caz, puteți opri procesul ragent, ștergeți lista de clustere (srvribrg.lst) și porniți din nou ragent.

Verificați potrivirea dintre porturile specificate în parametrul de port al liniei de comandă pentru pornirea serviciului de agent server și cele specificate în dialogul de parametri centrali ai serverului din consola cluster:

— Opriți serviciul 1C:Enterprise 8.1 Server Agent.

Dacă Server Agent rulează ca o aplicație, acesta poate fi oprit apăsând combinația de taste Ctrl+C.
- Asigurați-vă în Task Manager că toate procesele ragent, rmngr, rphost s-au încheiat. Dacă este necesar, completați-le folosind Managerul de activități.

— Deschideți proprietățile serviciului 1C:Enterprise 8.1 Server Agent.

- Fiți atenți la linia „Fișier executabil” (Calea către executabil). Are parametrul -d urmat de directorul de date cluster. Toate fișierele legate de cluster se află în acest director.
- Ștergeți tot conținutul acestui director.
— Porniți serviciul 1C:Enterprise 8.1 Server Agent.
- Asigurați-vă în Task Manager că toate procesele ragent, rmngr, rphost au început.
— Lansați consola cluster și înregistrați serverul central în ea. Consola ar trebui să se conecteze la serverul central și să arate un cluster creat implicit.
Posibilele probleme legate de eșecul Clusterului de servere includ probleme cu cheile de securitate, drepturile contului de serviciu și parametrii de pornire incorecți.

1. Cheia de protecție a serverului este instalată LOCAL pe fiecare server din întreprindere
2. Nu setați un cont de serviciu cu o parolă goală
3. Cu mai multe clustere, porturile utilizate nu trebuie să se suprapună

Vă rugăm să rețineți că în timpul procesului de instalare a platformei 1C:Enterprise 8.1, pot fi afișate mesaje de eroare. Cele mai probabile mesaje sunt enumerate mai jos. Sunt indicate motivele care au determinat mesajele și pașii pentru eliminarea acestora.

Eroare 1069: serviciul nu rulează din cauza unei erori de conectare

Problema este legată de drepturile contului de a rula ca serviciu de sistem. Deschideți utilitarul Local Security Policy și adăugați utilizatorul (în numele căruia sunt lansate serverele de lucru în cluster) la Politicile Logon as service și Logon as batch job.
Dacă datele stocate în fișierele de serviciu sunt deteriorate, pornirea serverelor de producție ale clusterului poate eșua. Asigurați-vă că agentul serverului 1C:Enterprise 8.1 rulează (procesul ragent în Task Manager).
Nu uitați că Windows Event Auditing este, de asemenea, un instrument de analiză. Pentru a face acest lucru, căutați să vedeți dacă în jurnalul de evenimente Windows apar mesaje „suspecte”.

Eroare 8007056B / 800708C5

Noua parolă nu respectă politicile privind parola. Parola poate fi prea scurtă sau ați folosit deja această parolă recent.
Motiv: parola specificată pentru cont în caseta de dialog „Instalare 1C: Server Enterprise” nu îndeplinește cerințele politicii de securitate.
Soluție: Setați o nouă parolă pentru contul selectat care îndeplinește cerințele politicii de securitate sau slăbiți cerințele politicii de securitate aplicate, de exemplu. nu necesită o parolă „complexă”, nu limitați numărul de caractere din parolă, nu verificați încercările de repetare etc.

Eroare 1923: Nu există privilegii de instalat prin serviciu

Cauză: eroarea este legată de drepturile de instalare ale contului ca aplicații. Această eroare este tipică pentru încercările de a instala un server pe un controler de domeniu unde sunt necesare măsuri de securitate sporite.
Soluție: Nu utilizați un controler de domeniu pentru a găzdui serverul de întreprindere sau relaxați cerințele de securitate și specificați drepturile „Run as a service” sau „Run as a batch job” pentru contul selectat.

Eroare 80070056

Parola dvs. nu a putut fi schimbată. Fiecare parolă trebuie utilizată cel puțin x zile.
Cauză și soluție: O altă eroare care apare atunci când cerințele politicii de securitate pentru parolele utilizate sunt încălcate. Soluția este similară cu eroarea 800708C5.

Windows Sockets - 11004(0x00002AFC)

1) Asigurați-vă că pe serverul de lucru al clusterului din Managerul de activități rulează următoarele:
Agent server (ragent.exe),
Manager cluster (rmngr.exe),
Procesul de lucru în cluster (rphost.exe).
2) Pentru a verifica rezoluția numelui adresei IP, rulați pe linia de comandă:
ping nume mașină
În răspunsul sistemului la comandă, suntem interesați să stabilim dacă adresa IP este determinată.
3) Dacă numele este determinat, dar Procesul de lucru nu este încă găsit, atunci asigurați-vă că adresa IP a numelui este determinată<имя машины>Și<имя машины>.<имя домена>nu sunt definite diferit.

(Windows Sockets - 10054(0x00002746).

Gazda de la distanță a închis forțat conexiunea.
Acest mesaj poate fi primit dacă serverul este repornit sau dacă procesul de lucru este forțat să fie șters.
Această eroare nu apare de obicei la reconectare. Dacă eroarea persistă, este necesar să se investigheze motivele eșecului serverelor de producție ale clusterului.
Această eroare poate apărea atunci când un proces de lucru atinge capacitatea maximă de memorie pe sistemele pe 32 de biți.
Un alt caz este o încercare de conectare de la un client cu un mesaj de eroare:

(Socket Windows - 10060(0x0000274C)

O încercare de a stabili o conexiune nu a reușit deoarece... răspunsul necesar nu a fost primit de la alt computer în timpul necesar sau o conexiune deja stabilită a fost întreruptă din cauza unui răspuns incorect de la computerul deja conectat.
Esența acestei erori este lipsa de răspuns într-un anumit timp (timeout).
1) Asigurați-vă că firewall-ul dvs. nu blochează traficul aplicațiilor. Opriți firewall-ul.
Pentru a face acest lucru, executați comanda în linia de comandă (comanda este disponibilă începând de la Windows XP și Windows Server 2003; versiunile anterioare nu au un firewall încorporat, dar se poate instala software de la terți):
netshfirewalla stabilitopmodedezactivați
Dacă comanda are succes, veți primi un mesaj:
BINE.
Pe lângă un firewall, filtrele de rețea pot bloca traficul. Sunt dezactivate implicit. Cu toate acestea, asigurați-vă că este așa:

1. Deschideți folderul Network Connections.
2. Faceți clic dreapta pe conexiunea de rețea pe care doriți să o configurați și selectați Proprietăți.
3. Pe fila Sunt comune(pentru conectarea prin rețea locală) sau pe filă Net(pentru toate celelalte conexiuni) selectați Protocol Internet (TCP/IP)și apăsați butonul Proprietăți.
4. Faceți clic pe butonul În plus.
5. Deschide fila Opțiuni, selecteaza o optiune Filtrare TCP/IPși apăsați butonul Proprietăți.
6. Asigurați-vă că caseta de selectare Activați filtrarea TCP/IP (toate adaptoarele)îndepărtat.

2) Asigurați-vă că resursele procesorului nu sunt încărcate 100% (CPU%).
3) Măsurați activitatea de rețea a interfețelor client și server. Sarcina adaptorului de rețea nu trebuie să depășească 60%.

(Windows Sockets - 10061(0x0000274D)

Conexiunea nu a fost stabilită deoarece Computerul de destinație a respins cererea de conectare.
Un motiv tipic pentru această eroare este absența unui Server Agent care rulează. Porniți serverul manual sau reporniți serverul pentru a porni automat.

Răspunsuri la întrebări

Multiplatformă 1C

Instalare server

Î: Eroare la instalarea serverului 1c pe MS Server 2008 R2 x64 Când instalați serverul 1c prin linia de comandă, de exemplu, ragent.exe -instsrvc -port 2040 -regport 2041 -range 2060:2091 -d „C:\Program Files\1cv82 \ (luat de pe discul ITS), linia de comandă scrie mesajul: „Eroare! Eroare OpenSCManager!” Serviciul nu este creat în acest caz. Testat pe 8.1.15.14 și 8.2.10.77

R: Pentru a instala din linia de comandă pe un sistem de operare în care este prezent UAC, trebuie să utilizați serviciul RunAs, deoarece Chiar dacă utilizatorul este membru al grupului Administratori, UAC blochează acțiunile care schimbă starea sistemului.

Chei de protecție

Î: Cheia de protecție pentru Server 8.2 îmi permite să rulez Server 8.1?
A: Da, da

Î: Pentru a porni un server 1C, am nevoie de un fel de chei hap de server? Local, sau nu va funcționa pentru 5 utilizatori?

R: da, serverul are nevoie de propria sa cheie, utilizatorul local și cheile de rețea nu vor funcționa. Mai multe detalii în « « , slide numărul 30.

Î: Să presupunem că un cluster de servere 1C este format din 3 servere fizice. de câte chei de securitate sunt necesare?

Î: Există un server terminal și o cheie pentru 5 licențe, trebuie achiziționată o a șasea licență suplimentară. licență. Se poate instala pe server langa cheie la 5? Și toți cei 6 utilizatori vor lucra în sesiuni de terminal sau 5 - sub terminal și 1 în versiunea fișierului?
A: Nu, nu vor. A șasea licență sub forma unei chei locale trebuie să fie conectată la computerul utilizatorului, dar nu la terminal.

Actualizări de server 1C

Î: Când este lansată o nouă versiune 8.2.xxx a platformei, care este procedura de actualizare a serverelor și clienților?
R: Distribuțiile 8.2 își instalează fișierele în foldere diferite (fiecare versiune are propriul folder), adică. teoretic, rămâne posibilă apelarea mai multor versiuni ale serverului în paralel.

Nu am avut probleme. Cu toate acestea, trebuie să monitorizați cu atenție porturile ocupate de instanța serverului 1C. Nu ar trebui să existe intersecții.

Configurarea serverului 1C

Î: În 1C 8.1, care este cel mai bun mod de a plasa baze de informații, dacă există mai multe dintre ele, într-un singur cluster sau de a crea un cluster separat pentru fiecare bază de date? R: Cu un volum sau o sarcină mare, bazele de date de testare trebuie plasate în grupuri separate!

Î: ÎNTREBARE: Este fluxul de lucru 1C:Enterprise 8.1 o aplicație cu un singur thread sau una cu mai multe fire? Acestea. pot fi încărcate multe nuclee cu un utilizator conectat? Cu mai multe? Dar fluxul de lucru 1C:Enterprise 8.2? Mulțumesc.
R: 1Сv8.exe și rphost.exe în versiunea 8.1 au consumat 1 nucleu. Deoarece în 8.1 conexiunea client este strict legată de procesul de lucru, putem presupune condiționat că procesarea clientului 1C este efectuată într-un singur nucleu. Excepție este DBMS, care utilizează nuclee indiferent de modul în care funcționează serverul 1C.

În versiunea 8.2, conexiunile sunt înlocuite cu sesiuni. Este posibil ca sesiunile să ruleze deja în diferite procese de lucru. Prin urmare, apelarea 8.2 single-threaded nu este probabil corectă. Clientul 8.2 încarcă vizual mai multe nuclee, deci acesta:

Platforma 8.2 nu implementează toate capabilitățile unui sistem multi-threaded, dar folosește mult mai bine capabilitățile hardware în comparație cu 8.1, inclusiv în ceea ce privește paralelismul.

Î: Este necesar să aveți mai multe procese de lucru 1C:Enterprise 8.1 pentru serverul de baze de date (MS SQL) pentru a încărca mai multe nuclee? (Se remarcă faptul că MS SQL „încarcă” de obicei un singur nucleu, adică „paralelizarea” procesării unei cereri pe mai multe nuclee, de regulă, nu are loc.) Vă mulțumim.
R: Nu este nevoie să gestionați în mod specific MS SQL, este un sistem destul de auto-ajustat care utilizează resursele după cum este necesar. Puteți controla paralelismul de execuție:

EXEC sys.sp_configure N’max grad de paralelism’, N’5′
MERGE
RECONFIGURAȚI CU OVERRIDE
MERGE

Puteți crea mai multe procese de lucru pe serverul 1C pe baza faptului că un proces de lucru nu oferă utilizatorilor posibilitatea de a se reconecta în cazul în care procesul de lucru se blochează. Procesul 2 (pe 8.2 este mai bine să-l faci „backup”) rezolvă această problemă. Dar este logic să adăugați o treime sau mai multe procese de lucru numai dacă primele două procese de lucru sunt încărcate puternic (mai mult de 90%). Nu are rost să multiplici procesele de lucru în mod inutil, acest lucru poate înrăutăți productivitatea.

R: Trebuie să existe cel puțin 1 proces de lucru de rezervă în 8.2.

Cluster de failover

Î: Întrebare despre activarea redundanței pentru clusterele 1s 8.2. Dacă serverul nostru s-a prăbușit (doamna de curățenie a scos firul), atunci numele rețelei, de exemplu „server:2540” va fi indisponibil. Cum știe un client al cărui șir de conexiune spune „server:2540” că trebuie să se conecteze la clusterul de rezervă? de unde va primi numele celuilalt server? Ce se întâmplă dacă scrieți clustere separate prin virgule în șirul de conexiune la baza de date?
R: Mai multe clustere sunt combinate într-un „grup de redundanță”. În acest scop, există o „listă de rezervări” în snap-in-ul cluster.

Când un client accesează pentru prima dată un cluster, i se oferă o listă de clustere incluse în grupul de redundanță.

Dacă clientul nu v-a contactat niciodată, atunci în acest caz trebuie să specificați manual adresele tuturor clusterelor, de exemplu storm:2541,monster:2541.

Datele sincronizate sunt schimbate între clustere de redundanță.

Î: Ce se întâmplă după ce clusterul principal este restaurat? când utilizatorii au trecut la backup.

A: Se întorc. Pot exista pauze la comutare în timpul sincronizării acestor clustere.

Lucrări de fundal

Î: Cum să ștergeți un job de fundal care rulează pe serverele 1C:8.1 și 1C:8.2?

R: Capacitatea de a anula o sarcină de rutină funcționează numai dacă codul este executat în limbajul încorporat 1C:Enterprise. Dacă codul este executat în biblioteci externe, atunci o astfel de sarcină nu poate fi anulată decât prin oprirea forțată a fluxului de lucru. Dacă în acest proces există un bloc StartTransaction() - CommitTransaction(), atunci este puțin probabil. Alte lucrări de fundal pot fi șterse prin consola de joburi.

Proceduri de reglementare

Î: Este posibil să distrugi baza în timpul T&I?

R: Nu sunt la curent cu astfel de cazuri, dar din punctul meu de vedere, orice este posibil. Prin urmare, ar fi o idee bună să faceți o copie de rezervă înainte de T&I.

Î: Vyacheslav, din ce motive nu efectuați reindexarea folosind 1C Testing and Correction?
R: Capacitățile DBMS sunt mai potrivite pentru aceste scopuri, deoarece în esență reconstruiesc și indecși, dar nu necesită confiscarea exclusivă a bazei de date.

Revista de tehnologie

Î: Bună ziua. Întrebare de la o revistă de tehnologie: Trebuie să primesc copii ale ecranelor stației de lucru în cazul erorilor 1C. Trebuie să configurez un jurnal tehnologic pe stațiile de lucru pentru asta sau este doar pentru server?
R: Puteți configura primirea unei capturi de ecran numai atunci când platforma cade, și nu atunci când există vreo eroare. Cu toate acestea, nu există prea multă utilitate într-o astfel de operațiune, este suficient să colectați situații de excepție folosind un jurnal tehnologic. În același timp, majoritatea erorilor pot fi văzute folosind TZ pe partea serverului 1C. Excepția pot fi evenimente precum o „eroare de formatare a fluxului” asociată cu un cache de metadate învechit.

Probleme și erori

Î: Ați întâmpinat o problemă - dispariția setărilor de raport pentru utilizatori la actualizarea dinamică a configurațiilor pe platforma 8.2. Ceva recomandări despre cum să faceți acest lucru?
R: Problemele legate de actualizarea dinamică sunt reflectate în „Servere 1C: Enterprise 8.1 și 8.2 - cu ce să mănânci”), slide numărul 60. Goliți memoria cache. Poate că în unele cazuri este necesar să înțelegem unde sunt stocate exact setările utilizatorului. Dacă este necesar, stocați ca date binare în registrul de informații.

Î: O întrebare legată, pentru că... acest lucru este relevant pentru modul fișier: ce erori corectează chdbfl.exe?
R: Acesta este un instrument de corectare a erorilor structurii de stocare a datelor. Aceasta ar putea fi o situație în care, de exemplu, apare „Fișierul bazei de date este deteriorat.../1Cv8.1CD”. Acestea. remediază corupția fișierului bazei de date. Cu toate acestea, nu îndeplinește funcții T&I. Rulez chdbfl.exe dacă T&I nu rulează cu succes.

Î: Vă rog să-mi spuneți dacă ați întâmpinat o astfel de problemă. când există un număr mare de utilizatori în baza de date (aproximativ 40) la procesarea documentelor mari, de exemplu, reflectând PO în reg. Reprezentând aproximativ 8000 de linii. Mesajul de eroare este că nu există suficientă memorie pe serverul enterprise 1C și utilizatorul care a inițiat acest document cade. Documentul poate fi apoi procesat numai după repornirea agentului de server 1C.
R: Se pare că există scurgeri de memorie:

1. Reporniți serverul 1C, creșteți numărul de procese de lucru și păstrați numai această bază de date în cluster.

2. Bateți ținerea în porții, să zicem câte 1000 de rânduri o dată. Folosind TZ, urmăriți obiectele care ocupă memorie la începutul operațiunii, dar nu eliberați memoria la finalizare.

3. Instalați versiunea x64, creșteți cantitatea de RAM, treceți la 8.2.

Î: Întrebare despre testare și management. Este posibil să rulați o „Verificare a integrității referențiale” pe baza URDB cu selecție pe baza datelor transmise? (adică, în unele noduri nu există fizic obiecte, dar există legături către ele). Mulțumesc!
R: Din păcate, acest lucru nu este posibil încă.

Î: De ce testarea și remedierea nu rezolvă toate problemele simultan, trebuie să le rulați de mai multe ori?

R: Numai dezvoltatorii pot răspunde cu precizie. Eu conduc T&I conform reglementărilor (ciclic), așa că această problemă nu este foarte relevantă pentru mine. T&I trebuie făcute nu o singură dată, ci în mod constant, ca „MOT pentru o mașină”.

Î: Există o diferență între T&I 8.1 și 8.2?

R: În momentul scrierii răspunsului și lansării 8.2.10, nu cunosc diferența.

Î: Este necesară reindexarea în timpul restructurării?
A: Nu este nevoie.

Alte

Î: Stimati domni, a încercat cineva să oglindească bazele de date folosind MSSql 2008. Este chiar posibil?

Î: Întrebare despre forțarea memoriei partajate pe serverul 1s 8.2

R: Nu este nevoie să forțați nimic, serverul va înțelege.

Î: Pentru 1C:Enterprise 8.1 s-au observat situații când, pe același hardware, versiunea server de fișiere cu operațiuni „grele” și un singur utilizator funcționează mult mai rapid decât versiunea client-server, când toate „legăturile” (baza de date server, 1C server :Enterprise și client) sunt instalate pe același server. În plus, atunci când se efectuează această operațiune „grea”, nu există supraîncărcări hardware evidente (sarcina pe procesor, memorie și hard disk este minimă). Adică, există o mulțime de resurse hardware, dar funcționează lent. Cu ce ​​ne putem „odihni”? Mulțumesc.
R: Avantajul arhitecturii client-server din punct de vedere al performanței este capacitatea de a procesa cererile clienților de date în PARALEL. Acestea. Viteza de curgere nu este un indicator asupra căruia să se tragă concluzii generale. Mecanismele care îmbunătățesc concurența pot reduce încă puțin performanța într-un singur fir.

Pentru a găsi fără ambiguitate blocajul în cazul dvs., trebuie să obțineți volumul de lucru al echipamentului server și să o comparați în timp cu cele mai lungi operațiuni în modul client-server. Adesea, aceasta este o mișcare excesivă a datelor către partea clientului. Acestea. În loc să se efectueze operațiuni pe serverul 1C, datele din baza de date sunt transferate prin server către client.

Viteza dintr-un fir al versiunii client-server va atinge doar performanța versiunii de fișier. Merită abordată această problemă dacă timpul de funcționare în numere absolute este măsurat în nu mai puțin de minute. Optimizarea interogărilor în 1-3 secunde este îndoielnică.

Î: Despre diferența dintre terminalul Windows și clientul subțire 1C.
R: Până când majoritatea soluțiilor sunt traduse COMPLET în 8.2, este cu siguranță dificil să vorbim despre o comparație practică a acestor tehnologii.

Este clar că clientul subțire 1C ar trebui să consume mai puțin trafic și să ofere posibilitatea de a lucra prin web. Dar acesta este ceva care nu a fost încă implementat, iar soluțiile terminale sunt utilizate pe scară largă acum.

Pentru managerii de proiect conservatori și pragmatici care convertesc 8.1 în 8.2 - o soluție terminală. Pentru proiectele mici cu un cost redus de erori și o configurație imediat implementată cu formulare gestionate și sisteme de control al accesului, un client subțire este de preferat IMHO.

Î: Cum se efectuează testarea de sarcină aproape de condițiile reale? La urma urmei, nu poți forța utilizatorii să „face clic pe ceva”.

A: 1C: Centru de testare cu o selecție a celor mai dificile operațiuni, reproducerea 100% nu este necesară, clicurile în sine nu sunt dificile, în principal efectuând și solicitând rapoarte. Va exista un webinar separat despre testare. Vă voi spune și mai detaliat.

Î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, 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 (calculele 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 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țele 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 lucrări 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.