Може да има няколко причини, поради които програмата замръзва:

1) погледнете количеството памет, разпределено от rphost на сървъра 1C. Ако имате x32 версия на сървъра, процесът може да използва максимум 1,75 GB RAM
Ако няма достатъчно памет, сървърът не може да приеме нови връзки или увисва, когато текущата сесия изисква допълнителна памет
www.viva64.com/ru/k/0036
2) Вижте настройките на „Работни настройки на сървъра“; Имах този проблем и сървърът продължи да замръзва. Моите настройки са приложени. На сървъра са разпределени 11 GB.
3) Може да има проблеми при настройването на Postgressql.

Предоставете характеристиките на вашия сървър, размерите на базата данни, конфигурациите на Postgressql. Трудно е да се каже без информация.

Моята конфигурация на PostgreSQL: https://drive.google.com/file/d/0B2qGCc-vzEVDMERVW...
Тази конфигурация е избрана за наличното количество RAM.
PostgreSQL инсталиран на Linux, 3 GB RAM, 3 CPU ядра.
Сървър 1C8: 11 GB RAM, 5 процесорни ядра
4 бази данни, приблизително 1 GB всяка (качени в dt)

Предоставете всички характеристики на вашия сървър: 1C8 сървър и база данни, физическа или виртуална, операционна система, количество RAM на всеки сървър, какъв тип CPU, колко RAM заемат процесите на rphost, колко са? Използвате ли RAID масив?

Преди това самият аз използвах PostgreSQL, но по време на процеса срещнах някои проблеми при стартиране на база данни на PostgreSQL и наскоро преминах към MS SQL.

Вашият сървър не е лош за тези бази данни. За да използвате PostgreSQL, трябва много добре да разбирате неговата конфигурация. Когато базите данни са малки, много грешки в конфигурацията се прощават. Когато току-що започнахме да прилагаме 1C + PostgreSQL, също имахме много чести проблеми с работата на базата данни (имаше чести замръзвания, работеше бавно). PostgreSQL е по-добре да се използва в Linux, не в Windows. Аз самият не съм специалист по база данни, за да настроя сървъра на базата данни, наехме специалист от 1Sbit и той ни го настрои и след това нямаше проблеми в работата.

съвет:
Имате големи бази данни, не пестете, наемете специалист по база данни, който може да я настрои вместо вас. Един човек не може да бъде експерт във всичко.

1) преди колко време сте проверили самата база данни и сте я индексирали отново? ВАКУУМ и РЕИНДЕКС
2) преди колко време сте тествали и коригирали базата данни с помощта на 1C инструменти?
3) регистрационният файл на базата данни поставен ли е на отделен твърд диск?
4) HDD силно ли е натоварен?

Помислете за преминаване към MS Sql; често той не изисква „на практика“ никаква конфигурация и е по-лесен за използване. За разлика от PostgreSQL, MS Sql е готов да работи веднага, но PostgreSQL трябва да бъде конфигуриран.

Ако имате въпроси, пишете, може би мога да помогна с нещо в Skype: tisartisar

Наемете специалист по настройка на база данни

Защо преминахме към MS SQL:
Използваме конфигурацията на UT и при затваряне на месеца понякога възникват грешки, които не могат да бъдат разрешени. Ако сте прехвърлили базата данни във файлов режим и сте започнали да затваряте месеца, тогава всичко се е затворило нормално, същата база данни е била заредена на сървъра на PostgreSQL при изчисляване на разходите, възникнали са грешки. По това време изоставахме с половин година в приключващите месеци поради плаващи грешки. Създадохме тестова база данни на MS SQL и месецът, който не можа да бъде затворен на PostgreSQL на MS Sql, беше затворен. Освен това закръгляването на цената в ценовата листа не работи правилно на PostgreSQL. Всъщност поддържа се работа с 1C на PostgreSQL, но все пак се препоръчва използването на MS SQl.
Поради това беше решено да се премине към MS SQL, защото... стабилността на работа 1C е по-скъпа.

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

