Обновления платформы 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 секунд обычно достаточно пользователям, чтобы скопировать и вставить картинку, если им нужно.
UPDATE от 23.04.2025 Техподдержка 1с отписалась что ошибка исправлена в платформе 8.3.27.1508
