Gazda la distanță a încheiat conexiunea 1c existentă. Gazda la distanță a încheiat forțat o conexiune existentă

Acest cod de eroare 10054, unul critic, apare utilizatorilor î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 incorectă;
date incorecte;
o interogare care apelează un eșantion mare pe care nu îl 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 problemei pe cât posibil:

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

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

Dacă repornirea serverului rezolvă problema, continuați monitorizarea. Adăugați un script de repornire a serviciului noaptea în timpul orelor de lucru.

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

Testarea și corectarea se efectuează cu recalcularea rezultatelor și reindexarea tabelelor.

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

Dacă problema nu poate fi rezolvată, următorul pas este configurarea și analizarea jurnalului de proces.

Ce poate deveni clar în timpul procesului:

Dacă încărcarea pe server este în pragul 100%, luați în considerare opțiunea de a separa serverul de baze de date și serverul 1C, aceasta de obicei încetinește, dar stabilizează munca (în 8.3 există un mecanism de memorie partajată care accelerează interacțiunea dintre 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 funcționalitatea prietenilor dvs. unde este instalat.
Nu ar strica să faceți aceeași verificare pe 32 de biți pentru a înțelege eroarea din date sau pe un anumit server.
Descărcarea și încărcarea pot elimina manifestarea.
Ca ultimă soluție, luați în considerare transferul de date prin conversie de date sau adăugarea de date la o copie de lucru (o procedură îndelungată)

Verificați jurnalele Windows pentru erori de sistem:

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

Dacă problema nu este rezolvată într-un timp scurt, este posibil să aveți nevoie de ajutorul unor administratori autorizați sau experți 1C.

O eroare destul de comună când se folosește 1C 8.2 în modul client-server este că gazda la distanță a oprit 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 este asociată cu repornirea fluxului de lucru. Pot exista mai multe motive pentru care repornește, dar cel mai frecvent este o repornire banală conform unui program. Datorită creșterii fișierelor fluxului de lucru rphostși încetinirea bruscă ulterioară a activității care urmează acestei creșteri, administratorii încearcă să rezolve problema repornind procesele de lucru și se confruntă imediat cu o altă problemă - deconectarea utilizatorilor care lucrează. Crearea unui flux de lucru suplimentar nu oferă nimic deoarece... contrar documentației oficiale de trecere a clientului gros la un alt flux de lucru nu se intampla. Mai mult, există o sarcină crescută pe procesor - este necesar să se ocupe de schimbarea contextului. Apropo, 1C însuși recomandă un flux de lucru pentru 50-100 de utilizatori.

1) pentru a elibera memoria ocupată de procesul de lucru 1C, utilizați repornirea automată a proceselor de lucru. Se recomandă repornirea fluxurilor de lucru o dată pe zi (la fiecare 86400 de secunde). În acest caz, procesul de lucru este mai întâi oprit (conexiunile noi la acesta nu sunt posibile, 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, rețineți că numărătoarea inversă a acelorași 86400 începe din momentul începerii serviciului Agent server 1C Enterprise. Acestea. Este indicat 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. Cu mai multe procese de lucru, timpul CPU este pierdut la comutarea contextului între ele.

3) ștergeți memoria folosită. Creșterea rapidă a memoriei ocupate de procesul rphost se datorează cel mai adesea unei configurații scrise neglijent, programatorii nu se obosesc adesea să curețe memoria ocupată, mai ales sub tabele de valori, enumerari si tablouri. Acest lucru este mai ales pronunțat atunci când se întâmplă în sarcinile de fundal. Prin urmare, atunci când analizați problema scurgerilor de memorie, trebuie să începeți cu ele, de exemplu, dezactivându-le în proprietățile bazei de informații pentru 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 în care a apărut eroarea „Gazda la distanță a închis forțat conexiunea” din cauza reciclare ridicată a echipamentelor de rețea. Când timpul de răspuns al serverului crește la 150-300 ms sau mai mult, conexiunea este deconectată din cauza unui timeout. De exemplu, acest lucru s-a întâmplat când mai mulți utilizatori au încărcat simultan routerul la care era conectat serverul 1C prin copierea fișierelor mari. Administratorii ar trebui să țină cont de posibilitatea acestei situații și, atunci când achiziționează routere, să acorde atenție vitezei fabricii de comutare.

