Вплив блокувань на продуктивність 1С:Підприємство 8

Команда gilev вже багато років займається питаннями продуктивності та успішно вирішує у тому числі питання усунення очікувань на блокуваннях та взаємоблокувань.

Нижче ми розповімо наш досвід щодо вирішення цих проблем.

Виявлення проблем блокувань у 1С

Питання продуктивності в розрахованому на багато користувачів режимі зовсім не обов'язково пов'язані з поганим кодом або поганим залізом. Спочатку нам треба відповісти на запитання — які проблеми продуктивності існують і що їх викликає?

Відстежити вручну діяльність сотень користувачів вручну не можна, потрібен інструмент, що автоматизує збір такої інформації.

Існує багато інструментів, але практично у них є один дуже істотний недолік - ціна.

Але є вихід — ми як інструмент аналізу вибираємо

Ми будемо досліджувати проблему на MS SQL Server, тому нам знадобляться наступні сервіси цього набору:

1. Моніторинг та аналіз довгих запитів(Докладніше про налаштування читайте тут) - потрібен для того щоб оцінити наявність довгих операцій до субд.

Власне факт їх наявності дозволяє говорити про те, що проблеми з продуктивністю є, і проблеми полягають у рядках коду конфігурацій 1С, який сервіс проранжує за важливістю. Проблеми на початку списку треба вирішувати насамперед. Такі рішення проблемних рядків принесуть максимальний ефект, тобто. буде найбільше користі та штибу для користувачів системи.

(Докладніше читайте тут) дозволить нам оцінити — а чи власне викликаний час тривалих (довгих) запитів очікуванням блокувань чи є інші причини (неоптимальний код, перевантажене залізо тощо) Сервіс покаже причину виникнення очікування запитом, а саме ресурс, який був заблокований і хто його заблокував. Тобто. ми зрозуміємо наявність проблем із блокуваннями та їх причини.

3. Аналіз взаємних блокувань у 1С та MS SQL server(докладніше про налаштування читайте тут) — дозволить нам оцінити складніші ситуації з очікуванням ресурсів, коли кілька учасників частина ресурсів вже встигли «захопити» блокуванням і тепер змушені чекати змушені чекати один одного через те, що вони не можуть звільнити зайняті ресурси до завершення захоплення інших ресурсів, заблокованих сусідами.

Втім в такій складній ситуації вручну не розібратися, потрібен такий сервіс.

4. Контроль завантаженості обладнання(Докладніше про налаштування читайте тут) допомагає нам відповісти на запитання — скільки користувачів в системі, чи є у них блокування, як багато блокувань, чи справляється залізо з навантаженням?

Сервіси налаштовуються дуже легко, але навіть якщо у вас однаково залишилися питання, є!

За допомогою вище перерахованих інструментів ми маємо об'єктивну інформацію про продуктивність системи. Це дозволяє нам правильно оцінити ситуацію та запропонувати адекватні заходи.

Фактично ми отримуємо інформацію про всі проблеми продуктивності і можемо точно відповісти на питання на кшталт «скільки проблем у системі», «де конкретно вони виникають», «кожна з проблем з якою частотою виникає», «які проблеми значущі, а які другорядні». Тобто. бачимо всі передумови, які сформували причину виникнення проблеми.

Сервіси дозволяють суттєво покращити розуміння умов виникнення проблем, не змушуючи вручну копатися у таких речах як структура зберігання даних інформаційної бази на рівні СУБД, механізм накладання блокувань тощо.

В результаті ми отримаємо картину продуктивності, яка вимірюється.

час запиту (зрозуміло, відранжувавши проблемні запити за вагою (час запиту на кількість викликів цього запиту));

- Час очікування блокувань;

Отже, ми запустили сервіс Аналіз очікувань на блокування

У верхній таблиці сервіс показує перелік «жертв» блокувань з урахуванням сумарної ваги «тяжкості очікувань».

У нижній таблиці для кожної жертви розглядаються один або більше учасників «боротьби за висококонкуретний ресурс», де й виникло очікування блокування.

У нижній таблиці відкрийте деталізацію за фактом однієї з подій таймауту. Як, наприклад, на картинці.

Підсвітивши рядок з «винуватцем», ми побачимо, що вузьким місцем стала таблиця _Reference64, причому виникла проблема на кластерному індексі з областю «невідомо». Можливо, у майбутньому ми перейменуємо на «таблиця», оскільки насправді така поведінка характерна для підвищення/укрупнення області блокування.

Рядок з «жертвою» показує який код виявився заручником ситуації і не зміг заблокувати всі рядок «по ключу» (мінімальна область блокування даних у цій таблиці).

Вирішувати цю проблему можна «правильно» і «легко».

Правильним шляхом йти складніше — фактично треба переписувати код, мінімізуючи ймовірність виникнення подібних ситуацій.

Один із факторів, як не дивно звучить, — це зменшення тривалості.

Зменшити тривалість транзакції можна:

1. переписавши алгоритм

2. переписавши запит (швидший запит зменшує ймовірність блокувань у складних транзакціях на таблицях, яких іноді навіть може бути в запиті!)

2.1 додавши відсутній покриваючий індекс (іноді індекс не тільки прискорює запит, а й зменшує область читання даних, що зменшує можливість блокування)