1) колко памет е разпределена за MS SQL сървър? това е конфигурирано в самия MS SQL сървър.
2) Редовно тествайте базата данни с помощта на 1C
3) статия за това как да настроите архивиране и поддръжка. Това е важно и трябва да се прави редовно. Правя го всеки ден. Разгледайте всичките 3 части на ръководството.

Как да затворите програма, ако замръзне и спре да отговаря. Защо програмите замръзват? Кой е виновен и какво да прави? В тази статия ще се опитаме да анализираме основните причини и решения на този проблем.

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

Първо, успокойте се и дочетете статията. Абсолютно всеки е попадал в тази ситуация; всички програми са написани от хора, така че не са идеални. Основното, което трябва да разберем, е как да действаме правилно в такива случаи и защо това се случва.

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

Какво да не правите, ако програмата замръзне

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

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

Какво да направите, ако програмата замръзне

1. Преди да преминете към по-радикални методи, опитайте да го затворите в лентата на задачите, като щракнете с десния бутон върху замразената програма и изберете подходящия елемент.
2. Ако не помогне, отидете на доказания метод; за това ще трябва да стартираме диспечера на задачите. Можете да извикате диспечера на задачите, като използвате клавишната комбинация Ctrl + Shift + Esc (Windows 7) Ctrl + Alt + Del (Windows XP).

Интересуваме се от раздела „приложения“; тук се показват всички приложения, работещи в момента на компютъра. Търсим приложението, което е замразено (в моя пример това е програма) и щракнете → Край на задачата. По правило това е достатъчно!! Не помогна → точка 3.
3. Какво да направите, ако програмата продължава да замръзва? Отидете на следващия раздел → „Процеси“. Факт е, че всяка програма, която стартирате на вашия компютър, има някакъв процес или процеси, свързани с нея. И програмата, която в момента е замразена, също има свой собствен процес, който можете да разберете, като щракнете с десния бутон върху прекия път на програмата и изберете → „Свойства“. В моя пример това е процесът → VideoConverter.exe

Избирайки раздела процеси → потърсете вашия процес (в моя случай това е „VideoConverter.exe“) и щракнете → „край на процеса“ или, за да сте сигурни, → щракнете с десния бутон върху процеса → „Край на дървото на процеса“

Ето как, използвайки стандартните инструменти на Windows, можете да разрешите проблема със замразена програма. Можете също да затворите замразена програма, като използвате програми на трети страни, например програмата

Тази статия обсъжда основните фактори: когато 1C се забавя, 1C замръзва и 1C работи бавно. Данните са изготвени въз основа на дългогодишния опит на SoftPoint в оптимизирането на големи ИТ системи, изградени на базата на комбинацията 1C + MS SQL.

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

От практиката: Най-лесният начин за оптимизиране е 1C v7.7 (Оптимизирането на 1C 8.1, 1C 8.2, 1C 8.3 е по-трудна задача, тъй като приложението се състои от 3 връзки). Довеждането му до 400 едновременни потребители е доста типичен проект. До 1500 вече е трудно и изисква упорит труд.

Вторият мит: за да подобрите производителността на 1C и да се отървете от замръзванията на 1C, трябва да инсталирате по-мощен сървър. Като правило, в проекти за оптимизация в 95% от случаите е възможно да се постигне приемлива производителност или без изобщо да се надгражда, или чрез актуализиране на малка част от оборудването, например чрез добавяне на RAM. Трябва да се отбележи, че оборудването все още трябва да бъде базирано на сървър, особено дисковата подсистема. Остарялата дискова подсистема е само една от причините, поради които 1C работи бавно.

Основното ограничение при работа с много потребители в 1C е заключващият механизъм. Това е блокирането в 1C, а не сървърното оборудване, което обикновено не позволява на голям брой хора да работят в базата данни. За да преодолеете този проблем, трябва да работите усилено и да промените логиката на заключване в 1C - да ги намалите от таблични към редови. Тогава, например, публикуването на документ ще блокира само един, а не всички документи в системата.

Фигура 1. Опашка за блокиране на 1C в системата за наблюдение PerfExpert, с информация за потребителите на 1C, конфигурационен модул и конкретен ред код в този модул.

