O greșeală destul de comună când se operează 1C 8.2 în modul client-server este că gazda la distanță s-a rupt forțat conexiunea existentă. De regulă, se aplică administratorii clienților din sectorul corporativ, i.e. unde sunt operate 20 sau mai multe locuri de muncă.

În 98% din cazuri, această eroare se datorează repornirii fluxului de lucru. Pot exista mai multe motive pentru care repornește, dar cel mai frecvent este o repornire programată banală. Datorită creșterii fișierelor fluxului de lucru rphostși încetinirea bruscă ulterioară a activității după această creștere, administratorii încearcă să rezolve problema repornind procesele de lucru și se confruntă imediat cu alta - deconectarea utilizatorilor care lucrează. Crearea unui flux de lucru suplimentar nu face nimic. contrar documentației oficiale de trecere a unui client gros la un alt proces de lucru nu se intampla. Mai mult, există sarcina crescuta pe procesor - este necesar să se ocupe de comutarea contextului. Apropo, 1C însuși recomandă un flux de lucru pentru 50-100 de utilizatori.

1) pentru a elibera memoria ocupată de fluxul de lucru 1C, utilizați repornirea automată a fluxurilor de lucru. Se recomandă repornirea proceselor de lucru o dată pe zi (la fiecare 86400 de secunde). În același timp, fluxul de lucru este mai întâi oprit (conexiunile noi la acesta sunt imposibile, cele vechi continuă să funcționeze) și se lansează una nouă. Apoi, când toate conexiunile la vechiul proces sunt închise, procesul se încheie. În același timp, fiți atenți că numărătoarea inversă a acelorași 86400 începe din momentul începerii serviciului Agent server 1C Enterprise. Acestea. este de dorit să o porniți noaptea.

2) nu utilizați mai mult de un proces de lucru dacă aveți până la 100 de utilizatori. La Mai mult procesele de lucru petrec timpul CPU schimbând contextele între ele.

3) ștergeți memoria folosită. Creșterea rapidă a memoriei ocupate de procesul rphost este cel mai adesea cauzată de configurația scrisă neglijent, de multe ori programatorii nu se deranjează să curețe memoria ocupată, mai ales sub tabele de valori, enumerari și matrice. Acest lucru este evident mai ales când se întâmplă în locuri de muncă de fundal. Prin urmare, atunci când analizați problema scurgerilor de memorie, este necesar să începeți cu acestea, de exemplu, prin dezactivarea lor în proprietăți baza de informatii de ceva timp.

4) utilizarea servere separate pentru SQL și 1C. După cum știți, nu există niciodată prea multă memorie pentru SQL.

Ar trebui să acordați atenție cazurilor notate ale erorii „Gazda la distanță a închis forțat conexiunea” din cauza reciclare ridicată echipamente de retea . Când timpul de răspuns al serverului crește la 150-300 ms sau mai mult, conexiunea este deconectată de timeout. De exemplu, acest lucru s-a întâmplat când mai mulți utilizatori încarcă simultan routerul, la care este conectat și serverul 1C, prin copierea fișierelor dimensiuni mari. Administratorii ar trebui să ia în considerare posibilitatea acestei situații și să acorde atenție vitezei fabricii de comutare atunci când cumpără routere.

În concluzie, voi adăuga că instalarea și configurarea unui server este o chestiune responsabilă, care necesită cunoștințe și experiență, este mai bine să-l încredințezi unor profesioniști. Specialistii nostri efectueaza o instalare la cheie a serverului, vezi sectiunea pentru mai multe detalii.

Această eroare cu cod 10054, de natură critică, se manifestă la utilizatori în momentul înregistrării. Cel mai adesea găsit în versiunile mai vechi ale 1C 8.2.

Captură de ecran a erorii 10054:

În general, apariția acestei erori indică faptul că are loc o acțiune neașteptată pentru dezvoltatorul serverului 1C:

• sosește o cerere nevalidă;
• date incorecte;
• o interogare care necesită o selecție mare pe care nu o poate îndeplini;
• caz special: numărul documentului a fost mai mare decât lungimea specificată la numărător;
• verificați funcționarea cu antivirusuri sau firewall-uri dezactivate

Corecţie:

Constă în localizarea pe cât posibil a problemei:

• stabilirea tipului de document,
• registrul cu care apare eroarea,
• utilizator,
• calculator.

