Напоследък потребителите и администраторите все повече започват да се оплакват, че новите 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 е бавен“ и да го разрешите най-ефективно и без допълнителни разходи.

• Тагове:

Моля, активирайте JavaScript, за да видите

Симптоми и история на пациента:

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

Основните признаци на блокираща операция:

• бърза работа на потребителите с базата данни през мрежата в изключителен режим и изключително бавна, когато няколко потребители работят едновременно
• бързо потребителско изживяване с локална база данни на сървъра и бавна работа в мрежата
• достъпът до файловата система е малко под 10 MB/сек

И така, получих задачата да се уверя, че до трима потребители могат да работят в 1C едновременно! Смешно, нали?

Забравих всички шеги, когато видях с какво трябва да се справя: „сървър“ под формата на обикновен офис компютър и два лаптопа.

Щастието би било непълно, ако не бяха прекрасните операционни системи - Windows 7 на компютъра и на единия лаптоп, Windows 8 на другия.

При опит за едновременно публикуване на документи на лаптопи, единият остана за около минута, а вторият се срина от 1C с текста за грешка „не може да заключи масата...“.

Стартирането на 1C на лаптоп е отделно шоу, което продължи около 3 минути!

На много ресурси срещнах съвети да премина към работа в терминален достъп. За съжаление, Windows 7 не ви позволява да се превърнете в терминален сървър с помощта на стандартни инструменти - има максимум една активна връзка. В този случай останалите сесии не се прекратяват; можете да се свържете отново под друг потребител - "изхвърляйки" предишния потребител, но без да прекъсвате неговата сесия. Следователно трябва да прехвърлите 1C на сървърна операционна система, където няма такива ограничения. Клиентът, на свой собствен риск, реши проблема, като вместо това използва помощна програма на трета страна Windows7_SP1_RDPhack.

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

1. Деактивиранеизползване на мрежов протокол IPv6, конфигурирайте адресирането на „стария“ IPv4.

2. Добавете 1C процеси към изключенията на защитната стена на Windows, както и към антивирусните изключения или ги деактивирайте напълно (по-рисковано, но прост тест показа увеличаване на скоросттаповторно прехвърляне на документи, когато антивирусната програма Avast е деактивирана фактор на!)

3. Започнете индексирането на пълнотекстово търсене в 1C или го изключете напълно

4. Стартирайте тестване и коригиране на базата данни, като проверите с помощната програма ChDbfl

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

6. Деактивирайте ненужните функционални опции.

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

8. Започнете да преизчислявате сумите и да възстановявате последователността (значително увеличение може да настъпи само ако сумите не са били възстановени дълго време)

9. Посочете "Скорост на връзката - ниска" в настройките на списъка с база данни (това не даде много резултат, освен че изображенията на подсистемите бяха изключени :))

След като завърши всички тези стъпки, файловата база данни 1C започна да работи много по-бързо. Започна да се стартира за максимум 10 секунди, а скоростта на прехвърляне на документи се увеличи средно 12 пъти.

Може би тази кратка статия ще ви бъде полезна, ако внезапно трябва да ускорите вашата 1C файлова база данни.

P.S: Но стартирането на файл 1C с помощта на мрежов достъп до споделена папка все още е нереалистично, защото... Дори най-бързият SSD диск, RAM и процесор ще се натъкнат на мрежови блокажи и работата на повече от един потребител ще бъде практически невъзможна. Говорим конкретно за конфигурацията на UT 11.1. Самостоятелно написаните малки конфигурации могат да работят доста бързо дори във файловата версия.

Допълнения от коментариза публикация:

Дефрагментатор на дискс файлова база

Конволюциябаза данни (може да е полезно, ако базата данни е голяма, например за няколко години). Базата данни на клиента беше доста млада, така че намаляването не беше практично.

Хардуерен ъпгрейд - по-бърз хард диск, нов комутатор, процесор и др.

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

Как да ускорите работата в 1C: Счетоводство 8.3 (издание 3.0) или да деактивирате рутинни и фонови задачи

2019-01-15T13:28:19+00:00

Тези от вас, които вече са преминали към новото издание на 1C: Счетоводство 8.3 (издание 3.0), са забелязали, че е станало по-бавно от 2. Някакви странни забавяния, безкрайни фонови задачи по няколко пъти на ден, които никой не я е карал да изпълнява без наше знание.

Моите счетоводители ми казаха веднага след прехода, че новото издание на 1C: Accounting 3.0 е направо бавно в сравнение с предишните! И просто е невъзможно да се работи.

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

Е, например, защо трябва да изпълняваме задачата „Извличане на текст“ сто пъти на ден, ако не извършим пълнотекстово (счетоводители, не се тревожете) търсене във всички обекти в нашата база данни.

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

Същото важи и за постоянните опити на 1C да се свърже със сайта и да проверява и актуализира банковите класификатори. За какво? Аз самият ще натисна бутона за актуализиране на класификаторите, ако не намеря правилната банка по нейния BIC.

Как да направите това стъпка по стъпка по-долу.

1. Отидете в секцията „Администриране“ и изберете „Поддръжка“ () в панела с действия:

2. В прозореца, който се отваря, намерете и изберете „Рутинни и фонови задачи“:

