Тесни места в базата данни на файлове - как да се избегнат (от скорошен опит). Файлово базирано забавяне - как да се избегне (от скорошен опит) Файлово базирана версия забавя 1C 8.3 по мрежата

2. Характеристики на програмата. Често, дори при оптимални настройки, 1C работи много бавно. Производителността спада особено рязко, когато броят на едновременно работещите с базата данни надвишава 4-5 потребители.

Кой си ти в компанията?

Решението на проблема с бавната работа на 1C зависи от това кой сте в компанията. Ако сте техничар, просто прочетете. Ако сте директор или счетоводител, последвайте специалната връзка ↓

Честотна лента на мрежата

По правило не един, а няколко потребители работят с една информационна база (ИС). В същото време има постоянен обмен на данни между компютъра, на който е инсталиран клиентът 1C, и компютъра, на който се намира информационната сигурност. Обемът на тези данни е доста значителен. Често възниква ситуация, когато локална мрежа, работеща със скорост от 100 Mbit/s, което е най-често срещаната скорост, просто не може да се справи с натоварването. И отново потребителят се оплаква, че програмата е бавна.

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

Сега нека разгледаме няколко решения на проблема с ниската скорост на 1C и тяхната цена, използвайки примера на локална мрежа от 10 средно големи компютъра.

Решение едно. Модернизация на инфраструктурата

Това е може би най-очевидното решение. Нека изчислим минималната му цена.

Най-малко за всеки компютър се нуждаем от 2 GB RAM памет, която струва средно 1500 рубли, мрежова карта, поддържаща скорост от 1 Gbit / s, струва около 700 рубли. Освен това ще ви е необходим поне 1 рутер, поддържащ скорост от 1 Gbit/s, което ще струва около 4000 рубли. Обща цена - 26 000 рубли за оборудване, с изключение на работата.

По принцип скоростта може да се увеличи значително, но сега вече не е възможно да се купуват евтини компютри за офиса. В допълнение, това решение не е приложимо за тези, които използват Wi-Fi или искат да работят през интернет - в техния случай скоростта на мрежата може да бъде десетки пъти по-ниска. Възниква мисълта: „Не е ли възможно да се внедри цялата програма на един мощен сървър, така че компютърът на потребителя да не участва в сложни изчисления, а просто да служи за прехвърляне на изображение?“ Тогава можете да работите дори на много слаби компютри, дори в мрежи с ниска честотна лента. Разбира се, такива решения съществуват.

Решение две. Терминален сървър

Той придоби голяма популярност в дните на 1C 7. Той е внедрен на сървърната версия на Windows и се справя добре с нашата задача. Той обаче има своите клопки, а именно цената на лицензите.

Самата операционна система ще струва около 40 000 рубли. В допълнение към това ще ни трябва за всеки, който планира да работи в 1C, лиценз за Windows Server CAL, струващ около 1700 рубли, и лиценз за Windows Remote Desktop Services CAL, който струва около 5900 рубли.

След като изчислихме цената за мрежа от 10 компютъра, в крайна сметка получихме 116 000 рубли. само за един лиценз. Добавете към това цената на самия сървър (най-малко 40 000 рубли) и разходите за внедряване, но дори и без това цената на лицензите се оказа впечатляваща.

Решение три. Услуга 1C Enterprise

1C разработи собствено решение на този проблем, което може значително да увеличи скоростта на програмата. Но и тук има един нюанс.

Факт е, че цената на такова решение варира от 50 000 до 80 000 рубли, в зависимост от изданието. За компания с до 15 потребители излиза доста скъпо. Големи надежди бяха възложени на „корпоративен мини-сървър 1C“, който според компанията 1C е насочен към малкия бизнес и струва около 10 000 - 15 000 рубли.

Въпреки това, когато влезе в продажба, този продукт беше голямо разочарование. Факт е, че максималният брой потребители, с които можеше да се използва мини-сървърът, беше само 5.

Както един програмист на 1C написа във форума: „Все още не е ясно защо 1C избра точно 5 връзки! Проблемите започват само с 4 потребители, но с пет всичко свършва. Ако искате да свържете шести човек, платете още 50 хил. Можем да направим поне 10 връзки...”

Разбира се, мини-сървърът също намери своя потребител. Въпреки това, за компании, където 5 или повече души работят с 1C, просто и евтино решение не се появи.

В допълнение към методите за ускоряване на програмата, описани по-горе, има още един, който е идеален за сегмента от 5 - 15 потребители, а именно уеб достъп за 1C във файлов режим.

Решение четири. Уеб достъп за 1C във файлов режим

Принципът на работа е следният: на компютъра се инсталира допълнителна роля на уеб сървър, на който се публикува информационна сигурност.

Естествено, това трябва да бъде или най-мощният компютър в мрежата, или отделна машина, посветена на тази роля. След това можете да работите с 1C в режим на уеб сървър. Всички тежки операции ще се извършват от страната на сървъра и трафикът, предаван по мрежата, ще бъде сведен до минимум, както и натоварването на компютъра на клиента.

По този начин дори много слаби машини могат да се използват за работа в 1C и честотната лента на мрежата не става критична. Нашите тестове показаха, че можете удобно да работите през мобилния интернет на евтин таблет, без да изпитвате дискомфорт.

Тази опция е по-ниска от корпоративния 1C сървър по отношение на скоростта на работа, но тази разлика е практически невидима до 15-20 потребители. Между другото, за внедряване на уеб сървър можете да използвате IIS (за Windows) и Apache (за Linux) и двете решения са безплатни!

Въпреки очевидните предимства, този метод за оптимизиране на работата на 1C не е придобил голяма популярност.

Не мога да кажа със сигурност, но най-вероятно това се дължи на две причини:

• Доста слабо описание в техническата документация
• Намира се на пресечната точка на отговорността на системния администратор и 1C програмиста

Обикновено, когато се обърне към системен администратор с проблем с ниска скорост, той предлага надграждане на инфраструктурата или терминален сървър; ако се свърже със специалист 1C, му се предлага 1C корпоративен сървър. Така че, ако във вашата компания специалист, отговарящ за инфраструктурата, и специалист, отговарящ за 1C, работят „ръка за ръка“, тогава можете безопасно да използвате решение, базирано на уеб сървър.

Нека ускорим 1C. Дистанционно, бързо и без Ваше участие

Ние знаем как да ускорим 1Ski, без да пречим на клиента. Вникваме в проблема, вършим си работата и си тръгваме. Ако искате програмата просто да работи нормално, свържете се с нас. Ще го разберем.

Оставете заявка и получете безплатна консултация за ускоряване на програмата.

В много отношения оптимизацията на 1C и скоростта на работа зависят от работата с ключалки, заявки и индекси. Ще се опитаме да отговорим на въпроса „как да ускорим работата на 1C“ (ще разгледаме въпроса как да ускорим стартирането на 1C в друга статия) и да избегнем оплакванията на потребителите относно „дълга обработка на документи“, което неизбежно засяга бизнес процесите.

Част 3. 1C производителност

Брави в 1C 8.3: търсене и елиминиране в кода, прехвърляне към управлявани брави

Бравите са част от механизма ACID. Нека разгледаме неговата концепция, представена под формата на опростена диаграма, използвайки примера на SQL SERVER

В автоматичен режим заключванията се управляват от самата СУБД. В същото време се появиха странични ефекти на MS SQL сървъра, като заключване на празни таблици и гранични диапазони от данни (Serializable level), което създаде допълнителни проблеми при работа с много потребители. За да разреши тези проблеми, 1C създаде контролирани ключалки.

1C Управляеми брави

Заключващият механизъм беше преместен на сървъра 1C, а на ниво СУБД изолацията беше намалена до минимум. В MS SQL нивото на изолация беше понижено до Read Committed със споделен механизъм за заключване на платформата 8.2 и механизъм за версия на редове на платформата 8.3 (т.нар. Read Committed Snapshot Isolation). По-точно, това е едноименното свойство на базата данни и два режима на работа Read Committed, които зависят от този параметър.

На последното ниво на изолация (RCSI) механизмът направи възможно да не се пресичат транзакциите за четене и запис на едни и същи ресурси на СУБД сървъра. Цялата основна работа беше поета от услугата за блокиране на 1C, която определя, въз основа на собствени метаданни, дали да разреши или не транзакции към DBMS сървъра, така че да няма нарушения на бизнес логиката. Проблемите със заключването на празни маси и гранични диапазони са нещо от миналото.

СУБД	Тип заключване	Ниво на изолация на транзакция	Прочетете извън транзакцията
Автоматични брави
Файлова база данни	Маси	Може да се сериализира	Мръсно четиво
MS SQL сървър	Публикации		Мръсно четиво
IBM DB2	Публикации	Повторно четене или сериализиране	Мръсно четиво
PostgreSQL	Маси	Може да се сериализира	Последователно четене
База данни на Oracle	Маси	Може да се сериализира	Последователно четене
Управлявани ключалки
Файлова база данни	Маси	Може да се сериализира	Мръсно четиво
MS SQL Server 2000	Публикации	Прочетете Посветено	Мръсно четиво
MS SQL Server 2005 и по-нова версия		Прочетете ангажираната моментна снимка	Последователно четене
IBM DB2 преди версия 9.7	Публикации	Прочетете Посветено	Мръсно четиво
IBM DB2 версия 9.7 и по-нова	Публикации	Прочетете Посветено	Последователно четене
PostgreSQL	Публикации	Прочетете Посветено	Последователно четене
База данни на Oracle	Публикации	Прочетете Посветено	Последователно четене

За да разберете в какъв режим на заключване е базата данни на програмата 1C, трябва да изпълните следната заявка от SSMS в контекста на желаната база данни:

1C брави. Потребителят няма да чака ключалки, 1C ще ускори, ако спазвате определени правила:

• Продължителността на транзакциите трябва да бъде намалена възможно най-много. Извършването на дълги изчисления в транзакция в 100% от случаите ще доведе до блокиране при работа на OLTP система.
• Елиминирани са дълги външни операции в рамките на транзакция, например изпращане и получаване на потвърждения по имейл, работа с файловата система и други допълнителни действия. Всички операции трябва да бъдат поставени в отложени кратки задачи.
• Заявките са максимално оптимизирани.
• Индексите трябва да се създават само при необходимост, за да се осигури оптимална производителност на заявките в приложението.
• Включванията на често актуализирани колони в клъстерирания индекс са сведени до минимум. Актуализациите на колона/и на клъстериран индекс изискват заключване както на клъстерирания индекс, така и на всички неклъстерирани индекси (тъй като техният ред за локатор съдържа ключа на клъстерен индекс).
• Когато е възможно, се създава покриващ индекс и се използва за намаляване на времето за извличане на данни.
• Използване на най-ниското ниво на изолация на транзакция, което ще изисква превключване към режим на управлявано заключване.

Инструменти за диагностициране на запушвания:

• Технологично списание;
• Център за управление на производителността от 1C инструменти;
• Gilev облачни услуги;

По-долу е даден пример за мониторинг на системата с помощта на услугата Gilev. Общата продължителност на блокирането е ~15 часа. Повече от 400 активни потребители. След вземане на решения и оптимизиране, времето за изчакване е по-малко от минута, а броят на блокировките е намален с ~670 пъти.

Беше:

стана:

В ситуация, в която „всичко виси и отнема много време“ и услугите за мониторинг не са конфигурирани или изобщо не се използват, като си спомняте принципа на Парето, трябва да се съсредоточите върху кода.

В автоматичен режим наличието на ключалки на сървъра може да бъде открито чрез системна процедура в контекста на желаната база данни. Тази съхранена процедура ви позволява да определите в какъв режим работят заключванията, тяхното състояние, тип и т.н.:

След като финализирате процедурата за 1C, можете да получите визуална информация за това, което се случва в момента на сървъра, като вземете предвид спецификата на таблиците 1C:

Фрагмент 1

//Заключва по отношение на 1C SELECT * FROM dbo.ReturnLockName1C(DEFAULT,DEFAULT) as t Където TableName1C НЕ Е NULL ORDER BY t.Resource

Използването на този механизъм ви позволява да получите пълна информация за текущите ключалки. Ако отчетът съдържа само S-ключалки, проблемът може да е дълготрайна заявка или заявки. За да установите причината и мястото на тяхното появяване в кода, можете да поемете по различни пътища: използвайте DMO обекти на SQL сървъра (но имайте предвид, че данните от тях се нулират след рестартиране на сървъра) или конфигурирайте Data Collector, запазване на данните от мониторинга в таблици за определено време. Основното е да получите текстовете на проблемни искания.

Използване на SQL Server DMO обекти

Ние показваме началната дата на сървъра, за да разберем уместността на данните. Разделяме пакета по рейтинг на четене (физически, логически, натоварване на процесора). В този случай се използват основните данни от sys.dm_exec_query_stats. Ние превеждаме текста на заявката в термините на 1C. Ако можете да разберете контекста на обаждането от текста на заявката, тогава всичко, което остава, е да разгледате плана на заявката, да намерите проблемни оператори и да разберете какво може да се направи.

Фрагмент 2

//начален час ИЗБЕРЕТЕ sqlserver_start_time ОТ sys.dm_os_sys_info; //Най-популярни заявки за физическо четене ИЗБЕРЕТЕ ТОП (50) (total_physical_reads) AS Total_physical_reading,

Идентифициране на проблемни заявки в резултат на събирането на Data Collector

Използвайки този инструмент, можете да класирате данните според необходимите параметри, като натоварване на процесора, продължителност, логически I/O, физически операции за четене, което ви позволява да запазите пълна статистика за по-нататъшен анализ, въпреки рестартирането на SQL сървъра.

След като проблемните заявки бъдат събрани от сървъра без мониторинг от трета страна, можете да класирате получените данни според необходимите параметри.

След това, като включите технологичния дневник и посочите в настройките „търсене по низ“ и частта от заявката, която гарантирано ще се срещне, можете да разберете откъде е извикана проблемната заявка. Ако сървърът има няколко бази данни или потребителското име е известно, струва си да добавите допълнителни полета за филтъра, за да намалите натоварването на сървъра при събиране на регистрационния файл на процеса.

Пример за проблемна заявка и пример за настройка на технологичен дневник:

Оптимизацията на заявките като възможност за ускоряване на 1C 8.3

Последствията от неоптималните заявки могат да се проявят под формата на продължителна обработка на документи, болезнено дълго генериране на отчети, замръзване на системата и други неприятни събития.

Когато работите със заявки, НЕ МОЖЕТЕ:

• Обединяване на таблици с подзаявки;
• Свържете обикновени маси с виртуални;
• Използвайте логическо "ИЛИ" в условия;
• Използвайте подзаявки в условия на присъединяване;
• Получаване на данни чрез точка от полета от съставен тип без ключова дума „Express“.

Когато работите със заявки, ВИЕ МОЖЕТЕ:

• Създаване на индекси на условия на заявка, съединяване, агрегиране и полета за сортиране;
• Филтрирането на виртуални таблици трябва да се извършва с помощта на параметри за избор.

Използване на индекси и тяхното влияние върху качеството на работата на системата

Много е писано за индексите, необходимостта от тяхното използване и влиянието върху качеството на работа на системата. Нека се опитаме да разберем тънкостите на „дизайна“ на индекси, опции за приложение и предимства пред обикновените таблици.

Индексирането е важна част от ядрото на СУБД. Липсващи индекси или обратното, прекомерен брой от тях, влияят върху скоростта на извличане, модифициране, добавяне и изтриване на данни.Нека да разгледаме индексирането, използвайки примера на най-често срещаната СУБД на Microsoft.

За общо разбиране как работи това, нека разгледаме подробностите на механизма за съхранение на данни, който обикновено представяме под формата на таблица (например Excel).

Единицата за физическо съхранение на данни е страницата - модул от 8 KB, който принадлежи само на един обект (например таблица или индекс). Страницата е най-малката единица за четене и писане. Страниците се събират в екстенти. Екстентът се състои от 8 последователни страници. Страниците с екстент могат да принадлежат на един или повече обекти. Когато страниците принадлежат на множество обекти, екстентът се нарича "смесен".

Съдържанието му може да видите по-долу:

Сега, след като имаме представа как работи дисковото устройство за съхранение, нека поговорим повече за таблиците и индексите.

По подразбиране, ако не използвате специални T-SQL оператори, празната таблица се създава като "купчина" - прост набор от страници и екстенти.Данните в купчината нямат логичен ред. Механизмът на SQL Server следи собствеността върху страницата и степента на конкретен обект, използвайки специални системни страници, наречени карти за разпределение на индекси. Всяка таблица или индекс има поне една IAM страница, наречена "първата IAM страница".

По този начин, след създаване на обикновена таблица, по подразбиране резултатът е хаотично подреждане на данни. Можете да видите състоянието на таблицата, като използвате следната процедура:

Основните индекси, използвани от платформата 1C

Фрагмент 3

Митове и реалност:

Мит първи: клъстерираните индекси и таблица с данни са две различни единици, съхранявани отделно една от друга.

Мит втори: може да има много групирани индекси в една таблица.

Изтеглих програма за оптимизиране на СУБД. Създадени препоръчителни индекси. Скоростта на вземане на проби е увеличена с 50%. Промяната и добавянето на данни се забави 7 пъти.

Клъстериран (групиран) индекс

Клъстерираните индекси са набор от страници, които сортират и съхраняват редове от данни в таблици или изгледи въз основа на техните ключови стойности – колоните, включени в дефиницията на индекса. Има ограничение за този тип индекс от 16 колони и 900 байта. За всяка маса има само един групиран индекс,защото редовете с данни могат да бъдат сортирани само в един ред. Създаването на клъстерен индекс става чрез реорганизиране на таблицата, вместо чрез копиране на данните, което позволява таблицата да бъде съхранена като балансирано дърво.

Фрагмент 4

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE object_id = OBJECT_ID("Проследяване на данни")

Неклъстъриран индекс

Неклъстерираните индекси имат структура, отделна от редовете с данни. Неклъстерният индекс съдържа стойностите на ключа на клъстерния индекс и всеки запис съдържа ключа на клъстерния индекс (не RID, тъй като 1C таблиците не използват купчини, с редки изключения).

Можете да добавите неключови колони към листовото ниво на неклъстъриран индекс и да заобиколите съществуващото ограничение на ключовете на индекса (900 байта и 16 ключови колони), като изпълнявате напълно индексирани заявки.

След добавяне на неклъстъриран индекс, данните бяха копирани и се появи друг обект:

Фрагмент 5

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE object_id = OBJECT_ID("Проследяване на данни")

Схема на клъстерирания индекс след извличането му от купчината под формата на балансирано дърво:

Схема на неклъстериран индекс, извлечен от клъстерирана таблица (обърнете внимание, че колоната за локатор на ред има ключ за клъстерен индекс):

Влияние на индексите върху производителността на заявките

Използвайки индекс, оптимизаторът на заявки търси в ключовите колони в индекса, намира къде се съхраняват редовете на заявката и извлича съвпадащи редове от там. Търсенето в индекс е много по-бързо от търсенето в таблица, защото, за разлика от таблица, индексът често съдържа по-малко колони на ред и редовете са сортирани по ред.

Създаването на множество индекси води до факта, че скоростта на вземане на проби се увеличава, а скоростта на запис по време на модификация е значително намалена. За да разрешите този проблем, първо трябва да изтриете ненужните индекси или първо да ги заключите, без да ги изтривате, което ще ви позволи просто да ги активирате, ако възникне такава необходимост.

Моля, обърнете внимание, че клъстерен индекс не може да бъде блокиран при никакви обстоятелства, т.к това ще блокира достъпа до данните от таблицата. Това се отнася само за индекси, които сте създали сами чрез T-SQL. Причината за създаване на индекси с помощта на T-SQL, заобикаляйки 1C:Enterprise, е свързана преди всичко с ограничените възможности на платформата 1C по отношение на манипулиране на индекси и включване на допълнителни полета в създадения индекс.

T-SQL оператор, който изпълнява действието за заключване на индекс:

//Заключване на отделен индекс в таблицата -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 DISABLE; //Включете желания индекс -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 REBUILD;

В допълнение към горните стъпки е важно да създадете файлова група на физически диск, който не съдържа текущите файлове на базата данни и да преместите там неклъстерираните индекси. Това ще ускори модифицирането на данните чрез паралелизиране на записа им.

Определяне кои индекси са необходими или ненужни за ускоряване на заявките

По подразбиране 1C създава определен основен набор от индекси. Често те просто не достигат. SQL Server има механизми, които ви позволяват да разберете, въз основа на вашето работно натоварване, колко необходими са вашите съществуващи индекси.

Database Engine Tuning Advisor анализира бази данни и прави препоръки за оптимизиране на производителността на заявките. Може да се използва за избор и създаване на оптимални набори от индекси, без да имате експертно ниво на разбиране на дизайна на базата данни или вътрешните процеси на SQL Server. Асистентът за конфигуриране на Database Engine ви позволява да изпълнявате следните задачи:

• Отстраняване на проблеми с изпълнението на конкретна проблемна заявка;
• Конфигурирайте голям набор от заявки в една или повече бази данни.

DMO (обекти за динамично управление), които включват динамични изгледи за управление и функции за динамично управление. Например T-SQL оператор може да извлече всички индекси, които не са били използвани от последното стартиране на сървъра.

Фрагмент 6