Apoi se face o copie a bazei de date (prin 1C sau DBMS).

Dacă repornirea serverului rezolvă problema, continuați monitorizarea. Adăugați un script de repornire a serviciului pe timp de noapte la timpul de lucru.

Dacă repornirea este ciclică, verificați dacă aveți repornirea automată configurată în proprietățile clusterului:

Se efectuează testarea și corectarea cu recalcularea totalurilor și reindexarea tabelelor.

Se ridică copia anterioară a bazei de date în care se observă problema, se verifică diferențele, poate că acest lucru va duce la cauza.

Dacă problema nu poate fi rezolvată, urmatorul pas va avea loc setarea si analiza jurnalului tehnologic.

Ce se poate găsi în proces:

Dacă încărcarea pe server este în pragul 100%, luați în considerare separarea serverului de baze de date și serverului 1C, acest lucru încetinește de obicei, dar stabilizează munca (în 8.3 există un mecanism memorie partajată, care accelerează comunicarea cu serverul și).

• Adăugați memorie la server dacă este posibil.
• O posibilă soluție ar fi înlocuirea serverului cu unul pe 64 de biți, dar mai întâi verificați performanța prietenilor dvs., unde se află.
• Aceeași verificare pe 32 de biți nu va strica să înțelegeți eroarea de date sau de un anumit server.
• Descărcarea cu încărcare poate elimina manifestarea.
• Ca ultimă soluție, luați în considerare transferul de date prin conversie de date sau încărcarea datelor în copie de lucru(procedura lunga)

Verificați jurnalele Windows pentru erori de sistem:

• în funcționarea în rețea
• echipamente
• aplicatii
• reporniți routerele, comutatoarele (rar, dar există probleme în ele)

Dacă problema nu este rezolvată în un timp scurt, este posibil să aveți nevoie de ajutorul administratorilor certificați sau al experților 1C.

Descrierea erorii

adresa_server=tcp://<имясервера>:1562 descr=Eroare de acces la rețea la server (Windows Sockets - 10054(0x00002746). Gazda la distanță a întrerupt forțat conexiunea existentă.) line=1031 file=.\src\DataExchangeTcpClientImpl.cpp

Cum să faci față acestei probleme

Configurați jurnalul tehnologic și analizați jurnalele acestuia.
Cel mai cauze comune există blocări ale părții server din 1C: Enterprise.
De asemenea, puteți verifica dacă se creează imagini (uitați-vă la calea logcfg.xml, dacă nu există nicio setare de descărcare în ea, apoi în directorul %USERPROFILE%\Local Settings\Application Data\1C\1Cv81\Dumps, de exemplu C :\ Documente și setări\<Имя пользователя>\Local Settings\Application Data\1C\1Cv81\dumps. Blocările platformei pot apărea cel mai adesea din cauza solicitărilor cu parametri nestandard. Trimiteți documente către e-mailul de asistență tehnică 1C: [email protected]
1. Cel mai adesea am întâmpinat o problemă în jurnalul de documente în cererile de selecție au fost similare cu aceasta:

SELECTAȚI TOP 35 PERMISI R.Data_Ora A1,
R.Numărul A2,
R.Fld9608A3,
R.Fld9613 A4,
R.Fld9606A5,
R.Fld9610 A6,
R.Fld9611A7,
R.Fld9607 A8,
R.Fld9612 A9,
R.Fld9615 A10,
R.Fld9614 A11,
R.Fld9609A12,
R.Fld9605 A13,
R.Documentul A14,
R. marcat A15,
R.Posted A16,CAST(R.Fld9608 AS REF(Reference9)).Descriere
A17,CAST(R.Fld9606 AS REF(Reference52)).Descriere A18,CAST(R.Fld9611
AS REF(Reference93)).Descriere A19, CASE WHEN R.Fld9609 REFS
Reference53 THEN CAST(R.Fld9609 AS REF(Reference53)).Descriere WHEN
R.Fld9609 REFS Reference150 THEN CAST(R.Fld9609 AS
REF(Reference150)).Descriere WHEN R.Fld9609 REFS Reference63 THEN
CAST(R.Fld9609 AS REF(Reference63)).Descriere WHEN R.Fld9609 REFS
Reference114 THEN CAST(R.Fld9609 AS REF(Reference114)).Descriere END
A20,CAST(R.Fld9605 AS REF(Reference79)).Descriere A21
DIN DocumentJournal9604 R UNDE
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) ȘI
(R.Date_Time > DATETIME(2006,12,31,12,0,0) SAU (R.Date_Time =
DATETIME(2006,12,31,12,0,0) ȘI (R.Document >=
343:b654000bcd6ad80811dba49c7aabe269)))
COMANDĂ DE A1 ASC, A14 ASC’