3. зменшивши обсяг даних, оброблюваний на тразакції (крім лінійної швидкості пам'ятаємо ще про ескалацію блокувань)

4. збільшивши продуктивність устаткування рамках кожного потоку

Час виконання запиту

1) різні користувачі можуть працювати паралельно з різними даними
2) різні користувачі повинні працювати строго послідовно з одними і тими самими даними

Однак оптимізувати використання блокувань можна, зменшивши загальний час очікування.

Як працюють блокування (цей пункт можна не читати)

Роботою з блокуваннями займається спеціальний модуль SQL Server – менеджер блокувань (Lock Manager). До його завдань входить:

• створення та встановлення блокувань;
• зняття блокувань;
• ескалація блокувань;
• визначення сумісності блокувань;
• усунення взаємоблокувань (deadlocks) та багато іншого.

Коли користувач робить запит на оновлення або читання даних, менеджер транзакцій СУБД передає управління менеджеру блокувань СУБД для того, щоб з'ясувати, чи були блоковані запитувані ресурси, і, якщо так, чи сумісне запитуване блокування з поточним. Якщо блокування несумісне, виконання поточної транзакції відкладається, доки дані не будуть розблоковані. Як тільки дані стають доступними, менеджер блокувань накладає запитуване блокування і повертає управління менеджеру транзакцій.

Основна причина, що знижує швидкодію – блокування

Очікування на блокуваннях є основною проблемою швидкодії розрахованого на багато користувачів режиму. І це зрозуміло, адже вони збільшують час очікування операцій, а отже, і час відгуку. Чи можна сказати, що очікування на блокуваннях - це не правильно і помилка розрахованої на багато користувачів системи? Так би мовити не можна, оскільки сам собою механізм блокування ресурсів забезпечує цілісність даних. За допомогою механізму блокувань конкурентні дані ЗАПИСУЮТЬСЯ НАСЛІДНО.

Різниця між необхідними та надмірними блокуваннями

Коли користувач повідомляє про помилку очікування на блокуванні, то з його точки зору це завжди помилка, тому що вона заважає йому працювати - збільшується час виконання його роботи.

Досвід підказує нехитре правило, якщо більше половини часу виконання запиту він фактично чекає на заблокований ресурс, то треба подивитися: можливо частину блокувань вдасться оптимізувати, зменшити час блокування ресурсу.

Тут як би ненароком вводжу визначення:

Очікування на блокуванні - це ситуація, яка виникає в тому випадку, якщо два користувачі намагаються одночасно захопити одні й ті самі дані. При цьому один із цих користувачів виявляється заблокованим, тобто має чекати до закінчення транзакції першого користувача.

А транзакція — це безліч обчислень та операцій із даними (найяскравіший приклад — під час проведення документа) , виконуваних як єдине ціле. Невиконання будь-якої операції транзакції призводить до скасування транзакції цілком.

Отже, користувачі в розрахованих на багато користувачів інформаційних базах можуть часто скаржитися, що неможливо працювати через ці блокування, при цьому в коді дійсно можуть бути блокування, які в цьому місці не потрібні (надлишкові).
А ще й у коді конфігурації вони самі по собі блокування можуть не бути, про них можна прочитати наприклад тут http://kb.1c.ru/articleView.jsp?id=30 (стаття є фрагментом книги П.С. .В.Островерх «1С:Підприємство: від 8.0 до 8.1».). Пропоную спрощений спосіб пояснення відмінності блокувань на простому прикладі так:

У вашій конфігурації в режимі 1С: Підприємство створіть дві однакові накладні з однаковим складом товару. Але обов'язково вкажіть різні склади надходження.
У коді обробки проведення треба додати рядок з виведенням на екран повідомлення (або інший код, здатний затримати виконання обробки проведення на 21 секунду (таймаут блокування відбувається через 20 секунд, якщо параметри за замовчуванням)).
Проводьте два документи.
Якщо виникає тайм-аут, а за логікою товари приходять на різні склади, у додатку присутні надмірні блокування. Бізнес - логіці (вважай за здоровим глуздом) тут блокувань не повинно бути.
Якщо ж ми тепер зробимо у цих двох накладних однакові склади. То створені блокування в результаті спроби одночасного проведення приведуть НЕОБХІДНЕ блокування і це ДОБРЕ!

Тобто. доки накладна вносить зміни до залишків на складі, інша має зачекати.

Звичайно, навіть цей простий приклад залишає багато питань. Наприклад, якщо документи від одного постачальника і «рухається» заборгованість по ньому. А якщо рухаються не лише залишки на складі, а кілька регістрів, а документи різного виду.
Але найголовніше питання – А ЗА ЯКОЮ ТАКОЮ БІЗНЕС-ЛОГІкою НЕ ПОВИННО БУТИ БЛОКУВАЧ. Хто цей бізнес - логіку і де прописує в контексті блокувань? Але давайте про все по порядку.

