Thinprint gazda la distanță a închis forțat conexiunea existentă. Gazda la distanță a încheiat forțat o conexiune existentă
Acest cod de eroare 10054, de natură 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ă se întâmplă ceva 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 pe timp de noapte timp 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 separarea serverului de baze de date de serverul 1C, acest lucru încetinește de obicei, dar stabilizează munca (în 8.3 există un mecanism memorie partajată, care accelerează interacțiunea 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 funcționalitatea prietenilor dvs. unde se află.
- 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 datelor 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.
Descrierea erorii
adresa_server=tcp://<имясервера>:1562 descr=Eroare de acces la rețea la server (Windows Sockets - 10054(0x00002746). Gazda la distanță a fost oprită 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 motive comune Există blocări ale părții server 1C:Enterprise.
De asemenea, vă puteți asigura că vedeți 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) ȘI (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 of Regular Tasks: 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 o eroare. Dacă blocările utilizatorilor coincid în timp cu ieșirea 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 prăbușirilor platformei, de sus erorile indicate:
— Majoritatea accidentelor sunt cauzate de munca în fundal, așa cum era de așteptat în subiect.
- Nu cu o strângere spatiu pe disc
— Disponibilitate un numar mare 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 joburilor de fundal care defectează, cu forţa, memoria utilizată în timpul funcționării lor (Nu trebuie să sperați că 1C va aloca 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 utilizată SQL Server, este probabil ca serverul pur și simplu să nu aibă suficientă memorie
— Verificați setările politicii dvs Director activ
— Ș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ă 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 - 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 Fișiere HOST sistem de operare(cel mai probabil va fi suficient să înregistrați asocierea doar în fișiere 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 de întreprindere)
— 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 legat de întrebarea de ce este recomandabil să aveți echipamente de la un furnizor în rețea. Oricine dorește poate verifica, de exemplu, în documentația tehnică 3COM scrie: dacă o placă de rețea detectează că interacționează cu o placă 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, testat pentru experienta personala salt de performanță până la 50%)
— Verificați nivelurile de semnal ale consumatorilor/calculatoarelor finale (poate fi banal, nivel scăzut semnale, solicitări repetate constante de blocare, întârziere în coada 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 așteptare pentru sosirea semnalului. Daca vrei sa intelegi această problemă consultați protocolul de operare Ethernet/CSMA CD/CSMA. Numărul de încercări de a transmite un pachet prin acest protocol nu este infinit...))) Și nici tamponul din carduri nu este infinit.)
— Adăugați memorie la servere
— Transferați unii/toți utilizatorii în modul terminal (adică furnizați ceea ce MULȚI utilizatori definesc ca fiind CLIENȚ 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 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 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.
———————————
Examinați rolurile „Utilizator” dacă există în configurație tipică desigur, și în special, după ce calculezi problemă document folosind , trebuie să găsiți rolul problematic (cine se plânge).
Apoi, pentru rolul Utilizator, uitați-vă la radarul documentului, dacă setari aditionale nu (pur), atunci Click dreapta pe el - căutați legături către un obiect și vizualizați secvențial radarul pentru rolul „Utilizator” 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)
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 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 comutarea 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. La Mai mult procesele de lucru petrec timpul CPU schimbând contextul î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 pronunțat mai ales când se întâmplă în locuri de muncă de fundal. Prin urmare, atunci când analizați problema scurgerilor de memorie, trebuie să începeți cu acestea, de exemplu, dezactivându-le î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 în care a apărut eroarea „Gazda la distanță a închis forțat conexiunea” din cauza utilizare ridicată echipamente 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 dimensiuni 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. Specialiștii noștri efectuează instalarea serverului la cheie pentru mai multe detalii, vezi secțiunea.
