Trassir je udaljeni host nasilno zatvorio postojeću vezu. Udaljeni host je prisilno prekinuo postojeću vezu

Ovaj kod pogreške 10054, kritičan, pojavljuje se korisnicima u vrijeme snimanja. Najčešće se nalazi u starijim izdanjima 1C 8.2.

Snimka zaslona pogreške 10054:

Općenito, pojavljivanje ove pogreške ukazuje na to da se događa neočekivana radnja za programera 1C poslužitelja:

  • stiže netočan zahtjev;
  • netočni podaci;
  • upit koji poziva veliki uzorak koji ne može ispuniti;
  • poseban slučaj: broj dokumenta bio je veći od duljine navedene u brojniku;
  • provjerite rad s isključenim antivirusnim programima ili vatrozidima

Ispravak:

Sastoji se od lokaliziranja problema što je više moguće:

  • određivanje vrste dokumenta,
  • registar u kojem se pojavljuje greška,
  • korisnik,
  • računalo.

Zatim se izrađuje kopija baze podataka (koristeći 1C ili DBMS).

Ako ponovno pokretanje poslužitelja riješi problem, nastavite s praćenjem. Dodajte skriptu za ponovno pokretanje usluge noću tijekom neradnog vremena.

Ako je ponovno pokretanje cikličko, provjerite jeste li konfigurirali automatsko ponovno pokretanje u svojstvima klastera:

Testiranje i ispravak provode se ponovnim izračunom rezultata i ponovnim indeksiranjem tablica.

Prethodna kopija baze podataka u kojoj je uočen problem se preuzima, razlike se provjeravaju i možda će to dovesti do uzroka.

Ako se problem ne može riješiti, sljedeći korak je konfiguracija i analiza dnevnika procesa.

Što može postati jasno tijekom procesa:


Ako je opterećenje poslužitelja na rubu 100%, razmislite o odvajanju poslužitelja baze podataka i 1C poslužitelja, to obično usporava, ali stabilizira rad (u 8.3 postoji mehanizam zajednička memorija, što ubrzava interakciju poslužitelja i).

  • Dodajte memoriju poslužitelju ako je moguće.
  • Moguće rješenje bi bila zamjena servera 64-bitnim, ali prvo provjerite funkcionalnost svojih prijatelja gdje se nalazi.
  • Ne bi škodilo izvršiti istu provjeru na 32-bitnom poslužitelju kako biste razumjeli pogrešku u podacima ili određenom poslužitelju.
  • Istovar i utovar mogu eliminirati manifestaciju.
  • Kao posljednje sredstvo, razmislite o prijenosu podataka putem pretvorbe podataka ili dodavanju podataka u radnu kopiju (dugačak postupak)

Provjerite sistemske pogreške u zapisnicima sustava Windows:

  • u radu mreže
  • oprema
  • aplikacije
  • ponovno pokretanje routera, switcheva (rijetko, ali ima problema s njima)

Ako se problem ne riješi u kratkom vremenu, možda će vam trebati pomoć certificiranih administratora ili stručnjaka 1C.

Prilično uobičajena pogreška pri korištenju 1C 8.2 u načinu klijent-poslužitelj - udaljeni host je prisilno isključen postojeći priključak. U pravilu se prijavljuju administratori klijenata iz korporativnog sektora, tj. gdje radi 20 ili više radnih mjesta.

U 98% slučajeva ovu grešku povezan s ponovnim pokretanjem tijeka rada. Može biti nekoliko razloga zašto se ponovno pokreće, ali najčešći je banalno ponovno pokretanje prema rasporedu. Zbog rasta datoteke tijeka rada rphost i kasnijeg naglog usporavanja rada koje prati taj rast, administratori problem pokušavaju riješiti ponovnim pokretanjem radnih procesa, a odmah se suočavaju s još jednim problemom - isključivanjem radnih korisnika. Stvaranje dodatnog tijeka rada ne daje ništa jer... protivno službena dokumentacija prebacivanje debelog klijenta na drugi tijek rada ne događa se. Štoviše, povećano je opterećenje procesora - potrebno je rukovati prebacivanjem konteksta. Usput, sam 1C preporučuje jedan tijek rada za 50-100 korisnika.