Надлишкові блокування - зайві - які не потрібні з точки зору забезпечення цілісності даних і при цьому знижують загальну продуктивність системи, збільшуючи загальний час "простою" - очікування на блокування.
Необхідне блокування виникає при захопленні двома користувачами тих самих ресурсів (об'єктів даних). Якщо ж користувачі працюють з ресурсами, що не перетинаються, але при цьому відбувається очікування на блокуванні, то блокування вважається надлишковим.

Найбільш зрозумілими критеріями надмірності блокувань позначу:

1. Взаємні блокування;

2. Рівень (область) блокування вище за необхідне (як окремий випадок підвищення рівня блокування, т.зв. ескалація);

3. Час блокування більший за час «реального» використання об'єкта блокування.

Отримавши інформацію про угруповання проблем у розрізі метаданих 1С:Підприємство, рекомендую звернути увагу насамперед на об'єктах:

• Константи
• Послідовність
• Реєстри бухгалтерії
• Регістри накопичення
• Реєстри відомостей
• Реєстри розрахунку

1) Донедавна була загальновідома рекомендація у константи нічого не писати. В крайньому випадку робити це з-під одного користувача, і то пам'ятає, що поки користувач «пише» одну константу, не тільки цю, але й будь-яку іншу константу інші користувачі будуть «чекати». Тому особливо небезпечно використовувати констати для обробки проведення. Значення всіх констант зберігаються в одному ресурсі.

На малюнку показано фізичне розміщення констант конфігурації УПП у таблиці бази даних MS SQL Server 2005.

Це означає, що при блокуванні однієї константи буде заблоковано всі константи. СУБД накладає блокування на ВРЮ єдину РЯДКУ таблиці, тобто. на всі константи.

Однак у останніх релізах платформи зберігання констант змінено. Тепер кожна константа – це окрема таблиця. Правда сильно не захоплюйтеся, якщо ви створите тисячі таблиць, то можете зловити блокування на базі master.

Увага, якщо у вас конфігурація існує давно, змінити формат зберігання можна шляхом «реструкторизації» в Тестуванні та Виправленні конфігуратора.

2) Відмовитися від використання об'єкта метаданих «Послідовність». Хоча б від рухів при оперативному проведенні проводити при неоперативному (допроводі). Дивіться, як реалізовано в останніх версіях УПП.

3) Якщо в системі здійснюється оперативний запис рухів по бухгалтерському регістру в розрахованому на багато користувачів режимі, то рекомендується:

• включити для цього регістру режим поділу результатів;
• не використовувати контроль залишків регістру під час оперативної роботи.

4) У регістрі накопичення у разі відсутності необхідності отримати «оперативні» дані можна включити поділ підсумків, що підвищить паралельність запису даних і прискорить роботу загалом. Уважно стежити за вимірами, щоб «залишки» можна було отримати максимальною деталізацією вимірів.

5) Позбутися деяких надлишкових блокувань, створюваних платформою можна тільки шляхом . В автоматичному режимі роботи конфігурацій платформа «бере він» блокування ресурсів. Ціна безтурботного використання автоматичного режиму – можливі блокування на межах діапазонів індексів, блокування порожньої таблиці, ескалація блокувань.

Ці блокування повністю зникають даних у транзакції. Тобто, дане взаємоблокування буде неможливим при роботі в керованому режимі.

Вже кілька разів промовив «керовані блокування», «керований режим». Треба розуміти, що є два види блокувань:
Блокування СУБД – автоматично встановлюються на рівні СУБД при виконанні запитів.
Блокування 1С: Підприємство – встановлюються автоматично під час запису (модифікації) даних та завжди вручну під час читання даних.

Прискіпливий читач скаже, що 1С ділить ще на об'єктні та не об'єктні блокування, але зараз цей підхід ми чіпати не будемо.

Натомість зазначу, що накладає більше вимог кваліфікації та досвіду 1С-фахівця.

6) Відсутні індекси (особливо у складних запитах) це взагалі основний фактор виникнення більш високого рівня блокувань, ніж необхідно. Тобто. парадокс, я з одного боку говорив, що до оптимізації запиту казав, що спочатку треба подивитися на блокування, а тепер говорю, щоб оптимізувати блокування — треба оптимізувати запит. У мене є виправдання, що переклад конфігурації на керовані блокування зменшує надлишкові блокування навіть не в оптимальному запиті. Це відбувається через зменшення рівня ізоляції транзакцій, що у свою чергу менеджеру блокувань СУБД дає менше підстав накласти надлишкове блокування.

Основні причини надлишкових блокувань (підсумуємо вище сказане)

