Проблемы на ровном месте, или рассказ о том, как у нас каждое утро стабильно подвисал dev-сервер 1С

12.04.24

Администрирование - Сервера

Меня зовут Павел Белоусов, я работаю Ведущим программистом 1С в компании OCS Distribution. Хочу поделиться историей, как мы столкнулись с постоянными зависаниями dev-сервера 1C, каким образом решили проблему и какие любопытные уроки вынесли из ситуации.

Однажды у нас начали происходить странные вещи: dev-сервер 1С намертво зависал после двух-трёх суток работы, после чего требовался внеплановый перезапуск системы. Первым «звоночком» всегда становилось резкое замедление работы.

При этом prod работал стабильно и не показывал каких-либо признаков проблем. Обычно всё происходит наоборот: dev работает, а на prod — проблемы, ошибки, тормоза и прочее. И в такой ситуации всё понятно: нагрузка больше, значит часть потенциальных проблем на dev'е мы просто не заметили. В нашем же случае получается, что dev отдыхает и виснет. Причем виснет ближе к утру, чаще даже до начала следующего рабочего дня, когда, понятное дело, нагрузки на него нет вообще никакой. Для справки: на тот момент стояла платформа 8.3.18, но думаю, что дело совсем не в этом.

 

Расследование. Начало

Первым делом мы обнаружили связь зависаний с одной конкретной базой на этом сервере — нашей общей тестовой базой, в которой аналитики проверяли доработки непосредственно перед их отправкой на prod. Как именно нашли, я уже вспомнить не смогу: наблюдали за работой клиентов, доверились интуиции... Проверили гипотезу достаточно просто: в течение некоторого времени отключали на ночь тестовую базу. Результатом стало отсутствие проблем с зависанием. Как только перестали это делать — всё вернулось назад.

Дальнейшие поиски возможных причин проблемы мы проводили уже на этой базе, хоть нам было и непонятно, чем она отличается от остальных. На  сервере их более десятка, и все, включая тестовую, — клоны одной и той же рабочей базы.

Первое подозрение упало на нехватку выделенной оперативной памяти. Однако технологический журнал ничего особенного не показал: всё, что нужно было, каждый раз выделялось без проблем. Свободной памяти оставалось достаточно вплоть до момента полного зависания системы. И в этом была главная странность.