Смяната на заключващия механизъм 1C е много сложна технология. Не всеки може да направи такъв трик и за тях остава само един начин - оптимизиране на структурата и ускоряване на времето за изпълнение на операциите. Факт е, че блокирането в 1C и времето за изпълнение на операциите са силно взаимосвързани показатели. Например, ако операцията по публикуване на документ отнема 15 секунди, тогава ако има голям брой потребители, има голяма вероятност по време на прехвърлянето някой друг да се опита да публикува документа и да чака в блокиране. Ако увеличите времето за изпълнение до поне 1 секунда, тогава блокирането на 1C за тази операция ще бъде значително намалено.

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

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

Фигура 2. Зареждане на работещия сървър по отношение на конфигурационни модули от всички потребители. Всеки модул има свой собствен цвят. Има ясен дисбаланс в натоварването, създадено от 1C.

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

В допълнение към стартирането на тежки отчети, неоптималните настройки на MS SQL и MS Windows могат да забавят времето за изпълнение на операциите и следователно да увеличат интензивността на блокирането на 1C. Този проблем се среща при 95% от клиентите. Трябва да се отбележи, че това са сървъри на сериозни организации, в тяхната поддръжка и конфигуриране са ангажирани цели отдели от висококвалифицирани администратори.

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

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

На пръв поглед картината е ясна - трябва да оптимизирате всичко, което забавя работата на 1C сървъра. Но нека си представим себе си на мястото на такъв оптимизатор - да кажем, че имаме 1C 8.1 8.2 8.3 UPP и 50 потребители работят едновременно. Един ужасен ден потребителите започват да се оплакват, че 1C е бавен и трябва да решим този проблем.

На първо място, ние гледаме какво се случва на сървъра - какво ще стане, ако някой особено независим антивирус извършва пълно сканиране на системата. Проверка показва, че всичко е наред - сървърът се натоварва на 100% и то само от sqlservr процеса.

От практиката: един от младшите администратори по собствена инициатива включи автоматично актуализиране на сървъра, Windows и SQL щастливо се актуализираха и след актуализацията започна масово забавяне на работата на потребителите на 1C или 1C просто замръзна.

Следващата стъпка е да проверите кои програми зареждат MS SQL. Проверката показва, че натоварването се генерира от приблизително 20 връзки към сървър на приложения.

От практиката: програма, която своевременно обновява данните в уебсайт, влезе в цикъл и вместо да обновява веднъж на 4 часа, го прави непрекъснато, без паузи, натоварвайки силно сървъра и блокирайки данните.

По-нататъшният анализ на ситуацията е изправен пред големи трудности. Вече разбрахме, че натоварването идва директно от 1C, но как да разберем какво точно правят потребителите? Или поне кои са те. Добре е, ако в една организация има 10 потребители на 1C, тогава можете просто да ги прегледате и да разберете какво правят сега, но в нашия случай има петдесет от тях и те са разпръснати в няколко сгради.

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

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

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

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

Във всеки случай, за да разрешите проблеми с производителността на 1C, препоръчваме първо да закупите и използвате мониторинг на производителността PerfExpert , това ще ви позволи да вземете правилните управленски решения и да спестите пари. Продуктът е подходящ както за малки информационни системи 1C:Enterprise - до 50 потребители, така и за системи - от 1000 потребители. От юли 2015 г. мониторинг на изпълнението PerfExpert получи сертификат за 1C: Compatible, премина тестване в Microsoft и помага за решаване на проблеми с производителността не само за 1C системи, но и за други информационни системи, базирани на MS SQL Server (Axapta, CRM Dynamics, Doc Vision и други).

Ако сте харесали информацията, препоръчайте допълнителни действия:

- Ако искате самостоятелно да се справите с технически проблеми с производителността на 1C (1C 7.7, 1C 8.1, 1C 8.2,1C 8.3) и други информационни системи, тогава за вас има уникален списък с технически статии в нашия Алманах (Блокиране и задръствания, голямо натоварване на процесора и дисковете, поддръжка на база данни и настройка на индекса са само малка част от техническите материали, които ще намерите там).
.
- Ако искате да обсъдите проблеми с производителността с нашия експерт или да поръчате решение за мониторинг на производителността PerfExpert, след това оставете заявка и ние ще се свържем с вас възможно най-скоро.

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

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