1) da biste oslobodili memoriju koju zauzima radni proces 1C, koristite automatsko ponovno pokretanje radnih procesa. Preporuča se ponovno pokretanje radnih procesa jednom dnevno (svakih 86400 sekundi). U tom slučaju prvo se isključuje radni proces (nove veze s njim nisu moguće, stare nastavljaju raditi) i pokreće se novi. Zatim, kada se zatvore sve veze sa starim procesom, proces se prekida. Istodobno, imajte na umu da odbrojavanje tih istih 86400 počinje od trenutka pokretanja usluge Agent poslužitelja 1C Enterprise. one. Preporučljivo je započeti noću.

2) nemojte koristiti više od jednog radnog procesa, ako imate do 100 korisnika. Na više radnički procesi troše CPU vrijeme na prebacivanje konteksta između njih.

3) očisti korištenu memoriju. Brzi rast memorije koju zauzima rphost proces najčešće je posljedica nemarno napisane konfiguracije; tablice vrijednosti, enumeracije i nizovi. To je posebno izraženo kada se događa u pozadinskim zadacima. Stoga, kada analizirate problem curenja memorije, morate početi s njima, na primjer, onemogućivanjem u svojstvima informacijska baza neko vrijeme.

4) korištenje odvojeni poslužitelji za SQL i 1C. Kao što znate, za SQL nikada nema previše memorije.

Trebali biste obratiti pozornost na zabilježene slučajeve u kojima se pojavila pogreška "Udaljeni host je prisilno zatvorio vezu" zbog visoka iskoristivost mrežna oprema . Kada se vrijeme odgovora poslužitelja poveća na 150-300 ms ili više, veza se prekida zbog vremenskog ograničenja. Na primjer, to se dogodilo kada je nekoliko korisnika istovremeno učitalo usmjerivač na koji je 1C poslužitelj bio povezan kopiranjem datoteka velike veličine. Administratori trebaju uzeti u obzir mogućnost ove situacije, a pri kupnji usmjerivača obratiti pažnju na brzinu preklopne tkanine.

Zaključno ću dodati da je instalacija i konfiguracija poslužitelja odgovorna stvar koja zahtijeva znanje i iskustvo, bolje je povjeriti je profesionalcima. Naši stručnjaci instaliraju poslužitelj po principu ključ u ruke; za više detalja pogledajte odjeljak.

Opis greške

server_addr=tcp://<имясервера>:1562 descr=Pogreška mrežnog pristupa poslužitelju (Windows Sockets - 10054(0x00002746). Udaljeni host je prisilno zatvorio postojeću vezu.) line=1031 file=.\src\DataExchangeTcpClientImpl.cpp

Kako se nositi s ovim problemom

Postavite tehnološki dnevnik i analizirajte njegove zapise.
Većina uobičajeni razlozi Postoje rušenja poslužiteljskog dijela 1C:Enterprise.
Također se možete uvjeriti tako da pogledate stvaraju li se dumpovi (pogledajte stazu logcfg.xml, ako postavke dumpa nisu tamo, zatim u direktoriju %USERPROFILE%\Local Settings\Application Data\1C\1Cv81\Dumps, na primjer C:\ Dokumenti i postavke\<Имя пользователя>\Local Settings\Application Data\1C\1Cv81\dumps. Do pada platforme najčešće može doći zbog zahtjeva s nestandardnim parametrima. Pošaljite ispise na e-poštu tehničke podrške 1C: [e-mail zaštićen].
1. Najčešće sam nailazio na problem u odabirima dnevnika dokumenata, upiti su bili slični ovome:

ODABIR DOZVOLJENO TOP 35 R. Datum_vrijeme A1,
R. Broj 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. Dokument A14,
R. Označeno A15,
R.Posted A16,CAST(R.Fld9608 AS REF(Reference9)).Opis
A17,CAST(R.Fld9606 AS REF(Referenca52)).Opis A18,CAST(R.Fld9611
KAO REF(Referenca93)).Opis A19, SLUČAJ KADA R.Fld9609 REFS
Referenca53 THEN CAST(R.Fld9609 AS REF(Referenca53)).Opis WHEN
R.Fld9609 REFS Referenca150 THEN CAST(R.Fld9609 AS
REF(Referenca150)).Opis WHEN R.Fld9609 REFS Referenca63 THEN
CAST(R.Fld9609 AS REF(Reference63)).Description WHEN R.Fld9609 REFS
Referenca114 THEN CAST(R.Fld9609 AS REF(Referenca114)).Opis END
A20,CAST(R.Fld9605 KAO REF(Referenca79)).Opis A21
FROM DocumentJournal9604 R WHERE
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) I
(R.Date_Time > DATETIME(2006,12,31,12,0,0) ILI (R.Date_Time =
DATETIME(2006,12,31,12,0,0) I (R.Dokument >=
343:b654000bcd6ad80811dba49c7aabe269)))
POREDAK PREMA A1 ASC, A14 ASC’