Также мы наблюдали за выделением памяти в мониторе ресурсов (в операционной системе), но ничего подозрительного не обнаружили: её было более чем достаточно, использовалась только треть... Но! Когда мы долго наблюдали за числами памяти по rphost`ам, заметили, что они скачут, а значит есть какая-то активность. Другим открытием стало следующее — часть выделенной памяти со временем не освобождается. Хотя и совсем маленькая часть, в пределах погрешности. Речь о килобайтах. Абсурдно мало, но проблема есть. И мы продолжили поиски.

 

Ищем активности

Итак, регламентные задания мы давно выключили. На всякий случай убрали обработчики ожидания. Не помогло.
Мы дошли до того, что выключили вообще все обработчики.

// "дошли до ручки"
 Процедура ПередНачаломРаботыСистемы(Отказ)
     Возврат;
 КонецПроцедуры

Процедура ПриНачалеРаботыСистемы()
     Возврат;
 КонецПроцедуры

В итоге мы включаем замер производительности и убеждаемся, что вообще никакой код не выполняется. По сути просто конфигурация 1С с базой данных. Далее смотрим монитор ресурсов и видим: есть активность! Выделение памяти по-прежнему прыгает и немножко деградирует: килобайты со временем не освобождаются, хотя этого и недостаточно, чтобы забить всю доступную память.
У нас уже не оставалось никаких идей, как вдруг в почти пустом к этому времени журнале регистрации мы замечаем наличие запросов к базе по rest-интерфейсу каждые 3–5 минут. Начинаем проверять эту версию. В 1С никакой лог-информации по запросам нет — просто работают и всё, а что делают, никто не знает. У нас сразу появились подозрения: может быть эти rest-запросы выбирают слишком много данных и вешают сервер? Но нет! Разработчики интеграции с сайтом быстро сознались, что это их запросы: выборка минимальная, просто обращение к справочнику пользователей с отбором по наименованию.

https://ИмяСервера/ИмяБазы/odata/standard.odata/Catalog_Пользователи?$select=Ref_Key,Description&$format=json;odata=nometadata?$filter=Description eq 'ИмяПользователя'

Поле, естественно, индексированное, но всё же отключаем и их. Тут добавлю интригу: догадываясь, что происходит, я попросил коллег не выключать совсем, а увеличить между запросами интервал, например, до 30 минут. И это сработало! Сервер перестал зависать.

Было бы абсурдом утверждать, что запросы по интерфейсу rest нельзя делать чаще, чем раз в полчаса, да я и не собираюсь. Прежде чем объяснить ситуацию, я хочу дать небольшую справку о том, как работает «типовой» менеджер памяти. Хочу отметить, что мои коллеги меня не поняли или просто не поверили в мои выводы. Мы настроили принудительный перезапуск dev-сервера каждую ночь, хотя я просил лишь «не беспокоить с 3 до 4 утра». Такие вот пироги...

 

Модель работы менеджера памяти

Здесь маленькое отступление: я не буду приводить конкретных цифр и вдаваться в нюансы работы определенных механизмов. Это не имеет никакого смысла. В данном контексте достаточно оперировать понятиями «маленькая» (ничтожно) и «большая» (значимая). Поскольку работу конкретных механизмов программы знает лишь их автор, мы будем пользоваться понятной нам моделью — «черным ящиком».

Реальность может быть совсем не такой, как в модели, но это не меняет сути. Менеджер памяти, как обладатель ресурса (большого облака свободной памяти), должен выделять блоки памяти любого размера по запросу, и далее по запросу освобождать их. Для выделения нового блока ему необходимо знать, какое место в облаке уже занято, а какое — свободно. Для этого при каждом выделении памяти менеджер заполняет соответствующую табличку, где фиксирует предоставленные области и их размер. Сама эта табличка, к слову, тоже требует выделение места в памяти. Было бы просто, если бы все выделяемые блоки имели одинаковую длину, но они все разные. Из этого следует, что при выделении каждого нового блока менеджеру памяти нужно обращаться к своей табличке в поисках свободного места (пока незанятого адресного пространства). И чем больше выделено блоков, тем объемнее табличка. Это первый момент, влияющий на скорость работы с памятью, а фактически, на скорость работы всей программы и даже целого сервера.

 

Где находится менеджер памяти?

Ответ на этот вопрос: везде. Операционная система отдаёт память платформе 1С по запросу, однако, если полагаться только на ОС, скорость будет очень низкой, так как выделяется огромное количество блоков памяти. Я предполагаю (или даже верю в это), что в самой платформе 1С также есть свой менеджер памяти, который получает от ОС большой блок памяти, а затем распределяет его по собственному усмотрению на внутренние нужды. То есть мы имеем два менеджера памяти — на сервере и на клиенте. Возможно, даже у каждой формы свой, и так далее... Тем не менее не играет роли сколько их и где они располагаются. Важно, что цель одна и схожи принципы работы.

Перем Строка, Параметры; // выделение памяти под переменную
 Строка = "Привет"; // выделение памяти для строки.
 Строка = "Привет Паша!"; // а также выделение памяти либо изменение размера блока каждый раз при изменении.
 Параметры = Новый Структура(); // выделение памяти под структуру
 МояФорма = ОткрытьФорму("МояФорма"); // выделение памяти. и на сервере, и на клиенте.
 Запрос = Новый Запрос(ТекстЗапроса); // выделение памяти для объекта
 Результат = Запрос.Выполнить(); // выделени памяти под данные
 ФоновыеЗадания.Выполнить("МоеФоновоеЗадание"); // выделение памяти под новый сеанс, а уже внутри него - все предыдущие случаи.

 

Освобождение памяти

Программируя на 1С, мы не задумываемся о том, когда нужно освобождать память. Эту функцию берёт на себя платформа. Об этом написано много статей. Вот несколько общих выводов о работе 1С и других платформ с памятью:

  1. Память освобождается не сразу после выполнения задачи, а позже, для некоторого пула блоков, так как это эффективнее. Например, после закрытия формы, завершения сеанса и фонового задания. Либо периодически запускается «Сборщик мусора». Хочу отметить, что здесь неважно, происходят действия на клиенте (формы) или сервере (фоновые задания и т.д.), поскольку процессы везде аналогичные.
  2. Платформа 1С (как и любая другая программа) ведёт учёт ссылок на каждый объект, чтобы понимать, что можно освобождать, а что — нет. Освобождение памяти, занимаемой объектом (структурой, массивом, запросом, формой, переменной, прочим), возможно лишь в случае, когда на него больше нет ссылок: удалены, ранее ссылавшиеся на объект переменные перезаписаны другими значениями и т.д.

3, 4 и 5-й выводы я опишу после примеров.

Перейдем к примерам:

// код на форме
 Параметры = Новый Структура("Строка", "Паша"); // переменная формы.
 ПараметрыПриложения = Параметры; // переменная модуля приложения.

В коде выше на объект «Структура» имеются две ссылки — в переменных «Параметры» и «ПараметрыПриложения». Соответственно, после закрытия формы (либо позже) при попытке освободить память «Структуры» и переменных освобождается память, занимаемая данными формы и переменной «Параметры». После закрытия формы они больше не требуются. Но на «Структуру» при этом остается ссылка в переменной «ПараметрыПриложения». Освободить занимаемую ею память можно будет позже, когда мы присвоим переменной другое значение или завершим сеанс программы целиком.

Рассмотрим еще один пример:

// Циклические ссылки
Листинг = Новый Массив();
Данные = Новый Структура();
Данные.Вставить("Листинг", Листинг);
Листинг.Добавить(Данные);

 Здесь, на первый взгляд, ничего «криминального» нет. На переменные «Листинг» и «Данные» ссылаются по одному разу. Они также ссылаются друг на друга. Если обе переменные являются переменными формы, то, казалось бы, при закрытии формы могут быть удалены. Возможно, в продвинутых менеджерах памяти так и происходит, но в общем случае нельзя удалить переменную «Листинг», пока существует «Данные», как и нельзя удалить «Данные», пока на неё ссылается «Листинг». Мы наблюдаем замкнутый круг под названием «Циклические ссылки». Обе переменные в итоге не будут удалены до окончания работы сеанса программы, соответственно, не будет освобождена занимаемая ими память. На сервере, да и где бы то ни было, ситуация аналогичная: циклические ссылки на локальные переменные в любой процедуре не будут удалены после выхода из процедуры.
Циклические ссылки не обязательно парные. Например, можно присвоить «Структуру» самой себе:

Данные = Новый Структура();
Данные.Вставить("Корень", Данные);

С точки зрения выполнения кода никаких проблем нет, но освободить память из под такой структуры будет непросто.

 Данные = Неопределено; // не получится, т.к. есть ещё ссылка.

К самой структуре уже доступа нет, а ссылка осталась.

Конечно, можно написать:

Данные.Удалить("Корень"); // удалится ссылка
Данные = Неопределено; // можно будет освободить память.

Но кто это будет делать? И кто вообще об этом вспомнит? Обычно, циклические ссылки незаметно появляются при работе с данными: в массивах, структурах, соответствиях и т.д. Их часто можно наблюдать в многоуровневых структурах, больших массивах. Например, это происходит, когда мы читаем пользователей из справочника и преобразовываем данные в структуру. Скажем, у нас есть «Руководитель» со списком подчинённых, который в структуре «замкнётся».
Один из самых некрасивых примеров циклической ссылки — присвоение переменной формы значение самой формы. А ещё хуже — передать её в другую форму.

ФормаОбработки = ЭтотОбъект;

Начиная с момента, описанного в примере выше, занимаемая формой память не может быть освобождена после закрытия формы, так как на неё ссылается переменная «ФормаОбработки».

 

Теперь вернёмся к выводам про освобождение памяти:

  1. Часть блоков, которые были выделены под одно общее дело (вызов процедуры, открытие формы и т.д.), не могут быть освобождены вместе с остальными. Но они могут быть освобождены позднее, например, после завершения сеанса.
  2. Запросы на выделение памяти происходят постоянно и сильно мешают процессу «сборки мусора», который не отличается быстротой. Отсюда следует пятый вывод.
  3. Менеджер памяти часто использует тактику отложенного анализа и освобождения блоков. Он выжидает, когда активность запросов на выделение новой памяти дойдет до нуля. В этот момент запустится анализ или «Сборщик мусора». Если в процессе появится запрос на выделение памяти, проведённая работа будет «выброшена», а менеджер станет ждать следующего подходящего случая.

 

Итоги. Что происходит на практике

Давайте подведем итоги. Мы выяснили, что из большого облака ресурсов постоянно выделяются маленькие блоки памяти. Часть из них освобождается, а часть — нет. Какое-то время они остаются «заблокированными». При этом что-то освобождается позже, а что-то — никогда. Проблема в том, что это мешает выделению новых блоков: каждый раз системе требуется анализировать таблицу занятых блоков и искать пространство, длина которого не меньше запрашиваемого. Когда такого «мусора» в памяти становится слишком много, поиск свободного подходящего места замедляет работу программы и сервера. При этом места заданной длины может просто не найтись, хоть и по общему показателю будет ещё очень много свободной памяти.


Здесь можно найти сходство с фрагментацией жесткого диска, но есть принципиальные отличия — файл на диске можно порезать на кусочки и положить в разные места, а с оперативной памятью так поступить не получится, поскольку нужен свободный кусок заданной длины.


Итак, пришло время раскрыть интригу

Я показал примеры кода из конфигурации, но то же самое справедливо и для самой платформы 1С. Поскольку система занимается обслуживанием запросов по rest-интерфейсу, часть выделенной ранее памяти не может быть освобождена в нужный момент и остаётся висеть посередине предоставленного ресурса.

После завершения сеансов менеджер памяти на платформе (а может и в операционной системе, что по большому счету неважно) делает паузу, выжидая снижения активности программы, а потом запускает длительный процесс — «сборщик мусора» для освобождения уже ненужных блоков памяти и реорганизации таблицы выделенных блоков памяти. Следующее соединение (rest-запрос) вынуждает отложить работу на потом. В нашем кейсе запросы приходили каждые 3–5 минут. В итоге «мусора» посреди большого ресурса становится всё больше, что и приводит к зависанию сервера.

 

Почему на prod такой проблемы нет? Там подобные запросы происходят не по расписанию, а по событию — определённым действиям на сайте. Интервал между событиями может быть как нулевой, то есть они идут друг за другом, так и больше, но «сборщик мусора», как правило, успевает нормально работать.

 

Все вышеизложенные выводы в статье сделаны на модели работы менеджера памяти в режиме «черного ящика».

Косвенным подтверждением модели может выступить обычное наблюдение за монитором ресурсов: с течением времени, после завершения работы программы или сеанса, показатели выделенной памяти у процессов rphost меняются. Медленно начинают освобождаться блоки, уходу которых мешали ссылки. Это может занимать как секунды, так и минуты. Затем процесс освобождения ускоряется, уходят большие блоки, иногда лавинообразно.

Раньше, лет 10–20 назад, может кто-то вспомнит, после закрытия программы некоторое время «шуршал» диск винчестера. Это был именно процесс освобождения памяти. У меня есть точное подтверждение этому, так как в то время я занимался разработкой на C++, и запуск программ под отладчиком четко показывал корреляцию между длительностью «шуршания» и количеством (не от объёма) выделенных блоков памяти.

Коллеги по работе в итоге мне не поверили (или не поняли). А вы верите? :)

Менеджер памяти Сервер 1С Зависание Выделение памяти Работа с памятью Память

См. также

Сервера Системный администратор Россия Бесплатно (free)

Основные критерии, на которые необходимо обратить внимание.

31.07.2024    2126    EFSOL_oblako    2    

0

Сервера Системный администратор Россия Бесплатно (free)

Цель данного исследования — сравнить производительность процессоров Intel и AMD при работе с 1С в виртуальной среде Hyper-V.

25.07.2024    4933    EFSOL_oblako    19    

3

Мониторинг Сервера Системный администратор Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

StartPlus и система контроля и сбора информации (настраиваем за час и пользуемся). Данное решение позволяет быстро собирать и анализировать различную информацию из разных источников данных (не обязательно серверов 1С). В любой момент можно менять состав сводной информации без сложной разработки на стороне 1С.

1 стартмани

18.07.2024    698    6    moolex    0    

5

Сервера Linux Системный администратор Россия Бесплатно (free)

Тема Ubuntu, PostgreSQL и 1С уже избитая. Но все же, следуя инструкциям всех мануалов, пришлось потратить около 3-х дней. И как результат — готовые скрипты для установки сервера 1С и PostgreSQL на свежей Ubuntu за 5 минут.

14.06.2024    3065    user1389975    13    

38

Мониторинг Сервера Системный администратор Программист Платформа 1С v8.3 Управляемые формы Абонемент ($m)

Размер, имя информационной базы из реестра кластера (файл 1CV8Clst.lst), дата последнего изменения файлов в каталоге баз (srvinfo\reg_*\uuid) центрального сервера. Отдельно показан размер индекса ППД (полнотекстовый поиск данных) и его актуальность. Полезна в случае, если у вас удалялись базы 1С и никто не озаботился удалением журналов регистрации.

1 стартмани

15.05.2024    1315    20    MaximSh    0    

7

Linux Сервера Системный администратор Платформа 1С v8.3 Абонемент ($m)

Сказ о том, как сделать "кошерный" запуск серверов хранилища конфигураций (вдруг еще кто-то до сих пор пользуется) и удаленного администрирования под GNU/Linux с использованием systemd

1 стартмани

07.09.2023    5743    Sloth    0    

24
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. webester 26 12.04.24 06:20 Сейчас в теме
Самая большая боль в этом тексте, что повлиять ты никак на это не можешь даже если понимаешь причины. И чего я так и не понял - если есть частые обращения к серверу по расписанию, то высока вероятность, что сборщик мусора работать не будет никогда? Выглядит как-то не очень правдоподобно.
manlak; amoarok; +2 Ответить
2. pbelousov 26 12.04.24 06:42 Сейчас в теме
Да, я уверен, что есть вероятность, когда при определенных условиях (которые нам неведомы), сборщик мусора не будет успевать отрабатывать. Вероятность непостоянна, иначе разработчики сразу бы это заметили и приняли бы меры к исправлению. Зависит от конкретного исполняемого кода, как и какие блоки памяти он запрашивает.

Нет, повлиять иногда можно! В статье, в нашем кейсе предложено решение: "ночной час тишины" с 3 до 4 утра.
А ещё об одном успешном случае, я собираюсь рассказать в докладе на предстоящей конференции, если конечно-же пройду туда отбор.
n_mezentsev; Дмитрий74Чел; +2 Ответить
3. user1559729 12.04.24 09:05 Сейчас в теме
(0) простите, но полстатьи про теорию освобождения памяти - такое себе...
а интеграция как быстро получает ответ по своему запросу (по всей видимости - в цикле по своему справочнику пользователей)? может имеет смысл интеграции для тестовой базы получать справочник полностью? а потом обрабатывать на своей стороне?
manlak; andshw; +2 Ответить
6. pbelousov 26 12.04.24 10:29 Сейчас в теме
(3) на тестовой базе "интеграция" ? вы шутите? коллеги пробовали обращаться к базе через odata, и не важно что они там делали. время от начала сеанса до завершения порядка 2-4 секунды. и, думаю, большая его часть уходит на инициализацию нового сеанса.
Тут важно само наличие большого количества соединений!
И кстати, у меня есть другой аналогичный кейс, но уже на сеансах фоновых заданий.
9. user1559729 12.04.24 11:33 Сейчас в теме
(6) признаюсь, я не очень в теме как оно там внутри работает, но зато мне интересно)
представим такой примитивный пример:
- вы работаете мастером, с определенной скоростью, и изготавливаете 20 изделий в час
- я прихожу к вам в начале часа и в течении 2-4-х секунд отдаю вам свой заказ на 50 изделий
- вам сложно мне отказать, и вы ставите заказ в работу
- через час я приношу новый заказ на 50 изделий
- и так - каждый последующий час...
Аналогия верная или нет?
11. pbelousov 26 12.04.24 12:16 Сейчас в теме
(9)

нет, не верно. вы здесь описываете совершенно другой случай, когда работа откладывается на потом, что в конечном итоге приводит к бесконечной очереди невыполненных заказов.

предложу верную аналогию:
Заказ вы выполняете почти сразу, и есть даже время прибрать своё рабочее место, стряхнуть пыль, и вынести в мусор ненужные отходы заготовок. но вы этого не делаете сразу, лень далеко ходить с пустой тележкой.
к концу дня, незаметно накапливается большое количество отходов, которые уже занимают всё свободное пространство. Вам уже труднее находить новые заготовки, они заставлены отходами. уже нужно потратить время, покопаться среди мусора. И наступит однажды момент, когда клиент уйдёт, не дождавшись ответа. Заготовку вы так и не найдёте. И желательно, закрыть контору на технический перерыв, чтобы взять тележку и вывезти весь мусор.
4. user673778_karavaykov 1 12.04.24 09:29 Сейчас в теме
Сначала подумал, что Вы "Тот Самый" Павел Белоусов
7. pbelousov 26 12.04.24 10:30 Сейчас в теме
(4) Спасибо! наверняка у многих есть "Тот Самый" Павел Белоусов :)
Но Я - это Я !
Andrei_Ivanov; +1 Ответить
5. muskul 12.04.24 10:11 Сейчас в теме
8. s22 22 12.04.24 11:29 Сейчас в теме
ф = ПроверитьЦиклическиеСсылкиВстроенногоЯзыка();?
10. pbelousov 26 12.04.24 11:53 Сейчас в теме
Да, это штука полезная. интересно, кто-нибудь пользовался?
в нашем же случае, мы убрали вообще весь код из конфигурации!
про циклические ссылки в статье - только в качестве одного из примеров, мешающих работе с памятью.
12. Vitaly1C8 12.04.24 18:45 Сейчас в теме
Конечно нет ! Хотя ... если dev сервер на Линуксе тогда я не знаю, - как на линуксе все устроено ...
А вот если на винде тогда ... надо бы знать, что проблемы со сборщиком мусора, это по-большей части проблема DOSa. В винде же используется "виртуальная память" тот самый файл подкачки. И каждый раз когда процесс выделяет память и ее не хватает, - сборщик не запускается ! Вместо этого просто увеличивается файл подкачки. (Это в общих чертах)
Поэтому никакого зависания процесса из-за сборки мусора быть не может. Зависание может быть если процесс выделит очень много памяти (больше чем физически есть на сервере) и будет эту память читать случайным образом, - вызывая подгрузку *превышающих физический размер памяти* блоков в оперативную память.
Утверждать что проблема связана со сборщиком мусора это на мой взгляд ... Пранк ?!
manlak; Созинов; +2 Ответить
14. siamagic 12.04.24 18:52 Сейчас в теме
(12)Файл подкачки даже на домашнем отключен, линукс тоже будет свопить если разрешить.
13. siamagic 12.04.24 18:50 Сейчас в теме
Можно пример кода который рест запросами ложился? Выглядит как оправдание криворуких. Пытался воспроизвести не получилось.
15. pbelousov 26 13.04.24 07:41 Сейчас в теме
(12) "файл подкачки" не наш случай. это несерьезно. может быть такое актуально для домашнего компьютера, когда нет возможности докупить память...
Я показал кейс, где свободной памяти в системе ещё больше, чем предостаточно, и выделенная rphost`ами память далека от своих же максимальных значений. Днём нагрузка на dev заметно выше. это команда разработчиков и аналитиков, каждый со своей копией базы, со своими запросами. И никаких проблем днём нет. Ночью же, нагрузка близка к нулю.
17. Vitaly1C8 13.04.24 09:39 Сейчас в теме
(15) Хотел мягко намекнуть ... но вы похоже не унимаетесь. Попробую еще раз.
Все что написано в абзаце Итак, пришло время раскрыть интригу, самый натуральный бред. Вы либо попросили чат-gpt написать это, либо не компетентны.