Î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 instaleaza serverul la cheie pentru mai multe detalii, vezi sectiunea.

Descrierea erorii

adresa_server=tcp://<имясервера>:1562 descr=Eroare de acces la rețea la server (Windows Sockets - 10054(0x00002746). Gazda la distanță a închis 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.
Cele mai frecvente motive sunt blocările părții server 1C:Enterprise.
Vă puteți asigura, de asemenea, căutând pentru a vedea dacă se creează depozite (uitați-vă la calea logcfg.xml, dacă setările de descărcare nu sunt acolo, atunci în directorul %USERPROFILE%\Local Settings\Application Data\1C\1Cv81\Dumps , de exemplu C:\ Documents and Settings\<Имя пользователя>\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 selecțiile de înregistrare a documentelor, interogările au fost similare cu aceasta:

SELECTAȚI TOP 35 PERMISI R.Data_Ora A1,
R.Numărul A2,
R.Fld9608 A3,
R.Fld9613 A4,
R.Fld9606 A5,
R.Fld9610 A6,
R.Fld9611 A7,
R.Fld9607 A8,
R.Fld9612 A9,
R.Fld9615 A10,
R.Fld9614 A11,
R.Fld9609 A12,
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) AND (R.Document >=
343:b654000bcd6ad80811dba49c7aabe269)))
COMANDĂ DE A1 ASC, A14 ASC’

2. Un exemplu de jurnal TJ care arată motivul blocării serverului la actualizarea unei căutări 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_90201606_9020903
GeneralModule.Module de sarcini obișnuite: 46: Full-TextSearch.UpdateIndex(False, True);”

Soluția finală din acest exemplu ar fi dezactivarea procesului de fundal în baza de date problematică. Așteptați lansarea noii platforme și actualizarea.
Pentru mai multe informații despre blocările platformei, consultați blogul meu.
3. Exemplu de TC pentru repornirea ciclică a proceselor. Pentru a analiza acest eveniment pe computerul serverului 1C:Enterprise, trebuie să activați o intrare în jurnalul de evenimente tehnologice PROC (exemplu fișier logcfg.xml).
Când un proces este oprit, va fi declanșat 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 eroare. Dacă blocările utilizatorilor coincid în timp cu rezultatul acestui eveniment, atunci cauza este o oprire forțată a fluxului de lucru fie de către administrator (prin consola cluster), fie din cauza unei reporniri automate.
4. Asigurați-vă că cauza este/nu este acțiunile administratorului în consolă

—————————-

Mai jos este o versiune a soluției unui coleg.

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

10051, 10053, 10054, 10064

După cum a arătat debriefing-ul blocărilor platformei, cu erorile de mai sus:

— Majoritatea accidentelor sunt cauzate de munca în fundal, așa cum era de așteptat în subiect.

- Lipsa spațiului pe disc

— Prezența unui număr mare de tranzacții nefinalizate în jurnalul 1C

— Înainte de a analiza jurnalul tehnologic, analizați joburile de fundal utilizate în configurare și dezactivați-le pe cele de care nu aveți nevoie pentru lucru sau configurare (este banal, analiza a 14 GB de gunoi poate fi considerată o distracție dacă nu aveți nimic mai bun de făcut.. . :))))

— Analizați și faceți corecții la lucrările de fundal pe care le-ați adăugat, asigurați-vă că acestea sunt completate cu un cod de finalizare normal (fără erori sau tranzacții închise)

— Adăugați fragmente de cod la algoritmii sarcinilor de fundal care defecționează cu forţa, memorie folosită în timpul funcționării lor (Nu ar trebui să sperați că 1C va separa memoria utilizată la finalizare)

