Чаму тармозіць 1С 8.3? Файлавы рэжым.

  1. Спажыванне рэсурсаў, першы погляд
  2. сетка
  3. Дык чаму ж 1С тармозіць? Будзем разбірацца далей.
  4. Дыскавая падсістэма кліента і SSD
  5. Аператыўная памяць
  6. працэсар
  7. высновы

Да нас часта прыходзяць пытанні пра тое што тармозіць 1с, асабліва пры пераходзе на версію 1с 8.3, благодоря нашым калегам з ТАА "Інтэрфейс", мы падрабязна распавядаем:

У нашых мінулых публікацыях мы ўжо тычыліся ўплыву прадукцыйнасці дыскавай падсістэмы на хуткасць працы 1С, аднак дадзенае даследаванне тычылася лакальнага выкарыстання прыкладання на асобным ПК або тэрмінальным серверы. У той жа час большасць невялікіх укараненняў мяркуюць працу з файлавай базай па сетцы, дзе ў якасці сервера выкарыстоўваецца адзін з карыстацкіх ПК, альбо выдзелены файлавы сервер на базе звычайнага, часцей за ўсё таксама недарагога, кампутара.

Невялікае даследаванне рускамоўных рэсурсаў па 1С паказала, што гэта пытанне старанна абыходзіцца бокам, у выпадку ўзнікнення праблем звычайна раіцца пераход да кліент-сервернага або тэрмінальная рэжыму. А таксама практычна агульнапрынятым стала меркаванне, што канфігурацыі на кіраваным дадатку працуюць значна павольней звычайных. Як правіла аргументы прыводзяцца "жалезныя": "вось Бухгалтэрыя 2.0 проста лётала, а" тройка "ледзьве варушыцца", безумоўна, для праўды ў гэтых словах ёсць, таму паспрабуем разабрацца.

Спажыванне рэсурсаў, першы погляд

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

Для тэставання мы ўзялі дзве віртуальныя машыны пад кіраваннем Windows Server 2012 R2 і Windows 8.1 адпаведна, вылучыўшы ім па 2 ядра хостового Core i5-4670 і 2 ГБ аператыўнай памяці, што адпавядае прыкладна сярэдняй офіснай машыне. Сервер размясцілі на RAID 0 масіве з двух WD Se, а кліент на аналагічным масіве з дыскаў агульнага прызначэння.

У якасці паддоследных баз мы выбралі некалькі канфігурацый бухгалтэрыі 2.0, рэлізу 2.0.64.12, якую затым абнавілі да 3.0.38.52, усе канфігурацыі запускаліся на платформе 8.3.5.1443.

Першае, што звяртае на сябе ўвагу, гэта які вырас памер інфармацыйнай базы "тройкі", прычым істотна вырас, а таксама значна вялікія апэтыты да аператыўнай памяці:

Першае, што звяртае на сябе ўвагу, гэта які вырас памер інфармацыйнай базы тройкі, прычым істотна вырас, а таксама значна вялікія апэтыты да аператыўнай памяці:

Мы ўжо гатовыя пачуць звыклае: "так чаго яны там такога дадалі ў гэтую тройку", але давайце не будзем спяшацца. У адрозненне ад карыстальнікаў кліент-серверная версій, якія патрабуюць наяўнасці больш-менш кваліфікаванага адміністратара, карыстальнікі файлавых версій вельмі рэдка задумваюцца аб абслугоўванні баз. Таксама рэдка пра гэта думаюць абслугоўваюць (чытай - абнаўляюць) гэтыя базы супрацоўнікі спецыялізаваных фірмаў.

Між тым інфармацыйная база 1С - гэта паўнавартасная СКБД свайго фармату, якая таксама патрабуе абслугоўвання і для гэтага нават ёсць інструмент, які называецца Тэставанне і выпраўленне інфармацыйнай базы. Магчыма злы жарт згуляла назву, якое як-бы мае на ўвазе, што гэта інструмент для ліквідацыі праблем, але нізкая прадукцыйнасць - таксама праблема, а рэструктурызацыя і реиндексация, разам з выкарыстаннем кампрэсіі табліц - добра вядомыя любому адміністратару СКБД сродкі аптымізацыі баз дадзеных. Праверым?