3. Отворете всяка задача, която има „Включено“ в колоната „Включено“. има галка.

4. Премахнете отметката от „Активирано“ и щракнете върху бутона „Запазване и затваряне“.

5. Направете това с всяка от включените задачи и се насладете на новото издание. Като цяло според мен е много по-добре от две.

В същото време платформата все още ще активира някои от планираните задачи, които сте деактивирали.

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

Всъщност съществува три метода за ускоряване на 1C:

• Увеличаване на хардуерния капацитет.
• Оптимизиране на настройките на операционната система и СУБД.
• Оптимизиране на код и алгоритми в 1C.

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

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

Компанията 1C дава доста неясен отговор на въпроса колко ресурси са необходими; ние писахме за това по-рано в нашите публикации. И следователно трябва самостоятелно да провеждате експерименти и да разберете от какво зависи производителността на 1C. Експериментите с изпълнението на програмата в EFSOL са описани по-долу.

При работа с 1C 8.2, особено с конфигурации, които използват управлявани формуляри, беше забелязан странен факт: 1C работи по-бързо на работна станция, отколкото на мощен сървър. Освен това всички характеристики на работната станция са по-лоши от тези на сървъра.

Таблица 1 - Конфигурации, на които е извършено първоначалното тестване

Работната станция показва 155% повече производителност от 1C сървър с превъзходни характеристики. Започнахме да разбираме какво се случва и да стесним търсенето.

Фигура 1 - Измервания на производителността на работната станция с помощта на теста Gilev

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

Брой и честота на RAM

Анализът на наличната информация в Интернет показа, че мнозина пишат за зависимостта на производителността на 1C от честотата на паметта. Зависи от честотата, а не от силата на звука. Решихме да тестваме тази хипотеза, тъй като имаме RAM честота от 1066 Mhz на сървъра срещу 1333 Mhz на работната станция, а количеството RAM на сървъра вече е много по-високо. Решихме веднага да инсталираме не 1066 Mhz, а 800 Mhz, така че ефектът от зависимостта на производителността от честотата на паметта да е по-ясен. Резултатът е, че производителността спада с 12% и възлиза на 39,37 единици. Инсталирахме памет с честота 1333 Mhz вместо 1066 Mhz на сървъра и получихме леко увеличение на производителността - около 11%. Производителността е 19,53 единици. Съответно, не е въпрос на памет, въпреки че честотата й дава леко увеличение.

Фигура 2 – Измервания на производителността на работна станция след понижаване на честотата на RAM

Фигура 3 – Измервания на производителността на сървъра след увеличаване на честотата на RAM

Дискова подсистема

Следващата хипотеза беше свързана с дисковата подсистема. Веднага възникнаха две предположения:

• SSD са по-добри от SAS устройствата, дори ако са в raid 10.
• iSCSI е бавен или неправилен.

Затова в работната станция беше инсталиран обикновен SATA диск вместо SSD и същото беше направено със сървъра - базата данни беше поставена на локален SATA диск. В резултат на това измерванията на производителността не се промениха изобщо. Най-вероятно това се случва, защото има достатъчно RAM и дисковете практически не участват по никакъв начин при провеждане на теста.

процесор

Процесорите на сървъра, разбира се, са по-мощни и има два от тях, но честотата е малко по-ниска, отколкото на работната станция. Решихме да проверим ефекта от честотата на процесора върху производителността: нямаше процесори с по-висока честота под ръка за сървъра, така че намалихме честотата на процесора на работната станция. Веднага го намалихме до 1,6, за да стане по-ясна корелацията. Тестът показа, че производителността е спаднала значително, но дори и с 1.6 процесор, работната станция е произвела почти 28 единици, което е почти 1,5 пъти повече, отколкото на сървъра.

Фигура 4 – Измервания на производителността на работна станция с 1,6 Ghz процесор

Видео карта

В интернет има информация, че производителността на 1C може да бъде повлияна от видеокартата. Опитахме да използваме интегрираното видео на работната станция, професионален адаптер Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5 и стара видеокарта GeForce 16MbSDR. По време на теста на Гилев не се забелязва съществена разлика. Може би видеокартата все още има ефект, но в реални условия, когато трябва да отворите управлявани форми и т.н.

Към момента има две подозрения защо работната станция работи по-бързо дори при видимо по-лоши характеристики:

1. ПРОЦЕСОР.Типът процесор на работната станция е по-подходящ за 1C.
2. Чипсет.При равни други условия нашата работна станция е с по-нов чипсет, може би това е проблемът.

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

Етап 1. Настройка на системата

Първо, нека направим следните настройки в BIOS и операционната система:

1. В BIOS на сървъра деактивираме всички настройки, за да спестим енергия на процесора.
2. Изберете плана „Максимална производителност“ в операционната система.
3. Процесорът също е настроен за максимална производителност. Това може да стане с помощта на помощната програма PowerSchemeEd.

Етап 2. Настройка на SQL сървър и 1C:Enterprise сървър

Правим следните промени в настройките на СУБД и сървъра на 1C:Enterprise.

1. Настройка на протокола за споделена памет:
   
   
   • Споделената памет ще бъде активирана само на платформата, започвайки от 1C 8.2.17; в по-ранните версии Named Pipe ще бъде активирана - малко по-ниска по скорост на работа. Тази технология работи само ако услугите 1C и MSSQL са инсталирани на един и същ физически или виртуален сървър.
2. Препоръчително е да превключите услугата 1C в режим на отстраняване на грешки, тъй като, парадоксално, това дава тласък на производителността. По подразбиране отстраняването на грешки е деактивирано на сървъра.
3. Настройка на SQL сървър:
   
   
   • Нуждаем се само от сървъра, другите услуги, които са свързани с него и може би някой ги използва, само забавят работата. Ние спираме и деактивираме услуги като: FullText Search (1C има собствен механизъм за пълнотекстово търсене), Integration Services и др.
   • Задаваме максималното количество памет, разпределено на сървъра. Това е необходимо, така че sql сървърът да изчисли тази сума и да изчисти паметта предварително.
   • Задаваме максималния брой нишки (Maximum worker threads) и задаваме повишения приоритет на сървъра (Boost priority).

Етап 3: Създаване на производствена база данни

След като DBMS сървърът и 1C:Enterprise са оптимизирани, преминаваме към настройките на базата данни. Ако базата данни все още не е разширена от .dt файла и знаете нейния приблизителен размер, тогава е по-добре незабавно да посочите размера за инициализация на основния файл с „>=“ от размера на базата данни, но това е въпрос на вкус, той все още ще расте по време на разширяването. Но размерът на автоматичното увеличаване трябва да бъде посочен: приблизително 200 MB на база и 50 MB на журнал, т.к. Стойностите по подразбиране - нарастване с 1 MB и 10% забавят много работата на сървъра, когато трябва да увеличава файла на всяка 3-та транзакция. Освен това е по-добре да посочите съхранението на файла на базата данни и регистрационния файл на различни физически дискове или RAID групи, ако се използва RAID масив, и да ограничите растежа на журнала. Препоръчително е да преместите Tempdb файла във високоскоростен масив, тъй като СУБД има достъп до него доста често.

Етап 4. Настройване на планирани задачи

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

• Дефрагментирането на индексите и актуализирането на статистиката трябва да се извършва ежедневно, т.к ако фрагментацията на индекса е > 25%, това драстично намалява производителността на сървъра.
• Дефрагментирането и актуализирането на статистиката се извършва бързо и не изисква прекъсване на връзката на потребителите. Също така се препоръчва да се прави ежедневно.
• Пълно повторно индексиране – извършва се при блокирана база данни, препоръчително е да се прави поне веднъж седмично. Естествено, след пълно преиндексиране, индексите веднага се дефрагментират и статистиката се актуализира.

В резултат на това, с помощта на фина настройка на системата, SQL сървъра и работещата база данни, успяхме да увеличим производителността с 46%. Измерванията бяха извършени с помощта на инструмента 1C KIP и с помощта на теста Gilev. Последният показа 25.6 единици срещу 17.53, които бяха първоначално.

Кратко заключение

1. Производителността на 1C не зависи много от честотата на RAM. След като бъде достигнато достатъчно количество памет, по-нататъшното разширяване на паметта няма смисъл, тъй като не води до увеличаване на производителността.
2. Производителността на 1C не зависи от видеокартата.
3. Производителността на 1C не зависи от дисковата подсистема, при условие че опашката за четене или запис на диска не е превишена. Ако са инсталирани SATA устройства и тяхната опашка не е превишена, тогава инсталирането на SSD няма да подобри производителността.
4. Производителността зависи доста от честотата на процесора.
5. При правилна конфигурация на операционната система и MSSQL сървъра е възможно да се постигне увеличение на производителността на 1C с 40-50% без никакви материални разходи.

ВНИМАНИЕ! Много важен момент! Всички измервания бяха извършени на тестова база с помощта на теста Gilev и инструменти за измерване 1C. Поведението на реална база данни с реални потребители може да се различава от получените резултати. Например в тестовата база данни не открихме никаква зависимост на производителността от видеокартата и количеството RAM. Тези заключения са доста съмнителни и в реални условия тези фактори могат да имат значително влияние върху производителността. Когато работите с конфигурации, които използват управлявани форми, видеокартата е важна и мощният графичен процесор ускорява работата по отношение на изчертаването на програмния интерфейс, визуално това се проявява в по-бързата работа на 1C.

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

Системна интеграция. Консултиране

Основната цел на написването на тази статия е да се избегне повтарянето на очевидни нюанси за онези администратори (и програмисти), които все още не са натрупали опит с 1C.

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

Тестът на В. Гилев вече се превърна в своеобразен стандарт „de facto“. Авторът на своя уебсайт даде доста ясни препоръки, но аз просто ще представя някои резултати и ще коментирам най-вероятните грешки. Естествено, резултатите от теста на вашето оборудване може да се различават; това е само ориентир за това какво трябва да бъде и към какво можете да се стремите. Бих искал веднага да отбележа, че промените трябва да се правят стъпка по стъпка и след всяка стъпка проверявайте какъв резултат е дал.

В Infostart има подобни статии, ще поставя връзки към тях в съответните секции (ако пропусна нещо, моля, предложете ми в коментарите, ще го добавя). И така, нека приемем, че вашият 1C е бавен. Как да диагностицираме проблема и как да разберем кой е виновен, администраторът или програмистът?