1. Когда такого «мусора» в памяти становится слишком много, поиск свободного подходящего места замедляет работу программы и сервера
до тех пор пока есть лишняя память - она просто выделяется мгновенно; (наличие свободной памяти Вы подтверждаете низкой загрузкой)

2. После завершения сеансов менеджер памяти на платформе (а может и в операционной системе, что по большому счету неважно) делает паузу, выжидая снижения активности программы, а потом запускает длительный процесс — «сборщик мусора» для освобождения уже ненужных блоков памяти и реорганизации таблицы выделенных блоков памяти.
Насколько это длительный процесс ? Допустим у нас 1 миллион фрагментов в памяти, - тогда сборка мусора это цикл от 1 до 1 миллиона (это долго ?) При этом, за счет того что память виртуальная, при освобождении фрагмента на диск в файл подкачки - НИЧЕГО не пишется (00 не записываются) Вся операция происходит в оперативной памяти. Оптимизируется только таблица блоков.

3. Все вышеизложенные выводы в статье сделаны на модели работы менеджера памяти в режиме «черного ящика».
С фига ли ? А можно астрологию использовать с тем же успехом !

4. Косвенным подтверждением модели может выступить обычное наблюдение за монитором ресурсов: с течением времени, после завершения работы программы или сеанса, показатели выделенной памяти у процессов rphost меняются. Медленно начинают освобождаться блоки, уходу которых мешали ссылки. Это может занимать как секунды, так и минуты. Затем процесс освобождения ускоряется, уходят большие блоки, иногда лавинообразно.
Это никак не подтверждает идею о том что это вызывает зависание, является критично долгим. Такое же наблюдение за Экселем при закрытии большого файла можно взять за основу ?! То что система освобождает память процесса обычное дело, фрагментация от rest - запросов это детский лепет по сравнению с фрагментацией которая возникает при простой работе винды, когда все время на постоянной основе выделяется и освобождается память.
starik-2005; +1 Ответить
23. pbelousov 26 13.04.24 17:46 Сейчас в теме
(17) вижу причину вашего непонимания. на холивар отвечать не буду, а вот ошибку в ваших рассуждениях обсудим.
вы считаете освобождение и выделение простым линейным процессом, я бы даже постеснялся такое заявлять.