2. Un exemplu de jurnal TJ care arată cauza blocării serverului la actualizarea căutării full-text
11:40.9690-0,EXCP,1,process=rphost,p:processName=<база данных>,t:clientID=3, t:applicationName=BackgroundJob,t:connectID=27,Usr=DefUser,DumpFile=C:\Program Files (x86)\1cv81\dumps\rphost_8.1.13.41_7d4e2366_200209036_200201606_m.
GeneralModule.RegularAssignmentModule: 46: FullTextSearch.UpdateIndex(False, True);'

Soluția finală din acest exemplu ar fi dezactivarea procesului de fundal în baza de probleme. Așteptați o nouă lansare a platformei și actualizați.
Pentru mai multe detalii despre blocările platformei, consultați blogul meu.
3. Exemplu de TJ pentru repornirea ciclică a proceselor. Pentru a analiza acest eveniment pe computerul serverului 1C:Enterprise, trebuie să activați înregistrarea în jurnalul de evenimente PROC al procesului (exemplu al fișierului logcfg.xml).
Când un proces se închide, va fi emis un eveniment PROC cu proprietatea Txt=Process devenit dezactivată.
Când un proces este terminat, va fi emis un eveniment PROC cu proprietatea Txt=Proces terminat. Orice client a terminat cu o eroare. Dacă blocările utilizatorilor coincid cu rezultatul acestui eveniment, atunci cauza este oprire forțată proces de lucru fie de către un administrator (prin consola clusterului), fie din cauza unei reporniri automate.
4. Asigurați-vă că cauza este/nu sunt acțiunile administratorului în consolă

—————————-

Mai jos este soluția unui coleg.

Toata lumea interesatîn rezolvarea problemelor cu blocările platformei cu erori:

10051, 10053, 10054, 10064

După cum arată debriefing-ul pe platformă cade, de sus erorile indicate:

- Majoritatea căderilor sunt cauzate de muncă locuri de muncă de fundal, așa cum era de așteptat în subiect.

- lipsa de prindere spatiu pe disc

— Prezența un numar mare tranzacții incomplete în jurnalul 1C

- Înainte de a analiza cu jurnalul tehnologic, analizează joburile de fundal folosite în configurație și dezactivează-le pe cele care nu sunt necesare pentru ca tu să lucrezi, configurația (e banal, analiza a 14 GB de gunoi poate fi considerată o distracție dacă nu ai ce face ... :))))

— Analizați și faceți corecții la sarcinile de fundal pe care le-ați adăugat, asigurați-vă că acestea se completează cu un cod de ieșire normal (fără erori și fără tranzacții închise)

- Introduceți fragmente de cod în algoritmii joburilor de fundal care protejează, cu forţa, memoria folosită în timpul activității lor (Nu trebuie să sperați că 1C eliberează memoria folosită la sfârșit)

— Analizați și REPARAȚI PROBLEME DE FUNCȚIONARE în joburile tipice de configurare în fundal

- Efectuați proceduri de rutină cu baza de date, prin elementul de meniu Administrare-Testare și corectare, nu uitați neapărat, comprimați baza de date

- Analizați cantitatea de spațiu folosită de serverul SQL, este probabil ca serverul pur și simplu să nu aibă suficientă memorie

- Verificați setările politicii Director activ

- Și, de asemenea, comprimați/ștergeți jurnalul de tranzacții SQL astfel (pentru SQL 2000):

Opțiunea 1:DBCC SHRINKFILE(pubs_log, 2)
(În cazul în care un marimea corecta nu a fost atins încercați opțiunea 2) Opțiunea 2:JURNAL DE BACKUP pub-uri CU TRUNCATE_ONLY
DBCC SHRINKFILE(pubs_log,2)

Unde pub_log este numele bazei de date

Opțiunea 3:
sp_detach_db - deconectați baza cu această procedură și sp_attach_db - conectați din nou. Jurnalul de tranzacții va fi șters.
(Consultați MSDN Q256650 (pentru SQL 7.0) și Q272318 (pentru SQL 2000) pentru mai multe detalii.)