Първоначални данни:

Тестван компютър, основно пробно зайче: HP DL180G6, оборудван с 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. За сравнение, Core i3-2100 показва сравними резултати в еднонишковия тест. Оборудването, което съзнателно избрах, не беше най-новото, с модерното оборудване резултатите са значително по-добри.

За тестване на отделни 1C и SQL сървъри, SQL сървър: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

За тестване на 10 Gbit мрежа бяха използвани адаптери Intel 520-DA2.

Версия на файла. (базата данни е на сървъра в споделена папка, клиентите се свързват през мрежата, CIFS/SMB протокол). Алгоритъм стъпка по стъпка:

0. Добавете тестовата база данни на Gilev към файловия сървър в същата папка, където са основните бази данни. Свързваме се от клиентския компютър и пускаме теста. Помним резултата.

Разбираемо е, че дори за стари компютри преди 10 години (Pentium на 775 сокет ) времето от щракване върху прекия път на 1C:Enterprise до появата на прозореца на базата данни трябва да бъде по-малко от минута. ( Celeron = бавен).

Ако имате компютър по-лош от Pentium 775 гнездо с 1 GB RAM, тогава ви съчувствам и ще ви бъде трудно да постигнете удобна работа на 1C 8.2 във файловата версия. Помислете или за надграждане (крайно време е) или за преминаване към терминален (или уеб, в случай на тънки клиенти и управлявани форми) сървър.

Ако компютърът не е по-лош, тогава можете да изритате администратора. Най-малко проверете работата на мрежата, антивирусната програма и драйвера за защита на HASP.

Ако тестът на Гилев на този етап показа 30 „папагала“ или повече, но работната база 1C все още работи бавно, въпросите трябва да бъдат насочени към програмиста.

1. Като ръководство за това колко клиентски компютър може да "изцеди", ние проверяваме работата само на този компютър, без мрежа. Инсталираме тестовата база данни на локален компютър (на много бърз диск). Ако клиентският компютър няма нормален SSD, тогава се създава ramdisk. Засега най-простият и безплатен е Ramdisk enterprise.

За тестване на версия 8.2 е достатъчен 256 MB рамдиск и! Най-важните. След рестартиране на компютъра, при работещ ramdisk, трябва да има 100-200 MB свободни на него. Съответно, без ramdisk, за нормална работа трябва да има 300-400 MB свободна памет.

За да тествате версия 8.3, 256 MB ramdisk е достатъчен, но имате нужда от повече свободна RAM.

Когато тествате, трябва да погледнете натоварването на процесора. В случай, близък до идеалния (ramdisk), локалният файл 1c зарежда 1 процесорно ядро, когато работи. Съответно, ако по време на тестване ядрото на вашия процесор не е напълно заредено, потърсете слаби места. Малко емоционално, но като цяло правилно е описано влиянието на процесора върху работата на 1C. Само за справка, дори при съвременните Core i3s с високи честоти числата 70-80 са доста реалистични.

Най-честите грешки на този етап.

а) Неправилно конфигурирана антивирусна програма. Има много антивируси, настройките за всяка са различни, ще кажа само, че при правилна конфигурация нито мрежата, нито Kaspersky 1C се намесват. С настройките по подразбиране могат да бъдат отведени приблизително 3-5 папагала (10-15%).

б) Режим на изпълнение. По някаква причина малко хора обръщат внимание на това, но ефектът е най-значимият. Ако имате нужда от скорост, тогава трябва да направите това, както на клиентски, така и на сървърни компютри. (Гилев има добро описание. Единственото предупреждение е, че на някои дъна, ако изключите Intel SpeedStep, не можете да включите TurboBoost).

Накратко, докато 1C работи, има много чакане за отговор от други устройства (диск, мрежа и др.). Докато чакате отговор, ако режимът на производителност е активиран, процесорът намалява честотата си. Отговорът идва от устройството, 1C (процесорът) трябва да работи, но първите тактови цикли са с намалена честота, след това честотата се увеличава - и 1C отново чака отговор от устройството. И така - много стотици пъти в секунда.

Можете (и за предпочитане) да активирате режим на производителност на две места:

Чрез BIOS. Деактивирайте режимите C1, C1E, Intel C-state (C2, C3, C4). В различните биоси те се наричат ​​по различен начин, но значението е едно и също. Отнема много време за търсене, изисква се рестартиране, но ако го направите веднъж, можете да го забравите. Ако направите всичко правилно в BIOS, скоростта ще се увеличи. На някои дънни платки можете да конфигурирате настройките на BIOS, така че режимът на производителност на Windows да не играе роля. (Примери за настройки на BIOS от Гилев). Тези настройки се отнасят главно за сървърни процесори или „разширени“ BIOS, ако не сте намерили това и НЯМАТЕ Xeon, това е добре.

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

Как да проверите дали режимът е активиран. Стартирайте диспечера на задачите - производителност - монитор на ресурси - процесор. Изчакваме, докато процесорът не е зает с нищо.