WITH vl as (SELECT OBJECT_NAME(I.object_id) AS objectname, I.name AS indexname, I.index_id AS indexid FROM sys.indexes AS I INNER JOIN sys.objects AS O ON O.object_id = I.object_id WHERE I.object_id > 100 AND I.type_desc = "NONCLUSTERED" AND I.index_id NOT IN (SELECT S.index_id FROM sys.dm_db_index_usage_stats AS S WHERE S.object_id=I.object_id AND I.index_id=S.index_id AND database_id = DB_ID("Име_на_база данни '))) SELECT име на обект,T1.NameTable1C, indexid, indexname FROM vl OUTER APPLY dbo.ReturnTableName1C(име на обект) като T1 ORDER BY име на обект, име на индекс;

Инструкции, които могат да се използват за създаване на необходимите индекси, препоръчани от ядрото на СУБД:

Фрагмент 7

ИЗБЕРЕТЕ T1.NameTable1C като Table_Name_1C, "CREATE INDEX" + "ON"
Оптимизаторът на заявки, когато генерира плана за изпълнение на заявката, идентифицира необходимостта от създаване на липсващия индекс. Той съхранява тази информация в XML ShowPlan. защото плановете за заявки се хешират и инструкциите се запазват (до следващото рестартиране на сървъра), след което могат да бъдат извлечени, обработени и се получават готови инструкции за създаване на необходимите индекси за всеки план за изпълнение в кеша. Струва си да се обърне внимание на честотата на изпълнение на заявката: колкото по-висока е тя, толкова по-подходящи са резултатите от заявката и съответно събраните индикатори. Ако заявката е била изпълнена веднъж, резултатите от нея не са толкова показателни.

Фрагмент 8

CROSS APPLY query_plan.nodes('//StmtSimple") AS stmt(stmt_xml) WHERE stmt_xml.exist("QueryPlan/Missinglndexes") = 1) ИЗБЕРЕТЕ ТОП 30 DatabaseName като DatabaseName, TableName като Table_Name, T1.NameTable1C като Table_Name 1C, равенство _колона ns като Comparison_columns, include_columns като Columns_to_include,

Фрагмент 9

ИЗПОЛЗВАЙТЕ [Име_на_база_данни] КЪРНЕТЕ СЪЗДАВАЙТЕ НЕКЛУСТЕРИРАН ИНДЕКС НА .[_Document497] ([_Fld12771_TYPE],[_Fld12771_RTRef]) ВКЛЮЧВАЙТЕ ([_Date_Time],[_Fld12771_RRRef],[_Fld12782RRef],[_Fld12784]) КЪРНЕТЕ Някои характеристики на индексиране чрез обобщени полета и полета за сортиране.

Създаването на индекс върху колоните, посочени в клаузата ORDER BY, помага на оптимизатора на заявки бързо да организира набора от резултати, тъй като стойностите на колоните са сортирани предварително в индекса. Вътрешното внедряване на механизма GROUP BY също сортира първо стойностите на колоните, за да групира бързо необходимите данни.

Когато използвате стандартни препоръки, струва си да проверите резултата преди и след оптимизацията. Нека дадем пример за използване на логическия съюз „ИЛИ“ и неговата алтернатива (за решаване на проблема с помощта на стандартни препоръки) - техниката за промяна на заявка с помощта на синтаксиса „ОБЕДИНЯВАНЕ НА ВСИЧКИ“.

Самата заявка 1C с „ИЛИ“:

ИЗБЕРЕТЕ код, име, връзка ОТ директория. Контрагенти КАТО Контрагенти WHERE Контрагенти. Код = "000000004" ИЛИ Контрагенти. Код = "0074853" ИЛИ Контрагенти. Код = "000000024" ИЛИ Контрагенти. Код = "009679294" ИЛИ Контрагенти. Код = " 0074742" ИЛИ Контрагенти. Код = "000000104";

Модифициране на заявката с „UNITE ALL“:

ИЗБЕРЕТЕ код, име, връзка ОТ директория. Контрагенти КАТО контрагенти WHERE контрагенти. Код = "000000004" КОМБИНИРАЙТЕ ВСИЧКИ ИЗБЕРЕТЕ код, име, връзка ОТ директория. Контрагенти КАТО контрагенти WHERE контрагенти. Код = "0074853" КОМБИНИРАЙТЕ ВСИЧКИ ИЗБЕРЕТЕ Код, име, връзка FROM Directory.Counterparties AS Counterparties WHERE Counterparties.Code = "000000024" COMBINE ALL SELECT Code, Name, Link FROM Directory.Counterparties AS Counterparties WHERE

Действителен план на заявката (за улесняване на показването и сравнение на производителността, заявките са прихванати и изпълнени в SSMS):

В този случай, след оптимизация, производителността спадна наполовина поради многократното използване на оператора Key Lookup, който винаги е придружен от оператора Nested Loops. Следователно, когато използвате схема за оптимизиране на заявки, трябва да измервате целевото време преди и след използване на подобрения. Този пример е показан с цел „доверете се, но проверете“, тъй като може да има несъответствие между типични препоръки и практически проблеми.

Как да ускорите работата в 1C: Счетоводство 8.3 (издание 3.0) или да деактивирате рутинни и фонови задачи

2019-01-15T13:28:19+00:00

Тези от вас, които вече са преминали към новото издание на 1C: Счетоводство 8.3 (издание 3.0), са забелязали, че е станало по-бавно от 2. Някакви странни забавяния, безкрайни фонови задачи по няколко пъти на ден, които никой не я е карал да изпълнява без наше знание.

Моите счетоводители ми казаха веднага след прехода, че новото издание на 1C: Accounting 3.0 е направо бавно в сравнение с предишните! И просто е невъзможно да се работи.

Започнах да го проучвам и много скоро разбрах, че основната причина за замръзване и последващо недоволство на потребителите са рутинни и фонови задачи, много от които са активирани по подразбиране, въпреки че за огромното мнозинство счетоводители няма нужда от тях.

Е, например, защо трябва да изпълняваме задачата „Извличане на текст“ сто пъти на ден, ако не извършим пълнотекстово (счетоводители, не се тревожете) търсене във всички обекти в нашата база данни.

Или защо постоянно да изтегляме валутни курсове, ако нямаме валутни транзакции или ги правим от време на време (и преди това ние сами можем да кликнем върху бутона за изтегляне на курсове).

Същото важи и за постоянните опити на 1C да се свърже със сайта и да проверява и актуализира банковите класификатори. За какво? Аз самият ще натисна бутона за актуализиране на класификаторите, ако не намеря правилната банка по нейния BIC.

Как да направите това стъпка по стъпка по-долу.

1. Отидете в секцията „Администриране“ и изберете „Поддръжка“ () в панела с действия:

2. В прозореца, който се отваря, намерете и изберете „Рутинни и фонови задачи“:

3. Отворете всяка задача, която има „Включено“ в колоната „Включено“. има галка.

4. Премахнете отметката от „Активирано“ и щракнете върху бутона „Запазване и затваряне“.

5. Направете това с всяка от включените задачи и се насладете на новото издание. Като цяло според мен е много по-добре от две.

В същото време платформата все още ще активира някои от планираните задачи, които сте деактивирали.

Системата 1C днес е един от основните инструменти за управление на малки и средни предприятия. По правило всички служители на организацията имат достъп до програмата. По този начин, ако 1C започне да се забавя или да работи бавно, това значително се отразява на поведението на бизнеса. Нека да разгледаме как можете сами да ускорите и оптимизирате работата в 1C.

Оптимизация с помощта на 1C актуализация

Новите версии на 1C винаги работят по-успешно и бързо, така че е наложително да следвате актуализациите. Препоръчително е да актуализирате счетоводните си записи възможно най-често. Особено когато се пускат версии на регламентирано отчитане.

Много хора използват възможността за автоматично актуализиране на програмата от дълго време. Въпреки че този проблем може лесно да бъде разрешен ръчно за 1C Enterprise 8.3, чието актуализиране няма да причини проблеми.

Първата стъпка е да изтеглите най-новата версия на платформата, която използвате в момента. Това се прави или с помощта на ITS диска, или чрез уеб интерфейса, където те осигуряват текуща поддръжка на потребителите на програма като 1c Enterprise 8.3, актуализация на конфигурацията за която също се предоставя официално.

В последния случай архивът с данните за актуализация се изтегля отделно. Той се разопакова във всяка папка, която се счита за най-удобна за потребителя. След това трябва да стартирате .exe файла. В следващия прозорец просто щракнете върху бутона „Напред“.

Ще се появи друга страница. На него потребителят избира пътя, по който да завърши инсталацията. Но тази стъпка се препоръчва само за напреднали собственици на персонални компютри. Функциите по подразбиране обикновено са достатъчни за решаване на повечето проблеми. По подразбиране в този случай е посочена една папка, където всички актуализации се инсталират наведнъж. Това е много по-удобно, отколкото когато крайните пътища са различни. Просто кликваме няколко пъти върху бутоните „Напред“ в програмата 1c Enterprise 8.3, чиято конфигурация трябва да се актуализира бързо.

Остава само последният бутон, който предлага „Инсталиране“.

Как да ускорите 1C, ако платформата е бавна

Проблемите най-често произтичат от факта, че на един от етапите концентрацията на вниманието на изпълнителя намалява. Тук е важно да изберете правилната схема за актуализиране, само в този случай няма да срещнем проблем, когато 1c замръзне по време на актуализацията.

Актуализация на версия 7.7

Има няколко вида конфигурация. В зависимост от това се избира курсът на по-нататъшните действия.

• Стандарт – в този случай се приема, че актуализацията се извършва и за регулирано отчитане.
• Типичните индустриални конфигурации до голяма степен напомнят предишните опции. Важно е предварително да прочетете инструкциите, предоставени от разработчика. В противен случай няма да можете да разберете защо 1C 8.3 се срива по време на актуализацията.
• Модифициран стандарт - потребителят винаги има възможност сам да модифицира приложението, така че да отговаря на текущите нужди. Друг вариант за разширяване на функционалността е преминаването към нови платформи. Например версия 8.

Относно версия 8.0 и 8.1

В момента платформа 8.0 вече се оттегля от поддръжка. Новите стандартни разработки ще работят само при използване на най-новите версии. Просто трябва да запомните, че всички междинни версии са завършени безпроблемно. В противен случай има голяма вероятност просто да загубите информация. Или срещнете ситуация, при която 1c замръзва при актуализиране на конфигурацията.

Възможна е опция, когато се внедри нова стандартна конфигурация, след което остатъците от старите информационни бази данни се прехвърлят към нея.

Що се отнася до версия 8.1, можете да я актуализирате по няколко начина:

1. ръчно;
2. в автоматичен режим;
3. контакт със специалисти от компании, предоставящи услуги в тази област.

Работа с нестандартни или модифицирани версии

Първоначално всяка конфигурация се отнася до стандартни разработки. То престава да бъде такова, ако в предприятието се направят определени промени. Например по време на инсталацията. Има два класа, които се открояват сред нестандартните конфигурации:

1. променен;
2. създаден от нулата, като се вземат предвид нуждите на конкретно предприятие.

Понякога конфигурация от втори клас се разпространява активно между потребителите. Тогава се счита за типично. Просто производителят не се счита за самия 1C, а за компанията, създала новата версия.

Конфигурациите могат да се поддържат актуални чрез следните действия:

• Корекция на грешка.
• Разширяване на функционалността.
• Подобрение.
• Промяна в 1C 8.3, конфигурацията не се актуализира в случай на грешки в поддръжката.

Процесът на инсталиране може да отнеме различно време в зависимост от скоростта на интернет, с която го използвате в момента. В отделен прозорец потребителят избира дали да актуализира след приключване на работата или веднага. При последната опция трябва да сте сигурни, че никой друг не работи с приложението. Самият процес включва използването на изключителен режим в приложението 1c Enterprise 8.3, последната актуализация не е изключение.

• Трябва да помним, че не всички версии на изданието може да са подходящи за текущата конфигурация.
• Ако актуализациите не са били извършвани дълго време, може да се наложи да изтеглите няколко файла или архива наведнъж.
• В списъка е лесно да се разбере коя версия на 1C Enterprise 8.3 е необходима, актуализацията се избира от потребителя.

Когато процесът приключи, самият конфигуратор може да бъде затворен. Този режим се използва най-често, ако е необходима актуализация. Той е удобен и автоматизира почти целия процес. Когато я стартирате за първи път, може да се появи съобщение, което показва, че платформата е остаряла. И че не е препоръчително да го използвате в настоящия момент.

Допълнителни причини за спиране

Ако програмата се актуализира правилно и без никакви грешки, но 1C все още се забавя, тогава причината може да е следната:

• Антивирусна програма - ако е конфигурирана правилно, никаква антивирусна програма няма да пречи на системата, но ако използвате фабричните настройки, производителността на 1C може да намалее с 5–10%. Можете да оптимизирате вашата антивирусна програма, като използвате допълнителни настройки, като премахнете фоновия режим (ако е абсолютно необходимо).
• Компютърни параметри - често недостатъчно мощните компютри водят до значително намаляване на производителността на 1C. Особено внимание трябва да се обърне на видеокартата, операционната система и процесора.

Такива методи значително ще оптимизират и ускорят работата в 1C за всяка компания или предприятие, след което производителността на програмата значително ще се увеличи.

Как да увеличите скоростта и лекотата на използване в 1C

Симптоми и история на пациента:

Работата на няколко потребители в мрежата с един и същ файл (база данни) включва механизъм за блокиране на мрежата. Това принуждава системата да губи ценно време за идентифициране на отворени записващи сесии и съответно разрешаване на конфликти.

Основните признаци на блокираща операция:

• бърза работа на потребителите с базата данни през мрежата в изключителен режим и изключително бавна, когато няколко потребители работят едновременно
• бързо потребителско изживяване с локална база данни на сървъра и бавна работа в мрежата
• достъпът до файловата система е малко под 10 MB/сек

И така, получих задачата да се уверя, че до трима потребители могат да работят в 1C едновременно! Смешно, нали?

Забравих всички шеги, когато видях с какво трябва да се справя: „сървър“ под формата на обикновен офис компютър и два лаптопа.

Щастието би било непълно, ако не бяха прекрасните операционни системи - Windows 7 на компютъра и на единия лаптоп, Windows 8 на другия.

При опит за едновременно публикуване на документи на лаптопи, единият остана за около минута, а вторият се срина от 1C с текста за грешка „не може да заключи масата...“.

Стартирането на 1C на лаптоп е отделно шоу, което продължи около 3 минути!

На много ресурси срещнах съвети да премина към работа в терминален достъп. За съжаление, Windows 7 не ви позволява да се превърнете в терминален сървър с помощта на стандартни инструменти - има максимум една активна връзка. В този случай останалите сесии не се прекратяват; можете да се свържете отново под друг потребител - „изхвърляйки“ предишния потребител, но без да прекъсвате сесията му. Следователно трябва да прехвърлите 1C на сървърна операционна система, където няма такива ограничения. Клиентът, на свой собствен риск, реши проблема, като вместо това използва помощна програма на трета страна Windows7_SP1_RDPhack.

Но приключенията не свършиха дотук. Дори в терминалната връзка имаше значителни забавяния. За пореден път всемогъщите търсачки ми помогнаха. По-долу са дадени съвети за ускоряване на файл 1C, които следвах:

1. Деактивиранеизползване на мрежов протокол IPv6, конфигурирайте адресирането на „стария“ IPv4.

2. Добавете 1C процеси към изключенията на защитната стена на Windows, както и към антивирусните изключения или ги деактивирайте напълно (по-рисковано, но прост тест показа увеличаване на скоросттаповторно прехвърляне на документи, когато антивирусната програма Avast е деактивирана фактор на!)

3. Започнете индексирането на пълнотекстово търсене в 1C или го изключете напълно

4. Стартирайте тестване и коригиране на базата данни, като проверите с помощната програма ChDbfl

5. Стартирайте елемента Проверка на конфигурацията в конфигурацията (ако конфигурацията не е стандартна, това може да е полезно). Въз основа на резултатите от проверката на конфигурацията, той магически намалява по размер с почти една трета. Наистина не се задълбочих какво точно са актуализирали пристигащите програмисти преди мен, но фактът е очевиден.

6. Деактивирайте ненужните функционални опции.

7. Настройте потребителски права. (Този и предишният съвет изглеждаха глупави, докато не наблюдавах изобразяването на управлявани формуляри при отваряне на списък с документи. Колкото по-малко е ненужно в управлявания интерфейс, толкова по-бързо работи, като правило)

8. Започнете да преизчислявате сумите и да възстановявате последователността (значително увеличение може да настъпи само ако сумите не са били възстановени дълго време)

9. Посочете "Скорост на връзката - ниска" в настройките на списъка с база данни (това не даде много резултат, освен че изображенията на подсистемите бяха изключени :))

След като завърши всички тези стъпки, файловата база данни 1C започна да работи много по-бързо. Започна да се стартира за максимум 10 секунди, а скоростта на прехвърляне на документи се увеличи средно 12 пъти.

Може би тази кратка статия ще ви бъде полезна, ако внезапно трябва да ускорите вашата 1C файлова база данни.

P.S: Но стартирането на файл 1C с помощта на мрежов достъп до споделена папка все още е нереалистично, защото... Дори най-бързият SSD диск, RAM и процесор ще се натъкнат на мрежови блокажи и работата на повече от един потребител ще бъде практически невъзможна. Говорим конкретно за конфигурацията на UT 11.1. Самостоятелно написаните малки конфигурации могат да работят доста бързо дори във файловата версия.

Допълнения от коментариза публикация:

Дефрагментатор на дискс файлова база

Конволюциябаза данни (може да е полезно, ако базата данни е голяма, например за няколко години). Базата данни на клиента беше доста млада, така че намаляването беше непрактично.

Хардуерен ъпгрейд - по-бърз хард диск, нов комутатор, процесор и др.

Инсталирайте на уеб сървър, достъп чрез тънък клиент. Тук мненията са разделени. Някои казват, че е в пъти по-бързо, други казват, че не се забелязва ускорение.