2. Primjer TJ dnevnika koji prikazuje razlog pada poslužitelja prilikom ažuriranja pretraživanja cijelog teksta
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_20090609021136_10236.mdmp,Context=’
GeneralModule.Modul redovnih zadataka: 46: Full-TextSearch.UpdateIndex(False, True);'

Konačno rješenje u ovom primjeru bilo bi onemogućiti pozadinski proces u problematičnoj bazi podataka. Pričekajte novo izdanje platforme i ažuriranje.
Za više informacija o padu platforme, pogledajte moj blog.
3. Primjer TC za cikličko ponovno pokretanje procesa. Da biste analizirali ovaj događaj na poslužiteljskom računalu 1C:Enterprise, morate omogućiti unos u zapisnik tehnoloških događaja PROC (primjer datoteke logcfg.xml).
Kada se proces isključi, pokrenut će se PROC događaj sa svojstvom Txt=Proces postaje onemogućen.
Kada se proces prekine, izdat će se PROC događaj sa svojstvom Txt=Proces prekinut. Svaki klijent završio je s pogreškom. Ako se rušenja korisnika vremenski poklapaju s rezultatom ovog događaja, tada je uzrok prisilno gašenje tijeka rada od strane administratora (putem konzole klastera) ili zbog automatskog ponovnog pokretanja.
4. Provjerite jesu li uzrok radnje administratora u konzoli

—————————-

Ispod je verzija rješenja kolege.

svi zainteresirani u rješavanju problema s rušenjima platforme s pogreškama:

10051, 10053, 10054, 10064

Kao što je izvješće o padu platforme pokazalo, odozgo naznačene greške:

- Većina padova uzrokovana je radom pozadinski poslovi, kako se očekuje u temi.

- Ne sa stiskom prostor na disku

— Dostupnost veliki broj nedovršene transakcije u dnevniku 1C

— Prije parsiranja tehnološkog dnevnika analizirajte pozadinske poslove korištene u konfiguraciji i onemogućite one koji vam ne trebaju za rad ili konfiguraciju (trivijalno je, analiziranje 14 GB smeća može se smatrati razbibrigom ako nemate ništa pametnije raditi.. . :))))

— Analizirajte i ispravite pozadinske poslove koje ste dodali, provjerite jesu li dovršeni normalnim kodom za dovršetak (bez pogrešaka ili zatvorenih transakcija)

— Dodajte fragmente koda algoritmima pozadinskih zadataka koji stvaraju pogrešku prisilno, memorija korištena tijekom njihovog rada (Ne treba se nadati da će 1C dodijeliti korištenu memoriju nakon završetka)

— Analizirajte i ISPRAVITE PROBLEME S IZVEDBOM tipičnih pozadinskih konfiguracijskih poslova

— Provedite regulatorne postupke s bazom podataka, kroz stavku izbornika Administracija-Testiranje i ispravak, ne zaboravite Obavezno, izvršiti kompresiju baze podataka

— Analizirajte količinu iskorištenog prostora SQL poslužitelj, vjerojatno je da poslužitelj jednostavno nema dovoljno memorije

— Provjerite pravila Aktivne postavke Imenik

- I također komprimirajte/očistite zapisnik SQL transakcije s otprilike sljedećim kodom (za SQL 2000):

Opcija 1:DBCC SHRINKFILE(pubs_log, 2)
(Ako prava veličina nije postignut pokušajte opciju 2) Opcija 2:BACKUP LOG pubs WITH TRUNCATE_ONLY
DBCC SHRINKFILE(pubs_log,2)

Gdje je pub_log naziv vaše baze podataka

Opcija 3:
sp_detach_db - ovim ćemo postupkom odspojiti bazu podataka i sp_attach_db - ponovno ćemo je spojiti. Dnevnik transakcija bit će izbrisan.
(Za više informacija pogledajte MSDN teme Q256650 (za SQL 7.0) i Q272318 (za SQL 2000).)

Opcija 4: (za 7.0)
DBCC SHRINKFILE(naziv_datoteke, ciljna_veličina)
DBCC SHRINKDATABASE (naziv_baze_podataka, ciljni_postotak)
DNEVNIK SIGURNOSNE KOPIJE naziv_baze podataka SAMO S TRUNCATE_ONLY

Ako se padovi nastave nakon ovih operacija, nastavite slijediti preporuke:

- Pokušajte unijeti promjene u HOST datoteke operativni sustav(najvjerojatnije će biti dovoljno registrirati asocijaciju samo u datotekama na jednom ili dva računala, gdje se najčešće ruše)

— Pokušajte razdvojiti 1C enterprise i SQL poslužitelje ako ih imate na istom stroju.

— Ili, naprotiv, instalirajte ih na jedno računalo (ako imate dovoljno resursa) Postoje slučajevi kada je prijenos poslužitelja na jedan poslužitelj pomogao (po mom mišljenju, to je vrlo upitno i odnosi se konkretnije na razlog za početak rada, ovo je kompresija dnevnika transakcija)

— Provjerite vrijeme odziva poslužitelja (najvjerojatnije će sve biti u granicama normale, a rijetki kvarovi u vremenu usluge ne mogu imati tako snažan utjecaj na rad poslužitelja poduzeća)

— Provjerite rad routera na mreži (Rijetko, ali događa se da njihova rekonfiguracija utječe na broj padova)

— Provjerite sukobe opreme na mreži (ovo se odnosi na pitanje zašto je poželjno imati opremu jednog dobavljača na mreži. Tko želi može provjeriti npr. u tehničkoj dokumentaciji 3COM-a piše: ako mrežna kartica otkriva da je u interakciji sa sličnom mrežna kartica, tada se može prebaciti na produktivniji način rada prebacivanjem na optimizirani algoritam obrade mrežni paketi, testirano na osobno iskustvo skok performansi do 50%)

— Provjerite razine signala potrošača/krajnjih računala (možda trivijalno, niska razina signale, stalno ponavljane zahtjeve za blokadama, kašnjenje u redu čekanja za uslugu u mreži, te stoga eventualno dobivanje poruke da je krajnji poslužitelj zatvorio vezu kada broj pokušaja premaši vrijeme čekanja na dolazak signala. Ako želite razumjeti ovo pitanje pogledajte Ethernet/CSMA CD/CSMA operativni protokol. Broj pokušaja prijenosa paketa od ovaj protokol nije beskonačno...))) A međuspremnik u karticama također nije beskonačan.)

— Dodajte memoriju poslužiteljima

— Prijenos nekih/svih korisnika u terminalski način rada (tj. pružanje onoga što MNOGI korisnici definiraju kao TANKI KLIJENT 1C). Za takav poslužitelj bih preporučio Citrix Metaframe ili Terminal Server MS

Najvjerojatnije, kada slijedite ove preporuke, s izuzetkom analize problema s hardverom, stabilnost rada će se toliko povećati da će padovi platforme postati vrlo rijetki, čime će se zatvoriti tehnološki nedostaci za održavanje baze podataka, koji su još uvijek POTREBNI slijediti i nemojte misliti da su gore navedene preporuke lijek za sve probleme.

Oni će riješiti mnoge, ali ne sve probleme.

I sretan si ako nemaš takvih problema; svatko tko ih ima razumjet će me.

———————————

Pregledajte uloge "Korisnik" ako ih ima tipična konfiguracija naravno, a posebno, nakon što izračunate problem dokument koristeći , trebate pronaći problematičnu ulogu (tko se žali).
Zatim, za ulogu korisnika, pogledajte radar dokumenta, ako dodatne postavke ne (čisto), dakle desni klik na njemu - tražite poveznice na objekt i redom pregledajte radar za ulogu "Korisnik" za svaki objekt.

Zamjena visokog korisničkog intenziteta za napad na protokol u nekim slučajevima Windowsa.
>Pokrenite regedit.exe, dodajte novu DWORD vrijednost pod nazivom SynAttackProtect ključu registra HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ i dajte mu vrijednost 00000000
Ima smisla to učiniti za Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx

1C poslužitelj i baza podataka na jednom računalu ispod Upravljanje Debianom Stisak.

Zaobilazno rješenje: Postavite parametar jezgre tcp_syncookies na 0.

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