Vzdálený hostitel násilně uzavřel existující připojení 10054. Vzdálený hostitel násilně uzavřel existující připojení
Poměrně častá chyba při použití 1C 8.2 v režimu klient-server - vzdálený hostitel byl násilně odpojen stávající připojení. Zpravidla se uplatňují správci klientů z firemní sféry, tzn. kde je provozováno 20 a více pracovišť.
V 98 % případů je tato chyba spojena s restartováním pracovního postupu. Důvodů, proč se restartuje, může být několik, ale nejběžnějším je banální restart podle plánu. Kvůli růstu souboru workflow rphost a následném prudkém zpomalení práce, které po tomto růstu následuje, se administrátoři snaží problém vyřešit restartováním pracovních procesů a hned jsou postaveni před další problém – odpojování pracujících uživatelů. Vytvoření dalšího pracovního postupu nic nedává, protože... v rozporu s oficiální dokumentací přechodu tlustého klienta na jiný workflow se neděje. Navíc existuje zvýšené zatížení na procesoru - je nutné zvládnout přepínání kontextu. Mimochodem, sám 1C doporučuje jeden pracovní postup pro 50-100 uživatelů.
1) pro uvolnění paměti obsazené pracovním postupem 1C použijte automatický restart pracovní procesy. Doporučuje se restartovat pracovní postupy jednou denně (každých 86 400 sekund). V tomto případě se nejprve vypne pracovní proces (nová připojení k němu nejsou možná, stará nadále fungují) a spustí se nový. Poté, když jsou všechna připojení ke starému procesu uzavřena, proces se ukončí. Zároveň mějte na paměti, že odpočítávání těchto stejných 86400 začíná od okamžiku zahájení služby Serverový agent 1C Enterprise. Tito. Je vhodné začít v noci.
2) nepoužívejte více než jeden pracovní proces, pokud máte až 100 uživatelů. Na více pracovní procesy tráví čas CPU přepínáním kontextu mezi nimi.
3) vymazat použitou paměť. Rychlý nárůst paměti obsazené procesem rphost je nejčastěji způsoben nedbale zapsanou konfigurací programátoři se často neobtěžují vyčistit obsazenou paměť, zejména pod; tabulky hodnot, výčty a pole. To je zvláště výrazné, když se to stane v úlohách na pozadí. Při rozboru problematiky úniků paměti je proto potřeba začít s nimi, například jejich zakázáním ve vlastnostech informační základna po určitou dobu.
4) použití samostatné servery pro SQL a 1C. Jak víte, pro SQL není nikdy příliš mnoho paměti.
Měli byste věnovat pozornost uvedeným případům, kdy se objevila chyba „Vzdálený hostitel násilně ukončil připojení“. vysoké využití síťová zařízení . Když se doba odezvy serveru zvýší na 150-300 ms nebo více, spojení se přeruší kvůli vypršení časového limitu. Stalo se to například, když několik uživatelů současně načetlo router, ke kterému byl server 1C připojen, kopírováním souborů velké velikosti. Správci by měli vzít v úvahu možnost této situace a při nákupu routerů věnovat pozornost rychlosti přepínací struktury.
Na závěr dodám, že instalace a konfigurace serveru je zodpovědná záležitost, která vyžaduje znalosti a zkušenosti, je lepší ji svěřit profesionálům. Naši specialisté instalují server na klíč, více viz sekce.
Tato chyba s kódem 10054, který je svou povahou kritický, se uživatelům zobrazí v době záznamu. Nejčastěji se vyskytuje ve starších verzích 1C 8.2.
Snímek obrazovky s chybou 10054:
Vzhled této chyby obecně naznačuje, že se děje neočekávaná akce pro vývojáře serveru 1C:
- přijde nesprávná žádost;
- nesprávné údaje;
- dotaz volající velký vzorek, který nemůže splnit;
- zvláštní případ: číslo dokladu bylo větší než délka uvedená v čitateli;
- zkontrolujte fungování s vypnutými antiviry nebo firewally
Oprava:
Spočívá v co největší lokalizaci problému:
- určení typu dokumentu,
- registr, ve kterém se chyba vyskytuje,
- uživatel,
- počítač.
Poté se vytvoří kopie databáze (pomocí 1C nebo DBMS).
Pokud restartování serveru problém vyřeší, pokračujte v monitorování. Přidejte skript restartování služby v noci mimo pracovní dobu.
Pokud je restart cyklický, zkontrolujte, zda jste ve vlastnostech clusteru nakonfigurovali automatický restart:
Testování a opravy jsou prováděny s přepočtem výsledků a reindexací tabulek. 
Zvedne se předchozí kopie databáze, ve které je problém pozorován, zkontrolují se rozdíly a možná to povede k příčině.
Pokud problém nelze vyřešit, dalším krokem je konfigurace a analýza protokolu procesu.
Co může být během procesu jasné:
Pokud je zatížení serveru na hranici 100 %, zvažte oddělení databázového serveru a serveru 1C, obvykle to práci zpomalí, ale stabilizuje (ve verzi 8.3 existuje mechanismus sdílená paměť, což urychluje interakci se serverem a).
- Pokud je to možné, přidejte na server paměť.
- Možným řešením by byla výměna serveru za 64bitový, ale nejprve zkontrolujte funkčnost svých přátel, kde je nainstalován.
- Nebylo by na škodu provést stejnou kontrolu na 32bitové verzi, abyste pochopili chybu v datech nebo konkrétním serveru.
- Vykládání a nakládání může eliminovat projevy.
- Jako poslední možnost zvažte přenos dat konverzí dat nebo přidání dat do pracovní kopie (dlouhý postup)
Zkontrolujte protokoly systému Windows, zda neobsahují systémové chyby:
- v síťovém provozu
- zařízení
- aplikací
- restartovat routery, switche (zřídka, ale jsou s nimi problémy)
Pokud problém není vyřešen v krátký čas, možná budete potřebovat pomoc certifikovaných správců nebo odborníků 1C.
Popis chyby
server_addr=tcp://<имясервера>:1562 descr=Chyba síťového přístupu k serveru (Windows Sockets - 10054(0x00002746). Vzdálený hostitel násilně uzavřel existující připojení.) line=1031 file=.\src\DataExchangeTcpClientImpl.cpp
Jak se s tímto problémem vypořádat
Nastavte protokol technologie a analyzujte jeho protokoly.
Většina běžné důvody Dochází k pádům serverové části 1C:Enterprise.
Můžete se také ujistit, že se podíváte, zda se nevytvářejí výpisy (podívejte se na cestu logcfg.xml, pokud tam nastavení výpisu není, pak do adresáře %USERPROFILE%\Local Settings\Application Data\1C\1Cv81\Dumps , například C:\Dokumenty a nastavení\<Имя пользователя>\Local Settings\Application Data\1C\1Cv81\dumps. K selhání platformy může nejčastěji dojít kvůli požadavkům s nestandardní parametry. Odesílejte výpisy na e-mail technické podpory 1C: [e-mail chráněný].
1. Nejčastěji jsem narazil na problém ve výběrech protokolu dokumentu, dotazy byly podobné tomuto:
VYBERTE POVOLENÝCH NEJLEPŠÍCH 35 R.Date_Time A1,
R.číslo 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)).Popis
A17,CAST(R.Fld9606 AS REF(Reference52)).Popis A18,CAST(R.Fld9611
JAKO REF(Reference93)).Popis A19, PŘÍPAD KDYŽ R.Fld9609 REFS
Reference53 THEN CAST(R.Fld9609 AS REF(Reference53)).Popis WHEN
R.Fld9609 REFS Reference150 THEN CAST(R.Fld9609 AS
REF(Reference150)).Popis KDYŽ R.Fld9609 REFS Reference63 THEN
CAST(R.Fld9609 AS REF(Reference63)).Popis KDYŽ R.Fld9609 REFS
Reference114 THEN CAST(R.Fld9609 AS REF(Reference114)).Popis END
A20,CAST(R.Fld9605 AS REF(Reference79)).Popis A21
Z DocumentJournal9604 R KDE
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) A
(R.Date_Time > DATETIME(2006,12,31,12,0,0) NEBO (R.Date_Time =
DATETIME(2006;12;31;12;0;0) AND (R.Document >=
343:b654000bcd6ad80811dba49c7aabe269)))
OBJEDNAT PODLE A1 ASC, A14 ASC'
2. Příklad logu TJ ukazující důvod pádu serveru při aktualizaci fulltextového vyhledávání
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_20090106Context=9m’3mp_text.
GeneralModule.Module of Regular Tasks: 46: Full-TextSearch.UpdateIndex(False, True);’
Konečným řešením v tomto příkladu by bylo zakázat proces na pozadí v problematické databázi. Počkejte na vydání a aktualizaci nové platformy.
Další informace o pádech platformy najdete na mém blogu.
3. Příklad TC pro cyklický restart procesů. Chcete-li analyzovat tuto událost na počítači serveru 1C:Enterprise, musíte povolit záznam v protokolu technologických událostí PROC (příklad souboru logcfg.xml).
Když je proces vypnutý, vyvolá se událost PROC s vlastností Txt=Proces se zakáže.
Když je proces ukončen, bude vydána událost PROC s vlastností Txt=Proces ukončen. Všichni klienti skončili s chybou. Li havaruje aktivity uživatele se časově shodují s výstupem této události, pak je příčinou nucené zastavení workflow buď administrátorem (prostřednictvím clusterové konzole) nebo z důvodu automatického restartu.
4. Ujistěte se, že příčinou je/není činnost administrátora v konzole
—————————-
Níže je verze řešení kolegy.
Každý zájem při řešení problémů s pády platformy s chybami:
10051, 10053, 10054, 10064
Jak ukázal přehled havárií plošin, shora uvedené chyby:
- Většina pádů je způsobena prací práce na pozadí, jak se očekává v tématu.
- Ne s rukojetí místo na disku
— Dostupnost velké číslo nedokončené transakce v protokolu 1C
- Před analýzou technologický časopis, analyzujte úlohy na pozadí použité v konfiguraci a deaktivujte ty, které k práci nepotřebujete, konfigurace (je to triviální, analýzu 14 GB smetí lze považovat za zábavu, pokud nemáte nic lepšího na práci... :))))
— Analyzujte a provádějte opravy úloh na pozadí, které jste přidali, ujistěte se, že jsou dokončeny s běžným kódem dokončení (žádné chyby nebo uzavřené transakce)
— Přidejte fragmenty kódu do algoritmů úloh na pozadí, které bugují násilně, paměť použitá během jejich provozu (Neměli byste doufat, že 1C po dokončení oddělí použitou paměť)
— Analyzujte a OPRAVTE PROBLÉMY VÝKONU typických úloh konfigurace na pozadí
— Proveďte regulační postupy s databází prostřednictvím položky nabídky Správa-Testování a opravy, nezapomeňte Nezbytně, provést kompresi databáze
— Analyzujte množství využitého prostoru SQL server, je pravděpodobné, že server prostě nemá dostatek paměti
— Zkontrolujte nastavení zásad Aktivní adresář
— A také komprimovat/vymazat protokol transakcí SQL s něčím podobným tomuto kódu (pro SQL 2000):
Možnost 1:DBCC SHRINKFILE(pubs_log, 2)
(Li správná velikost nedosaženo zkuste možnost 2) Možnost 2:ZÁLOHOVÁNÍ LOGU hospody S TRUNCATE_ONLY
DBCC SHRINKFILE(pubs_log;2)
Kde pub_log je název vaší databáze
Možnost 3:
sp_detach_db - tímto postupem odpojíme databázi a sp_attach_db - opět připojíme. Tím se vymaže protokol transakcí.
(Další informace naleznete v tématech MSDN Q256650 (pro SQL 7.0) a Q272318 (pro SQL 2000).)
Možnost 4: (Pro 7.0)
DBCC SHRINKFILE(název_souboru, cílová_velikost)
DBCC SHRINKDATABASE (název_databáze, cílová_procenta)
ZÁLOHA LOG jméno databáze S TRUNCATE_ONLY
Pokud pády přetrvávají i po těchto operacích, pokračujte podle doporučení:
- Zkuste provést změny HOST soubory operační systém(s největší pravděpodobností bude stačit zaregistrovat sdružení pouze v souborech na jednom/dvou strojích, kde dochází k pádům nejčastěji)
— Zkuste oddělit podnikové a SQL servery 1C, pokud je máte na stejném počítači.
- Nebo je naopak nainstalujte na jeden stroj (pokud máte dostatek prostředků) Jsou případy, kdy přesun serverů na jeden server pomohl (podle mého názoru je to velmi pochybné a souvisí spíše s důvodem zahájení práce, toto je komprese transakčních protokolů)
— Zkontrolujte dobu odezvy serveru (s největší pravděpodobností bude vše v normálních mezích a vzácné poruchy v době provozu nemohou mít tak silný dopad na provoz podnikového serveru)
— Zkontrolujte fungování routerů v síti (Zřídka, ale stává se, že na počet pádů má vliv jejich překonfigurování)
— Zkontrolujte konflikty zařízení v síti (s tím souvisí otázka, proč je vhodné mít v síti zařízení od jednoho dodavatele. Kdo chce, může si ověřit např. v technické dokumentaci 3COM je napsáno: pokud síťová karta zjistí, že komunikuje s podobným síťová karta, pak jej lze přepnout do produktivnějšího režimu přepnutím na optimalizovaný algoritmus zpracování síťové pakety, testováno pro osobní zkušenost skok výkonu až o 50%)
— Zkontrolujte úrovně signálu spotřebitelů/koncových počítačů (může být triviální, nízká úroveň signály, neustále se opakující požadavky na bloky, zpoždění ve frontě na službu v síti, a proto případně přijetí zprávy, že koncový server ukončil spojení, když počet pokusů překročí dobu čekání na příchod signálu. Chcete-li tomuto problému porozumět, podívejte se na operační protokol Ethernet/CSMA CD/CSMA. Počet pokusů o odeslání paketu tento protokol není nekonečný...))) A zásobník v kartách také není nekonečný.)
— Přidání paměti na servery
— Převeďte některé/všechny uživatele do terminálového režimu (tj. poskytněte to, co MNOHO uživatelů definuje jako TENKÝ KLIENT 1C). Pro takový server bych doporučil Citrix Metaframe nebo Terminal Server MS
S největší pravděpodobností, když se budete řídit těmito doporučeními, s výjimkou analýzy problémů s hardwarem, stoupne stabilita práce natolik, že pády platformy budou velmi vzácné, což vykryje technologické mezery pro údržbu databáze, která stále MUSÍ být dodržujte a nemyslete si, že výše uvedená doporučení Všelék na všechny problémy.
Vyřeší mnoho, ale ne všechny problémy.
A jsi rád, když takové problémy nemáš, kdo je má, pochopí mě.
———————————
Prozkoumejte role „Uživatel“, pokud nějaké jsou typická konfigurace samozřejmě a zejména poté, co spočítáte problém document using , musíte najít problematickou roli (kdo si stěžuje).
Dále se pro roli Uživatel podívejte na radar dokumentu, pokud další nastavení ne (čistý), tedy klikněte pravým tlačítkem myši na něm - vyhledejte odkazy na objekt a postupně prohlížejte radar pro roli „Uživatel“ pro každý objekt.
Záměna vysoké intenzity uživatele za protokolový útok v některých případech Windows.
>Spusťte regedit.exe, přidejte novou hodnotu DWORD nazvanou SynAttackProtect do klíče registru HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ a přidělte jí hodnotu 00000000
Má smysl to udělat pro Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx
1C server a databáze na jednom počítači pod Správa Debianu Sevření.
Řešení: Nastavte parametr jádra tcp_syncookies na 0.
root@machine:~# echo "net.ipv4.tcp_syncookies = 0" >> /etc/sysctl.conf && sysctl -p
(autor Vadim Ivakhin)
