Советы по предварительной настройке программного окружения 1С 7.7
Давайте вспомним, как работает платформа 1С 7.7 DBF. У каждого пользователя указан так называемый рабочий каталог, имя пользователя, полное имя пользователя. При старте платформа 1С проверяет, нет ли в рабочем каталоге пользователя файла *.lck (режим, когда рабочий каталог пользователя не указан – не рассматриваем, позже станет ясно - почему). Если файл lck есть – значит данный пользователь уже работает и 1С не пустит его в базу, выдав сообщение “каталог пользователя занят”. Если такого файла нет – пользователь начинает работу. При открытии пользователем экранных форм, содержащих реквизиты с сохраненными настройками, платформа 1С извлекает эти настройки из файла *.cfg, лежащего, конечно же, в рабочем каталоге пользователя. Замечу, что в данном файле со временем скапливается много мусора, причем файл может даже оказаться поврежденным. Во время работы пользователя, и соответственно, выполнения программного кода, платформа 1С выполняет некие действия, из которых нас интересует следующее: опишу на примере - когда пользователь запускает отчет, в котором выполняется запрос, состоящий, с точки зрения платформы 1С, из нескольких простых запросов – платформа 1С выполняет простые запросы по очереди, сохраняет результаты каждого простого запроса в виде файлов dbf в рабочем каталоге пользователя, после чего считывает их заново, и производит окончательное формирование результата запроса.
Правило №1:
1. Каждому пользователю должен быть назначен рабочий каталог. В этом случае настройки каждого пользователя, будут хранится в отдельном файле cfg, а не в одном файле cfg на всех пользователей. Временные файлы dbf также будут хранится в отдельных каталогах.
2. Размер файла cfg каждого пользователя не должен превышать нескольких сотен килобайт (и, тем более, не должен быть размером 1 мегабайт и более). Файл cfg размером 1 мегабайт (и больше) приводит к серьезному замедлению работы пользователя. Рекомендую безжалостно удалять cfg файл, если его размер больше чем 200-400 килобайт. Для профилактики, оптимизации, или устранения торможения 1С – удалите файлы cfg всех пользователей.
3. Тот факт, что 1С создает временные dbf файлы (не считая *.cfg, *.lck) в рабочем каталоге пользователя, определяет следующую идею оптимизации. Рабочие каталоги пользователей нужно располагать на самом быстром жестком диске сервера (нежелательно, чтобы на этом же диске была операционная система, или файл подкачки).
В объектной модели 1С существует только два вида объектов, которые может создавать интерактивно пользователь – это элемент справочника, и документ. Для оповещения всех работающих экземпляров 1С о том, что элемент справочника (либо документ) открыт (и значит недоступен для изменения), 1С применяет тот же способ - создание временных файлов. В случае документа, в каталоге информационной базы 1С создается файл 1sjourn.$lk, в котором блокировкой определенного байта фиксируется факт открытия экранной формы объекта пользователем. Для элементов справочников создается файл sс****.$lk, где **** - внутренний идентификатор справочника в конфигурации (идентификаторы всех объектов конфигурации можно узнать, открыв любым текстовым редактором файл 1cv7.dd). Подробнее об этом методе блокировки можно прочитать тут. Мы же можем только вздохнуть, и констатировать, что механизмы платформы 1С DBF 7.7 архаичны и используют методы “вековой давности”. Впрочем, последний релиз платформы 7.7 действительно выпущен в далеком 1999 году.
Правило №2:
1. Учитывая реалии современной жизни, а именно тот факт, что жизнь современной операционной системы без антивирусной программы немыслима – проводим тонкую настройку антивируса. Никогда не используйте в настройках исключений антивируса – исключение всего каталога с информационной базой 1С. Нужно задать исключения только для файлов с масками: $lk, *.cfg, *.mlg, *.ert, *.efd, *.log, *.upd, *.md, *.dbf, *.cdx, *.xml. Все остальные файлы в каталоге базы 1С антивирус должен сканировать. Тем самым вы "убьете двух зайцев": избежите “торможения” базы 1С из-за антивируса, и не позволите вирусам спокойно плодится в укромных подкаталогах каталога информационной базы 1С.
Знайте также, что платформа 1С 7.7 DBF, не ограничиваясь созданием временных файлов в рабочих каталогах пользователей и в каталоге базы, создает свои временные файлы и в специальном каталоге для временных файлов. Кстати, с помощью ключа командной строки \Т можно явно указать программе 1С, где ей следует создавать временные файлы. Например так: С:\1С77.ADM\1cv7.exe /TD:\ (задан каталог для временных файлов – D:)
Полагаю, перечисление всех типов временных файлов создаваемых 1С, заставило читателя вспомнить о “старом лекарстве от всех временных файлов” – драйвере RamDrive (или аналогах)? Не рекомендую его применять по ряду причин. В первую очередь по причине неэффективности способа.
Как же тогда ускорить работу большой базы 1С 7.7 в формате DBF? А вот как. Большинство из нас, полагаю, давно не пользовались утилитой дефрагментации диска (за ненадобностью). О вашей базе: если у вас большая база DBF, т.е. 1-10 гигабайт, то вам стоит запустить анализ фрагментации жесткого диска, на котором находится каталог с базой 1С. Если под базу 1С не выделен отдельный жесткий диск на сервере, и, соответственно, на жесткий диск часто пишутся и удаляются данные, то, в большинстве случаев, самые большие файлы базы 1С (это файлы регистра партий, регистра продаж, табличной части документа реализация и т.д.) фрагментированы на несколько тысяч частей.
Правило №3:
1. Не допускайте чрезмерной фрагментации файлов базы 1С (а большая DBF база на невыделенном жестком диске очень склонна к фрагментации). Приведу пример (совсем не редкий из практики): если у вас файлы регистра партий, регистра продаж, табличной части документа реализация фрагментированы на 3000 частей каждый, то дефрагментация диска ускорит работу вашей базы в разы. В зависимости от скорости роста фрагментации, рекомендую запускать автоматическую дефрагментацию раз в сутки (или раз в неделю). Для автоматической дефрагментации используйте запуск утилиты defrag.exe с параметром – именем жесткого диска. Например: defrag.exe D:
Выполнив эти мелкие, но полезные шаги по оптимизации, предпримем более серьезные действия. Начну издалека. Как известно, DBF база состоит из совокупности dbf и cdx файлов (прочие файлы служебного назначения в расчет не берем). Таких файлов обычно несколько тысяч. Совокупный размер этих файлов может достигать нескольких гигабайт. Попробуем оценить следующее - какой объем информации 1С нужно считать из файлов, расположенных на жестком диске, при простом действии - проведении документа РеализацияТМЦ? Например, в базе, с которой я сейчас работаю (речь идет о конфигурации Торговля и Склад 7.7), размер файла итогов регистра ОстаткиТМЦ - 30 мегабайт, размер файла итогов регистра ПартииНаличие - 60 мегабайт. Как мы знаем, при проведении документа реализация в коде модуля проведения анализируются итоги регистра ОстаткиТМЦ и ПартииНаличие. Значит, платформе 1С для анализа итогов этих регистров придется прочитать оба этих файла с диска, т.е. считать информацию размеров 90 мегабайт. Не будем забывать, что система 1С также должна будет считать с диска файл журнала документов, и многие другие файлы. Операции чтения с диска занимают некое время, и скорее всего, в случае большой базы - немалое. Поэтому, уделим пристальное внимание тонкой настройке серверной операционной системы в части её работы с жестким диском. Провести настройку нам поможет утилита тонкой настройки операционной системы сервера - ConfigNT.
Правило №4:
1. В оснастке администрирования сервера отключаем службу индексирования диска, если она у вас включена.
2. В оснастке администрирования отключаем службу теневого копирования тома.
Запускаем утилиту ConfigNT и выполняем следующие действия:
3. На закладке Logon устанавливаем галку в чекбоксе "AutoEndTasks". Установка данной опции сообщит операционной системе сервера о том, зависшие процессы необходимо завершать немедленно, не оповещая об этом пользователя.
4. Установливаем на закладке Memory Management галку в чекбоксе "Maximize Throughput for File Sharing". Тем самым мы дадим знать операционной системе сервера, что желаем, чтобы для использования файлов выделялся максимально доступный объем памяти. При данной настройке, операционная система не будет сбрасывать долго не используемые страницы оперативной памяти на диск, т.е. в виртуальную память.
5. Устанавливаем на той же закладке галку в чекбоксе "Use large system cache". Установка данной опции сообщит операционной системе сервера о том, что под кэширование дисков нужно выделить максимум оперативной памяти.
6. На закладке Other снимаем галку в чекбоксе "Update last access time on NTFS". Установка данной опции сообщит операционной системе сервера о том, что не следует обновлять время последнего доступа к файлам.
Также рекомендую в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Filesystem создать ключ NtfsDisable8dot3NameCreation с типом DWORD и значением равным 1. По умолчанию, файловая система NTFS создает и хранит таблицу всех имен файлов и папок на диске в формате MS-DOS (т.е. 8 символов для имени файла, и 3 символа для расширения). Это нужно для совместимости со старыми приложениями. Установкой значения 1 для параметра NtfsDisable8dot3NameCreation отключим эту особенность NTFS.
Для того чтобы параметры возымели действие - перезагрузите сервер.
И, последний совет - если конфигурация вашего сервера позволяет использовать SSD жесткий диск - очень желательно приобрести жесткий диск такого типа. Жесткие диски использующие технологию SSD, обеспечивают на порядок большую скорость чтения информации с жесткого диска, нежели у жестких дисков традиционного типа, что увеличивает скорость работы базы 1С 7.7 в формате DBF в разы. Подробней о технологии SSD можно почитать тут.
Советы по оптимизации конфигурации 1С 7.7 DBF
Самый простой и самый эффективный способ оптимизировать быстродействие конфигурации 1С - выполнить так называемую "свертку", или "обрезание" базы. Но, не всегда эта операция допустима, и возможна. Продолжая повествование, будем исходить из того, что свертка конфигурации нежелательна.
Рассмотрим работу платформы 1С 7.7 “изнутри”. Основными объектами для хранения информации о хозяйственных операциях в 1С являются справочники и документы, как мы уже выяснили. В принципе, оперируя лишь этими объектами, мы могли бы получить все необходимые нам данные. Но, разработчики программы 1С ввели в объектную модель дополнительные объекты, призванные агрегировать информацию (из справочников и документов) и предоставить возможность быстрого доступа к ней. Такие объекты – это регистры остатков, регистры оборотов и проводки. Указанные объекты обычно хранят информацию (причем учитывая хронологию событий во времени) о движении остатков товаров, денежных средств и т.п.
Неправильное проектирование регистров зачастую приводит к ощутимому торможению базы 1С.
Правило №1:
1. Не используйте галки “Отбор движений” и “Отбор итогов” для измерений регистра без крайней необходимости, так как это увеличивает размер индекса. Крайняя необходимость – тот случай, когда в программном коде необходимо использовать функции ВыбратьДвижения(), ВыбратьИтоги() с фильтром по искомому измерению.
3. При проектировании регистра учитывайте особенность платформы 1С 7.7. Дело в том, что платформа создает один составной индекс для всех измерений регистра. Поэтому, полезный совет – располагайте измерения в регистре в порядке убывания частоты использования измерения в отборах. Например для регистра ОстаткиТМЦ правильным будет порядок следования измерений: а)Номенклатура б)Склад в)Фирма г)ЦенаПрод. А вот такой порядок: а)Фирма б)Склад в)Номенклатура г)ЦенаПрод – приведет падению скорости выборки данных из регистра и увеличению размера индексного файла.
4. Не допускайте случаев “не закрывающихся” регистров.
Еще одно узкое место платформы 1С 7.7 – это константы. С точки зрения методологии 1С, константы предназначены для хранения часто используемой, но редко изменяющейся информации (поэтому, наверное, разработчики 1С сочли возможным объединение всех констант в одну таблицу). На практике же, программистами часто допускается ситуация, когда в константы часто пишется некая информация. Такая методика приводит к печальным последствиям.
Немного информации о блокировках, применяемых платформой 1С 7.7 DBF. Блокировки бывают “на чтение” и “на запись”. Я специально выбрал эти термины, т.к. уже по названию блокировки понятно, как платформа 1С выбирает, которую применить. Сейчас нас интересует лишь возможность одновременной установки блокировок. Итак, блокировка “на запись” исключает установку другой блокировки “на запись”, а также “на чтение”. Блокировка “на чтение” разрешает установку других блокировок “на чтение”, но запрещает установку блокировок “на запись”. Отсюда следует простой вывод – если в константу часто идет запись, то, часто возникающие блокировки "на запись" будут исключать установку блокировок обоих типов, что в высоконагруженной системе (40-70 пользователей), приведет к появлению сообщений о ошибке транзакции у пользователей программы. В случае же использования констант “по назначению”, т.е. когда значения из констант будут большей частью считываться – ошибок транзакций не возникнет, т.к. блокировки “на чтение” могут устанавливаться одновременно несколькими экземплярами 1С.
Правило №2:
1. Используйте константы по назначению. Недопустима, например, ситуация, когда при проведении каждого документа в некую константу записывается информация.
Таблица констант, к сожалению, не единственное “узкое” место в структуре таблиц, применяемых платформой 1С 7.7 для хранения данных. Еще одно узкое место – таблица документов. При сохранении или проведении документа, 1С блокирует данную таблицу для всех пользователей, кроме того, кто выполняет сохранение (проведение). В высоконагруженной системе блокировки таблицы документов будут неизбежно (и часто) вызывать ошибки транзакций у пользователей. Более того, лавина транзакций будет вызывать растущую загрузку процессора – вплоть до 100%.
Правило №3:
1. Установите данную разработку. Разработка позволяет снизить загрузку процессора во время ожидания блокировки таблицы до незаметных величин. Более того, за счет нехитрого, но эффективного алгоритма повторных попыток заблокировать таблицу, количество неудачных попыток заблокировать таблицу снизится, а значит, заметно уменьшиться количество транзакций.
Примечание: для платформы 1C 7.7 SQL существует более эффективный инструмент – “гибкие блокировки”, но в данной статье платформа 1C 7.7 SQL рассматриваться не будет.
Понятно, что снизить число блокировок, приводящих к ошибке транзакции, можно также путем ускорения транзакции, т.е. уменьшения её длины.
Для этого можно применить, например, такие способы:
1. Для применения способа необходима установленная компонента УРБД. Создаем новую периферийную базу. Пользователей делим на 2 группы: а) пользователи, создающие документы текущей датой б) пользователи, формирующие отчеты, и создающие документы как текущей датой, так и "задним числом". Пользователи группы "а" работают в прежней базе. Пользователи группы "б" работают в периферийной базе. Для синхронизации данных между базами настраиваем автообмен.
2. Этот способ условно можно назвать - дублирование регистров. Суть способа состоит в том что в конфигурации заводятся новые регистры - дубли существующих. Выбирается день Х. На начало дня Х делается "снимок" итогов регистров остатков и заносится в соответствующие им дубли. В код конфигурации вносятся такие изменения, что все документы, начиная со дня Х проводятся по новым регистрам, программный код отчетов тоже изменяется - для отчетов по регистрам оборотов в код запросов просто дописывается второй регистр. Отчеты по регистрам остатков переписываются так, что до дня Х отчет формируется по старому регистру, со дня Х - по свежесозданному дублю этого регистра. Недостаток: Сформировать отчет с начальной даты = (ДеньХ-1 день) по конечную дату (ДеньХ+1) конечно же, нельзя.
На нескольких больших базах, пребывавших под моим наблюдением, был замечен следующий эффект: при выполнении обработкой массовой записи и проведения документов одинаковым временем, скажем - 08:00:00, при возникновении ошибки транзакции документ бесследно исчезал. Полагаю, читатель знаком с утверждением, что в 1С 7.7 (как впрочем и 1С 8) в пределах одной секунды можно записать достаточно большое число документов (1000-5000 например). Вышесказанное заставляет меня в этом усомниться (по крайней мере в случае большой базы формата DBF).
Думаю, читатель знаком и с утверждением, что позиция документа – это некая величина, зависящая от времени документа, и от порядка ввода документов в пределах одной секунды. Мои наблюдения на больших базах не подтверждают это утверждение. Типовой отчет “Остатки ТМЦ” (с детализацией по документам) выводит такие документы (имеющие одинаковое время, распределенные в пределах одной секунды) в порядке, отличающемся от порядка в журнале документов! Более того, путем определенных экспериментов было установлено, что при расчете остатков в модуле проведения такого документа, остатки выдавались неверные (в силу неверного определения позиции)!
Правило №4:
1. Т.к. вы работаете с информационной базой DBF, приближающейся к предельному объему, не искушайте судьбу – не используйте в ваших обработках массовую запись и проведение документов одинаковым временем. Документы должны записываться с шагом в 1 секунду.
2. Рекомендую иногда проверять размеры файлов 1sjourn.dbf и 1sjourn.cdx (журнал документов). В норме размер файла 1sjourn.cdx должен быть примерно в 1,5 раза больше размера файла 1sjourn.dbf. Если у вас соотношение размеров этих файлов кардинально другое (например файл 1sjourn.cdx меньше файла 1sjourn.dbf - чего быть никак не может) – то это один из признаков неисправности журнала документов.
3. Приблизительно такое же соотношение должно быть у размеров файлов 1scrdoc.dbf и 1scrdoc.cdx (перекрестные ссылки документов).
Как показывает практика, вышеуказанных техник вполне достаточно для оптимизации больших баз 7.7 DBF. Но, к сожалению, добившись комфортной скорости работы вашей базы вы не сможете долго наслаждаться покоем...
ГЛАВНАЯ ПРОБЛЕМА БОЛЬШИХ БАЗ 1С 7.7 DBF:
Суть проблемы заключается в том, что в один прекрасный момент вы столкнетесь с эффектом исчезновения документов, самопроизвольным снятием документов с проведения, некорректными данными в отчетах, внезапными вылетами программы 1С с сообщением об ошибке.
Почему так происходит? Оказывается, для файлов формата dbf, в которых платформа 1С 7.7 DBF хранит информацию, существует ограничение на максимальный размер. Для файлов формата dbf это ограничение равно 2 гигабайта. Но dbf файлов, используемых платформой 1С 7.7 максимальный размер равен 1 гигабайт. Почитать о природе данного ограничения вы можете тут.
Правило №5:
1) Заблаговременно (до достижения самым большим файлом dbf размера в 1 гигабайт) установите данную разработку.
2) После установки разработки, удалите все индексные файлы в каталоге вашей базы 1С, и запустите 1С в монопольном режиме. Индексные файлы будут воссозданы заново.
Путем выполнения указанных в статье рекомендаций можно “вернуть форму” базе 1С 7.7 DBF даже большого размера (10-12 гигабайт), и получить с приемлемую скорость работы, с минимумом транзакций.
Надеюсь что из данной статьи смогли почерпнуть максимум информации все три категории читателей:
1) ИТ-специалисты, поддерживающие базы на платформе 1С 7.7 DBF.
2) ИТ-специалисты, которые хотят понять все недостатки платформы 1С 7.7, для аргументированного принятия решения о переходе на платформу 1С 8.2.
3) Все те читатели, кому хочется знать существующие техники оптимизации и ускорения платформы 1С 7.7 DBF.
Примечание:
Вдумчивый читатель, разумеется, заметил некий перекос в изложении способов оптимизации. Действительно, тщательная подготовка и оптимизация программного окружения описана гораздо подробней, чем способы оптимизации непосредственно конфигурации 1С. Такое положение дел объясняется опытом автора в эксплуатации и оптимизации баз 1С 7.7 DBF. Практика показывает, что главная причина возникающего с ростом размера базы "торможения", "зависаний", увеличивающейся длины транзакции, и, соответственно - ошибок транзакций - это то, что с ростом размера базы значительно увеличивается время, требующееся 1С для извлечения информации из нескольки тысяч dbf и cdx файлов хаотично разбросанных по жесткому диску, причем, значительно фрагментированных. Во многих случаях достаточно приобрести SSD жесткий диск, и получить ускорение работы конфигурации в разы. Тогда как можно пойти другим путем - последовательно применить несколько трудоемких техник по оптимизации самой конфигурации 1С и получить ускорение всего в 30%-50%.