Малко проучване на рускоезичните ресурси на 1C показа, че този проблем се избягва усърдно; ако възникнат проблеми, обикновено се препоръчва да преминете към режим клиент-сървър или терминал. Също така стана почти общоприето, че конфигурациите на управлявано приложение работят много по-бавно от обикновено. Като правило аргументите са „железни“: „Счетоводство 2.0 току-що излетя и „тройката“ едва се движи. Разбира се, в тези думи има известна истина, така че нека се опитаме да го разберем.

Консумация на ресурси, на пръв поглед

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

За тест взехме две виртуални машини, работещи съответно с Windows Server 2012 R2 и Windows 8.1, давайки им 2 ядра на хост Core i5-4670 и 2 GB RAM, което съответства приблизително на средна офис машина. Сървърът беше поставен на RAID 0 масив от два, а клиентът беше поставен на подобен масив от дискове с общо предназначение.

Като експериментални бази избрахме няколко конфигурации на Счетоводство 2.0, версия 2.0.64.12 , който след това беше актуализиран до 3.0.38.52 , всички конфигурации бяха стартирани на платформата 8.3.5.1443 .

Първото нещо, което привлича вниманието, е увеличеният размер на информационната база на Тройката, която е нараснала значително, както и много по-голям апетит за RAM:

Готови сме да чуем обичайното: „защо добавиха това към тези три“, но нека не бързаме. За разлика от потребителите на клиент-сървър версии, които изискват повече или по-малко квалифициран администратор, потребителите на файлови версии рядко мислят за поддържане на бази данни. Освен това служителите на специализирани компании, обслужващи (да се чете актуализиращи) тези бази данни, рядко се замислят за това.

Междувременно информационната база 1C е пълноценна СУБД от собствен формат, която също изисква поддръжка и за това дори има инструмент, наречен Тестване и коригиране на информационната база. Може би името изигра жестока шега, което някак предполага, че това е инструмент за отстраняване на проблеми, но ниската производителност също е проблем, а преструктурирането и преиндексирането, заедно с компресирането на таблици, са добре известни инструменти за оптимизиране на бази данни за всеки администратор на СУБД . да проверим ли

След прилагане на избраните действия базата данни рязко „загуби тегло“, ставайки дори по-малка от „двете“, които никой никога не е оптимизирал, а консумацията на RAM също леко намаля.

Впоследствие след зареждане на нови класификатори и директории, създаване на индекси и др. размерът на основата ще се увеличи като цяло, "трите" бази са по-големи от "двете" бази. Това обаче не е по-важно, ако втората версия се задоволяваше със 150-200 MB RAM, тогава новото издание се нуждае от половин гигабайт и тази стойност трябва да се вземе предвид при планирането на необходимите ресурси за работа с програмата.

Нет

Мрежовата честотна лента е един от най-важните параметри за мрежови приложения, особено като 1C във файлов режим, които пренасят значителни количества данни в мрежата. Повечето мрежи на малки предприятия са изградени на базата на евтино 100 Mbit/s оборудване, така че ние започнахме тестване, като сравнихме показателите за производителност на 1C в 100 Mbit/s и 1 Gbit/s мрежи.

Какво се случва, когато стартирате 1C файлова база данни по мрежата? Клиентът изтегля доста голямо количество информация във временни папки, особено ако това е първото, „студено“ стартиране. При 100 Mbit/s се очаква да се справим с ширината на канала и изтеглянето може да отнеме значително време, в нашия случай около 40 секунди (цената за разделяне на графиката е 4 секунди).

Второто стартиране е по-бързо, тъй като част от данните се съхраняват в кеша и остават там до рестартирането. Преминаването към гигабитова мрежа може значително да ускори зареждането на програмата, както „студено“, така и „горещо“, и съотношението на стойностите се спазва. Затова решихме да изразим резултата в относителни стойности, като най-голямата стойност от всяко измерване се приема за 100%:

Както можете да видите от графиките, Accounting 2.0 се зарежда при всяка мрежова скорост два пъти по-бързо, преходът от 100 Mbit/s към 1 Gbit/s ви позволява да ускорите времето за изтегляне четири пъти. В този режим няма разлика между оптимизираните и неоптимизираните бази данни "тройка".

Също така проверихме влиянието на скоростта на мрежата върху работата в тежки режими, например по време на групови трансфери. Резултатът също се изразява в относителни стойности:

Тук е по-интересно, оптимизираната база на „тройката“ в мрежа от 100 Mbit/s работи със същата скорост като „двойката“, а неоптимизираната показва два пъти по-лоши резултати. При гигабита съотношенията остават същите, неоптимизираната „тройка“ също е наполовина по-бавна от „двойката“, а оптимизираната изостава с една трета. Освен това преходът към 1 Gbit/s ви позволява да намалите времето за изпълнение три пъти за издание 2.0 и наполовина за издание 3.0.

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

Всъщност за ежедневните задачи пропускателната способност на мрежата не е тясно място, неоптимизираната „тройка“ е само с 20% по-бавна от „две“, а след оптимизация се оказва, че е почти същата по-бърза - предимствата на работата в режим на тънък клиент са очевидни. Преходът към 1 Gbit/s не дава на оптимизираната база никакви предимства, а неоптимизираната и двете започват да работят по-бързо, като показват малка разлика помежду си.

От проведените тестове става ясно, че мрежата не е тясно място за новите конфигурации, а управляваното приложение работи дори по-бързо от обикновено. Можете също така да препоръчате преминаване към 1 Gbit/s, ако тежките задачи и скоростта на зареждане на базата данни са критични за вас, в други случаи новите конфигурации ви позволяват да работите ефективно дори в бавни мрежи от 100 Mbit/s.

Така че защо 1C е бавен? Ще го разгледаме допълнително.

Сървърна дискова подсистема и SSD

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

Въпреки сравнително големия брой входно-изходни операции в секунда (IOPS) - 913, дължината на опашката не надвишава 1.84, което е много добър резултат за двудисков масив. Въз основа на това можем да направим предположението, че огледало, направено от обикновени дискове, ще бъде достатъчно за нормалната работа на 8-10 мрежови клиента в тежки режими.

И така, необходим ли е SSD на сървър? Най-добрият начин да отговорите на този въпрос ще бъде чрез тестване, което извършихме по подобен метод, мрежовата връзка е 1 Gbit/s навсякъде, резултатът също се изразява в относителни стойности.

Да започнем със скоростта на зареждане на базата данни.

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

Да преминем към преработването:

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

В ежедневните задачи картината е подобна:

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

Клиентска дискова подсистема и SSD

Анализирахме влиянието на SSD върху скоростта на работа на локално инсталирания 1C в, голяма част от казаното е вярно и за работа в мрежов режим. Всъщност 1C доста активно използва дискови ресурси, включително за фонови и рутинни задачи. На фигурата по-долу можете да видите как Accounting 3.0 доста активно достъпва диска за около 40 секунди след зареждане.

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

Бавният твърд диск може да забави някои операции, но сам по себе си не може да доведе до забавяне на програмата.

RAM

Въпреки факта, че RAM сега е неприлично евтина, много работни станции продължават да работят с количеството памет, което е инсталирано при закупуването. Тук дебнат първите проблеми. Въз основа на факта, че средната „тройка“ изисква около 500 MB памет, можем да предположим, че общо количество RAM от 1 GB няма да е достатъчно за работа с програмата.

Намалихме системната памет до 1 GB и пуснахме две информационни бази данни.

На пръв поглед всичко не е толкова лошо, програмата е ограничила апетитите си и се вписва добре в наличната памет, но нека не забравяме, че нуждата от оперативни данни не се е променила, така че къде отиде? Изхвърлени в диск, кеш, суап и т.н., същността на тази операция е, че данните, които не са необходими в момента, се изпращат от бърза RAM, чийто размер не е достатъчен, за да забави дисковата памет.