Това са настройките по подразбиране. В BIOS C-състояние включени, режим на балансирана консумация на енергия
В BIOS C-състояние включени, режим на висока производителност За Pentium и Core можете да спрете дотук, Все още можете да изстискате малко "папагали" от Xeon
В BIOS C-състояние изключен, режим на висока производителност. Ако не използвате Turbo boost, ето как трябва да изглежда сървър, настроен за производителност

А сега числата. Да напомня: Intel Xeon 5650, рамдиск. В първия случай тестът показва 23,26, в последния - 49,5. Разликата е почти двойна. Числата може да варират, но съотношението остава по същество същото за Intel Core.

Уважаеми администратори, можете да критикувате 1C колкото искате, но ако крайните потребители се нуждаят от скорост, трябва да активирате режима с висока производителност.

в) Turbo Boost. Първо трябва да разберете дали вашият процесор поддържа тази функция, например. Ако поддържа, тогава все още можете съвсем законно да получите известна производителност. (Не искам да засягам проблемите с честотния овърклок, особено сървърите, направете го на свой риск и риск. Но съм съгласен, че увеличаването на скоростта на шината от 133 на 166 дава много забележимо увеличение както на скоростта, така и на разсейването на топлината)

Как да включите турбоусилване е написано например . Но! За 1C има някои нюанси (не най-очевидните). Трудността е, че максималният ефект от турбо усилване се получава, когато C-state е включен. И получаваме нещо подобно:

Моля, обърнете внимание, че множителят е максимален, скоростта на ядрото е красива и производителността е висока. Но какво ще се случи в резултат на 1s?

	Фактор	Скорост на ядрото (честота), GHz	CPU-Z единична нишка	Gilev Ramdisk тест версия на файла	Gilev Ramdisk тест клиентски сървър
Без Turbo boost
C-състояние изключено, Turbo boost				53.19	40,32
C-състояние включено, Turbo boost			1080	53,13	23,04

Но в крайна сметка се оказва, че според тестовете за производителност на процесора изпреварва версията с множител 23, според тестовете на Гилев във файловата версия производителността с множител 22 и 23 е същата, но при клиент-сървър версия - версията с множител 23 е ужасна, ужасна, ужасна (дори ако C -state е зададено на ниво 7, пак е по-бавно, отколкото с изключено C-state). Затова препоръката е да проверите сами и двата варианта и да изберете най-добрия. Във всеки случай разликата между 49,5 и 53 папагала е доста значителна, особено без много усилия.

Заключение - трябва да се включи турбо буст. Позволете ми да ви напомня, че не е достатъчно да активирате елемента Turbo boost в BIOS, трябва да погледнете и други настройки (BIOS: QPI L0s, L1 - деактивиране, почистване на изискване - деактивиране, Intel SpeedStep - активиране, Turbo boost - активиране. Контролен панел - Опции за захранване - Висока производителност). И все пак (дори за файловата версия) бих избрал опцията, при която c-state е изключено, въпреки че множителят е по-малък. Ще се получи нещо такова...

Доста спорен момент е честотата на паметта. Например, доказано е, че честотата на паметта има много силно влияние. Моите тестове не показаха такава зависимост. Няма да сравнявам DDR 2/3/4, ще покажа резултатите от промяната на честотата в същия ред. Паметта е същата, но в BIOS сме принудени да зададем по-ниски честоти.

И резултатите от тестовете. 1C 8.2.19.83, за файлова версия локален ramdisk, за клиент-сървър 1C и SQL на един компютър, Споделена памет. Turbo boost е деактивирано и в двете версии. 8.3 показва сравними резултати.

Разликата е в рамките на грешката на измерване. Специално извадих екранни снимки на CPU-Z, за да покажа, че с промяна в честотата се променят и други параметри, същата CAS Latency и RAS към CAS Delay, което неутрализира промяната в честотата. Разликата ще е при физическа смяна на модулите памет от по-бавни към по-бързи, но и там числата не са особено значими.

2. След като сме подредили процесора и паметта на клиентския компютър, преминаваме към следващото много важно място - мрежата. За настройката на мрежата са написани много томове книги, има статии за Infostart (и други), но тук няма да се съсредоточа върху тази тема. Преди да започнете да тествате 1C, моля, уверете се, че iperf между два компютъра показва цялата честотна лента (за 1 Gbit карти - добре, поне 850 Mbit, или още по-добре 950-980), че съветът на Гилев е спазен. След това - най-простият тест за работа ще бъде, колкото и да е странно, копирането на един голям файл (5-10 гигабайта) през мрежата. Косвен признак за нормална работа в 1 Gbit мрежа ще бъде средната скорост на копиране от 100 MB/sec, добра работа - 120 MB/sec. Бих искал да обърна внимание на факта, че слабото място (включително) може да бъде натоварването на процесора. SMB Протоколът на Linux е доста слабо паралелен и по време на работа може доста лесно да „изяде“ едно процесорно ядро ​​и да не консумира повече.

И по-нататък. С настройките по подразбиране клиентът на Windows работи най-добре с Windows сървър (или дори работна станция на Windows) и SMB/CIFS протокол, Линукс клиент (debian, ubuntu не погледна другите) работи по-добре с Linux и NFS ( работи и с SMB, но на NFS папагалите са по-високи). Фактът, че по време на линейно копиране Windows Linux сървър към NFS се копира в един поток по-бързо, не означава нищо. Настройката на Debian за 1C е тема за отделна статия, все още не съм готов за това, въпреки че мога да кажа, че във файловата версия получих дори малко по-добра производителност от версията Win на същото оборудване, но с postgres с над 50 потребители Все още имам всичко много лошо.