Пасля ўжывання выбраных дзеянняў база рэзка "схуднела", стаўшы нават менш "двойкі", якую таксама ніхто ніколі не аптымізаваў, таксама трохі зменшылася спажыванне АЗП.

У далейшым, пасля загрузкі новых класіфікатараў і даведнікаў, стварэння індэксаў і да т.п. памер базы вырасце, у цэлым базы "тройкі" больш баз "двойкі". Аднак больш важна не гэта, калі другая версія здавольвалася 150-200 МБ аператыўнай памяці, то новай рэдакцыі трэба ўжо полгигабайта і з гэтага значэння варта зыходзіць, плануючы неабходныя рэсурсы для працы з праграмай.

сетка

Прапускная здольнасць сеткі - адзін найбольш важных параметраў для сеткавых прыкладанняў, асабліва, як 1С ў файлавым рэжыме, перамяшчаюць па сетцы значныя аб'ёмы дадзеных. Большасць сетак невялікіх прадпрыемстваў пабудаваныя на базе недарагога 100 Мбіт / с абсталявання, таму мы пачалі тэставанне менавіта са параўнання паказчыкаў прадукцыйнасці 1С ў сетках 100 Мбіт / с і 1 Гбіт / с.

Што адбываецца пры запуску файлавай базы 1С па сетцы? Кліент запампоўвае ў часавыя тэчкі досыць вялікая колькасць інфармацыі, асабліва калі гэта першы, "халодны", запуск. На 100 Мбіт / с мы чакана упремся у шырыню канала і загрузка можа заняць значнае час, у нашым выпадку каля 40 секунд (кошт дзялення графіка - 4 сек).

На 100 Мбіт / с мы чакана упремся у шырыню канала і загрузка можа заняць значнае час, у нашым выпадку каля 40 секунд (кошт дзялення графіка - 4 сек)

Другі запуск адбываецца хутчэй, так як частка дадзеных захоўваецца ў кэшы і знаходзіцца там да перазагрузкі. Пераход на гігабітную сетку здольны значна паскорыць загрузку праграмы, як "халодны", так і "гарачы", прычым суадносіны значэнняў пры гэтым выконваецца. Таму мы вырашылі выказаць вынік у адносных значэннях, узяўшы за 100% самае вялікае значэнне кожнага вымярэння:

Таму мы вырашылі выказаць вынік у адносных значэннях, узяўшы за 100% самае вялікае значэнне кожнага вымярэння:

Як можна заўважыць з графікаў, Бухгалтэрыя 2.0 загружаецца пры любой хуткасці сеткі ўдвая хутчэй, пераход са 100 Мбіт / с на 1 Гбіт / с дазваляе паскорыць час загрузкі ў чатыры разы. Розніцы паміж аптымізаванай і неоптимизированной базамі "тройкі" у дадзеным рэжыме не назіраецца.

Таксама мы праверылі ўплыў хуткасці сеткі на працу ў цяжкіх рэжымах, напрыклад, пры групавым перепроведении. Вынік таксама выяўлены ў адносных значэннях:

Тут ужо цікавей, аптымізаваная база "тройкі" ў 100 Мбіт / с сеткі працуе з такой жа хуткасцю, як і "двойка", а неоптимизированная паказвае удвая горшы вынік. На гігабіт суадносін захоўваюцца, неоптимизированная "тройка" таксама ўдвая павольней "двойкі", а аптымізаваная адстае на траціну. Таксама пераход на 1 Гбіт / с дазваляе скараціць час правядзення ў тры разы для рэдакцыі 2.0 і ў два разы для 3.0.

Для таго, каб ацаніць уплыў хуткасці сеткі на паўсядзённае працу мы скарысталіся замеры прадукцыйнасці, выканаўшы ў кожнай базе паслядоўнасць загадзя наканаваных дзеянняў.

Для таго, каб ацаніць уплыў хуткасці сеткі на паўсядзённае працу мы скарысталіся замеры прадукцыйнасці, выканаўшы ў кожнай базе паслядоўнасць загадзя наканаваных дзеянняў

Уласна, для паўсядзённых задач прапускная здольнасць сеткі не з'яўляецца вузкім месцам, неоптимизированная "тройка" усяго толькі на 20% больш павольна двойкі, а пасля аптымізацыі аказваецца прыкладна настолькі ж хутчэй - адбіваюцца перавагі працы ў рэжыме тонкага кліента. Пераход на 1 Гбіт / с не дае аптымізаванай базе ніякіх пераваг, а неоптимизированная і двойка пачынаюць працаваць хутчэй, паказваючы невялікую розніцу паміж сабой.

З праведзеных тэстаў становіцца відавочна, што сетка не з'яўляецца вузкім месцам для новых канфігурацый, а кіраванае прыкладанне працуе нават хутчэй, чым звычайна. Таксама можна рэкамендаваць пераход на 1 Гбіт / с калі для вас крытычныя цяжкія задачы і хуткасць загрузкі баз, у астатніх выпадках новыя канфігурацыі дазваляюць эфектыўна працаваць нават у павольных 100 Мбіт / с сетках.

Дык чаму ж 1С тармозіць? Будзем разбірацца далей.

Дыскавая падсістэма сервера і SSD

У мінулым матэрыяле мы дамагліся павелічэння прадукцыйнасці 1С размясціўшы базы на SSD. Магчыма недастаткова прадукцыйнасці дыскавай падсістэмы сервера? Мы зрабілі замеры прадукцыйнасці дыскавай сервера падчас групавога правядзення адразу ў двух базах і атрымалі даволі аптымістычны вынік.

Нягледзячы на ​​адносна вялікая колькасць аперацый уводу-высновы ў секунду (IOPS) - 913, даўжыня чаргі не перавысіла 1,84, што для двухдыскавага масіва вельмі добры вынік. Зыходзячы з яго можна зрабіць здагадку, што люстэрка са звычайных дыскаў будзе дастаткова для нармальнай працы 8-10 сеткавых кліентаў у цяжкіх рэжымах.

Дык ці патрэбны SSD на сэрвэры? Лепш за ўсё адказаць на гэтае пытанне дапаможа тэставанне, якое мы правялі па аналагічнай методыцы, сеткавае падключэнне ўсюды 1 Гбіт / с, вынік таксама выяўлены ў адносных значэннях.

Пачнем са хуткасці загрузкі базы.

Можа быць камусьці і падасца дзіўным, але на хуткасць загрузкі базы SSD на сэрвэры не ўплывае. Асноўны стрымальны фактар ​​тут, як паказаў папярэдні тэст, прапускная здольнасць сеткі і прадукцыйнасць кліента.

Пяройдзем да перепроведению:

Пяройдзем да перепроведению:

Вышэй мы ўжо адзначалі, што прадукцыйнасці дыскавай цалкам дастаткова нават для працы ў цяжкіх рэжымах, таму на хуткасць правядзення SSD таксама не аказвае ўплыву, акрамя неоптимизированной базы, якая на SSD дагнала аптымізаваную. Уласна, гэта яшчэ раз пацвярджае, што аперацыі аптымізацыі парадкуюцца інфармацыю ў базе дадзеных, памяншаючы колькасць выпадковых аперацый ўводу высновы і павялічваючы хуткасць доступу да яе.

На паўсядзённых задачах карціна аналагічная:

Выйгрыш ад SSD атрымлівае толькі неоптимизированная база. Вы, вядома, можаце набыць SSD, але значна лепш будзе задумацца аб своечасовым абслугоўванні баз. Таксама не забывайце аб дэфрагментацыі падзелу з інфармацыйнымі базамі на сэрвэры.

Дыскавая падсістэма кліента і SSD

Ўплыў SSD на хуткасць працы лакальна ўсталяванай 1С мы разбіралі ў папярэднім матэрыяле, многае з сказанага справядліва і для працы ў сеткавым рэжыме. Сапраўды, 1С досыць актыўна выкарыстоўвае дыскавыя рэсурсы, у тым ліку і для фонавых і рэгламентных задач. На малюнку ніжэй можна бачыць, як Бухгалтэрыя 3.0 даволі актыўна звяртаецца да дыска ў плыні каля 40 секунд пасля загрузкі.

Але пры гэтым варта ўсведамляць, што для рабочай станцыі дзе актыўная праца вырабляецца з адной - дзвюма інфармацыйнымі базамі рэсурсаў прадукцыйнасці звычайнага HDD масавай серыі цалкам дастаткова. Набыццё SSD здольна паскорыць некаторыя працэсы, але радыкальнага паскарэння ў паўсядзённай працы вы не заўважыце, так як, напрыклад, загрузка будзе абмяжоўвацца прапускной здольнасцю сеткі.

Павольны жорсткі дыск здольны запаволіць некаторыя аперацыі, але сам па сабе з'яўляцца прычынай тармажэння праграмы не можа.

Аператыўная памяць

Нягледзячы на ​​тое, што аператыўка зараз непрыстойна танная, многія працоўныя станцыі працягваюць працаваць з тым аб'ёмам памяці, які быў усталяваны пры куплі. Вось тут і пільнуюць першыя праблемы. Ужо зыходзячы з таго, што ў сярэднім "тройцы" патрабуецца каля 500 МБ памяці можна выказаць здагадку, што агульнага аб'ёму аператыўнай памяці ў 1ГБ для працы з праграмай будзе недастаткова.

Мы паменшылі памяць сістэмы да 1 Гб і запусцілі дзве інфармацыйныя базы.

Мы паменшылі памяць сістэмы да 1 Гб і запусцілі дзве інфармацыйныя базы

На першы погляд усё не так і дрэнна, праграма зменшыць апетыты і цалкам ўклалася ў даступную памяць, але не будзем забываць, што патрэба ў аператыўных дадзеных не змянілася, так куды ж яны дзеліся? Скінутыя ў дыскавы, кэш, падпампоўку і да т.п., сутнасць гэтай аперацыі складаецца ў тым, што не патрэбныя ў дадзены момант дадзеныя адпраўляюцца з хуткай аператыўнай памяці, колькасці якой недастаткова, у павольную дыскавую.

Да чаго гэта прывядзе? Паглядзім, як выкарыстоўваюцца рэсурсы сістэмы ў цяжкіх аперацыях, напрыклад, запусцім групавое перепроведение адразу ў двух базах. Спачатку на сістэме з 2 ГБ аператыўнай памяці:

Як бачым, сістэма актыўна выкарыстоўвае сетку, для атрымання дадзеных і працэсар для іх апрацоўкі, дыскавая актыўнасць нязначная, у працэсе выканання апрацоўкі яна эпізадычна вырастае, але не з'яўляецца стрымліваючым фактарам.

Цяпер паменшым памяць да 1 ГБ:

Цяпер паменшым памяць да 1 ГБ:

Сітуацыя радыкальным чынам мяняецца, асноўная нагрузка зараз прыходзіцца на жорсткі дыск, працэсар і сетка прастойваюць, чакаючы пакуль сістэма лічыць з дыска ў памяць патрэбныя дадзеныя і адправіць туды непатрэбныя.

Пры гэтым нават суб'ектыўная праца з двума адкрытымі базамі на сістэме з 1 ГБ памяці апынулася вельмі некамфортным, даведнікі і часопісы адкрываліся са значнай затрымкай і актыўным зваротам да дыска. Напрыклад, адкрыццё часопіса Рэалізацыя тавараў і паслуг заняло каля 20 секунд і суправаджалася ўвесь гэты час высокай дыскавай актыўнасцю (вылучана чырвонай лініяй).

Каб аб'ектыўна ацаніць уплыў аператыўнай памяці на прадукцыйнасць канфігурацый на аснове кіраванага прыкладання мы правялі тры вымярэння: хуткасць загрузкі першай базы, хуткасць загрузкі другі базы і групавое перепроведение ў адной з баз. Абедзве базы цалкам ідэнтычныя і створаны капіяваннем аптымізаванай базы. Вынік выяўлены ў адносных адзінках.

Вынік гаворыць сам за сябе, калі час загрузкі вырастае прыкладна на траціну, што яшчэ цалкам памяркоўна, то час выканання аперацый у базе вырастае ў тры разы, ні пра якую камфортнай працы ў такіх умовах казаць не прыходзіцца. Дарэчы, гэта той выпадак, калі купля SSD здольная палепшыць сітуацыю, але значна прасцей (і танней) змагацца з прычынай, а не з наступствамі, і проста купіць патрэбную колькасць аператыўнай памяці.

