Обновления платформы 1с на linux в большом офисе это каждый раз новый, неожиданный опыт и попытки придумать очередной забавный костыль для нормальной работы сотрудников. Вот и в этот раз после обновления платформы до версии 8.3.24.1758 у сотрудников начались неожиданные зависания системы по всему офису, а это порядка 500 человек. Чтобы найти корень проблемы на задачу были брошены лучше силы ИТ отдела, все два системных администратора, месяц бесплодных попыток найти хоть какую-то зависимость действий пользователей и зависания системы. В анамнезе получили что после обновления платформы на машинах в какой-то не очень определенный момент времени сначала начинает заканчиваться свободная память, потом свап, потом система зависает.
Для правильной и хорошей статьи наверняка надо не забыть описать техническую составляющую, поэтому немного отвлечемся на скучные данные, на всех машинах стоит ubuntu 20.04, 1С толстый клиент (это важно как оказалось в последствии), самописная конфигурация, сервер 1С на майкрософтвском SQL. Вот с этим вроде и закончили.
Что мы только не делали и как только не пытались найти причину утечек памяти 1С. Начали с того что воспроизвели все это на типовых платформах (Бухгалтерии и ЗУП), выяснили что утечка может происходить даже если сотрудник ничего не делает в 1С, а в некоторых случаях даже если 1С просто запускается то сразу начинает зажирать ОЗУ как не в себя, причем в разных случаях с разной скоростью. Были уже готовы опустить руки, но как всегда под новый год случилось чудо, один из менеджеров на сравнительно слабой машине с 4 гигабайтами ОЗУ, позвонил в ИТ отдел и сказал что он наконец-то нашел соответствие своих действий и зависаний системы. Когда он копировал через буфер обмена большую таблицу из либреофиса, компьютер зависал через пару минут после этого. Дальше было все сопоставить уже не сложно. На сайте 1С в описании платформы нашли что в 8.3.24 1С внедрил программную работу с буфером обмена. Опыты показали что копирование любой картинки в буфер обмена при открытом толстом клиенте 1С и открытой любой не управляемой формы в 1С приводит к той самой утечке памяти. В зависимости от размера картинки память утекает с разной скоростью, и при копировании таблицы из либреофис система считает что в буфере обмена находится картинка.
После этого смешной опыт общения с тех поддержкой 1С, бесполезные попытки донести до них что описание ошибки как "В Linux при наличии в буфере обмена больших данных во время работы потребление памяти клиентского приложения может увеличиваться." не совсем корректное (совсем не корректное) и клятвенные обещания с их стороны что раз ошибка воспроизводится то её совсем скоро исправят (пока все еще нет).
А теперь то ради чего писалась вся эта статья, вдруг кому-то поможет наш костыль.
1. Устанавливаем xclip для работы с буфером обмена через консоль: apt-get install -y xclip
2. На пользовательских машинах создаем скрипт:
#!/bin/bash
while true; do
if xclip -selection clipboard -t TARGETS -o | grep -q image; then
echo "attention! image in clipboard!"
sleep 5
xclip -selection clipboard /dev/null
fi
sleep 5
doneи ставим его в автозагрузку.
Скрипт проверяет раз в 10 секунд есть ли картинка в буфере обмена и если есть то очищает буфер. Как показала практика 10 секунд обычно достаточно пользователям чтобы скопировать вставить картинку если им нужно.