|
Утечки памяти на сервере приложения 1С
Цель исследования
Определиться с алгоритмом и подходом поиска этих ошибок, минуя данные технологического журнала.
Сразу отметим, в рамках данного исследования не предполагается демонстрация основных ошибок, связанных с утечками памяти, а определяется алгоритм и подход для поиска этих ошибок.
Суть проблемы
Наверняка многие разработчики и эксперты по технологическим вопросам сталкивались с проблемой утечки памяти сервера приложения, падения процесса rphost.exe. Почему при этом процессы не отдают операционной системе освободившуюся память? Данная проблема особенно проявляется при достаточно большом количестве пользователей 1С.
Все уповают на разработчиков платформы, на «глюки» системы и прочие причины. Предлагают различные классификации ошибок (логические, платформенные). Но как разобраться к какому классу ошибок относится ваша конкретная ситуация? Как правило, единственно доступным механизмом 1С является сбор событий технологического журнала и их последующий анализ. Но в данном материале мы расскажем об альтернативном методе поиска причин утечек памяти, тем более что буквально совсем недавно мы столкнулись с подобной проблемой – на масштабном проекте внедрения 1С8.2 информации от технологического журнала было недостаточно, да и его сбор вносил большую нагрузку на систему в целом.
На следующем рисунке показаны два графика, которые отражают уменьшение свободной оперативной памяти на сервере приложения 1С. Был установлен факт, что уменьшение памяти обусловлено исключительно потреблением ее процессом rphost.exe. Поэтому абсолютно правомерно объяснять ситуацию именно на нем.
На верхнем графике мы видим уменьшение памяти равными долями (3,7 Гб), поэтому график напоминает ступени лестницы. Для поиска причин пришлось воспроизвести все действия пользователей за интервал, и оказалось, что причиной данной ситуации явился неправильный тип в одном из реквизитов составного типа. Таким образом, при открытии элемента справочника с неправильным типом сервер приложения менее чем за 1 секунду потреблял более 3 Гб. При этом у пользователя не возникало ошибки, и он продолжал работать.
Данную ситуацию легко отслеживать, выполняя «Проверку логической целостности». Если она настроена в режиме «Тестирование и исправление», то проблемный элемент будет удален. Поэтому, по возможности этот режим можно использовать, в крайнем случае, но с предварительной проверкой на резервной копии.
На нижнем графике видно, что память уменьшается постепенно, из этого можно сделать вывод, что с большой вероятностью проблема происходит на определенной операции пользователя. Требуется лишь найти эту операцию и, позже, смоделировать ситуацию на тестовой базе данных.
Для поиска проблемы сервер приложения 1С8.2. предоставляет возможность безопасного отключения от требуемого rphost сеансов и переброску их на другой процесс rphost. Таким образом, если rphost не прекращает потребление памяти, то на нем останется только тот (или те) сеанс, который привел к этому потреблению.
В заключение хочется отметить, что для правильной интерпретации и решении проблем утечек памяти сервера приложения 1С требуется понимать динамику потребления памяти за некоторый промежуток времени.
Вы можете самостоятельно воспроизвести проблему, используя следующую инструкцию ->тут<-
Обработку по потреблению памяти можно скачать ->тут<-
Выводы
Выполнение «проверки логической целостности» в режиме «тестирование и исправление» рекомендуется проводить в крайних случаях, но с учетом предварительной проверки на резервной копии базы данных. Рекомендуется делать сначала только тестирование.
Также нельзя ограничивать себя только данными технологического журнала 1С и «бесконечными» письмами в поддержку. Можно по определенным признакам определять вероятную проблему и выбирать для ее решения и идентификации нужную методику.
Специфика работы сервера приложения 1С8.2. и «тонкого» клиента 1С
Данное исследование не претендует на всеобъемлющее описание «тонких» клиентов 1С и их взаимодействие с сервером приложений, а лишь раскрывает некоторые особенности.
Цель исследования
Краткое введение в специфику взаимодействия сервера приложения 1С8.2. и «тонкого» клиента.
Описание проблематики
Программисты и администраторы 1С по-разному представляют это взаимодействие. С одной стороны им конечно понятен смысл разработки фирмой 1С «тонкого» клиента (масштабируемость, отказоустойчивость, отсутствие больших требований к программным и аппаратным ресурсам), с другой стороны для многих само взаимодействие – «черный ящик».
В коде 1С активно используются директивы вида &НаКлиенте, &НаСервере, &НаСервереБезКонтекста, которыми, в соответствии с функционалом, программист управляет вызовы процедур и функций.
«Тонкие» клиенты 1С (далее – ТнКл) устанавливают связь с сервером приложения посредством TCPIP и Socket. По организованному каналу связи ТнКл отправляет и получает пакеты от сервера приложения 1С, этим они полностью напоминают «толстых клиентов 1С. Так в чем же принципиальная разница?
Пакеты, отправляемые и получаемые ТнКл 1С представляют из себя xml–пакеты (пример на следующем рисунке).
Данный xml–пакет можно получить, если перехватить трафик между ТнКл и сервером приложений. Отсюда и вытекает основная разница между «тонким» и «толстым» клиентом 1С.
Таким образом, «тонкий» клиент уже больше имеет сходства с веб–клиентом, который имеет аналогичный протокол обмена с сервером приложения 1С. Отсюда и отказоустойчивость при потере связи, и масштабируемость.
На следующем рисунке представлен пример взаимодействия между ТнКл и сервером приложения 1С.
На рисунке показан только один пример взаимодействия между ТнКл и сервером приложения 1С. Но по нему уже можно догадаться, что кроме непосредственно кода логики 1С в конфигурации, сервер приложения значительную часть ресурсов тратит на разбор и создание xml–пакетов.
При большом количестве пользовательских и регламентных операций количество отправленных/полученных пакетов может быть очень большое, и дополнительная нагрузка на их обработку соизмерима или больше длительности непосредственно операций 1С. Поэтому при разработке кода 1С на ТнКл повышенное внимание необходимо уделять клиент-серверному взаимодействию. Рекомендации по оптимальному написанию кода выпущены фирмой 1С и ее партнерами в достаточном количестве.
В крупных проектах внедрения 1С8.2, даже с учетом рекомендаций по разработке кода 1С, мы столкнулись с необычными явлениями, но об этом в следующих разделах.
Выводы
При разработке кода 1С на «тонких» клиентах 1С мы рекомендуем уделять повышенное внимание клиент-серверному взаимодействию, согласно рекомендациям фирмы 1С по оптимальному написанию кода.
Деградация производительности при работе с «тонкими» клиентами 1С
Описание исследования
Специфика взаимодействия сервера приложения 1С с тонкими клиентами вносит свой вклад в длительности выполнения команд. Зачастую, длительное время выполнения операций 1С не зависит от загрузки ресурсов или параллельной работы других пользователей 1С. Для демонстрации этого была создана обработка, основной целью которой было открытие и закрытие формы одного и того же документа и замер времени выполнения этой незамысловатой процедуры. Фрагмент кода представлен на следующем рисунке:
На сервере приложения 1С не включен технологический журнал, есть большое количество свободной оперативной памяти и ресурса CPU. На нем запускается исключительно один процесс с обработкой.
После анализа статистики длительностей этой операции получены следующие данные:
На первом рисунке представлены все данные, а на втором – только длительности менее 2 секунд. При этом средняя длительность около 1,5 секунд (далее матожидание).
На что следует обратить внимание:
• На первом рисунке отчетливо видно, что значительные (до 9 секунд) отклонения длительностей от матожидания. Периодичность этих отклонений каждый 2 минуты. Следовательно, сервер приложения 1С запускает процедуру, приводящую к увеличению длительности. Поиск подобных процедур не дал результата, поэтому есть большая вероятность, что эта процедура никак не управляется со стороны администратора.
• Если увеличить масштаб (второй рисунок), то открывается другая интересная картина – на графике вырисовывается две четких линии с разницей до 30%. Природа этого явления, скорее всего, отличная от предыдущей. Но в этом случае уже значительная часть операций (около 25-30% от всего количества) выполняется медленнее.
Выводы
В случае работы множества пользователей на тонких клиентах 1С, деградация производительности может быть значительно больше. Поэтому перед реализацией проекта внедрения новой системы 1С8.2 следует взвешенно делать выбор типов клиентов 1С и до внедрения проводить мероприятия по моделированию пиковой нагрузки.
Распределенные взаимоблокировки при использовании «управляемых блокировок 1С»
В любой информационной системе, будь то 1С или другая, при работе с общими ресурсами (логическими, физическими) есть вероятность встретиться с взаимоблокировками (deadlock). Взаимоблокировка – уже из названия следует ответ: есть несколько конкурирующих процессов, один занял ресурс [1] и ожидает освобождения ресурса [2], а второй захватил ресурс [2], ожидает освобождения ресурса [1]. Взаимоблокировка – это мертвая блокировка и решается исключительно «сбрасыванием» одного из ожидающих процессов.
На слудующем рисунке представлена взаимоблокировка двух процессов, хотя в реальности количество процессов может быть значительно больше. Для простоты нами будет рассматриваться 2 процесса.
Простейший пример – взаимоблокировка на сервере БД (например, MS SQL). Пользователи эти события отслеживают по ошибкам («Transaction (Process ID) was deadlocked on resources with another process and has been chosen as the deadlock victim. Rerun the transaction»), которые MS SQL отправляет клиентским приложениям.
На сервере приложения 1С тоже есть механизм разрешения взаимоблокировок, который работает по тем же принципам, что и на MS SQL. События взаимоблокировки можно отследить посредством технологического журнала.
Но как быть, если общие ресурсы принадлежат не одному программному продукту, а предположим нескольким, расположенным на разных серверах. Эти взаимоблокировки называют распределенными и их идентификация достаточно сложна.
В рамках проектов по оптимизации мы регулярно сталкиваемся с подобными ситуациями. Как они появляются? Обычно сложный функционал информационной системы разрабатывается/дорабатывается множеством программистов, которые используя свои навыки, не задумываются о том, что если не придерживаться определенных правил, можно столкнуться с большими проблемами в будущем (при росте информационного потока, количества пользователей и функционала).
Для большей наглядности в типовую конфигурацию с «управляемыми блокировками» поставили точки останова в определенные места кода процедуры ОбработкаПроведения. Это требуется для искусственного увеличения длительности транзакции. В типовом коде хронология следующая:
На первый взгляд все логично – наложение блокировок перед проверкой остатков регистра. Очистка регистров может не присутствовать в этой процедуре и выполняться автоматически. В большинстве случаев эта схема будет работать, но в ряде случаев у пользователей будет возникать «ошибка таймаута блокировки». Несмотря на то, что ошибка будет иметь такой вид, а будет ли эта обычная блокировка? Давайте разберемся. Пользователь «Абдулов» работал с документом приходная накладная [2] и товарной позицией [1]. Документ был проведен, пользователь делал корректировку количества и начал проведение. Параллельно с ним, пользователь «Любимов» создавал и проводил документ приходная накладная [2] с этой же товарной позицией [1]. Время проведения приходных накладных менее 1 секунды. Но программа у пользователей зависла и, в конце концов, через 20 секунд у одного из них появилась ошибка. Что же произошло?
На следующем рисунке представлены два скриншота с сервера приложения 1С и с сервера MS SQL. Как видно мы попали на распределенный deadlock, который не мог быть быстро обнаружен.
Из-за чего это произошло?
Пользователь «Абдулов», в момент перепроведения документа первым действием очистил данные регистра и подошел к наложению управляемых блокировок. Пользователь «Любимов», выполняя проведение, наложил управляемые блокировки, но для завершения операции ему необходимо изменить итоги по позиции [1], которые заблокировал «Абдулов» очищая данные.
Данная ситуация не единична, можно придумать десятки других примеров. Для диагностики распределенных взаимоблокировок требуется сопоставление информации с двух источников, их сопоставление и решение. Также надо помнить, что время ожидания сеанса на подобной взаимоблокировки напрямую зависит от времени таймаута, поэтому таймаут необходимо выбирать очень взвешенно.
Выводы
Правильная интерпретация ошибок – уже полдела. Особенно это касается проблем распределенных взаимоблокировок, идентификация которых трудная и нетривиальная задача.
|