давайте рассмотрим вычислительную сложность алгоритмов.
размерность N. вы предлагаете N = 1 000 000.
сразу скажу, что двоичный логарифм Ln(N) = 20.
выделяя блок памяти, вам нужно вести таблицу выделенных блоков для учета доступного свободного пространства,
и при каждом выделении - сначала смотреть в неё.
для размерности N вы пробежите по табличке тоже N раз. ваша вычислительная сложность получиться N * N / 2, а это уже миллион миллионов/2 , т.е. триллион (12 нулей) пополам или 500 миллиардов. эта цифра уже неподъёмна.

поэтому, вы приходите к необходимости сортировать эту табличку.
вычислительная сложность сортировки N*Ln(N). Это теория программирования, быстрее у вас не получится.

Иными словами, отбросив все остальные "сюрпризы", выделив уже 1 000 000 блоков, на каждый следующий вам понадобится минимум в 20 раз больше времени, чем на выделение первого!
это первый момент, и далеко не решающий.

второй момент, что ваша табличка будет "портиться" при каждой вставке и освобождении блока.
т.е. это уже не просто табличка, а вполне определенный механизм, функция, которая умеет вставлять/удалять данные в табличку за приемлемое время. если брать за аналогию код на 1С, то вставка всех строк в середину таблицы значений даст нам сложность N * N, т.е. снова 500 миллиардов. Вы можете даже это проверить.
В теории, мы опять же можем добиться сложности N*Ln(N).
На практике же, на моём опыте получалась сложность N * Ln(N) * Ln(N) т.е. миллион * 20 * 20.