Най-важните , което „изгорелите“ администратори знаят, но начинаещите не го вземат предвид. Има много начини да зададете пътя до базата данни 1c. Можете да направите \\server\share, можете да направите \\192.168.0.1\share, можете да използвате net z: \\192.168.0.1\share (и в някои случаи този метод също ще работи, но не винаги) и след това посочете Z устройството Изглежда, че всички тези пътища сочат към едно и също място, но за 1C има само един начин, който осигурява нормална производителност доста надеждно. И така, това е, което трябва да направите правилно:

На командния ред (или в политиките, или както ви е удобно) - направете net use DriveLetter: \\server\share. Пример: net use m:\\server\bases. Изрично подчертавам НЕ IP адреса, а именно Имесървър. Ако името на сървъра не се вижда, добавете го към dns на сървъра или локално към файла hosts. Но адресът трябва да е по име. Съответно, по пътя към базата данни, достъп до този диск (вижте снимката).

А сега ще покажа с цифри защо е такъв съветът. Първоначални данни: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 карти OS Win 2008 R2, Win 7, Debian 8. Последни драйвери, приложени актуализации. Преди да тествам, се уверих, че Iperf дава пълната честотна лента (с изключение на 10 Gbit карти, той успя да изтръгне само 7,2 Gbit, ще видя защо по-късно, тестовият сървър все още не е конфигуриран правилно). Дисковете са различни, но навсякъде има SSD (специално сложих един диск за тест, не е зареден с нищо друго) или raid от SSD. Скоростта от 100 Mbit беше получена чрез ограничаване на настройките на адаптера Intel 362. Нямаше разлика между 1 Gbit меден Intel 350 и 1 Gbit оптичен Intel X520-DA2 (получен чрез ограничаване на скоростта на адаптера). Максимална производителност, турбо усилване е изключено (само за сравнимост на резултатите, турбо усилване за добри резултати добавя малко по-малко от 10%, за лоши резултати може да няма никакъв ефект). Версии 1C 8.2.19.86, 8.3.6.2076. Не давам всички числа, а само най-интересните, за да имате с какво да сравнявате.

	Win 2008 - Win 2008 контакт чрез ip адрес	Win 2008 - Win 2008 Обаждане по име	Win 2008 - Win 2008 Контакт чрез IP адрес	Win 2008 - Win 2008 Обаждане по име	Win 2008 - Win 7 Обаждане по име	Win 2008 - Debian Обаждане по име	Win 2008 - Win 2008 Контакт чрез IP адрес	Win 2008 - Win 2008 Обаждане по име
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1C 8.2	11,29	26,18	15,29	43,10	40,65	36,76	15,11	44,10
8.2.19.83	12,15	25,77	15,15	43,10			14,97	42,74
	6,13	34,25	14,98	43,10	39,37	37,59	15,53	42,74
1C 8.3	6,61	33,33	15,58	43,86	40,00	37,88	16,23	42,74
8.3.6.2076		33,78	15,53	43,48	39,37	37,59		42,74

Изводи (от таблицата и от личен опит. Отнася се само за файловата версия):

През мрежата можете да получите съвсем нормални номера за работа, ако тази мрежа е правилно конфигурирана и пътят е въведен правилно в 1C. Дори първият Core i3 може спокойно да произведе 40+ папагала, което е доста добре и това не са само папагали, но и при реална работа разликата е осезаема. Но! Ограничението при работа с няколко (повече от 10) потребители вече няма да е мрежата, тук 1 Gbit все още е достатъчен, но блокиране при работа с много потребители (Гилев).

Платформата 1C 8.3 е многократно по-взискателна по отношение на правилната мрежова конфигурация. Основни настройки - виж Гилев, но имай предвид, че всичко може да се влияе. Видях ускорение от деинсталиране (а не само изключване) на антивирусната програма, от премахване на протоколи като FCoE, от смяна на драйвери към по-стара, но сертифицирана от Microsoft версия (особено за евтини карти като ASUS и DLC), от премахване на втората мрежова карта от сървъра. Има много опции, настройте мрежата си внимателно. Възможно е да има ситуация, при която платформа 8.2 дава приемливи числа, а 8.3 - два или дори повече пъти по-малко. Опитайте да играете с платформа версии 8.3, понякога получавате много голям ефект.

1C 8.3.6.2076 (може би по-късно, все още не съм търсил точната версия) все още е по-лесно да се конфигурира по мрежата от 8.3.7.2008. Успях да постигна нормална работа по мрежата от 8.3.2008 г. (в сравними папагали) само няколко пъти; не можах да го повторя за по-общ случай. Не разбрах много, но съдейки по обвивките на краката от Process Explorer, записът там не е толкова добър, колкото в 8.3.6.

Въпреки факта, че когато работите в мрежа от 100 Mbit, нейният график на натоварване е малък (можем да кажем, че мрежата е безплатна), скоростта на работа все още е много по-малка, отколкото при 1 Gbit. Причината е латентността на мрежата.