Недахоп аператыўнай памяці - асноўная прычына па якой праца з новымі канфігурацыямі 1С аказваецца некамфортным. Мінімальна падыходнымі варта лічыць канфігурацыі з 2 ГБ памяці на борце. Пры гэтым улічвайце, што ў нашым выпадку былі створаны "цяплічныя" ўмовы: чыстая сістэма, запушчаныя толькі 1С і дыспетчар задач. У рэальным жыцці на працоўным кампутары як правіла адкрыты браўзэр, офісны пакет, працуе антывірус і г.д, і да т.п., таму зыходзіце з патрэбы 500 МБ на адну базу плюс некаторы запас, каб пры цяжкіх аперацыях вы не сутыкнуліся з недахопам памяці і рэзкім зніжэннем прадукцыйнасці.

працэсар

Цэнтральны працэсар без перабольшання можна назваць сэрцам кампутара, так як менавіта ён, у канчатковым выніку, ажыццяўляе апрацоўку ўсіх вылічэнняў. Каб ацаніць яго ролю мы правялі яшчэ адзін набор тэстаў, такі ж, як і для аператыўнай памяці, паменшыўшы колькасць даступных віртуальнай машыне ядраў з двух да аднаго, пры гэтым тэст выконваўся два разы з аб'ёмамі памяці ў 1 ГБ і 2 ГБ.

Вынік апынуўся даволі цікавым і нечаканым, больш магутны працэсар даволі эфектыўна браў на сябе нагрузку ва ўмовах недахопу ў рэсурсах, у астатні час не даючы якіх-небудзь адчувальных пераваг. 1С Прадпрыемства складана назваць дадаткам, актыўна выкарыстоўваюць працэсарныя рэсурсы, хутчэй за непатрабавальным. А ў цяжкіх умовах на працэсар кладзецца нагрузка не столькі па аблік дадзеных самога прыкладання, колькі абслугоўвання накладных выдаткаў: дадатковых аперацый ўводу высновы і да т.п.

высновы

Такім чынам, чаму тармозіць 1С? У першую чаргу гэта недахоп аператыўнай памяці, асноўная нагрузка ў гэтым выпадку кладзецца на жорсткі дыск і працэсар. А калі яны не бліскаюць прадукцыйнасцю, як гэта звычайна бывае ў офісных канфігурацыях, то атрымліваем сітуацыю, апісаную ў пачатку артыкула - "двойка" працавала нармальна, а "тройка" бязбожна тармозіць.

На другое месца каштуе вынесці прадукцыйнасць сеткі, павольны 100 Мбіт / с канал здольны стаць рэальным бутэлькавым горлышком, але ў той жа час рэжым тонкага кліента здольны падтрымліваць даволі камфортны ўзровень работы нават на павольных каналах.

Затым варта звярнуць увагу на дыскавую, купля SSD наўрад ці будзе добрым укладаннем грошай, а вось замяніць дыск на больш сучасны будзе не лішнім. Розніцу паміж пакаленнямі жорсткіх дыскаў можна ацаніць па наступным матэрыяле: Агляд двух недарагіх дыскаў серыі Western Digital Blue 500 ГБ і 1 ТБ.

І нарэшце працэсар. Больш хуткая мадэль вядома ж не будзе лішняй, але вялікага сэнсу павялічваць яго прадукцыйнасць няма, калі толькі дадзены ПК не выкарыстоўваецца для цяжкіх аперацый: групавых апрацовак, цяжкіх справаздач, закрыцця месяца і да т.п.

Спадзяемся дадзены матэрыял дапаможа вам хутчэй разабрацца ў пытанні "чаму тармозіць 1С" і вырашыць яго найбольш эфектыўна і без лішніх выдаткаў.

крыніца: http: //interface31.ru/tech_it/2015/04/pochemu-tormozit-1s-faylovyy-rezhi ...

Праверым?
Што адбываецца пры запуску файлавай базы 1С па сетцы?
Дык чаму ж 1С тармозіць?
Магчыма недастаткова прадукцыйнасці дыскавай падсістэмы сервера?
Дык ці патрэбны SSD на сэрвэры?
На першы погляд усё не так і дрэнна, праграма зменшыць апетыты і цалкам ўклалася ў даступную памяць, але не будзем забываць, што патрэба ў аператыўных дадзеных не змянілася, так куды ж яны дзеліся?
Да чаго гэта прывядзе?