следующий момент, это наличие таблички, которая хранит количество ссылок на уже выделенные блоки, а также кто на них ссылается. То есть, количество строк в ней будет M, уже заведомо больше, чем N. M>N.
Когда ссылок нет, блоки можно удалять, запустив процесс освобождения. сложность его будет K*Ln(N). здесь К - количество удаляемых блоков.

Но не нужно забывать, что табличка со ссылками у нас также меняется, и после удаления одних блоков, количество ссылок у других уменьшается, и в какой-то момент они также становятся доступны для удаления.
Бегать по таблице ссылок мы также можем со сложностью M*Ln(M).
Но бегать приходится несколько раз! после каждого прохода (Итерации), появляются новые блоки к удалению, и их нужно снова найти.

Хорошим примером итерационного поиска будет игра в Сапёра. здесь на каждом шаге (итерации) появляются новые данные, мины. Важно, что количество шагов мы сразу никогда не знаем!

Также, пробегая по табличке ссылок, мы вполне можем получить ситуацию, когда после каждой итерации мы находим только 1 новый блок, потом ещё 1, ещё и так далее.
Это самый неудобный случай, Вычислительная сложность в этом случае вырастет до M * M * Ln(M).
Вспоминаем, что M>N, и получаем уже не 500 миллиардов, а несколько триллионов операций.

я пишу не статью, а всего-лишь комментарий.
я показал, что каждый запрос по памяти, будь то выделение или освобождение,
может при определенных условиях тратиться время сравнимое с квадратичной функцией, а это уже неприемлемо.
первый раз делаем шаг, на сотый раз делаем 100*100 шагов!

Могу порекомендовать к прочтению книгу Дональда Кнута "Искусство программирования".
Подумываю написать статью на хабре, уже с техническими подробностями, понятными профессионалам.
В сообществе 1С, к сожалению, тема вычислительной сложности алгоритмов непопулярна от слова совсем.
16. pbelousov 26 13.04.24 08:03 Сейчас в теме
(13) Даже одна строчка кода, типа " А = 0; " автоматически делает автора виновным во всём :)

Мы воспроизвели ситуацию, когда отключили вообще весь код в конфигурации.
Я же написал об этом в статье, а примеры только для понимания, для объяснения модели.

Более того, rest-интерфейс обслуживается исключительно платформой 1С,
без вмешательства конфигурации.

Я немного удивлён, что никто до сих пор не предложил сменить релиз платформы. Признаюсь, я не проверял этот кейс на других релизах. И не считаю это ни криворукостью, ни багом, ни проблемой конкретного релиза.

Ещё давайте вспомним, что когда мы даём передышку раз в сутки, то сервер без проблем работает ещё сутки!
и на prod под нагрузкой такой проблемы нет, хотя в пике и по несколько в секунду бывает.
19. siamagic 13.04.24 12:07 Сейчас в теме
(16) "Более того, rest-интерфейс обслуживается исключительно платформой 1С,
без вмешательства конфигурации. " верно поэтому и прошу направление на повтор.


"Я немного удивлён, что никто до сих пор не предложил сменить релиз платформы" я посчитал, что на проде такое же как на деве, к решению "там обращение было иногда а тут каждые 5 минут" отношусь скептический, годами работал инет магазин который напрямую таскал данные с прода - всё было тип топ, пока посещаемость не стала более 10 тыщ в сутки, сделали прокладку, она периодический таскала, опять всё хорошо.


Возможно действительно глюк платформы ну мне кажется дело в среде разработки.
21. pbelousov 26 13.04.24 16:45 Сейчас в теме
(19) я, кстати, не утверждаю что так будет всегда, "если делать запросы каждые N-минут".
просто звёзды так сошлись, что у нас эта проблема появилась, а также появилась реальная возможность поисследовать, выдвинуть гипотезы и их проверить.
18. JohnyDeath 302 13.04.24 12:02 Сейчас в теме
Мне кажется, что проблема скорее всего больше в odata, а не в том, о чем написано в статье.
Попробуйте написать свой http-сервис, который вернет элементы справочника пользователя по входящему фильтру наименования. И попросить коллег, чтобы они чутка поправили адрес запроса.

Из статьи не понял, кончается в итоге память или нет. Или вы хотите сказать, что свободной памяти еще вагон, но сервер зависает из-за того, что пытается запустить сборщик??
manlak; Дмитрий74Чел; +2 Ответить
20. pbelousov 26 13.04.24 16:41 Сейчас в теме
(18) Да. свободной памяти ещё вагон.
Да, зависанию всегда предшествует замедление работы, затем резкое замедление работы.
Да, если дать отдых, и следить в мониторе за rphost, то увидим растянутый во времени процесс постепенного освобождения памяти.
Да, он прекратится сразу, если снова включить запросы. Но зависания уже не будет, либо будет позже.

на чем конкретно зависает можно только догадываться. На основе своего опыта (а мне пришлось однажды писать свой менеджер памяти, и обслуживать до 100 тыс. блоков памяти) предполагаю, что сборщик всё-же запускается, но не успевает отрабатывать, не делает никакой полезной работы, т.к. неожиданно приходит новый запрос на выделение.
Также табличка, в которой хранятся адреса выделенных блоков, - если она была в процессе реорганизации (сортировки), становится несортированной, и найти в ней свободное место просто сравнением двух соседних записей - уже не получится, придётся искать по всей большой таблице... и т.д.
На самом деле тут можно и отдельную статью написать, но уже не в сообществе 1С.

вкратце моё предположение в том, что невозможностью распорядиться имеющейся памятью в связи с невыполнением регламентной процедуры - "сборщика мусора" и сортировкой учетных таблиц.
22. XAKEP 13.04.24 17:34 Сейчас в теме
кроме памяти у сервера имеется
сетевой интерфейс, процессор и дисковая система
и они не менее важны.

вы же "нашли крайнего" , причем не того.

если ваша система работала "на плаву" , то чуть больше нагрузки
на тестовой базе положило всю систему.

никаких данных ни о серваке ни о железе.
JohnyDeath; +1 Ответить
24. pbelousov 26 13.04.24 17:55 Сейчас в теме
(22) нет, не на плаву :)
наступает день, и нагрузка возрастает в сотни раз.
так что не могу никак согласиться с версией, что нагрузка его положит.

Наш кейс тем и замечателен, что по факту проблема идёт на минимуме активности.
иначе мне было бы даже неинтересно писать про какие-то банальные вещи.