При равни други условия (добре работеща мрежа) за 1C 8.2 връзката Intel-Realtek е с 10% по-бавна от Intel-Intel. Но realtek-realtek обикновено може да даде рязко слягане изневиделица. Ето защо, ако имате пари, по-добре дръжте мрежовите карти на Intel навсякъде; ако нямате пари, инсталирайте Intel само на сървъра (вашата CO). И има много пъти повече инструкции за настройка на мрежови карти на Intel.

Антивирусните настройки по подразбиране (използвайки drweb версия 10 като пример) заемат около 8-10% от папагалите. Ако го конфигурирате както трябва (позволете на процеса 1cv8 да прави всичко, въпреки че не е безопасно), скоростта е същата като без антивирусна.

НЕ четете Linux гурута. Сървър със samba е страхотен и безплатен, но ако инсталирате Win XP или Win7 (или дори по-добре - сървърна ОС) на сървъра, тогава файловата версия на 1c ще работи по-бързо. Да, samba и протоколният стек и мрежовите настройки и много, много други могат да бъдат добре настроени в debian/ubuntu, но това се препоръчва за специалисти. Няма смисъл да инсталирате Linux с настройки по подразбиране и след това да казвате, че е бавен.

Доста добра идея е да проверите работата на дискове, свързани чрез net use с помощта на fio. Поне ще стане ясно дали това са проблеми с платформата 1C или с мрежата/диска.

За версията за един потребител не мога да се сетя за тестове (или ситуация), при които разликата между 1 Gbit и 10 Gbit би била видима. Единственото нещо, при което 10Gbit за файловата версия дава по-добри резултати е свързването на дискове през iSCSI, но това е тема за отделна статия. Все пак мисля, че за файловата версия 1 Gbit карти са достатъчни.

Не разбирам защо при 100 Mbit мрежа 8.3 работи значително по-бързо от 8.2, но беше факт. Цялото друго оборудване, всички други настройки са абсолютно еднакви, просто в единия случай се тества 8.2, а в другия - 8.3.

Ненастроен NFS win-win или win-lin дава 6 папагала, не съм ги включил в таблицата. След настройка получих 25, но беше нестабилен (разликата в измерванията беше повече от 2 единици). Все още не мога да дам препоръки относно използването на Windows и NFS протокола.

След всички настройки и проверки, пускаме теста отново от клиентския компютър и се радваме на подобрения резултат (ако работи). Ако резултатът се е подобрил, има повече от 30 папагала (и особено повече от 40), по-малко от 10 потребители работят едновременно и работещата база данни все още е бавна - почти сигурно проблем с програмиста (или имате вече достигна върховите възможности на файловата версия).

Терминален сървър. (базата данни е на сървъра, клиентите се свързват през мрежата, RDP протокол). Алгоритъм стъпка по стъпка:

0. Добавете тестовата база данни на Gilev към сървъра в същата папка като основните бази данни. Свързваме се от същия сървър и провеждаме теста. Помним резултата.

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

2. Настройката на мрежови карти в случай на терминален сървър практически няма ефект върху работата на 1c. За да осигурите „специален“ комфорт, ако вашият сървър произвежда повече от 50 папагала, можете да играете с нови версии на протокола RDP, само за удобство на потребителите, по-бърз отговор и превъртане.

3. Ако активно работят голям брой потребители (а тук вече можете да опитате да свържете 30 души към една база данни, ако опитате), е много препоръчително да инсталирате SSD устройство. По някаква причина се смята, че дискът не влияе особено на работата на 1C, но всички тестове се извършват с активиран за писане кеш на контролера, което е неправилно. Тестовата база е малка, пасва доста добре в кеша, оттук и високите числа. В реални (големи) бази данни всичко ще бъде напълно различно, така че кешът е деактивиран за тестове.

Например, проверих работата на теста Gilev с различни опции на диска. Монтирах дисковете от това, което ми беше под ръка, просто да покажа тенденцията. Разликата между 8.3.6.2076 и 8.3.7.2008 е малка (в Ramdisk Turbo boost версия 8.3.6 дава 56.18 и 8.3.7.2008 произвежда 55.56, в други тестове разликата е още по-малка). Консумация на енергия - максимална производителност, турбо усилване деактивирано (освен ако не е посочено друго).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Единично SSD	Рамдиск		Кешът е активиран RAID контролер
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1C 8.2	21,65	28,57	32,05	48,54	49,02	53,19
8.2.19.83	21,65	28,41	31,45	48,54	49,50	53,19
	33,33	42,74	45,05	51,55	52,08	55,56	51,55
1C 8.3	33,46	42,02	45,05	51,02	52,08	54,95
8.3.7.2008	35,46	43,01	44,64	51,55	52,08	56,18

Активираният кеш на RAID контролера елиминира всички разлики между дисковете; числата са еднакви както за sat, така и за cas. Тестването с него върху малко количество данни е безполезно и не е показателно за никакъв вид.

За платформа 8.2 разликата в производителността между SATA и SSD опциите е повече от двойна. Това не е правописна грешка. Ако погледнете монитора на производителността по време на теста на SATA устройства. тогава можете ясно да видите „Активно време на работа на диска (в%)“ 80-95. Да, ако активирате кеша на самите дискове за запис, скоростта ще се увеличи до 35, ако активирате кеша на raid контролера - до 49 (независимо кои дискове се тестват в момента). Но това са синтетични папагали на кеша; в реална работа, с големи бази данни, никога няма да има 100% коефициент на попадение в кеша.

