Агульны падыход да аптымізацыі

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С для палягчэння іх далейшай падтрымкі і абнаўлення. У відэа выкарыстаны матэрыялы ...