Загальний підхід до оптимізації

1. 1. Поточний стан
2. 2. Уточнюючі питання
3. 3. 3 основних види проблем
4. 3.1 Проблеми неоптимального коду, довго виконуються операції:
5. 3.2 Проблеми завантаженості обладнання
6. 3.3 Проблеми паралельної роботи користувачів
7. 4. Висновок
8. Дивіться також:

Добрий день друзі! Сьогодні я хочу розповісти вам про загальний підхід до вирішення проблем продуктивності. Ця стаття буде невеликим практичним посібником «З якого боку підійти до цього звіра», якщо у вас виникла проблема продуктивності роботи 1С.

1. Поточний стан

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

1. Пацієнт при смерті. Ключові операції не виконуються, виконуються нестерпно довго, все в помилках, блокування, нічого не працює, клієнт в паніці. Потрібна реанімація. Дана ситуація характерна тим, що всі проблеми чітко видно, не потрібні ніякі APDEXи, нудні виміри та інші дії, яким нас вчать на курсах по продуктивності. Єдине, що нам треба зробити - забезпечити працездатність бази.
2. Пацієнт хворий. У даній ситуації система працює, але продуктивність її незадовільна. І ось в цій ситуації якраз не треба відразу починати виправляти проблеми. Справа в тому, що ключовим в успіху нашої роботи буде досягнення гарної продуктивності системи. Але що є хороша продуктивність? Нам обов'язково треба визначити це кінцевий стан. Тут ми використовуємо методику APDEX, поки нічого кращого не придумали. За допомогою цієї методики ми визначимо поточний стан системи і стан, яке нам необхідно досягти. Прочитати про дану методику можна тут . Але головне, що нам необхідно зробити на початковому етапі лікування - розставити лічильники на ключових операціях і почати збирати інформацію про час їх виконання.

2. Уточнюючі питання

Відмінно, ми розібралися з первинним ознаками хвороби. Далі ми подивимося на проблеми більш детально, задамо правильні питання, і зможемо визначити, яка саме ці проблеми і як нам рухатися далі.

Отже, питання, які треба задати клієнту:

• Що саме гальмує? Окремі види документів, довідників, звітів, або все відразу? Якщо гальмують окремі об'єкти, то очевидно, що проблеми саме в цих об'єктах, або взаємодіючих з ними. Швидше за все, не оптимально написаний код, або конфлікти блокувань. Якщо ж гальмує все, починаючи від проведення РТіУ, закінчуючи відкриттям довідника Номенклатура, то проблема загального характеру, і в код можна особливо не дивитися, а перевіряти загальну працездатність системи та обладнання.
• Гальмують на відкриття, або запис / проведення? Або все відразу? Дана інформація підкаже нам, чи є проблеми «на читання», або «на запис», або присутні обидві проблеми.
• Почалися чи проблеми плавно, непомітно, або різко? Якщо різко, чи були які-небудь зміни в інфраструктурі? Наприклад, новий реліз платформи, або обладнання поміняли. Якщо проблеми з'явилися плавно, то, швидше за все, вони пов'язані з ростом бази / ростом числа користувачів / ростом документообігу. Якщо ж проблеми з'явилися різко, то потрібно шукати проблеми в обладнанні, системі 1С (помилки платформи, кластер серверів і т.д.)
• Проблеми проявляються з однаковою інтенсивністю протягом дня, або різною? Чи залежить інтенсивність проблем від кількості одночасно працюючих користувачів? Якщо інтенсивність виникнення проблем однакова, то це нам нічого не дасть, а ось якщо клієнт говорить, що вранці все добре, а до обіду працювати неможливо, то ймовірні проблеми, пов'язані зі збільшенням кількості працюючих користувачів до середини дня і збільшенням документообігу. Тут треба дивитися в бік завантаженості обладнання та проблем паралельної роботи користувачів.
• Які ще є проблеми? Помилки перевищення часу очікування блокування, помилки взаімоблокіровок? Якщо є помилки, пов'язані з транзакційними блокуваннями і користувачі скаржаться на них, то однозначно є проблеми паралельної роботи.

3. 3 основних види проблем

Резюмуючи, можна виділити 3 основні види проблем:

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

Нам необхідно встановити, який вид проблеми у нас. Залежно від виду проблем ми йдемо різними шляхами вирішення.

3.1 Проблеми неоптимального коду, довго виконуються операції:

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

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

3.2 Проблеми завантаженості обладнання

Симптоми: все гальмує, лічильники обладнання «Зашкалюють». Ця проблема вже трохи складніше. Оскільки причин може бути кілька. Необхідно визначити, чому обладнання так завантажено. Подивитися монітор активності SQL на предмет найважчих запитів, а так само включити збір технологічного журналу з показниками найважчих запитів. Якщо є ЦУП, то зібрати виміри за допомогою нього і проаналізувати. Найчастіше причина одна з двох: або є дуже важкі неоптимальні операції, які займають майже всі ресурси устаткування (в одній з статтею недавно я приводив приклад ), Або, якщо таких операцій не знайдено, все працює штатно, то проблема в недостатній продуктивності обладнання. Але завжди пам'ятайте! Перш ніж сказати клієнту, що у нього недостатньо продуктивне обладнання, переконайтеся, що це дійсно так і всі інші причини виключені. Тому що, коли клієнт купить новий сервер за $$$ і у нього все буде працювати так само не поспішаючи, він «вкрай здивується і засмутиться».

3.3 Проблеми паралельної роботи користувачів

Симптоми: тут симптомів буде багато. Помилки, як, наприклад, на даних скріншотах, тобто конфлікти блокувань.

Ну це очевидно 🙂. А тепер інші симптоми:

Все гальмує нестабільно. Наприклад, вранці все добре, до обіду - погано. У режимі одного все «літає», а в розрахованому на багато користувачів гальмує. Одні і ті ж дії займають «то 5 секунд, то 40». Стає зрозуміло, що користувачі конфліктують між собою.

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

4. Висновок

На закінчення хотів сказати про те, що обов'язково треба перевіряти при будь-яких проблемах продуктивності:

• Налаштування СУБД. Наприклад, в недавньому прикладі в налаштуваннях СУБД було зазначено використання невеликої кількості пам'яті . З цієї причини великі таблиці не могли кешуватися і дані зчитувалися безпосередньо з дисків, сильно завантажуючи дискову підсистему.
• Реліз платформи. Так, релізи не всі стабільні. Іноді проблема криється в помилках релізу, про це можна почитати в баг-репорт і на партнерському форумі.
• Регламентні операції з БД, актуальність статистики, фрагментація індексів. Актуальність статистики та фрагментація індексів безпосередньо впливають на продуктивність, потрібно проконтролювати виконання регламентних операцій.

Дивіться також:

• Історія однієї оптимізації

  Всім привіт. Сьогодні я вам розповім історію однієї оптимізації або як я відновлював нормальну роботу в <НазваніеКомпаніі>. Симптоми були оголошені наступні: загальна незадовільна продуктивність системи: ...

• Нотатки з фронту оптимізації

  Добрий день друзі! Сьогодні я вам розповім історію про оптимізацію типового запиту УПП при відновленні послідовності розрахунків. Буде багато букв, але цікаво. Оптимізувати будемо трьома шляхами: Beginner, medium, high. Поїхали! ...

• Правила доопрацювання типових конфігурацій 1С

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