— Analizați și CORECTAȚI PROBLEME DE PERFORMANȚĂ ale joburilor tipice de configurare de fundal

— Efectuați proceduri de reglementare cu baza de date, prin elementul de meniu Administrare-Testare și Corectare, nu uitați Neapărat, efectuați compresia bazei 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 politicile de configurare Active Directory

— Și, de asemenea, comprimați/ștergeți jurnalul de tranzacții SQL cu ceva ca acest cod (pentru SQL 2000):

Opțiunea 1:DBCC SHRINKFILE(pubs_log, 2)
(Dacă nu se atinge dimensiunea dorită, î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 - vom deconecta baza de date cu această procedură, iar sp_attach_db - o vom conecta din nou. Aceasta va șterge jurnalul de tranzacții.
(Pentru mai multe informații, consultați subiectele MSDN Q256650 (pentru SQL 7.0) și Q272318 (pentru SQL 2000).)

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ă căderile continuă după aceste operații, atunci continuați să urmați recomandările:

— Încercați să faceți modificări la fișierele HOSTS ale sistemului de operare (cel mai probabil va fi suficient să înregistrați asocierea doar în fișierele de pe una sau 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, dimpotrivă, instalați-le pe o singură mașină (dacă aveți suficiente resurse) Există cazuri în care mutarea serverelor pe un server a ajutat (După părerea mea, este foarte îndoielnic și mai legat de motivul începerii lucrării, acest lucru este compresia jurnalelor de tranzacții)

— Verificați timpul de răspuns al serverului (cel mai probabil, totul va fi în limitele normale, iar eșecurile rare în timpul de serviciu nu pot avea un impact atât de puternic asupra funcționării serverului întreprinderii)

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

— Verificați dacă există conflicte de echipamente în rețea (acesta este vorba de întrebarea de ce este indicat să aveți echipamente de la un singur furnizor în rețea. Oricine dorește poate verifica, de exemplu, în documentația tehnică 3COM scrie: dacă o rețea). cardul detectează că interacționează cu o placă de rețea similară, apoi poate fi trecut la un mod mai productiv, datorită trecerii la un algoritm optimizat pentru procesarea pachetelor de rețea, a fost verificată un salt de performanță de până la 50% din experiența personală)

- Verificați nivelurile de semnal ale consumatorilor/calculatoarelor finale (poate fi banale, niveluri scăzute ale semnalului, solicitări repetate constante pentru blocuri, întârziere în coada de așteptare pentru serviciul în rețea și, prin urmare, eventual primirea unui mesaj că serverul final a închis conexiunea atunci când numărul de încercări depășește timpul de expirare a semnalului de primire Dacă doriți să înțelegeți această problemă, consultați protocolul Ethernet/CSMA CD/CSMA Numărul de încercări de a transmite un pachet folosind acest protocol nu este infinit...))) Și Nici tamponul din carduri nu este nelimitat.)

— Adăugați memorie la servere

— Transferați unii/toți utilizatorii în modul terminal (adică furnizați ceea ce MULTI utilizatori definesc ca fiind CLIENT SUBȚIR 1C). Pentru 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 analizării 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 acoperi golurile tehnologice pentru întreținerea bazei de date, care TREBUIE încă să fie urmat și să nu credeți că recomandările enumerate mai sus Un panaceu 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.

———————————

Explorați rolurile „Utilizator”, dacă acestea există într-o configurație tipică, desigur, și în special, după ce calculați problemă document folosind , trebuie să găsiți rolul problematic (cine se plânge).
Apoi, pentru rolul de utilizator, uitați-vă la radarul documentului dacă nu există setări suplimentare (pur), apoi faceți clic dreapta pe el pentru a căuta link-uri către un obiect și uitați secvențial la radar pentru „Utilizator”; rol pentru fiecare obiect.

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

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

Soluție: setați parametrul nucleului tcp_syncookies la 0.

root@machine:~# echo "net.ipv4.tcp_syncookies = 0" >> /etc/sysctl.conf && sysctl -p
(autor Vadim Ivakhin)