- Помилки проектування
(Ступінь паралельності визначається тим «наскільки дрібно нарізані дані»: можлива паралельна робота з двома рядками таблиці, робота з одним рядком буде йти тільки послідовно)
(Помилки використання метаданих: запис констант, послідовностей, оперативний облік на регістрах бухгалтерії)
- Надлишкове блокування з вини автоматичного режиму (зв'язка платформа - СУБД).
- Неоптимальна робота запиту
(наприклад, при скануванні таблиці блокується вся таблиця - надлишкова область
і збільшується час блокування – надлишковий час, додаткова кількість блокувань збільшує ймовірність ескалації блокування)

Як Ви бачите завдання оптимізації блокувань «багатогранне». Потрібно якнайкраще представляти «контекст», що спровокував проблему. На яких ресурсах, який код. Наскільки реально це блокування необхідне, або воно надмірне.

У дитини та дорослої болить горло. Коли лікар запитає: «Що не так?», дитина дивитиметься на лікаря і кричатиме (вірте мені, я знаю), тоді як дорослий вкаже на симптоми хвороби. Ці очевидна відмінність направляє лікаря до різних методів ідентифікації проблеми.
З дитиною, лікар повинен виконати багатотестів, зібрати дані, об'єднати їх, виконати аналіз і лише потім надати рекомендації. Тоді як із дорослим, він поставить кілька питань і, оскільки кількість вихідних даних невелика, час аналізу та визначення проблеми буде суттєво меншим. Як результат, рекомендації буде видано набагато раніше.

Користуйтеся нашими сервісами та у Вас з'явиться більше можливостей безкоштовно проаналізувати проблему та знайти рішення!

1С: Бухгалтерія – одна з найвідоміших та найзручніших програм бухгалтерського обліку. Доказом цього є її розповсюдження у всіх сферах діяльності: торгівлі, виробництві, фінансах та ін.

На жаль, як і у всіх комп'ютерних програм у 1С: Бухгалтерія також бувають різні збої та зависання. Одна з найбільш поширених проблем - повільна робота системи.

З метою розібратися в причинах її виникнення та спробувати їх вирішити та написано сьогоднішню статтю.

Усунення поширених причин повільної роботи 1С

1. Найпоширеніша причина повільної роботи програми - тривале отримання доступу до базового файлу 1С, яке можливе через помилки на жорсткому диску або через погану якість інтернет-з'єднання, у разі використання хмарних технологій. Можливі проблеми в налаштуваннях антивірусної системи.

Рішення: провести сканування з усуненням помилок та дефрагментацією жорсткого диска . Протестувати швидкість доступу до Інтернету. За низьких показників (менше 1 Мб/с) звернутися до служби ТП провайдера. Тимчасово відключити антивірусний захист та файрвол в антивірусній системі.

2. Можливо, повільна робота програми відбувається через великий розмір файлу бази даних.

Щоб вирішити цю проблемувідкрийте 1С у режимі «Конфігуратора», у меню системи виберіть «Адміністрування», далі «Тестування та виправлення». У вікні обов'язково має бути обраний пункт «Стиск таблиць інформаційної бази даних», нижче активний пункт «Тестування та виправлення». Натисніть «Виконати» та дочекайтеся закінчення процесу.

3. Наступна можлива причина – застаріле ПЗ чи неактуальна версія самої програми.

Вихід із цієї ситуації: оновити програмне забезпечення операційної системи або встановити останню на даний момент версію програми 1С. З метою попереджувальних дій завжди виконуйте оновлення до актуальної версії, у ній усунуті помилки ранніх конфігурацій.

Щоб встановити останню версію системи 1С, необхідно зайти в програму в режимі "Конфігурація", далі з меню перейти в "Сервіс" -> "Службові" -> "Оновлення конфігурації", після цього вибрати стандартні налаштування і натиснути кнопку "Оновити".

Добре знайома ІТ-фахівцям скарга користувачів «висить 1С» має багато причин. Для встановлення правильного «діагнозу» – виявлення та аналізу проблеми, потрібно її відтворення, адже проблему, яку неможливо відтворити, як правило, практично неможливо вирішити. Розібравшись у симптомах зависання 1С, ми зробимо перший крок на шляху до ефективно працюючої системи.

Дуже довгий запуск системи

Довгий запуск важкої конфігурації під одним користувачем вперше після додавання ІБ до списку баз на комп'ютері – явище нормальне. У процесі першого запуску відбувається кешування конфігурації. Другий та наступні запуски повинні виконуватися швидше.

Запуск системи, що займає тривалий час, може свідчити про проблеми архітектурної реалізації конфігурації. Більшість конфігурації зчитується платформою лише за першому зверненні до необхідного об'єкту метаданих. Довгий запуск говорить про ймовірність використання великої кількості метаданих об'єктів (багато звернень у різні загальні модулі, обробки і т.д.).

Слід враховувати, що з першому зверненні до тексту будь-якого модуля відбувається його компіляція. Цей процес також займає час, який особливо помітний, якщо модулів багато. Таким чином, проблема повільного запуску вирішується модифікацією (оптимізацією) конфігурації, метою якої є відключення виконання всіх обов'язкових алгоритмів, які виконуються при старті системи.

Є ймовірність, що конфігурація під час запуску намагається прочитати дані з Інтернету. Це також підвищує час запуску системи.

Дуже довге відкриття форм

Довге відкриття форм може бути обумовлено:

1. Великою кількістю елементів управління на формі - час витрачається на створення форми та взаємопов'язання розташування елементів форми;
2. Виконання алгоритмів при ініціалізації форми. Можливо, при створенні форми перевіряються будь-які умови та/або відбувається читання пов'язаних об'єктів з бази даних.

Перша проблема «лікується» спрощенням форми. Наприклад, частину елементів управління можна винести в окремі форми, що може бути зручніше для користувача. Наприклад, якщо на формі є поле адреси «Місто», «Вулиця», «Будинок» тощо, редагування адреси краще винести в окрему форму.

Друга проблема вирішується аналізом дій, що виконуються при створенні та відкритті форми, та оптимізацією цих алгоритмів. Можливо, частина алгоритмів вже застаріла, а частину можна спростити та оптимізувати, наприклад, виключити чи мінімізувати звернення до даних у базі.

Як інтерактивну дію розглянемо спробу користувача вибрати значення в елементі форми. У відповідь на нього система «про щось замислюється». Це може статися з таких причин:

1. Алгоритми, що виконуються при цій дії, перевіряють або обчислюють пов'язані з ними дані, що впливають на режим вибору значення;
2. Форма вибору, що відкривається для вибору цього значення, під час ініціалізації зчитує всі об'єкти з бази даних.

Для вирішення першої проблеми слід скористатися «Виміром продуктивності», знайти ресурсомісткі алгоритми та оптимізувати їх.

Другу проблему можна вирішити простим аналізом реалізації форми вибору. Наприклад, варто переконатися, що для динамічного списку встановлено властивість «Динамічне зчитування даних», правильно встановлено властивість «Основна таблиця», а реалізації списку не використовуються заздалегідь ресурсомісткі алгоритми.

Також є ситуації, коли при відкритті форми вибору з бази даних зчитуються якісь пов'язані дані (наприклад, при відкритті форми вибору «Номенклатура» зчитуються залишки товарів на складах). Як правило, це не найкраще рішення. Зчитування пов'язаних даних краще виконувати асинхронно вже після відкриття форми. Це викликає менше дискомфорту в користувача, т.к. після показу форми користувач витратить деякий час на сприйняття форми, що відкрилася, і цей час можна витратити на завантаження пов'язаних даних.

Дуже тривала реакція на оновлення

Один із тривіальних симптомів, проте, здатний розповісти про деякі проблеми системи: оновлення 1С зависає при запуску резервного копіювання. В основному це відбувається при оновленні через Інтернет і, швидше за все, говорить про те, що конфігурація давно не оновлювалася і релізи, накочуючись один на одного, викликали зависання. Запобігти подібній проблемі можна своєчасним встановленням оновлень, а при зіткненні з нею можна просто перервати процес резервного копіювання. Після запуску роботи конфігуратора база запуститься із внесеними змінами у звичайному режимі.

Слід зазначити, що 1С 8.3 зависає при оновленнях найчастіше ще й тому, що потребує ресурсомісткого апаратного забезпечення, ніж попередні версії платформи. Варто звернути увагу на обсяг оперативної пам'яті та при необхідності збільшити його - це в принципі має допомогти у вирішенні проблеми «1С зависає при оновленні конфігурації».

Довгий запис об'єктів/проведення документів

У цьому випадку «лікування по фотографії» практично виключено, оскільки причини можуть бути найрізноманітнішими, починаючи з великого обсягу даних в об'єкті, закінчуючи очікуванням на блокування.

Але навіть у цьому випадку, можна намітити напрямок для аналізу.

Відсутність значних змін часу запису, зумовлених часом доби або кількістю користувачів (за зразковою, суб'єктивною оцінкою), свідчить про проблему в коді або обсязі даних об'єкта. Для аналізу при цьому є сенс скористатися інструментом «Вимір продуктивності».

Кардинальна зміна часу запису при неясних залежностях, що вимагає виконання статистичного аналізу появи проблеми, тобто. аналізу продуктивності. Найпростіший спосіб – аналіз використання журналу реєстрації. Додатковою перевагою є підтримка платформою «1С:Підприємство 8» збереження даних журналу реєстрації у файл формату SQLite. Це дозволить використовувати SQL-запити для аналізу даних журналу. Час запису об'єктів цілком можна отримати з даних журналу, якщо врахувати той факт, що кожен запис об'єкта виконується в транзакції, а кожна транзакція має свій ідентифікаційний номер.

Якщо результат статистичного аналізу показав, що час запису об'єкта залежить від часу доби, а не кількості користувачів, необхідно проаналізувати завантаженість сервера 1С і сервера бази даних. Можливо, на сервері виконуються регламентні процеси, які забирають зайві ресурси.

Якщо час запису об'єктів залежить від кількості користувачів, проблеми, швидше за все, полягають у коді (можливі очікування на блокуваннях) або пропускну здатність обладнання. Для їх вирішення слід залучити спеціаліста, який має компетенцію «1С:Експерт із технологічних питань», оскільки уніфікованих правил вирішення такого завдання не існує.

У статті розглядаються основні чинники: коли 1С гальмує, 1С зависає і повільно працює 1С. Дані підготовлені на основі багаторічного досвіду компанії SoftPoint щодо оптимізації великих IT систем, побудованих на зв'язці 1С + MS SQL.

Для початку варто відзначити міф про те, що 1С не призначена для одночасної роботи великої кількості користувачів, що активно підтримується користувачами форумів, які знаходять у цих постах заспокоєння та причину для того, щоб залишити все як є. При достатньому терпінні та рівні знань можна довести систему до будь-якої кількості користувачів. Повільна робота та зависання 1С вже не буде проблемою.

З практики: Найлегше оптимізувати 1С v7.7 (Оптимізація 1С 8.1, 1С 8.2, 1С 8.3 складніше завдання, оскільки додаток складається з 3 ланок). Довести її до 400 одночасних користувачів – досить типовий проект. До 1500 – вже складний, що потребує наполегливої ​​роботи.

Другий міф: щоб покращити роботу 1С та позбутися зависань 1С потрібно поставити потужніший сервер. Як правило, у проектах оптимізації в 95% випадків вдається досягти прийнятних показників або взагалі без апгрейду, або оновивши незначну частину обладнання, наприклад, додавши оперативну пам'ять. При цьому слід зазначити, що обладнання має бути серверним, особливо дискова підсистема. Застаріла дискова підсистема - лише з причин, чому повільно працює 1С.

Основне обмеження при розрахованій на багато користувачів роботі в 1С - блокувальний механізм. Саме блокування в 1С, а не обладнання сервера, зазвичай, не дають працювати в базі великій кількості людей. Щоб подолати це лихо - доводиться добре попрацювати і змінювати логіку блокувань в 1С - опустити їх з табличних до рядкових. Тоді, наприклад, проведення документа блокуватиме лише один, а не всі документи у системі.

Рисунок 1. Черга блокувань 1С в системі моніторингу PerfExpert, з інформацією про користувачів 1С, модуль конфігурації та конкретний рядок коду в цьому модулі.

Зміна механізму блокувань 1С – дуже складна технологія. Не всім під силу провернути такий фокус і для них залишається лише один шлях – оптимізація структури та прискорення часу виконання операцій. Справа в тому, що блокування в 1С і час виконання операцій - взаємопов'язані показники. Наприклад, якщо операція проведення документа займає 15 секунд, то при великій кількості користувачів велика ймовірність, що під час проведення ще хтось спробує провести документ і чекатиме у блокуванні. Якщо довести час проведення, хоча б до 1 секунди, то блокування 1С цієї операції значно знизяться.

Більш небезпечними з точки зору блокувань є групові обробки, які можуть бути тривалими за часом виконання і одночасно викликати блокування 1С. Будь-яка обробка, яка змінює дані, наприклад відновлення послідовності або групова обробка документів блокують таблиці і не дають іншим користувачам проводити документи. Звичайно, чим швидше виконуються ці обробки, тим менше час блокування і легше працювати користувачам.

Важкі звіти, які виконують лише операції читання, також можуть бути небезпечними з точки зору блокувань, хоча, здавалося б, не блокують дані. На інтенсивність блокувань в 1С такі звіти впливають, уповільнюючи решту операцій у системі. Тобто, якщо звіт дуже важкий і забирає основну частину ресурсів сервера, може вийти, що до запуску звіту ті самі проведення виконувались 1 секунду, а під час виконання звіту виконуються 15 секунд. Звісно, ​​зі збільшенням часу виконання операцій збільшуватиметься і інтенсивність блокувань.

Рисунок 2. Навантаження на робочий сервер у межах модулів конфігурації, від усіх користувачів. Кожному модулю відповідає власний колір. Видно явний дисбаланс у створюваному з 1С навантаженні.

Основне правило при оптимізації – час проведення документа має займати мінімум часу та виконувати лише необхідні операції. Наприклад, часто в обробці проведення використовуються розрахунки по регістрам без зазначення умов фільтрації. В цьому випадку потрібно вказати для регістрів фільтри, що дозволяють отримати найкращу селективність, не знаючи, що за умовами фільтрації в регістрі повинні бути відповідні індекси.

Уповільнювати час виконання операцій і, отже, збільшувати інтенсивність блокувань 1С крім запуску важких звітів може неоптимальне налаштування MS SQL та MS Windows. Ця проблема виявляється у 95% клієнтів. Слід зазначити, що це сервери серйозних організацій, їхньою підтримкою та налаштуванням займаються цілі відділи висококваліфікованих адміністраторів.

Основною причиною неправильного налаштування сервера є страх адміністраторів що-небудь міняти на працюючому сервері і правило «Найкраще – ворог хорошого». Якщо адміністратор змінить налаштування сервера і почнуться проблеми, весь гнів начальства виллється на недбайливого адміна. Тому йому вигідніше залишити все як є, і не робити жодного кроку без розпорядження начальства, ніж експериментувати під свою відповідальність.

Друга причина – відсутність чіткої інформації з проблем оптимізації в мережі. Існує дуже багато думок, які часто повністю суперечать одна одній. Кожна думка, присвячена оптимізації, має своїх противників і фанатик, які його відстоюватимуть. В результаті, інтернет та форуми швидше плутають у справі налаштування серверів, ніж допомагають. У такій невизначеності у адміністратора ще менше бажання змінювати щось на сервері, який хоч якось, але працює.

На перший погляд, картина ясна – потрібно оптимізувати все, що гальмує роботу сервера 1С. Але давайте уявимо себе на місці такого оптимізатора – допустимо у нас 1С 8.1 8.2 8.3 УПП та одночасно працюють 50 користувачів. Один жахливий день користувачі починають скаржитися, що 1С гальмує, і нам потрібно вирішити цю проблему.

Насамперед дивимося, що відбувається на сервері - раптом там якийсь особливо самостійний антивірус проводить повну перевірку системи. Огляд показує, що все пристойно - сервер навантажений під 100%, причому процесом sqlservr.

З практики: один з молодших адміністраторів за своєю ініціативою включив на сервері автооновлення, Windows і SQL радісно оновилися, і після оновлення почалося масове уповільнення роботи користувачів 1С або просто 1С зависає.

Наступний крок – перевіряємо, які програми навантажують MS SQL. Огляд показує, що навантаження створюється приблизно з 20 з'єднань сервера додатків.

З практики: зациклилася програма, що оперативно оновлює дані на сайті, і замість того, щоб оновлювати раз на 4 години - робила це не перестаючи, без пауз, сильно навантажуючи сервер, і блокуючи дані.

Подальший аналіз ситуації стикається з великими труднощами. Ми вже з'ясували, що навантаження йде безпосередньо з 1С, але як зрозуміти, що роблять користувачі? Або хоча б, хто вони. Добре, якщо користувачів 1С в організації 10, тоді можна просто пройтися по них і дізнатися, чим вони зараз займаються, але в нашому випадку їх півсотні, і вони розкидані по кількох будинках.

У нами прикладі ситуація ще не сама я складна. А уявіть, що уповільнення роботи не сьогодні, а вчора. Сьогодні ситуація не повторюється, все гаразд, але Вам потрібно розібратися, чому вчора оператори не могли працювати (скаржилися вони природно тільки перед відходом додому, тому що базікати весь день, тому що нічого не працює, їм подобається більше, ніж працювати ). Це випадок підкреслює необхідність системи логування серверів, яка завжди вестиме історію основних параметрів роботи сервера і за якою можна відновити послідовність подій.

Система логування – просто незамінний інструмент для оптимізації системи. Якщо додати до нього ще й можливість онлайн-перегляду поточного стану – вийде система моніторингу стану сервера. Кожен проект оптимізації починається зі збирання статистики станів сервера, щоб виявити вузькі місця.

Коли ми почали працювати на ниві оптимізації, то перепробували багато систем моніторингу серверів, на жаль, знайти щось, що вирішує це завдання на належному рівні, нам не вдалося, тому довелося створювати систему самотужки. В результаті вийшов унікальний продукт PerfExpert, який дозволив автоматизувати та поставити на потік процеси оптимізації IT-систем. Програму відрізняють щільна інтеграція з 1С, відсутність дещо помітного додаткового навантаження і багаторазово перевірена придатність для практичного використання в бойових ситуаціях.

Повертаючись до нашого прикладу – найімовірніший результат: Адміністратор каже «Винні програмісти, які писали конфігурацію», програмісти у відповідь – «У нас все написано добре – це сервер погано працює». А віз, як то кажуть, і нині там. У результаті 1С гальмує, зависає чи працює повільно.

У будь-якому випадку для вирішення проблем продуктивності 1С ми рекомендуємо для початку придбати та використовувати моніторинг продуктивності PerfExpert , це дозволить Вам прийняти правильне управлінське рішення та заощадити гроші. Продукт підходить як для невеликих ІС 1С: Підприємство – до 50 користувачів, так і для систем – від 1000 користувачів. З липня 2015 року моніторинг продуктивності PerfExpert отримав сертифікат 1С:Сумісно, ​​пройшов тестування в Microsoft та допомагає вирішувати проблеми продуктивності не тільки для систем 1С, але й для інших інформаційних систем на базі MS SQL Server (Axapta, CRM Dynamics, Doc Vision та інші).

Якщо Вам сподобалася інформація, рекомендовані подальші дії:

- Якщо Ви хочете самостійно розбиратися з технічними проблемами продуктивності 1С (1С 7.7, 1С 8.1, 1С 8.2,1С 8.3) та інших інформаційних систем, то для Вас унікальний список технічних статей у нашому Альманасі (Блокування та взаємоблокування, велике навантаження на CPU та диски, обслуговування баз даних та індексний тюнінг – лише мала частина технічних матеріалів, які Ви там знайдете).
.
- Якщо Ви хочете обговорити з нашим експертом проблеми продуктивності або замовити рішення моніторингу продуктивності PerfExpert, то залиште заявку і ми зв'яжемося з Вами у найкоротші терміни.

2. Особливість роботи програми. Часто навіть за оптимальних налаштувань 1С працює дуже повільно. Особливо сильно швидкодію падає, коли кількість одночасно працюючих з базою перевищує 4-5 користувачів.

Хто ви у компанії?

Вирішення проблеми повільної роботи 1С залежить від того, хто ви в компанії. Якщо ви технічний фахівець – просто читайте далі. Якщо ви директор або бухгалтер, переходьте за спеціальним посиланням ↓

Пропускна спроможність мережі

Як правило, з однією інформаційною базою (ІБ) працює не один, а декілька користувачів. При цьому постійно йде обмін даними між комп'ютером, на якому встановлений клієнт 1С і комп'ютером, на якому розташована ІБ. Обсяг цих даних досить суттєвий. Часто виникає ситуація, коли локальна мережа працює на швидкості 100 Мбіт/с, а це швидкість, що найчастіше зустрічається, просто не справляється з навантаженням. І знову користувач скаржиться на гальма у програмі.

Кожен із цих факторів окремо вже суттєво знижує швидкість роботи програми, але найнеприємніше, що зазвичай ці речі підсумовуються.

Тепер давайте розглянемо кілька розв'язань проблеми з низькою швидкістю роботи 1С та їхню вартість, на прикладі локальної мережі з 10 середніх комп'ютерів.

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

Це, мабуть, найочевидніше рішення. Розрахуємо його мінімальну вартість.

Як мінімум, на кожен комп'ютер нам знадобиться планка оперативної пам'яті на 2 Гб, коштує в середньому 1500 руб, мережна карта з підтримкою швидкості 1 Гбіт/c коштує близько 700 руб. Додатково знадобиться щонайменше 1 маршрутизатор, що підтримує швидкість роботи 1 Гбіт/с, який обійдеться приблизно 4000 руб. Отже, вартість - 26000 рублів на обладнання, без урахування робіт.

В принципі, швидкість може суттєво зрости, проте тепер купувати в офіс недорогі комп'ютери вже не вийде. Крім того, дане рішення не застосовується для тих, хто використовує Wi-Fi або хоче працювати через інтернет - у їхньому випадку швидкість мережі може бути в десятки разів нижчою. Напрошується думка: «А чи не можна реалізувати роботу програми цілком на одному потужному сервері, щоб комп'ютер не брав участь у складних розрахунках, а служив просто для передачі зображення?» Тоді можна працювати навіть на дуже слабких комп'ютерах, навіть у мережах із низькою пропускною здатністю. Природно, такі рішення існують.

Рішення друге. Сервер терміналів

Набув великої популярності ще за часів 1С 7. Реалізований на серверній версії Windows і чудово справляється з нашим завданням. Однак, має своє підводне каміння, а саме - вартість ліцензій.

Сама операційна система обійдеться десь 40000 руб. Додатково до цього нам знадобиться для кожного, хто планує працювати в 1С ще ліцензія Windows Server CAL, вартістю приблизно 1700 руб і ліцензія Windows Remote Desktop Services CAL, яка коштує близько 5900 руб.

Порахувавши вартість мережі з 10 комп'ютерів, ми отримаємо в результаті 116 000 руб. лише на одні ліцензії. Додайте до цього вартість самого сервера (мінімум 40 000 руб) і вартість робіт із впровадження, втім, навіть без цього, ціна на ліцензії вийшла значною.

Рішення третє. Сервіс 1С Підприємства

Фірма 1С розробила своє вирішення цієї проблеми, здатне серйозно підвищити швидкість програми. Але тут є нюанс.

Справа в тому, що ціна такого рішення становить від 50 000 до 80 000 руб., Залежно від редакції. Для компанії до 15 користувачів виходить дорого. Великі надії покладалися на "міні-сервер 1С підприємства", який, за заявами фірми 1С, орієнтований на малий бізнес і коштує в районі 10000 – 15000 руб.

Однак, надійшовши у продаж, цей продукт став великим розчаруванням. Справа в тому, що максимальна кількість користувачів, з якими міні-сервер можна було використовувати, становила лише 5.

Як написав на форумі один програміст 1С: «Досі не зрозуміло, чому 1С обрала саме 5 підключень! Від чотирьох користувачів проблеми тільки починаються, а тут на п'яти все закінчується. Хочеш підключити шостого – доплати ще 50 тис. Зробили б хоч на 10 підключень…»

Звісно, ​​міні-сервер теж знайшов свого споживача. Однак для компаній, де з 1С працюють від 5 осіб, так і не з'явилося простого та недорогого рішення.

Крім описаних вище методів прискорення програми, існує ще один, що ідеально підходить для сегмента 5 - 15 користувачів, а саме - web-доступ для 1С у файловому режимі.

Рішення четверте. Web-доступ для 1С у файловому режимі

Принцип роботи наступний: на комп'ютері піднімається додаткова роль web-сервера, де відбувається публікація ІБ.

Звичайно, це має бути або найпотужніший комп'ютер у мережі, або окрема машина, виділена під цю роль. Після цього, з 1С можна працювати в режимі веб-сервера. Всі важкі операції будуть виконуватися на стороні сервера, а трафік, що передається по мережі, буде зведений до мінімуму, як і навантаження на комп'ютер клієнта.

Таким чином, для роботи в 1С можна використовувати дуже слабкі машини, а пропускна здатність мережі ставати не критичною. Наші тести показали, що можна комфортно працювати через мобільний інтернет на дешевому планшеті, при цьому не відчуваючи дискомфорту.

Даний варіант поступається серверу 1С підприємства за швидкістю роботи, але ця різниця до 15-20 користувачів візуально практично не помітна. До речі, для реалізації web-сервера можна використовувати IIS (для Windows) та Apache (для Linux) і обидва ці рішення безкоштовні!

Незважаючи на очевидні переваги, даний спосіб оптимізації роботи 1С не набув великої популярності.

Не беруся стверджувати напевно, але швидше за все це пов'язано з двома причинами:

• Досить слабкий опис у технічній документації
• Знаходиться на стику відповідальності системного адміністратора та програміста 1С

Зазвичай, коли із проблемою низької швидкості роботи звертаються до сисадміну, він пропонує модернізацію інфраструктури чи сервер терміналів, якщо спеціалісту 1С - пропонується сервер 1С підприємства. Так що, якщо у вашій компанії, фахівець, що відповідає за інфраструктуру і фахівець, що відповідає за 1С, працюють «пліч-о-пліч», то сміливо можете скористатися рішенням на базі web-сервера.

Прискоримо 1С. Дистанційно, швидко та без вашої участі

Ми вміємо прискорювати 1Скі і при цьому не смикати замовника. Ми вникаємо в проблему, робимо свою роботу та йдемо. Якщо вам хочеться, щоб програма просто нормально працювала – зверніться до нас. Ми розберемося.

Залишіть заявку - та отримайте безкоштовну консультацію щодо прискорення програми.