Opțiunea 4: (Pentru 7.0)
DBCC SHRINKFILE (nume_fișier, dimensiune_țintă)
DBCC SHRINKDATABASE(nume_bază de date, procent_țintă)
Jurnalul de backup numele bazei de date CU TRUNCATE_DOAR

Dacă după aceste operații căderile continuă, atunci continuați să urmați recomandările:

- Încercați să faceți modificări Fișiere HOST sistem de operare(cel mai probabil va fi suficient să înregistrați asocierea doar în fișiere de pe una/două mașini, unde se produc cel mai des blocaje)

- Încercați să separați serverele 1C enterprise și SQL dacă le aveți pe aceeași mașină.

- Sau invers, instalați-le pe aceeași mașină (dacă sunt suficiente resurse) Sunt cazuri când a ajutat transferul de servere pe un singur server (După părerea mea, este foarte îndoielnic și mai precis legat de motivul începe lucrul, aceasta este compresia jurnalelor de tranzacții)

- Verificați timpul de răspuns al serverului (cel mai probabil că totul va fi în intervalul normal, iar scăderile rare ale timpului de serviciu nu pot afecta atât de mult funcționarea serverului companiei)

- Verificați funcționarea routerelor în rețea (Rareori, dar se întâmplă ca reconfigurarea lor să afecteze numărul de picături)

- Verificați conflictele echipamente în rețea (aceasta este întrebarea de ce este de dorit să aveți echipamente de la același furnizor în rețea. Cine dorește poate verifica, de exemplu, în documentația tehnică 3COM scrie: dacă placa de rețea detectează că interacționează cu un similar card de retea, apoi poate fi comutat la un mod mai productiv prin trecerea la un algoritm de procesare optimizat pachete de rețea, verificat pentru experienta personala salt de performanță până la 50%)

- Verificați nivelurile semnalului la consumatori / computere finale (poate banal, nivel scăzut semnale, permanente cereri repetate blocuri, întârzierea cozii de serviciu de rețea și, prin urmare, în cele din urmă primirea unui mesaj că serverul de destinație a întrerupt conexiunea atunci când numărul de încercări depășește timpul de așteptare a semnalului. Daca vrei sa intelegi această problemă consultați protocolul de operare Ethernet/CSMA CD/CSMA. Numărul de încercări de a trimite un pachet acest protocol nu este infinit ...))) Și tamponul din carduri nu este, de asemenea, nelimitat.)

- Adăugați memorie la servere

- Mutați unii/toți utilizatorii în modul terminal (adică, furnizați ceea ce MULTI utilizatori definesc ca fiind THIN CLIENT 1C). Ca un astfel de server, aș recomanda Citrix Metaframe sau Terminal Server MS

Cel mai probabil, atunci când urmați aceste recomandări, cu excepția analizei problemelor cu hardware-ul, stabilitatea muncii va crește atât de mult încât blocările platformei vor deveni foarte rare, ceea ce va bloca golurile tehnologice în întreținerea bazei de date, care sunt încă NECESARE și nu gandeste-te ca acele recomandari care sunt indicate mai sus Panacea pentru toate problemele.

Vor rezolva multe, dar nu toate problemele.

Și ești fericit, dacă nu ai astfel de probleme, oricine le are mă va înțelege.

———————————

Investigați rolurile „Utilizator”, dacă există. configurație tipică desigur, și în special, după calcul problemă document folosind , trebuie să găsiți rolul problematic (cine se plânge).
În continuare, pentru rolul Utilizatorului, ne uităm la radarul documentului, dacă setari avansate nu (pur) atunci Click dreapta pe el - căutați legături către obiect și căutați secvențial prin radar rolul „Utilizator” pentru fiecare obiect.

Confundarea intensității ridicate a utilizatorului ca un atac de protocol în unele cazuri Windows.
> Rulați regedit.exe, adăugați o nouă valoare tastați DWORD numit SynAttackProtect la cheia de registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ și setați-o la 00000000
Este logic să faci pentru Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx

Server 1C și bază de date pe aceeași mașină care rulează Debian Squeeze.

Soluție: Setați parametrul kernelului tcp_syncookies la 0.

[email protected]:~# echo "net.ipv4.tcp_syncookies = 0" >> /etc/sysctl.conf && sysctl -p
(autor Vadim Ivakhin)