Скоростта дори на евтини SSD (тествах на Agility 3) е напълно достатъчна, за да стартира файловата версия. Ресурсът за запис е друг въпрос, трябва да го разгледате във всеки конкретен случай, ясно е, че Intel 3700 ще го има с порядък по-висок, но цената е съответна. И да, разбирам, че когато тествам SSD диск, тествам и кеша на този диск в по-голяма степен, реалните резултати ще бъдат по-малко.

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

Основните предимства на SSD устройствата за файловата версия ще се появят, когато има много бази данни, всяка с няколко потребители. Ако има 1-2 бази данни и има около 10 потребители, тогава SAS дисковете ще бъдат достатъчни. (но във всеки случай вижте зареждането на тези дискове, поне през perfmon).

Основните предимства на терминалния сървър са, че той може да има много слаби клиенти и мрежовите настройки влияят много по-малко на терминалния сървър (отново вашето K.O.).

Изводи: ако стартирате теста Gilev на терминален сървър (от същия диск, където се намират работещите бази данни) и в онези моменти, когато работещата база данни се забави, а тестът Gilev показва добър резултат (над 30), тогава бавната работа на основната работна база данни е виновен най-вероятно програмист.

Ако тестът на Gilev показва малки числа и имате процесор с висока тактова честота и бързи дискове, тогава администраторът трябва да вземе поне perfmon, да запише всички резултати някъде и да гледа, наблюдава и прави изводи. Няма да има окончателен съвет.

Опция клиент-сървър.

Тестовете бяха проведени само на 8.2, т.к на 8.3 всичко зависи доста сериозно от версията.

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

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Фибърен канал - SSD	SQL: Xeon E5-2630 Фибърен канал - SAS	SQL: Xeon E5-2630 Локален SSD	SQL: Xeon E5-2630 Фибърен канал - SSD	SQL: Xeon E5-2630 Локален SSD	1C: Xeon 5650 =	1C: Xeon 5650 = Споделена памет	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =
	16,78	18,23	16,84	28,57	27,78	32,05	34,72	36,50	23,26	40,65	39.37
1C 8.2	17,12	17,06	14,53	29,41	28,41	31,45	34,97	36,23	23,81	40,32	39.06
	16,72	16,89	13,44	29,76	28,57	32,05	34,97	36,23	23,26	40,32	39.06

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

SAS на системите за съхранение е по-бавен от локалните SSD, въпреки че системите за съхранение имат по-големи размери на кеша. SSD, както локални, така и на системи за съхранение, работят със сравними скорости за теста на Gilev. Не знам нито един стандартен многонишков тест (не само за запис, но и за цялото оборудване), с изключение на теста за натоварване 1C от MCC.

Промяната на 1C сървъра от 5520 на 5650 почти удвои производителността. Да, сървърните конфигурации не съвпадат напълно, но показва тенденция (не е изненада).

Увеличаването на честотата на SQL сървъра със сигурност дава ефект, но не същият като на 1C сървъра; MS SQL сървърът е отличен (ако го попитате) за използване на многоядра и свободна памет.

Промяната на мрежата между 1C и SQL от 1 Gbit на 10 Gbit дава приблизително 10% папагали. Очаквах повече.

Активирането на споделената памет все още дава ефект, но не и 15%, както е описано. Не пропускайте да го направите, за щастие е бързо и лесно. Ако по време на инсталацията някой даде на SQL сървъра наименуван екземпляр, тогава, за да работи 1C, името на сървъра трябва да бъде посочено не чрез FQDN (tcp/ip ще работи), не чрез localhost или просто ServerName, а чрез ServerName\InstanceName, например zz-тест\zzтест. (В противен случай ще има грешка в DBMS: Microsoft SQL Server Native Client 10.0: Shared Memory Provider: Библиотеката със споделена памет, използвана за установяване на връзка с SQL Server 2000, не е намерена. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr : SQLSTATE=08001, състояние=1, сериозност=10, собствен =126, ред=0).

За по-малко от 100 потребители единственият смисъл при разделянето му на два отделни сървъра е лиценз за Win 2008 Std (и по-стар), който поддържа само 32 GB RAM. Във всички останали случаи 1C и SQL определено трябва да бъдат инсталирани на един сървър и да им се даде повече (поне 64 GB) памет. Даването на MS SQL на по-малко от 24-28 GB RAM е неоправдана алчност (ако смятате, че имате достатъчно памет за него и всичко работи добре, може би файловата версия на 1C ще ви е достатъчна?)

Колко по-лошо работи комбинацията от 1C и SQL във виртуална машина е темата на отделна статия (намек - забележимо по-лошо). Дори в Hyper-V всичко не е толкова ясно...

Режимът на балансирана производителност е лош. Резултатите са доста съвместими с версията на файла.

Много източници казват, че режимът за отстраняване на грешки (ragent.exe -debug) причинява значително намаляване на производителността. Е, намалява, да, но не бих нарекъл 2-3% значителен ефект.