Накъде води? Нека да видим как се използват системните ресурси при тежки операции, например, нека стартираме групово повторно прехвърляне в две бази данни едновременно. Първо на система с 2 GB RAM:

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

Сега нека намалим паметта до 1 GB:

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

В същото време дори субективната работа с две отворени бази данни на система с 1 GB памет се оказа изключително неудобна; директории и списания се отварят със значително забавяне и активен достъп до диска. Например отварянето на дневника Продажби на стоки и услуги отне около 20 секунди и през цялото това време беше придружено от висока дискова активност (маркирана с червена линия).

За да оценим обективно въздействието на RAM върху производителността на конфигурации, базирани на управлявано приложение, ние извършихме три измервания: скоростта на зареждане на първата база данни, скоростта на зареждане на втората база данни и групово повторно стартиране в една от базите данни . И двете бази данни са напълно идентични и са създадени чрез копиране на оптимизираната база данни. Резултатът се изразява в относителни единици.

Резултатът говори сам за себе си: ако времето за зареждане се увеличи с около една трета, което все още е доста поносимо, тогава времето за извършване на операции в базата данни се увеличава три пъти, не е необходимо да се говори за комфортна работа в такива условия. Между другото, това е случаят, когато закупуването на SSD може да подобри ситуацията, но е много по-лесно (и по-евтино) да се справите с причината, а не с последствията, и просто да закупите правилното количество RAM.

Липсата на RAM е основната причина, поради която работата с нови 1C конфигурации се оказва неудобна. Конфигурации с 2 GB памет на борда трябва да се считат за минимално подходящи. В същото време имайте предвид, че в нашия случай бяха създадени „парникови“ условия: чиста система, работеха само 1C и диспечерът на задачите. В реалния живот, на работен компютър, като правило, браузър, офис пакет са отворени, антивирусна програма работи и т.н. и т.н., така че изхождайте от необходимостта от 500 MB на база данни, плюс известен резерв, така че по време на тежки операции не се натъквате на липса на памет и рязко намаляване на производителността.

процесор

Без преувеличение, централният процесор може да се нарече сърцето на компютъра, тъй като той в крайна сметка обработва всички изчисления. За да оценим ролята му, проведохме друг набор от тестове, същите като за RAM, като намалихме броя на ядрата, налични за виртуалната машина, от две на едно, като тестът беше извършен два пъти с количества памет от 1 GB и 2 GB.

Резултатът се оказа доста интересен и неочакван: по-мощен процесор доста ефективно пое натоварването при липса на ресурси, през останалото време, без да дава осезаеми предимства. 1C Enterprise (в режим на файл) трудно може да се нарече приложение, което активно използва процесорни ресурси, то е доста неизискващо. И в трудни условия процесорът се натоварва не толкова от изчисляването на данните на самото приложение, а от обслужването на режийни разходи: допълнителни входно-изходни операции и т.н.

заключения

И така, защо 1C е бавен? На първо място, това е липсата на RAM; основното натоварване в този случай пада върху твърдия диск и процесора. И ако не блестят с производителност, както обикновено се случва в офис конфигурациите, тогава получаваме ситуацията, описана в началото на статията - „двете“ работят добре, но „трите“ са безбожно бавни.

На второ място е производителността на мрежата; бавният канал със скорост 100 Mbit/s може да се превърне в истинско затруднение, но в същото време режимът на тънък клиент е в състояние да поддържа доста удобно ниво на работа дори на бавни канали.

Тогава трябва да обърнете внимание на дисковото устройство; закупуването на SSD едва ли ще бъде добра инвестиция, но замяната на устройството с по-модерно би било добра идея. Разликата между поколенията твърди дискове може да се оцени от следния материал: .

И накрая процесора. По-бързият модел, разбира се, няма да бъде излишен, но няма смисъл да се увеличава производителността му, освен ако този компютър не се използва за тежки операции: групова обработка, тежки отчети, затваряне в края на месеца и т.н.

Надяваме се, че този материал ще ви помогне бързо да разберете въпроса „защо 1C е бавен“ и да го разрешите най-ефективно и без допълнителни разходи.

• Тагове: