Ця помилка з кодом 10054, критичного характеру, виявляється у користувачів під час проведення записи. Найчастіше зустрічається у старих релізів 1С 8.2.
Скріншот помилки 10054:
Взагалі, поява цієї помилки говорить про те, що відбувається несподівана для розробника сервера 1С дію:
- надходить некоректний запит;
- неправильні дані;
- запит, який викликає велику вибірку, з якою він не може зустрітися;
- окремий випадок: номер документа був більшим, ніж довжина задана в нумераторі;
- перевірте роботу при відключених антивірусах або firewall-і
Виправлення:
Полягає у локалізації проблеми, наскільки це можливо:
- визначення виду документа,
- регістру, з яким відбувається помилка,
- користувача,
- комп'ютера.
Потім робиться копія бази (засобами 1С чи СУБД).
Якщо перезапуск сервера вирішує проблему, продовжуєте спостереження. Додати скрипт рестарту служби вночі в неробочий час.
Якщо перезапуск циклічний перевірте, чи не налаштований у вас автоматичний перезапуску властивостях кластера:
Проводиться тестування та виправлення з перерахуванням підсумків та реіндексацією таблиць. 
Піднімається колишня копія бази, в якій проблема спостерігається, звіряються відзнаки, можливо це наштовхне на причину.
Якщо вирішити проблему не вдається, наступним кроком буде налаштування та аналіз технологічного журналу.
Що може з'ясуватись у процесі:
Якщо навантаження на сервер, на межі 100%, розгляньте варіант поділу сервера бази даних та сервера 1С, зазвичай це уповільнює, але стабілізує роботу (8.3 є механізм спільної пам'яті, що прискорює взаємодію сервера і).
- Додайте пам'ять на сервер, якщо це можливо.
- Можливим рішенням буде заміна сервера на 64 бітний, але для початку перевірте працездатність у знайомих, де він стоїть.
- Не завадить така ж перевірка і на 32 бітах, щоб зрозуміти помилку в даних або конкретному сервері.
- Вивантаження із завантаженням може усунути прояв.
- Вкрай розгляніть перенесення даних через конвертацію даних або довантаження даних у робочу копію (тривала процедура)
Перевірте журнали Windows щодо системних помилок:
- у роботі мережі
- обладнання
- програми
- перезапустіть роутери, світчі (рідко, але буває проблеми саме в них)
Якщо проблема не вирішена в короткий час, можливо вам буде потрібна допомога сертифікованих адміністраторів або експертів 1С.
Досить поширена помилка при експлуатації 1С 8.2 в режимі клієнт-сервер, - віддалений хост примусово розірвав існуюче підключення. Зазвичай, звертаються адміністратори клієнтів із корпоративного сектора, тобто. там, де експлуатується від 20 та більше робочих місць.
У 98% випадків дана помилкапов'язана із перезапуском робочого процесу. Причин, чому він перезапускається, може бути кілька, але найпоширеніша – банальний перезапуск за розкладом. Внаслідок зростання файлу робочого процесу rphostі подальшого за цим зростанням різким уповільненням роботи, адміни намагаються вирішувати проблему перезапуском робочих процесів, і відразу стикаються з іншою - відключенням працюючих користувачів. Створення додаткового робочого процесу не дає т.к. всупереч офіційної документаціїперемикання товстого клієнта на інший робочий процес не відбувається. Більше того, виникає підвищене навантаження на процесор – необхідно обробляти перемикання контексту. До речі, сама 1С рекомендує для 50-100 користувачів один робочий процес.
1) для звільнення пам'яті, зайнятої робочим процесом 1С, використовувати автоматичний перезапуск робочих процесів. Рекомендується перезапускати робочі процеси щодня (кожні 86400 секунд). При цьому спочатку робочий процес вимикається (нові з'єднання з ним неможливі, старі продовжують працювати) і запускається новий. Потім, коли всі з'єднання зі старим процесом закриті, процес завершується. При цьому звернути увагу, що відлік цих 86400 починається з моменту старту служби Агент сервера 1С Підприємство. Тобто. бажано стартувати її вночі.
2) не використовувати більше одного робочого процесуякщо у вас до 100 користувачів. При більшій кількостіробочих процесів витрачається процесорний час перемикання контексту з-поміж них.
3) очищати пам'ять, що використовується. У швидкому зростанні займаної пам'яті процесом rphost найчастіше винна недбало написана конфігурація, часто програмісти не турбують себе очищенням пам'яті, особливо під таблицями значень, перерахуваннями та масивами. Особливо яскраво це проявляється, коли це відбувається у фонових завданнях. Тому, розбір питання щодо витоку пам'яті, треба починати саме з них, наприклад, відключивши їх у властивостях інформаційної базина певний час.
4) використовувати окремі сервери для SQL та 1С. Як відомо, для SQL пам'яті багато не буває.
Слід звернути увагу на зазначені випадки появи помилки. високої утилізації мережевого обладнання . У разі зростання часу відповіді сервера до 150-300 і більше мс відбувається розрив з'єднання по таймууту. Наприклад, це відбувалося, коли кілька користувачів одночасно навантажують маршрутизатор, до якого підключено і сервер 1С, копіюванням файлів великих розмірів. Адміністратори повинні враховувати можливість і такої ситуації, і при купівлі маршрутизаторів звертати увагу на швидкість матриці, що комутує.
Насамкінець додам, що інсталяція та налаштування сервера справа відповідальна, що вимагає знань і досвіду, краще доручити його професіоналам. Наші фахівці виконують встановлення сервера "під ключ", докладніше див. розділ .
Опис помилки
server_addr=tcp://<имясервера>:1562 descr=Помилка доступу до сервера (Windows Sockets — 10054(0x00002746). Віддалений хост примусово розірвав існуюче підключення.) line=1031 file=.\src\DataExchangeTcpClientImpl.cpp
Як боротися із цією проблемою
Налаштувати Технологічний журнал та розібрати його логи.
Найбільш частими причинамибувають падіння серверної частини 1С: Підприємства.
Також можна переконатися, подивившись — чи не створюються дампи (дивитися шлях logcfg.xml, якщо налаштування dump-ів у ньому відсутнє, то в каталозі %USERPROFILE%\Local Settings\Application Data\1C\1Cv81\Dumps, наприклад C:\ Documents and Settings\<Имя пользователя>\Local Settings\Application Data\1C\1Cv81\dumps. Падіння платформи найчастіше можуть виникати через запити з нестандартними параметрами. Дампи надсилайте на техпідтримку 1С email: [email protected].
1. Найчастіше мені зустрічалася проблема у журналі документів у відборах запити були схожі на цей:
SELECT ALLOWED TOP 35 R.Date_Time A1,
R.Number 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.Document A14,
R.Marked A15,
R.Posted A16,CAST(R.Fld9608 AS REF(Reference9)).
A17,CAST(R.Fld9606 AS REF(Reference52)).Description A18,CAST(R.Fld9611
AS REF (Reference93)). Description A19, CASE WHEN R.
Reference53 THEN CAST(R.Fld9609 AS REF(Reference53)).Description WHEN
R.Fld9609 REFS Reference150 THEN CAST(R.Fld9609 AS
REF(Reference150)).Description WHEN R.Fld9609 REFS Reference63 THEN
CAST(R.Fld9609 AS REF(Reference63)).Description WHEN R.Fld9609 REFS
Reference114 THEN CAST(R.Fld9609 AS REF(Reference114)).Description END
A20,CAST(R.Fld9605 AS REF(Reference79)).Description A21
FROM DocumentJournal9604 R WHERE
((R.Fld9605=79:b63e000bcd6ad80811da7cf12c684266)) AND
(R.Date_Time > DATETIME(2006,12,31,12,0,0) OR (R.Date_Time =
DATETIME(2006,12,31,12,0,0) AND (R.Document >=
343:b654000bcd6ad80811dba49c7aabe269)))
ORDER BY A1 ASC, A14 ASC'
2. Приклад лога ТЖ, що показує причину падіння сервера при оновленні повнотекстового пошуку
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_20090609
ЗагальнийМодуль.МодульРегламентнихЗавдань: 46: ПовнотекстовийПошук.ОбновитиІндекс(Брехня, Істина);’
Підсумковим рішенням у цьому прикладі буде відключити фоновий процес у проблемній базі. Дочекатися нового релізу платформи та оновитися.
Докладніше про падіння платформи дивіться у моєму блозі.
3. Приклад ТЖ для циклічного перезапуску процесів. Для аналізу цієї події на комп'ютері сервера 1С:Підприємства необхідно включити запис до технологічного журналу подій PROC (приклад файлу logcfg.xml).
Коли процес вимикається, буде виведено подію PROC із властивістю Txt=Process become disable.
Коли зупиняється, буде виведено подію PROC з властивістю Txt=Process terminated. Будь-який клієнт finished with error. Якщо аварійні завершення роботи користувачів збігаються з виведенням цієї події, то причиною є примусова зупинка робочого процесу або адміністратором (через консоль кластера), або внаслідок автоматичного перезапуску.
4. Переконатись, що причиною є/не є дії адміністратора в консолі
—————————-
Нижче наведено варіант рішення колегою.
Всім зацікавлениму вирішенні проблем із падінням платформи з помилками:
10051, 10053, 10054, 10064
Як показав розбір польотів по падінням платформи, з вище зазначеними помилками:
— Більшість падінь спричинена саме роботою фонових завдань, Як і передбачалося в топіці.
- Не хваткою дискового простору
- Наявністю великої кількостіне завершених транзакцій у журналі 1С
— Перш ніж займатися розбором з технологічним журналом, проаналізуйте фонові завдання, що використовуються в конфігурації, і відключіть ті, які не потрібні Вам для роботи, конфігурації (банально, аналіз 14 ГБ сміття можна вважати проведенням часу, якщо Вам нічим зайнятися... :)))))
— Проаналізуйте та внесіть виправлення до дописаних Вами фонових завдань, переконайтеся, що вони завершуються з нормальним кодом завершення (без помилок і не закритих транзакцій)
— Внесіть у алгоритми фонових завдань фрагменти коду, що очищають, примусово, пам'ять використовувану в ході їх роботи (Не варто сподіватися, що 1С при завершенні особливо чекає використану пам'ять)
— Проаналізуйте та ВИПРАВТЕ ПРОБЛЕМИ ФУНКЦІОНУВАННЯ типових фонових завдань конфігурації
- Виконайте регламентні процедури з базою даних, через пункт меню Адміністрація-Тестування та виправлення, не забудьте обов'язково, виконати стиснення бази даних
— Проаналізуйте обсяг простору, що використовується. сервером SQL, ймовірно, що серверу банально не вистачає пам'яті
— Перевірте політки налаштування Active Directory
— Також стисніть/очистіть журнал транзакцій SQLось приблизно таким кодом (для SQL 2000):
Варіант 1:DBCC SHRINKFILE(pubs_log, 2)
(Якщо потрібний розмірне досягнуть спробуйте варіант 2) Варіант 2:BACKUP LOG pubs WITH TRUNCATE_ONLY
DBCC SHRINKFILE(pubs_log,2)
Де pub_log – ім'я Вашої бази даних
Варіант 3:
sp_detach_db - відключимо з цією процедурою базу, а sp_attach_db - підключимо знову. Журнал транзакцій при цьому очиститься.
(Докладніше можна прочитати в розділах MSDN Q256650 (для SQL 7.0) та Q272318 (для SQL 2000).)
Варіант 4: (Для 7.0)
DBCC SHRINKFILE (file_name, target_size)
DBCC SHRINKDATABASE (database_name, target_percent)
BACKUP LOG database_name WITH TRUNCATE_ONLY
Якщо після цих операцій падіння продовжуються, тоді продовжуйте дотримуватися рекомендацій:
— Пробуйте внести зміни до файли HOSTS операційної системи(Найімовірніше буде достатньо прописати асоціювання тільки в файли на одній/двох машинах, де падіння відбуваються найчастіше)
- Пробуйте рознести сервера 1С підприємства та SQL, якщо вони у Вас на одній машині.
— Або навпаки встановіть їх на одній машині (якщо вистачає ресурсів) Відзначаються випадки, коли саме перенесення серверів на один сервер допомагало (На мій погляд, дуже сумнівно і більше стосується саме причини початку роботи, це стиснення журналів транзакцій)
— Перевірте час відгуку сервера (найвірогідніше, що все буде в межах норми, а рідкісні провали в часі обслуговування не можуть так сильно впливати на роботу сервера підприємства)
— Перевірте роботу маршрутизаторів у мережі (Рідко, але буває, що саме їх переналаштування впливає на кількість падінь)
— Перевірте конфлікти обладнання в мережі (це питання, чому бажано мати обладнання одного постачальника в мережі. Хто хоче може перевірити, наприклад, у тех. документації 3COM написано: якщо мережева карта виявляє, що взаємодіє з аналогічною мережевою картою, то вона може бути переключена на більш продуктивний режим, за рахунок переходу на оптимізований алгоритм обробки мережевих пакетів, перевірено на особистому досвідістрибок продуктивності до 50%)
— Перевірте рівні сигналів у споживачів/кінцевих комп'ютерів (може бути банально, низький рівеньсигналів, постійні повторні запити блоків, затримка черги на обслуговування в мережі, а отже зрештою отримання повідомлення, що кінцевий сервер розірвав з'єднання, коли кількість спроб перевищить час очікування надходження сигналу. Якщо хочете розібратися в даному питаннізверніться до протоколу Ethernet/CSMA CD/CSMA. Кількість спроб у передачі пакета по даному протоколуне нескінченно ...))) Та й буфер у картах теж не безмежний.)
— Додати пам'ять на сервер
— Переведіть частину/всіх користувачів у термінальний режим (тобто забезпечте те, що багато користувачів визначають як ТОНКОГО КЛІЄНТА 1C). Як такий сервер я б рекомендував Citrix Metaframe або Terminal Server MS
Найімовірніше, коли Ви виконаєте зазначені рекомендації, за винятком розбору проблем із залізом, стабільність роботи зросте настільки, що падіння платформи стануть дуже рідкісними, що перекриють технологічні проміжки з обслуговування бази даних, виконувати які все ж таки НЕОБХІДНО і не думайте, що ті рекомендації що вказані вище Панацея від усіх проблем.
Вони вирішать багато, але не всі проблеми.
І щасливі Ви, якщо Ви не маєте таких проблем, у кого вони є, той мене зрозуміє.
———————————
Дослідіть ролі «Користувача», якщо вони є в типової конфігураціїзвичайно, і зокрема, після того, як обчислите проблемнийдокумент за допомогою потрібно знайти проблемну роль (хто скаржиться).
Далі для ролі Користувача дивимося РЛС документа, якщо додаткових налаштуваньні (чисто), то правою кнопкоюна ньому - пошук посилань на об'єкт, і послідовно переглядаємо РЛС для ролі Користувач для кожного об'єкта.
Помилкове прийняття високої інтенсивності користувачів за атаку на протокол у деяких випадках Windows.
>Запустити програму regedit.exe, додай нове значення типу DWORD з ім'ям SynAttackProtect в розділ реєстру HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ і присвоє йому значення 00000000
Має сенс робити для Windows 2003 SP1 (http://msdn.microsoft.com/ru-ua/library/ms189083.aspx
Сервер 1С та БД на одній машині під керуванням Debian Squeeze.
Вирішення проблеми: встановлення параметра ядра tcp_syncookies у значення 0.
root@machine:~# echo "net.ipv4.tcp_syncookies = 0" >> /etc/sysctl.conf && sysctl -p
(Автор Вадим Івахін)