про железо не подскажу, я разработчик, не админ.
25. XAKEP 13.04.24 19:07 Сейчас в теме
(24)
т.е вы даже на спрашивали админа, в чем причина такого поведения ?
может он ограничил ресурсы для вашего сервиса
или в тот час происходили другие тяжелые процессы в системе.


Но! Когда мы долго наблюдали за числами памяти по rphost`ам, заметили, что они скачут, а значит есть какая-то активность. Другим открытием стало следующее — часть выделенной памяти со временем не освобождается

а может все-таки к админу !!!!
JohnyDeath; +1 Ответить
26. siamagic 13.04.24 19:38 Сейчас в теме
(25)Что админу делать на сервере дев? ))))

Обычно под дев берут мега машинку от пяти герц с ддр5 и проги играются, на вм сидеть позорно как-то учитывая что туда берут хламные серваки которые даже не для этого ))))
28. pbelousov 26 13.04.24 20:14 Сейчас в теме
(26) не совсем понял ваш вопрос.
к сожалению, сейчас не могу посмотреть конкретную конфигурацию.
у меня просто нет на это доступа, я разработчик 1С.
но могу позже спросить. не знаю чем это вам поможет.

Соглашусь, что это мой промах, т.к. вижу по вашим комментариям, что вы представляете себе
какой-то "полудохлый пыльный ящик с одной плашкой дешёвой памяти"
нет, это не тот случай :)
когда пара десятков разработчиков, плюс аналитики, держат по несколько копий баз 1С
на нём, это точно не "хлам". как устроена виртуализация, я не разбираюсь, не моё, не подскажу.
Большую нагрузку все сервера держат прекрасно. Численность компании нетрудно прогуглить,
так что "хламные серваки" это не наш случай.

ещё раз обращу внимание, что интерес нашего кейса в том, что проблематика проявлялась не на пике нагрузки, а как-раз на её отсутствии.
29. JohnyDeath 302 13.04.24 23:13 Сейчас в теме
(28)
ещё раз обращу внимание, что интерес нашего кейса в том, что проблематика проявлялась не на пике нагрузки, а как-раз на её отсутствии.

и именно поэтому виноват менеджер очистки памяти? что-то как-то не вяжется совсем.
Повторюсь, попробуйте переписать этот сервис с одаты на http-сервис. И да, желательно посмотреть что еще в это время работает параллельно на этой машине. Не удивлюсь, если это какой-нибуль корпоративный касперский делает полный скан машины раз в неделю в это время
32. pbelousov 26 14.04.24 12:53 Сейчас в теме
(29)
(29)
пробуйте переписать этот сервис с одаты на http-сервис.

а что вы от этого желаете получить? кстати, вы сами у себя можете попробовать и так и так, и сравнить.

кстати, там есть механизм, когда предыдущая сессия не завершается сразу, а определенное время ждёт следующего http-запроса. ой неспроста это. и очень коррелирует с выводами моей статьи.
всё-таки создание/завершение сессии, это относительно тяжёлая операция.

Причем здесь менеджер памяти - моя версия, основанная на моем прежнем практическом опыте (а я реально писал менеджер памяти на c++, когда стандартные функции перестали справляться (calloc, malloc, free)), идеально ложится на ВСЕ те симптомы, которые мы имеем, и которые я описал в статье.
можно со мной согласиться, можно нет.

все другие версии, которые мне довелось услышать, подходят под какой-то один симптом, игнорируя все остальные.

Версия про антивирус просто фантастическая...
при нашей то численности, когда в отделе администрирования я даже не всех знаю,
когда круглосуточно идёт мониторинг всего, есть ночной дежурный...
и даже если что-то случится, пользователи могут даже не узнать об этом, т.к. все успеют поправить.
в такой системе просто невозможно что-то запустить, повесить один из многих серверов, и чтоб никто не заметил.
27. pbelousov 26 13.04.24 19:44 Сейчас в теме
(25) Да, я не спрашивал админа.
я занялся исследованием аномалии уже после того,
как отдел разработки активно с отделом администрирования
предположили и проверили всё что можно;
Согласовал с директорами, что хочу заняться исследованием,
получил доступ к монитору, но не к администрированию сервера.
30. XAKEP 14.04.24 08:25 Сейчас в теме
(27)
мониторить нужно все :
сетевой интерфейс, процессор, диски (!) , не диск ,

ну и память, которую вы "обвинили"
31. pbelousov 26 14.04.24 12:26 Сейчас в теме
(30) этот этап уже был пройден. я же ответил вам.
33. Segate 239 15.04.24 07:25 Сейчас в теме
Прочитав статью, я так и не понял, что же конкретно виснет.

Сервер 1с- компьютер?
Сервер 1с - служба?
Сервер 1с - рабочий процесс?
Сервер 1с - менеджер кластера?

Налицо абсолютное непонимание как работает сервер приложений и отношение к нему как к магической коробке, а ведь это совсем не так.

Что конкретно висло-то?
34. pbelousov 26 15.04.24 07:57 Сейчас в теме
(33) в нашем кейсе "Сервер 1с- компьютер".

сейчас в любой крупной компании четкое разделение, кто чем занимается,
и разработчики 1С редко имеют доступ даже к консоли серверов 1С,
не говоря уже о том, чтоб зайти на сервер 1С "Компьютер",
тем более на Sql-сервер "компьютер".

так что статья написана на понятном большинству языке. кто спрашивает подробности, я детально отвечаю.
DmitryKSL; +1 Ответить
35. Segate 239 15.04.24 08:26 Сейчас в теме
(34) то есть у вас не было доступа к серверу? А почему вы решили, что вис именно компьютер.
И что значит "вис" к нему полностью пропадал доступ? Как вы это выяснили, если у вас не было к нему доступа?

Меня интересуют технические подробности. Какая диагностика конкретно сервера проводилась?
36. pbelousov 26 15.04.24 08:56 Сейчас в теме
(35) У нас есть замечательный отдел администрирования!
они следят за инфраструктурой 24/7.
и мне, как разработчику 1С, совершенно неинтересно лезть в их работу.

я на практике показал коллегам, как обойти проблему,
таким образом доказав невиновность аппаратной части.

просто есть ряд симптомов! а всякие версии про сбои, антивирус, "дохлый комп" напрочь игнорируют все эти симптомы.
пока других версий, объясняющих ВСЕ симптомы, описанные в статье - не было предложено никем.
37. Segate 239 15.04.24 09:03 Сейчас в теме
(36) Смотри, навскидку:
На тесте у вас используется Sqlite-формат ЖР, а на проде файловый.
При определенном стечении обстоятельств запись в такой журнал - встает в ожидание на блокировках, что в какой-то момент вешает работу процесса rmngr. что приводит ровно к вашим симптомам. Работа с БД журнала деградирует и сначала это выглядит как замедление" а потом все встает колом.
т.е. любое обращение к ЖР(а это почти любое действие в рамках кластера) повисает в ожидании

Это только один пример, могу еще таких же "телепатически-обусловленных" накидать с десяток.
38. pbelousov 26 15.04.24 09:40 Сейчас в теме
(37) Примеры, это хорошо. давайте.
только просьба, не игнорируя все симптомы.

записей всего 3. Создание сеанса, аутентификация, и Завершение сеанса.
ещё и в разных секундах. прям вешает.
а днем, когда весь отдел разработчиков что-то делает, проблема куда-то исчезает?
а ведь там записей и под сотню в секунду может быть.

и проведение документов в несколько потоков (12) прекрасно работает. уж там то должны быть "ожидания блокировок"?
когда по 20 документов в секунду проводятся?

вы серъёзно?
39. Segate 239 15.04.24 09:50 Сейчас в теме
(38) да, я серьезно. Менеджер кластера может так же поставить на колени не запись, а чтение. И тогда у вас будет ровно 0 записей.

но суть то не в этом, я просто привел исключительно на кофейной гуще нагаданную гипотезу, и вы ее "размели в пух и прах".

Я к тому, что техническое расследование - не должно содержать в себе предположений по его окончанию.
Благо, для большинства процессов пишутся логи(Не ЖР), и можно например собрать дамп.

А когда выясняется, что в качестве решения вы предложили "дать серверу отдохнуть" при помощи рестарта или просто паузы в работе, попутно объяснив это некоей магией сборщика мусора, на который вы никак не можете повлиять" - это не уровень технической статьи, это уровень доктора из анекдота.

"- Доктор у меня вот тут болит если надавить!
- А если не давить?
- Если не давить, то не болит.
- Ну так и не давите, с вас 5 тыщ"
user1559729; DmitryKSL; XAKEP; dlyubanevich; +4 Ответить
40. pbelousov 26 15.04.24 11:11 Сейчас в теме
(39) слышал я ваш анекдот. таксист рассказывал, он немного разбирается в компьютерах...

в журнале регистрации всё идеально: память выделяется, выделяется, выделяется.
прям до самого зависания.
и как-то никто не смог заметить что за последние 10 минут постепенно увеличиваются интервалы между запросами.

"дать серверу отдохнуть", а конкретно: "прекратить на время новые соединения" подтверждает версию, что дело в памяти. я писал об этом, смотрим как начинают пытаться высвобождать память rphostы. Этот процесс растянут во времени, и это время больше, времени до следующей активности в нашем кейсе.

также я вам уже ответил, что наши админы свою работу уже выполнили.

у вас рабочих версий нет? только анекдоты?
41. Segate 239 15.04.24 11:22 Сейчас в теме
(40) мои "рабочие версии" обычно строятся на логах и дампах.

Дайте на анализ хоть что-то кроме "наблюдений за циферкой" - и будет рабочая версия.

А так - гадание на кофейной гуще...
я спорю, что дело не в мифическом "менеджере памяти" с вероятностью 99%.

Моя последовательность действий была-бы такова:
1) Собрать ТЖ и проанализировать его(у вас написано что вы его проанализировали, но потом "ВНЕЗАПНО" увидели http-Соединения. Как можно было их не заметить при анализе ТЖ - загадка)
2) Выяснить какое конкретно приложение повисает.
3) Собрать дампы при зависании и посмотреть содержимое памяти
4) Если виснет рпхост - ковырять конкретный 1с код, на котором виснет процесс(понять это можно по ТЖ конкретного процесса)
5) Если виснет менеджер, то понять какой сервис вешает менеджер(Для этого из простого есть галка "менеджер под каждый сервис")
6) Работать с конкретной фактурой.

Как я понимаю, ничего из вышеперечисленного сделано не было, так?
42. pbelousov 26 15.04.24 11:39 Сейчас в теме
(41) "в журнале регистрации всё идеально:"
заговорился, сорри. конечно же в технологическом журнале.

а вы игнорите даже то, что "кода вообще не было". а ведь так удобно свалить на код? даже на одну строчку кода.
этим и примечателен rest-интерфейс, что обслуживается платформой без нашего участия.

виснет весь "компьютер", уже забыли?
что аппаратные проблемы имеют тенденцию повторяться, вас не смущает? жаль.
а вот как раз программной частью, можно управлять, и смотреть, что изменилось.
что за фактура, откуда взялась?

Хорошо, давайте лучше анекдот.
43. RustIG 1728 15.04.24 13:58 Сейчас в теме
про выделение памяти в опер. системе виндоус на языке С или С++ можно почитать про функцию malloc().
Платформа 1с написана то ли на VС++, то ли на Ява, в общем память под каждую переменную выделяется.
Освобождается память также согласно алгоритмической логики - где-то разработчик следит за освобождением памяти, где-то сама опер. система виндоус следит за этим - есть у нее определенный механизм.
Физически память находится в регистрах памяти. Может использовать физический диск - служебные сектора.
Но это все не имеет значения для озвученной проблемы.
У вас тестовая база была ОПУБЛИКОВАНА на веб-сервере?
Если да, то поиск с этого и надо было начинать - запросы из-вне сложно отследить. Отключаете публикацию на веб-сервере - и зависание прекращается.
Бывают зависания наоборот по причине что из 1с идут запросы на сервис, который не возвращает нужный ответ.
44. pbelousov 26 15.04.24 15:13 Сейчас в теме
(43) про выделение памяти: вы пробовали получить от системы миллион блоков разного размера?
да ещё рандомно возвращать вперемешку с выделением следующих.
аж захотелось проверить ещё раз, а то вдруг прогресс скакнул вперёд, а я не знаю.

из моего прошлого опыта, - просто встанет колом. первое что захочется сделать в этом случае, это брать от системы большие блоки памяти, и раздавать их внутри самому, разделяя их на мелкие. Иначе Также, за количеством ссылок на вашу память (ваши переменные) система следить никак не может. это внутреннее дело вашей программы, платформы, и т.д.
Про вычислительную сложность этих двух задач я уже отвечал "комментаторам". Это N*Ln(N) в лучшем случае, с вероятностью получить N*N и более. для миллиона блоков, это от 20 миллионов шагов до триллиона, что мы и видим в редких случаях при "удачном" стечении обстоятельств.
И даже неважно, кто этим занимается, ваш код, библиотеки C++, или система. На практике, все вместе.

про публикацию - "капитан очевидность" :)
не будет соединений, не будет проблем.
думаю, ещё надёжней - вообще выключить :)
46. RustIG 1728 15.04.24 19:11 Сейчас в теме
(44) я не думаю что память здесь участвует - к 1с идет запрос - она возвращает не ссылку на переменную (не адрес в памяти) а некий результат, который сайт должен корректно обработать.
Сайт запрашивает данные каждые 5 секунд, 1с отвечает каждые 10 секунд - возможно сайт "сыпится"... Между сайтом и 1с пакеты теряются...Ускорьте обработку 1с для сайта - для проверки просто возвращайте Истину, а не пользователя... А сайт пусть также обращается к 1С каждые 5 секунд.
Вообще не очень понял ваш пост, и в целом статью.
DmitryKSL; dlyubanevich; +2 Ответить
45. DENSKR 16 15.04.24 17:09 Сейчас в теме
«сборщик мусора», как правило, успевает нормально работать


Вот тут я бы наверное добавил "или присутствуют дополнительные условия для того чтобы он успел нормально отработать"...

У меня была большая проблема ежедневного зависания сервера 1С, ничто из базы, никакие сервисы или же фоновые задания кроме самого сервера 1С не грузило систему. В определенный момент опустив руки я по какому то наитию запустил режим восстановления ОС с помощью dism, подкинув образ исходной системы без обновлений и вуаля - 3й год сервер работает без каких либо проблем(обновления отключены сервер без интернета), в чем была причина так и не разобрался, в силу того что по восстановленным компонентам не было ничего что могло бы мешать работе сервера 1С, сбоев до этого не было в тех компонентах которые были восстановлены, обновлений сервера тоже не было, только устанавливаемые фрамворки для работы программ, из программ - MSSQL и 1С..
47. user1950534 16.04.24 09:26 Сейчас в теме
Ну а всё таки, симптоматика такого переполнения памяти какая? Утилизация ОЗУ под 90%? Какие-то сообщения в виндузовом может быть журнале приложений?

У нас написана например на ERP 2.4 система выгрузки в xml отчетности для клиентов. Файлы мегабайт по 5-8. В среднем тысяча запросов в сутки. Сделано через очередь, которая обслуживается фонами. Внутри да, там и запросы гигантские пакетов по 30-40 есть, и не скрою греха, пара тройка объемных таблиц значений. Фон отрабатывает и пишет результат в файл, что приклеивается в регистр сведений. Может при таком подходе переполняться та самая "память", и как это отследить? По идее, следуя логике сказанного выше, сборщик мусора отрабатывает (должен отрабатывать) в рамках каждого фонового процесса по своему. Или нет? Вообще заявка на неэффективную очистку памяти механизмами 1С - очень серьезная, и означает по сути массу ограничений, включая например запрет на использование платформы в качестве бэка для внутреннего портала через rest-запросы, да и много чего еще. Хотелось бы конечно услышать "официалов" по данной тематике
48. pbelousov 26 16.04.24 09:43 Сейчас в теме
(46) Да, вижу что не поняли, и вообще не читали.
Статья о том, как завалить сервер 1С, или сделать ему плохо, вообще не имея никакого кода.
а также о том, как этого избежать.
49. pbelousov 26 16.04.24 10:00 Сейчас в теме
(47) Ещё раз про симптомы.

1. нарастающее замедление работы перед проблемой. будь то зависание как в нашем кейсе, либо другой случай был, шло фоновое проведение, и часов так через 5 - вылет по странной ошибке типа "нет прав". при том, что под полными правами, и до этого всё было гуд. далее автоматическая перезагрузка рпхостов и дальнейшая нормальная работа. да, тут случай похожий, но иной. тут мы роем фоновых заданий добились переполнения по памяти. Симптомом было замедление. при среднем времени проведения документа пол секунды, последние документы перед сбоем проводились по 30-60 секунд. точнее, это время на создание фонового задания под них (смотрим на журнал регистрации). Номера сеансов у нас доходили до 5тыс.

2. возможность не допустить сбой! в нашем кейсе, после старта в 10 утра, зависание в 4 утра, через 42 часа. если кардинально, с вечера блокируем новые сеансы, тупо на час, то следующий день работаем без проблем.

3. вероятность проявления такого симптома непостоянна. как звёзды сойдутся. Например сейчас, на том же сервере, мы уже не можем воспроизвести этот случай.
50. pbelousov 26 16.04.24 10:18 Сейчас в теме
(47) ах да, про самое главное забыл.
время активности, в течении которого рпхосты освобождают память после окончания сеанса, - больше времени начала следующего сеанса. проверяется просто, блокируем новые соединения, и смотрим в монитор производительности.
Писал же в статье, сначала тишина (пауза), затем по чуть-чуть, затем чаще и быстрее...

можно бесконечно долго смотреть, как горит огонь, как течёт вода, и как освобождается память :)
будь то сеанс в 1С, либо любая другая программа после завершения.
51. user1950534 16.04.24 10:32 Сейчас в теме
(50) ну в общем-то обычные симптомы замирания/умирания кластера. Ничего эдакого.... У нас, к примеру, где-то 20 фонов роют обмен с внешними ресурсами. Так вот, когда внешние ресурсы вдруг ложатся (а как мы знаем http-сервисы могут не просто лечь, а начать таймаутить с определенными таймаутами), то начинаются похожие симптомы. Да, мы проверяем фоны что такой уже не запущен. Да, мы уменьшаем таймауты до приемлемых значений. Но - ничего из этого не помогает. Нагрузка на кластер начинает расти лавинообразным образом. Юзеры перезапускают клиентов, растет количество сеансов и привет ж...па новый год. Сделали фишку, админ сидит выключает фоны если что-то вдруг там с обменами не то. А так - всё полностью аналогично тому, как Вы это описываете.
52. pbelousov 26 16.04.24 10:53 Сейчас в теме
(51) у вас когда они ложатся? по расписанию?
53. user1950534 16.04.24 11:54 Сейчас в теме
(52) по расписанию, да. Ибо http-сервисы ложатся по своему там какому-то расписанию. Где-то в 15:45-16:00 по будням)
54. pbelousov 26 16.04.24 13:11 Сейчас в теме
(53) осталось только обратить внимание на выделенную рпхостами память за последний час.
55. Somebody1 69 18.04.24 13:49 Сейчас в теме
Кейс интересный. Но я хотел сказать чуть о другом. Всё изложенное в статье — следствие интеграции двух систем через "тянущий" интерфейс (pull). Построение интеграции на принципе "толкающего" интерфейса (push) позволяет делать нагрузку на систему более контролируемой. Подробнее описано тут: https://infostart.ru/1c/articles/792952.
56. starik-2005 3080 26.04.24 23:24 Сейчас в теме
Я предполагаю (или даже верю в это), что в самой платформе 1С также есть свой менеджер памяти...
Имеет.
И было время, для линуха можно было использовать тот менеджер памяти, который захочеццо.
В остальном бред.
57. booksfill 08.05.24 12:11 Сейчас в теме
В нашем кейсе запросы приходили каждые 3–5 минут

Т. е. получается, что у менеджера памяти был запрограммирована сценарий - ничего не делать, пока не наберется записей более, чем на 3 минуты работы для освобождения/дефрагментации, а потом ничего не делать т.к. за 3 минуты не успели?

При этом, когда идет обычная работа, в которой сервер обрабатывает множество запросов в эти же 3 минуты, все лечится, т.к. ночью у рабочего сервера появляется окно минут на 30 и тут сборщик мусора каак принимается все чистить?

Странно все это, такую ошибку в менеджере можно сделать только специально.

Да и алгоритм работы сборщика какой-то странный - начерта ему делать все в одной транзакции и если придет запрос на выделение памяти все откатывать? Чудно как-то.
Оставьте свое сообщение