ყველას, ვინც მუშაობს პროდუქტებთან 1C:Enterprise პლატფორმაზე, ალბათ მოისმინა ფრაზა „1C არის ნელი“. ზოგი ამაზე ჩიოდა, ზოგმა საჩივრები მიიღო. ამ სტატიაში შევეცდებით გადავხედოთ ამ პრობლემის ყველაზე გავრცელებულ მიზეზებს და მისი გადაჭრის ვარიანტებს.

მოდით მივმართოთ მეტაფორას: სანამ გაიგებთ, თუ რატომ არ მოვიდა ადამიანი სადმე, უნდა დარწმუნდეთ, რომ მას ფეხი აქვს ფეხი. ასე რომ, დავიწყოთ ტექნიკისა და ქსელის მოთხოვნებით.

თუ Windows 7 დაინსტალირებულია:

თუ დაინსტალირებული გაქვთ Windows 8 ან 10:

ისიც გახსოვდეთ თავისუფალი ადგილიდისკს უნდა ჰქონდეს მინიმუმ 2 გბ, ხოლო ქსელის კავშირს უნდა ჰქონდეს მინიმუმ 100 მბ/წმ სიჩქარე.

კლიენტ-სერვერის ვერსიაში სერვერების მახასიათებლების გათვალისწინებას აზრი არ აქვს, რადგან ამ შემთხვევაში ყველაფერი დამოკიდებულია მომხმარებელთა რაოდენობაზე და იმ ამოცანების სპეციფიკაზე, რომლებსაც ისინი წყვეტენ 1C-ში.

სერვერის კონფიგურაციის არჩევისას გაითვალისწინეთ შემდეგი:

• ერთი 1C სერვერის მუშა პროცესი მოიხმარს საშუალოდ 4 გბ-ს (არ უნდა აგვერიოს მომხმარებლის კავშირში, ვინაიდან ერთ მუშა პროცესს შეიძლება ჰქონდეს იმდენი კავშირი, რამდენიც თქვენ მიუთითებთ სერვერის პარამეტრებში);
• 1C და DBMS (განსაკუთრებით MS SQL) გამოყენება ერთ ფიზიკურ სერვერზე იძლევა სარგებელს დიდი რაოდენობით მონაცემების დამუშავებისას (მაგალითად, თვის დახურვა, მოდელის მიხედვით ბიუჯეტის გამოთვლა და ა.შ.), მაგრამ მნიშვნელოვნად ამცირებს შესრულებას გადმოტვირთული ოპერაციების დროს ( მაგალითად, განხორციელების დოკუმენტის შექმნა და წარმართვა და ა.შ.);
• გახსოვდეთ, რომ 1C სერვერები და DBMS უნდა იყოს დაკავშირებული არხზე "სქელი" 1 GB;
• გამოიყენეთ მაღალი ხარისხის დისკები და არ დააკავშიროთ 1C და DBMS სერვერის როლები სხვა როლებთან (მაგალითად, ფაილი, AD, დომენის კონტროლერი და ა.შ.).

თუ აღჭურვილობის შემოწმების შემდეგ 1C მაინც შენელდება

ჩვენ გვყავს პატარა კომპანია, 7 ადამიანი და 1C არის ნელი. ჩვენ სპეციალისტებს დავუკავშირდით და მათ გვითხრეს, რომ მხოლოდ კლიენტ-სერვერის ვარიანტი გადაგვარჩენს. მაგრამ ჩვენთვის ასეთი გამოსავალი მიუღებელია, ის ძალიან ძვირია!

განახორციელეთ რუტინული მოვლა მონაცემთა ბაზაში*:

1. გაუშვით მონაცემთა ბაზა კონფიგურატორის რეჟიმში.

2. მთავარ მენიუში აირჩიეთ "ადმინისტრაცია" და მასში - "ტესტირება და კორექტირება".

3. შეამოწმეთ ყველა ყუთი, როგორც სურათზე. დააჭირეთ გაშვებას.

*ამ პროცედურას შეიძლება დასჭირდეს 15 წუთიდან ერთ საათამდე, რაც დამოკიდებულია მონაცემთა ბაზის ზომაზე და თქვენი კომპიუტერის მახასიათებლებზე.

თუ ეს არ დაგვეხმარება, მაშინ ჩვენ ვაკეთებთ კლიენტ-სერვერ კავშირს, მაგრამ დამატებითი ინვესტიციების გარეშე აპარატურასა და პროგრამულ უზრუნველყოფაში:

1. აირჩიეთ ოფისში ყველაზე ნაკლებად დატვირთული დესკტოპ კომპიუტერი (არა ნოუთბუქი): მას უნდა ჰქონდეს მინიმუმ 4 გბ. ოპერატიული მეხსიერებადა ქსელის კავშირიმინიმუმ 100 მბ/წმ.

2. გააქტიურეთ მასზე IIS (ინტერნეტ ინფორმაციის სერვერი). ამისათვის:

3. გამოაქვეყნეთ თქვენი მონაცემთა ბაზა ამ კომპიუტერზე. ამ თემაზე ხელმისაწვდომია მასალა ITS-ზე, ან დაუკავშირდით დამხმარე სპეციალისტს.

4. მომხმარებლის კომპიუტერებზე, დააკონფიგურირეთ მონაცემთა ბაზაზე წვდომა თხელი კლიენტის საშუალებით. ამისათვის:

გახსენით 1C გაშვების ფანჯარა.

აირჩიეთ თქვენი სამუშაო ბაზა. აქ არის "შენი ბაზა". დააჭირეთ "რედაქტირება". დააყენეთ გადამრთველი „ვებ სერვერზე“ პოზიციაზე, მის ქვემოთ ხაზში მიუთითეთ სერვერის სახელი ან IP მისამართი, რომელზედაც გააქტიურდა IIS და სახელი, რომლითაც გამოქვეყნდა მონაცემთა ბაზა. დააჭირეთ ღილაკს "შემდეგი".

დააყენეთ "Basic startup mode" გადამრთველი "Thin Client" რეჟიმში. დააწკაპუნეთ "შესრულებულია".

ჩვენ გვაქვს საკმაოდ დიდი კომპანია, მაგრამ არა ძალიან დიდი, დაახლოებით 50-60 ადამიანი, ჩვენ ვიყენებთ კლიენტ-სერვერის ვარიანტს, მაგრამ 1C საშინლად ნელია.

ამ შემთხვევაში, რეკომენდებულია 1C სერვერის და DBMS სერვერის გაყოფა ორ სხვადასხვა სერვერად. განცალკევებისას აუცილებლად გახსოვდეთ: თუ ისინი დარჩნენ იმავე ფიზიკურ სერვერზე, რომელიც უბრალოდ ვირტუალიზებული იყო, მაშინ ამ სერვერების დისკები განსხვავებული უნდა იყოს - ფიზიკურად განსხვავებული! ასევე, დარწმუნდით, რომ დააყენეთ რუტინული ამოცანები DBMS სერვერზე, როდესაც საქმე MS SQL-ს ეხება (დაწვრილებით ამის შესახებ აღწერილია ITS ვებსაიტზე)

საკმაოდ დიდი კომპანია გვყავს, 100-ზე მეტი მომხმარებელი. ყველაფერი კონფიგურებულია 1C რეკომენდაციების შესაბამისად ამ ვარიანტისთვის, მაგრამ ზოგიერთი დოკუმენტის დამუშავებისას, 1C ძალიან ნელია და ზოგჯერ ხდება დაბლოკვის შეცდომა. იქნებ გავაკეთო ბაზის შეკრება?

მსგავსი სიტუაცია წარმოიქმნება ძალიან კონკრეტული დაგროვების ან სააღრიცხვო რეესტრის (მაგრამ უფრო ხშირად - დაგროვების) ზომის გამო, იმის გამო, რომ რეესტრი ან საერთოდ „იხურება“, ე.ი. არის შემომავალი მოძრაობები, მაგრამ არ არის ნაკადის მოძრაობები, ან გაზომვების რაოდენობა, რომლითაც გამოითვლება რეესტრის ნაშთები, ძალიან დიდია. შეიძლება არსებობდეს წინა ორი მიზეზის ნაზავიც კი. როგორ განვსაზღვროთ რომელი რეესტრი აფუჭებს ყველაფერს?

ჩვენ ვაფიქსირებთ დროს, როდესაც დოკუმენტები ნელა მუშავდება, ან დრო და მომხმარებელი, რომელსაც აქვს დაბლოკვის შეცდომა.

გახსენით რეგისტრაციის ჟურნალი.

ჩვენ ვპოულობთ დოკუმენტს, რომელიც გვჭირდება, საჭირო დროს, სწორი მომხმარებლისთვის ღონისძიების ტიპის „Data.Post“.

ჩვენ ვუყურებთ შესრულების მთელ ბლოკს, სანამ ტრანზაქცია არ გაუქმდება, თუ იყო დაბლოკვის შეცდომა, ან ვეძებთ ყველაზე ხანგრძლივ ცვლილებას (წინა ჩანაწერის დრო არის წუთზე მეტი).

ამის შემდეგ, ჩვენ ვიღებთ გადაწყვეტილებას, იმის გათვალისწინებით, რომ ამ კონკრეტული რეესტრის დაშლა ნებისმიერ შემთხვევაში უფრო იაფია, ვიდრე მთელი მონაცემთა ბაზა.

ჩვენ ვართ ძალიან დიდი კომპანია, 1000-ზე მეტი მომხმარებელი, ათასობით დოკუმენტი დღეში, ჩვენი საკუთარი IT დეპარტამენტი, სერვერების უზარმაზარი ფლოტი, რამდენჯერმე მოვახდინეთ მოთხოვნების ოპტიმიზაცია, მაგრამ 1C ნელია. ჩვენ აშკარად გადავაჭარბეთ 1C და გვჭირდება რაღაც უფრო ძლიერი.

ასეთი შემთხვევების დიდ უმრავლესობაში ნელდება არა 1C, არამედ გამოყენებული ხსნარის არქიტექტურა. არჩევანის გაკეთება სასარგებლოდ ახალი პროგრამაბიზნესისთვის, გახსოვდეთ, რომ თქვენი ბიზნეს პროცესების პროგრამაში ჩაწერა უფრო იაფი და მარტივია, ვიდრე მათი გადაყვანა ზოგიერთში, განსაკუთრებით ძალიან ძვირადღირებულ პროგრამაში. მხოლოდ 1C იძლევა ამ შესაძლებლობას. ამიტომ, უმჯობესია დავსვათ კითხვა: „როგორ გამოვასწოროთ სიტუაცია? როგორ შეგიძლიათ 1C „გაფრინდეს“ ასეთ მოცულობებზე? მოკლედ გადავხედოთ მკურნალობის რამდენიმე ვარიანტს:

• გამოიყენეთ პარალელური და ასინქრონული პროგრამირების ტექნოლოგიები, რომლებსაც მხარს უჭერს 1C (ფონური სამუშაოები და მოთხოვნები ციკლში).
• გადაწყვეტის არქიტექტურის შემუშავებისას, მოერიდეთ აკუმულაციური რეგისტრების და სააღრიცხვო რეგისტრების გამოყენებას ყველაზე მეტად შეფერხებულ ადგილებში.
• მონაცემთა სტრუქტურის (დაგროვების და/ან ინფორმაციის რეგისტრების) შემუშავებისას დაიცავით წესი: „წერისა და წაკითხვის ყველაზე სწრაფი ცხრილი არის ცხრილი ერთი სვეტით“. რაზეც ვსაუბრობთ, უფრო ნათელი გახდება, თუ გადახედავთ ტიპიურ RAUSE მექანიზმს.
• დიდი მოცულობის მონაცემების დასამუშავებლად გამოიყენეთ დამხმარე კლასტერები, სადაც ერთი და იგივე მონაცემთა ბაზაა დაკავშირებული (მაგრამ არავითარ შემთხვევაში ეს არ უნდა გაკეთდეს ინტერაქტიული მუშაობის დროს!!!). ეს საშუალებას მოგცემთ გადალახოთ სტანდარტული 1C საკეტები, რაც შესაძლებელს გახდის მონაცემთა ბაზასთან მუშაობას თითქმის იგივე სიჩქარით, როგორც უშუალოდ SQL ინსტრუმენტებთან მუშაობისას.

აღსანიშნავია, რომ 1C ოპტიმიზაცია ჰოლდინგებისა და მსხვილი კომპანიებისთვის არის ცალკე, დიდი სტატიის თემა, ამიტომ თვალყური ადევნეთ განახლებულ მასალებს ჩვენს ვებსაიტზე.

1C სისტემა იკავებს დომინანტურ პოზიციას მცირე და საშუალო ბიზნესის ავტომატიზაციის ბაზარზე. თუ კომპანიამ აირჩია 1C აღრიცხვის სისტემა, მაშინ, როგორც წესი, მასში თითქმის ყველა თანამშრომელი მუშაობს, რიგითი სპეციალისტებიდან მენეჯმენტამდე. შესაბამისად, კომპანიის ბიზნეს პროცესების სიჩქარე დამოკიდებულია 1C სიჩქარეზე. თუ 1C მუშაობს არადამაკმაყოფილებელი სიჩქარით, მაშინ ეს პირდაპირ გავლენას ახდენს მთელი კომპანიის მუშაობაზე და მოგებაზე.

რეალურად არსებობს 1C აჩქარების სამი მეთოდი:

• ტექნიკის სიმძლავრის გაზრდა.
• პარამეტრების ოპტიმიზაცია ოპერაციული სისტემადა DBMS.
• კოდის და ალგორითმების ოპტიმიზაცია 1C-ში.

პირველი მეთოდი მოითხოვს აღჭურვილობისა და ლიცენზიების შეძენას, მესამე მოითხოვს პროგრამისტებისთვის დიდ შრომას და, შედეგად, ორივე გზა იწვევს მნიშვნელოვან ფინანსურ ხარჯებს. უპირველეს ყოვლისა, ყურადღება უნდა მიაქციოთ პროგრამის კოდს, რადგან სერვერის სიმძლავრის ვერანაირი ზრდა ვერ ანაზღაურებს არასწორი კოდის. ნებისმიერმა პროგრამისტმა იცის, რომ მხოლოდ რამდენიმე სტრიქონის კოდით შესაძლებელია ისეთი პროცესის შექმნა, რომელიც მთლიანად დატვირთავს ნებისმიერი სერვერის რესურსებს.

თუ კომპანია დარწმუნებულია, რომ პროგრამის კოდი ოპტიმალურია, მაგრამ ის მაინც ნელა მუშაობს, მენეჯმენტი ჩვეულებრივ გადაწყვეტს გაზარდოს სერვერის მოცულობა. ამ დროს ჩნდება ლოგიკური კითხვა: რა აკლია, რამდენი და რა უნდა დაემატოს ბოლოს.

1C კომპანია საკმაოდ ბუნდოვან პასუხს იძლევა კითხვაზე, თუ რამდენი რესურსი გვჭირდება ამის შესახებ ადრე ჩვენს პოსტებში. და ამიტომ, თქვენ დამოუკიდებლად უნდა ჩაატაროთ ექსპერიმენტები და გაარკვიოთ, რაზეა დამოკიდებული 1C შესრულება. EFSOL-ში პროგრამის შესრულების ექსპერიმენტები აღწერილია ქვემოთ.

1C 8.2-თან მუშაობისას, განსაკუთრებით იმ კონფიგურაციებთან, რომლებიც იყენებენ მართული ფორმები, უცნაური ფაქტი დაფიქსირდა: 1C მუშაობს უფრო სწრაფად სამუშაო სადგურზე, ვიდრე მძლავრ სერვერზე. უფრო მეტიც, სამუშაო სადგურის ყველა მახასიათებელი უფრო უარესია, ვიდრე სერვერის.

ცხრილი 1 - კონფიგურაციები, რომლებზეც განხორციელდა საწყისი ტესტირება

სამუშაო სადგური აჩვენებს შესრულებას 155%-ით მეტს, ვიდრე 1C სერვერი უმაღლესი მახასიათებლებით. დავიწყეთ იმის გარკვევა, თუ რა ხდებოდა და შევამცირეთ ძებნა.

სურათი 1 - მუშაობის გაზომვები სამუშაო სადგურზე გილევის ტესტის გამოყენებით

პირველი ეჭვი იყო, რომ გილევის ტესტი არაადეკვატური იყო. ინსტრუმენტული ხელსაწყოების გამოყენებით ფორმების გახსნის, დოკუმენტების განთავსების, მოხსენებების გენერირების და ა.შ. გაზომვებმა აჩვენა, რომ გილევის ტესტი იძლევა შეფასებას 1C-ში მუშაობის რეალური სიჩქარის პროპორციულად.

ოპერატიული მეხსიერების რაოდენობა და სიხშირე

ინტერნეტში არსებული ინფორმაციის ანალიზმა აჩვენა, რომ ბევრი წერს 1C შესრულების დამოკიდებულების შესახებ მეხსიერების სიხშირეზე. ეს დამოკიდებულია სიხშირეზე და არა მოცულობაზე. ჩვენ გადავწყვიტეთ ამ ჰიპოთეზის შემოწმება, რადგან სერვერზე გვაქვს ოპერატიული მეხსიერების სიხშირე 1066 Mhz სამუშაო სადგურზე 1333 Mhz-ის წინააღმდეგ და სერვერზე RAM-ის რაოდენობა უკვე გაცილებით მეტია. ჩვენ გადავწყვიტეთ დაუყოვნებლივ დავაყენოთ არა 1066 Mhz, არამედ 800 Mhz, რათა მეხსიერების სიხშირეზე შესრულების დამოკიდებულების ეფექტი უფრო ნათელი ყოფილიყო. შედეგად, პროდუქტიულობა 12%-ით დაეცა და 39,37 ერთეული შეადგინა. ჩვენ სერვერზე დავაინსტალირეთ მეხსიერება 1333 Mhz სიხშირით 1066 Mhz-ის ნაცვლად და მივიღეთ შესრულების უმნიშვნელო მატება - დაახლოებით 11%. პროდუქტიულობა იყო 19,53 ერთეული. შესაბამისად, ეს არ არის მეხსიერების საკითხი, თუმცა მისი სიხშირე ოდნავ მატულობს.

სურათი 2 - მუშაობის გაზომვები სამუშაო სადგურზე ოპერატიული მეხსიერების სიხშირის შემცირების შემდეგ

სურათი 3 - მუშაობის გაზომვები სერვერზე RAM სიხშირის გაზრდის შემდეგ

დისკის ქვესისტემა

შემდეგი ჰიპოთეზა დაკავშირებული იყო დისკის ქვესისტემასთან. მაშინვე გაჩნდა ორი ვარაუდი:

• SSD-ები უკეთესია, ვიდრე SAS დისკები, მაშინაც კი, თუ ისინი არიან Raid 10-ში.
• iSCSI არის ნელი ან არასწორი.

ამიტომ, SSD-ის ნაცვლად სამუშაო სადგურში დამონტაჟდა ჩვეულებრივი SATA დისკი და იგივე გაკეთდა სერვერთან დაკავშირებით - მონაცემთა ბაზა განთავსდა ადგილობრივ SATA დისკზე. შედეგად, შესრულების გაზომვები საერთოდ არ შეცვლილა. სავარაუდოდ, ეს იმიტომ ხდება, რომ არის საკმარისი ოპერატიული მეხსიერება და დისკები პრაქტიკულად არანაირად არ არის ჩართული ტესტის დროს.

CPU

პროცესორები სერვერზე, რა თქმა უნდა, უფრო მძლავრია და არის ორი მათგანი, მაგრამ სიხშირე ოდნავ დაბალია ვიდრე სამუშაო სადგურზე. ჩვენ გადავწყვიტეთ შევამოწმოთ პროცესორის სიხშირის ეფექტი შესრულებაზე: პროცესორის სერვერისთვის უფრო მაღალი სიხშირეხელთ არ მქონია, ამიტომ პროცესორის სიხშირე შევამცირე სამუშაო სადგურზე. ჩვენ მაშინვე ჩამოვწიეთ 1.6-მდე, რათა კორელაცია უფრო ნათელი გახდა. ტესტმა აჩვენა, რომ შესრულება მნიშვნელოვნად დაეცა, მაგრამ 1.6 პროცესორითაც კი, სამუშაო სადგურმა გამოუშვა თითქმის 28 ერთეული, რაც თითქმის 1.5-ჯერ მეტია, ვიდრე სერვერზე.

სურათი 4 - მუშაობის გაზომვები სამუშაო სადგურზე 1.6 გჰც პროცესორით

ვიდეო კარტა

ინტერნეტში არის ინფორმაცია, რომ 1C-ის შესრულებაზე შეიძლება გავლენა იქონიოს ვიდეო კარტმა. ჩვენ ვცადეთ სამუშაო სადგურის ინტეგრირებული ვიდეო, პროფესიონალური ადაპტერის გამოყენება Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5, ძველი GeForce 16MbSDR ვიდეო ბარათი. გილევის ტესტის დროს მნიშვნელოვანი განსხვავება არ დაფიქსირებულა. შესაძლოა, ვიდეო ბარათს მაინც აქვს ეფექტი, მაგრამ რეალურ პირობებში, როცა საჭიროა მართული ფორმების გახსნა და ა.შ.

ამ დროისთვის, არსებობს ორი ეჭვი, თუ რატომ მუშაობს სამუშაო სადგური უფრო სწრაფად, თუნდაც შესამჩნევად უარესი მახასიათებლებით:

1. CPU.სამუშაო სადგურზე პროცესორის ტიპი უკეთესად შეეფერება 1C-ს.
2. ჩიპსეტი.ყველა სხვა თანაბარი იყოს, ჩვენს სამუშაო სადგურს აქვს უფრო ახალი ჩიპსეტი, ალბათ ეს არის პრობლემა.

ჩვენ ვგეგმავთ ვიყიდოთ საჭირო კომპონენტები და გავაგრძელოთ ტესტირება, რათა საბოლოოდ გავარკვიოთ, რაზეა დამოკიდებული 1C შესრულება დიდწილად. სანამ დამტკიცებისა და შესყიდვის პროცესი მიმდინარეობს, ჩვენ გადავწყვიტეთ ოპტიმიზაცია გაგვეკეთებინა, მით უმეტეს, რომ ეს არ ღირს. გამოვლინდა შემდეგი ეტაპები:

ეტაპი 1. სისტემის დაყენება

პირველი, მოდით გავაკეთოთ შემდეგი პარამეტრები BIOS-სა და ოპერაციულ სისტემაში:

1. სერვერის BIOS-ში ჩვენ ვთიშავთ ყველა პარამეტრს პროცესორის ენერგიის დაზოგვის მიზნით.
2. აირჩიეთ "მაქსიმალური შესრულების" გეგმა ოპერაციულ სისტემაში.
3. პროცესორი ასევე კონფიგურირებულია მაქსიმალური შესრულება. ეს შეიძლება გაკეთდეს PowerSchemeEd უტილიტის გამოყენებით.

ეტაპი 2. SQL სერვერის და 1C:Enterprise სერვერის დაყენება

ჩვენ ვაკეთებთ შემდეგ ცვლილებებს DBMS და 1C:Enterprise სერვერის პარამეტრებში.

1. გაზიარებული მეხსიერების პროტოკოლის დაყენება:
   
   
   • საზიარო მეხსიერება ჩართული იქნება მხოლოდ პლატფორმაზე 1C 8.2.17-დან დაწყებული ადრინდელ გამოშვებებში, სახელწოდებით მილი ჩართული იქნება - ოდნავ დაბალი ოპერაციული სიჩქარით. ეს ტექნოლოგიამუშაობს მხოლოდ იმ შემთხვევაში, თუ 1C და MSSQL სერვისები დაინსტალირებულია იმავე ფიზიკურ ან ვირტუალურ სერვერზე.
2. რეკომენდირებულია 1C სერვისის გადართვა გამართვის რეჟიმში, რადგან, პარადოქსულად, ეს გაზრდის შესრულებას. ნაგულისხმევად, გამართვა გამორთულია სერვერზე.
3. SQL სერვერის დაყენება:
   
   
   • ჩვენ გვჭირდება მხოლოდ სერვერი, სხვა სერვისები, რომლებიც მას ეხება და, შესაძლოა, ვინმე იყენებს მათ, მხოლოდ ანელებს მუშაობას. ჩვენ ვაჩერებთ და ვთიშავთ ისეთ სერვისებს, როგორიცაა: FullText Search (1C-ისთვის საკუთარი მექანიზმისრული ტექსტის ძიება), ინტეგრაციის სერვისები და ა.შ.
   • ჩვენ ვაყენებთ სერვერზე გამოყოფილი მეხსიერების მაქსიმალურ რაოდენობას. ეს აუცილებელია იმისათვის, რომ SQL სერვერმა გამოთვალოს ეს თანხა და წინასწარ გაასუფთავოს მეხსიერება.
   • ჩვენ ვაყენებთ ძაფების მაქსიმალურ რაოდენობას (Maximum worker threads) და დავაყენეთ სერვერის გაზრდილი პრიორიტეტი (Boost priority).

ეტაპი 3: წარმოების მონაცემთა ბაზის შექმნა

მას შემდეგ, რაც DBMS სერვერი და 1C:Enterprise ოპტიმიზირებულია, გადავდივართ მონაცემთა ბაზის პარამეტრებზე. თუ მონაცემთა ბაზა ჯერ არ არის გაფართოვებული .dt ფაილიდან და იცით მისი სავარაუდო ზომა, მაშინ უმჯობესია დაუყოვნებლივ მიუთითოთ ინიციალიზაციის ზომა პირველადი ფაილისთვის მონაცემთა ბაზის ზომის ">="-ით, მაგრამ ეს საქმეა. გემოთი, ის მაინც გაიზრდება გაფართოების დროს. მაგრამ ავტომატური გაზრდის ზომა უნდა იყოს მითითებული: დაახლოებით 200 მბ თითო ბაზაზე და 50 მბ თითო ჟურნალში, რადგან ნაგულისხმევი მნიშვნელობები - ზრდა 1 მბ-ით და 10%-ით ძალიან ანელებს სერვერს, როდესაც მას სჭირდება ფაილის გაზრდა ყოველ მე-3 ტრანზაქციაში. ასევე, უმჯობესია მიუთითოთ მონაცემთა ბაზის ფაილის შენახვა და ჟურნალის ფაილი სხვადასხვა ფიზიკურ დისკზე ან RAID ჯგუფზე, თუ გამოიყენება RAID მასივი და შეზღუდოთ ჟურნალის ზრდა. რეკომენდებულია Tempdb ფაილის გადატანა მაღალსიჩქარიან მასივში, რადგან DBMS საკმაოდ ხშირად წვდება მას.

ეტაპი 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 ინსტრუმენტული ხელსაწყოების გამოყენებით. რეალურ მომხმარებლებთან რეალური მონაცემთა ბაზის ქცევა შეიძლება განსხვავდებოდეს მიღებული შედეგებისგან. მაგალითად, სატესტო მონაცემთა ბაზაში ჩვენ ვერ ვიპოვნეთ შესრულების რაიმე დამოკიდებულება ვიდეო ბარათზე და ოპერატიული მეხსიერების რაოდენობაზე. ეს დასკვნები საკმაოდ საეჭვოა და რეალურ პირობებში ამ ფაქტორებს შეუძლიათ მნიშვნელოვანი გავლენა იქონიონ შესრულებაზე. კონფიგურაციებთან მუშაობისას, რომლებიც იყენებენ მართულ ფორმებს, ვიდეო ბარათი მნიშვნელოვანია და ძლიერი GPUაჩქარებს მუშაობას პროგრამის ინტერფეისის დახატვის თვალსაზრისით, ვიზუალურად ეს უფრო მეტად გამოიხატება სწრაფი მუშაობა 1C.

თქვენი 1C ნელა მუშაობს? შეუკვეთეთ კომპიუტერებისა და სერვერების IT ტექნიკური მომსახურება მრავალწლიანი გამოცდილების მქონე EFSOL-ის სპეციალისტების მიერ ან გადაიტანეთ თქვენი 1C მძლავრ და ხარვეზების შემწყნარებელ 1C ვირტუალურ სერვერზე.

სისტემური ინტეგრაცია. კონსულტაცია

1C არის პროგრამა, რომელიც შექმნილია ნებისმიერი საწარმოს საქმიანობის ავტომატიზაციისთვის. ეს პროგრამა მნიშვნელოვნად ამარტივებს ბევრ მოქმედებას საწარმოში. თუმცა, ამ პროდუქტის მომხმარებლებმა არაერთხელ შენიშნეს, რომ 1C ზოგჯერ ანელებს. ამას შეიძლება ბევრი მიზეზი ჰქონდეს და ეს სულაც არ არის დაკავშირებული თავად პროგრამასთან. სავარაუდოა, რომ თქვენ არ გაქვთ ყველა საჭირო ნორმალური ოპერაციაპროგრამები სისტემის მოთხოვნები, მაგრამ ზოგჯერ არსებობს ამ პროგრამის ნელი მუშაობის სხვა მიზეზები.

რა არის მინიმალური სისტემური მოთხოვნები 1C-ის გასაშვებად?

ისევე როგორც ყველა პროგრამული პროდუქტებიკომპიუტერისთვის განკუთვნილი, ასევე არის მინიმალური სისტემური მოთხოვნები 1C. ჩვენ ახლა შევხედავთ მათ.

სისტემის მოთხოვნები 1C-სთვის:

• ძირითადი სიჩქარე: 2.4 გჰც (კლიენტ-სერვერისთვის), 3 გჰც (ფაილის მნიშვნელობისთვის);
• მეხსიერება (RAM): 8 GB ( ფაილის ვერსია), 4 გბ (კლიენტ-სერვერისთვის);
• ინტერნეტის სიჩქარე - მინიმუმ 100 მბ/წმ;
• თავისუფალი მეხსიერება მყარ დისკზე - მინიმუმ 2 GB.

1C-ის ნელი მუშაობის მიზეზები. რამდენიმე სიტყვა ფაილის რეჟიმის შესახებ.

როგორც ზოგიერთი მომხმარებელი აღნიშნავს, ახალი 1C კონფიგურაციები შეიქმნა საფუძველზე მართული აპლიკაცია, მუშაობა არასაკმარისი სიჩქარით. ამ სტატიაში ჩვენ შევეცდებით ვუპასუხოთ რა მიზეზები მოქმედებს 1C-ის მუშაობაზე ფაილის რეჟიმში, გარდა იმისა, რომ ახალი ფუნქციები მეტ რესურსს მოითხოვს.

ადრე ვთქვით, რომ 1C სიჩქარე დამოკიდებულია დისკის სისტემის მუშაობაზე. ეს დასკვნები მიღებული იქნა აპლიკაციის გამოყენების შედეგად კონკრეტულ ინდივიდუალურ კომპიუტერზე ან ცალკე ტერმინალის სერვერი. ამასთან, მრავალი განხორციელება ხდება ქსელთან მუშაობისას, რომელშიც სერვერი არის გამოყოფილი სერვერი, რომელიც დაფუძნებულია მარტივ კომპიუტერზე, ან უბრალოდ მომხმარებლის კომპიუტერზე.

სხვადასხვა „შიდა“ რესურსების მონიტორინგმა გამოავლინა ამ კითხვასპრაქტიკულად არ ექცევა ყურადღება. პოპულარული რწმენა გახდა, რომ მართული აპლიკაციის კონფიგურაცია არის დამნაშავე. მთავარი რეკომენდაციაა სხვა რეჟიმზე გადასვლა: სერვერ-კლიენტი ან ტერმინალი. ეს განცხადებები მხოლოდ ნაწილობრივ შეესაბამება სიმართლეს. ეს მოგვიანებით იქნება განხილული.

პირველადი მიმოხილვა რესურსების მოხმარებაზე.

ამ სტატიაში ჩვენ შევეცდებით ვუპასუხოთ ორ კითხვას:

1. მართალია, რომ მართული აპლიკაციების კონფიგურაციები უფრო ნელია, ვიდრე მარტივი?
2. რა გავლენას ახდენს პირველ რიგში პროდუქტიულობაზე?

ამ კითხვებზე პასუხის გასაცემად ჩავატარეთ სპეციალური კვლევა. ამისთვის ავიღეთ ორი ვირტუალური მანქანა. პირველი კონტროლდება Wind o ws S e rv er 2012 R 2, და მეორე Wind o ws 8.1. თითოეულ ამ მანქანას გამოეყო ორი ბირთვი (Coრე ი 5-4670), ასევე 2 გიგაბაიტი ოპერატიული მეხსიერება. ეს მაჩვენებლები საშუალოა ტიპიური საოფისე კომპიუტერისთვის. სერვერი განთავსდა RAID 0-ზე ორიდან W.D. Se . კლიენტი იყო ზოგადი დანიშნულების დისკების მსგავს მასივზე.

ექსპერიმენტისთვის ავიღეთ Accounting 2.0-ის სხვადასხვა კონფიგურაცია, გამოშვება 2.0.64.12. მოგვიანებით ვერსია განახლდა 3.0.38.52-ზე. გაშვებები გაკეთდა პლატფორმაზე 8.3.5.1443.

მაშინვე შესამჩნევია, რომ მესამე ვერსიის საინფორმაციო ბაზის ზომა შესამჩნევად იზრდება. RAM მოთხოვნები ასევე იზრდება:

ბრინჯი. 1

მესამე ვერსიის მიმართ სკეპტიციზმის მიუხედავად, აღსანიშნავია, რომ ფაილის ვერსიების რიგითი მომხმარებლები რეალურად არ აქცევენ ყურადღებას მონაცემთა ბაზების შენარჩუნებისა და მათი განახლების აუცილებლობას. ეს მნიშვნელოვანი განსხვავებაა კლიენტ-სერვერის ვერსიისგან, რომელსაც, როგორც წესი, ინახავს კვალიფიციური ადმინისტრატორი.

თუმცა, 1C საინფორმაციო მონაცემთა ბაზა საჭიროებს მუდმივ მოვლას, რათა სწორად იმუშაოს, როგორც ნებისმიერი DBMS. ამისათვის სპეციალური ინსტრუმენტია საინფორმაციო ბაზის ტესტირება და კორექტირება. სახელის მიუხედავად, რომელიც ვარაუდობს, რომ ეს ინსტრუმენტი შექმნილია მხოლოდ პრობლემების გადასაჭრელად, ცუდი შესრულება ასევე პრობლემაა. თქვენ შეგიძლიათ მონაცემთა ბაზის ოპტიმიზაცია რესტრუქტურიზაციისა და რეინდექსირების გამოყენებით. ეს ასე გამოიყურება:

ბრინჯი. 2

ამ ვარიანტების გამოყენებამ განაპირობა ის, რომ მონაცემთა ბაზა უფრო მცირე გახდა, ვიდრე მეორე ვერსია. აღსანიშნავია, რომ "ორი" ასევე არ იყო ადრე ოპტიმიზირებული. სხვათა შორის, RAM-ის მოხმარებაც შემცირდა.

ბრინჯი. 3

მოგვიანებით ჩამოვტვირთეთ ახალი კლასიფიკატორები და საცნობარო წიგნები, შევქმენით ინდექსები და განვახორციელეთ მრავალი სხვა საჭირო ქმედებები. ამ ყველაფერმა გამოიწვია მესამე ვერსიის ბაზის ზრდა. ასე რომ, თუ "ორს" სჭირდებოდა მაქსიმუმ 20 მეგაბაიტი ოპერატიული მეხსიერება, მაშინ ახალ გამოცემას სჭირდება დაახლოებით 500 მბ. ეს მნიშვნელობა მხედველობაში უნდა იქნას მიღებული შემდგომი მუშაობისთვის.

წმინდა

მოდით განვიხილოთ ისეთი პარამეტრი, როგორიცაა ქსელის გამტარუნარიანობა, რომელიც ერთ-ერთი ყველაზე მნიშვნელოვანია ქსელის აპლიკაციებისთვის. 1C ავრცელებს ინფორმაციის დიდ მოცულობას, ხოლო ორგანიზაციებში ქსელები აგებულია ძირითადად 100 მეგაბიტიანი აღჭურვილობის საფუძველზე. ეს იყო წინაპირობა ტესტისთვის შესრულების ინდიკატორების ტოლი 100 მეგაბიტი და 1 გიგაბიტი წამში ასარჩევად.

მოდით შევხედოთ პროცესებს, რომლებიც ხდება პირველი გაშვების დროს ფაილის მონაცემთა ბაზა 1C ქსელში. პირველი გაშვებისას მომხმარებელი ჩამოტვირთავს დიდი რაოდენობაინფორმაცია დროებით საქაღალდეებში. 100 მეგაბიტი/წმ-ზე ჩამოტვირთვას დაახლოებით ორმოცი წამი დასჭირდება, ეს იმის გამო ხდება, რომ არხის სიგანე არ იძლევა პროცესების უფრო სწრაფად განხორციელების საშუალებას.

ბრინჯი. 4

მეორე გაშვება უფრო სწრაფი იქნება ზოგიერთი მონაცემების ქეშირების გამო. ქსელის 1 გბიტ/წმ-ზე შეცვლა სერიოზულად აჩქარებს 1C-ის დატვირთვას. ეს ნათლად არის გამოსახული ქვემოთ მოცემულ ფიგურაში:

ბრინჯი. 5

მონაცემების გაანალიზების შემდეგ ვხედავთ, რომ მეორე ვერსია უფრო სწრაფად იტვირთება, სიჩქარის მიუხედავად. ჩვენ ასევე ვხედავთ, რომ გიგაბიტის სიჩქარეზე გადასვლა 4-ჯერ აუმჯობესებს ჩამოტვირთვის დროს. ასევე, გრაფიკები აჩვენებს, რომ in ამ რეჟიმშიპრაქტიკულად არ არსებობს განსხვავებები მესამე ვერსიის ოპტიმიზაციასთან.

ქსელის სიჩქარის გავლენის ტესტირება მძიმე სამუშაოზე აჩვენა შემდეგი შედეგები:

ბრინჯი. 6

მოდით უფრო ახლოს მივხედოთ. 100 მეგაბიტიან მესამე ვერსიას ოპტიმიზებული ბაზით აქვს მეორე ვერსიის ექვივალენტური სიჩქარე, ხოლო ოპტიმიზაციის გარეშე „ტროიკა“ თითქმის ორჯერ „ნელდება“. 1 გბიტ/წმ-ზე პროპორციები პრაქტიკულად უცვლელი რჩება. გარდა ამისა, გიგაბიტის სიჩქარეზე გადასვლა რეალურად ამცირებს გადაცემის დროს სამჯერ ორზე და ნახევრად სამზე.

ბრინჯი. 7

თუმცა, რაც არ უნდა თქვას, პრობლემა არ არის გამტარუნარიანობა. ოპტიმიზაციამდე მესამე ვერსია ჩამორჩება მეორეს დაახლოებით 20 პროცენტით. ოპტიმიზაცია საშუალებას გაძლევთ დააჩქაროთ მუშაობა და გარკვეულწილად გადააჭარბოთ ორს. გიგაბიტის სიჩქარეზე გადასვლის შემდეგ ოპტიმიზებული სამეული არ იღებს არანაირ „ბონუსს“, ხოლო არაოპტიმიზებული ბაზები და ორმაგი უფრო სწრაფად მუშაობს. მათ შორის განსხვავებები მინიმალურია.

მაგრამ მაინც რა არის 1C-ის ნელი მუშაობის მიზეზი? მოდით გადავხედოთ შემდგომ!

სერვერის დისკის ქვესისტემა და SSD

ადრე, ჩვენ უკვე გავზარდეთ 1C სიჩქარე, მონაცემთა ბაზის განთავსების წყალობით SSD . სერვერის დისკის ქვესისტემა საკმაოდ აჩვენებს კარგი შესრულება, ამას მოწმობს მისი გაზომვების შედეგები ჯგუფური ტესტირებისას 2 ბაზაზე. ნუ ვიქნებით უსაფუძვლო, შეხედეთ ქვემოთ მოცემულ სურათს:

ბრინჯი. 8

გავაანალიზოთ შედეგები: I/O ოპერაციების რაოდენობა იყო 913 დროის ერთეულზე (1 წამში). ამ შემთხვევაში, რიგის სიგრძე არ არის 1,84-ზე მეტი. ცუდი არ არის 2-დისკიანი მასივისთვის, არა? ამრიგად, ლოგიკურია, რომ ათი ქსელის კლიენტისთვის კარგად იმუშაოს ნებისმიერ რეჟიმში, მარტივი დისკებისგან დამზადებული სარკეები შესაფერისია.

შემდეგი კვლევა გასცემს პასუხს საჭიროების კითხვაზე SSD სერვერზე. კვლევის პრინციპები მსგავსია ზემოაღნიშნულთან დაკავშირებით, კავშირი ყველა შემთხვევაში არის 1 გბიტი/წმ. ყველა შედეგი მოცემულია შედარებით მნიშვნელობებში.

1. მონაცემთა ბაზის ჩატვირთვის სიჩქარე

ბრინჯი. 9

უცნაურად საკმარისია, რომ მონაცემთა ბაზის ჩატვირთვის სიჩქარე არანაირად არ არის დამოკიდებული SSD . ეს გამოწვეულია ქსელის გამტარუნარიანობის შეზღუდვით. ასევე, შესრულებას აქვს გარკვეული გავლენა.

ბრინჯი. 10

როგორც აღვნიშნეთ, დისკის შესრულება შესაფერისია ნორმალური მუშაობისთვის (მიუხედავად რეჟიმის სიმძიმისა). ეს განსაზღვრავს ამას SSD სიჩქარეზე არ მოქმედებს. (გამონაკლისი, არაოპტიმიზებული ბაზა, რომელმაც გააუმჯობესა მისი შესრულება და გაუტოლდა ოპტიმიზებულს). ეს კიდევ ერთხელ ადასტურებს თეზისს, რომ ოპტიმიზაცია ხელს უწყობს შემთხვევითი I/O ოპერაციების რაოდენობის შემცირებას და ზრდის მონაცემთა ბაზაში წვდომის სიჩქარეს.

3. მოდით შევხედოთ ყოველდღიურ დავალებებს:

ბრინჯი. 11

ოპტიმიზაციის გარეშე ბაზა კვლავ იძენს უპირატესობას, ხოლო ოპტიმიზებული ბაზები SSD თითქმის არანაირი გავლენა არ ჰქონდა. ასე რომ, ვიყიდო თუ არ ვიყიდო SSD - არჩევანი შენია. ამასთან, არ დაგავიწყდეთ მონაცემთა ბაზების დროულად შენარჩუნება და დანაყოფის დეფრაგმენტაცია საინფორმაციო მონაცემთა ბაზებით.

კლიენტის დისკის ქვესისტემა SSD

ჩვენ უკვე ჩავატარეთ ზემოქმედების კვლევები SSD სამუშაო სიჩქარით 1C, რომელიც დამონტაჟებულია ადგილობრივად. გამოტანილი დასკვნები ნაწილობრივ გამოიყენება ქსელის რეჟიმში. ეს ვარაუდობს, რომ 1C იყენებს დისკის რესურსებს სხვადასხვა ამოცანებისთვის (მათ შორის, ფონური და რუტინული). შეხედეთ სურათს, რომელიც გვიჩვენებს, თუ როგორ წვდება 1C დისკის რესურსებს ჩატვირთვის შემდეგ (ხანგრძლივობა დაახლოებით 40 წამი).

სურ 12

ასე რომ, SSD შეიძლება გაზარდოს ზოგიერთი პროცესის სიჩქარე, მაგრამ ეს არ არის პანაცეა. ქსელის გამტარუნარიანობა მაინც შეზღუდავს სიჩქარეს. სტანდარტული პრობლემების გადასაჭრელად, მარტივი საკმაოდ შესაფერისია HDD

ლოგიკური დასკვნა არის ის, რომ ისინი ნელია მყარი დისკიარ არის პროგრამის შენელების მთავარი მიზეზი.

ოპერატიული მეხსიერება

აქ არის მომენტები, რომლებიც განსაკუთრებულ ყურადღებას იმსახურებს. მესამე ვერსიას სჭირდება დაახლოებით 500 მბ ოპერატიული მეხსიერება, ასე რომ, თუ ოპერატიული მეხსიერების მთლიანი რაოდენობაა 1 გბ, მაშინ ეს შეიძლება ძალიან ცოტა იყოს პროგრამის სწორად მუშაობისთვის.

მეხსიერების 1 გბ-მდე შემცირების შემდეგ, ჩვენ გავუშვით ორი საინფორმაციო ბაზა.

ბრინჯი. 13

როგორც ჩანს, სიტუაცია არ არის კრიტიკული, რადგან პროგრამამ ჩადო გამოყოფილ მეხსიერებაში. თუმცა, არ უნდა დაგვავიწყდეს, რომ პროგრამის საჭიროება ოპერატიული მონაცემების მიმართ არ შეცვლილა. ისინი უბრალოდ წავიდნენ ქეში, გაცვლა და ა.შ. ანუ, გამოუცხადებელი მონაცემები გადადის RAM-დან დისკის მეხსიერებაში. და ამ მონაცემების მოპოვების სიჩქარეში განსხვავება რადიკალურია.

მოდით შევადაროთ შედეგები 2 გბ-ზე გაშვებას:

ბრინჯი. 14

ქსელმა დაიწყო აქტიური გამოყენება მონაცემების მოსაპოვებლად და პროცესორიც არანაკლებ აქტიურად გამოიყენებოდა ამ მონაცემების დასამუშავებლად. დისკის აქტივობა მინიმალურია და არ ანელებს პროცესებს.

რა ხდება მეხსიერების 1 გბ-მდე შემცირების შემდეგ?

ბრინჯი. 15

მთელი დატვირთვა მყარ დისკზე გადავიდა. პროცესორი და ქსელი არ არის ჩართული, მაშინ როცა სისტემა ჯერ იღებს დისკიდან საჭირო მონაცემებს, შემდეგ კი იქ აგზავნის გამოუცხადებელ მონაცემებს.

ეს კი სუბიექტურ მუშაობას ორ ღია მონაცემთა ბაზასთან ნელი და უსიამოვნო ხდის. მაგალითად, დაახლოებით ოცი წამი დასჭირდა საქონლისა და სერვისების გაყიდვების ჟურნალის გახსნას. დისკის აქტივობა (ხაზგასმულია წითლად) ძალიან მაღალი იყო.

ბრინჯი. 16

ჩვენ გადავწყვიტეთ მივაღწიოთ ოპერატიული მეხსიერების გავლენის ადეკვატურობას და ობიექტურობას შესრულებაზე სამი გაზომვის ჩატარებით:

ჯგუფის ხელახალი ჩატარება ერთ-ერთ ბაზაზე

ორივე მონაცემთა ბაზა მსგავსია, შექმნილია ოპტიმიზებული მონაცემთა ბაზის კოპირებით. აი შედეგი:

ბრინჯი. 17

ჩატვირთვის დრო იზრდება 30%-ით, მაგრამ მონაცემთა ბაზაში ოპერაციების შესრულების დრო სამჯერ გაიზარდა. ეს თითქმის შეუძლებელს ხდის ნორმალურ მუშაობას (ამ სიტუაციაში შეგიძლიათ დაეხმაროთ SSD , მაგრამ უფრო ადვილი და ფინანსურად მომგებიანია მეტი ოპერატიული მეხსიერების შეძენა.

დასკვნა: RAM-ის მცირე რაოდენობა არის მთავარი პრობლემა, რომელიც ანელებს 1C-ს ახალი კონფიგურაციებით. მინიმალური ოპერატიული მეხსიერება არის 2 GB. და ეს არ ითვალისწინებს, რომ სავარაუდოდ არა მხოლოდ 1C გაიხსნება თქვენს კომპიუტერში, არამედ მრავალი სხვა პროგრამა, რომელიც ასევე "შეჭამს" ძვირფას RAM-ს.

CPU

პროცესორის როლის შესაფასებლად, ჩატარდა მთელი რიგი გაზომვები, რომლებიც მსგავსი იყო RAM-ისთვის. გაზომვები განხორციელდა ერთბირთვიანი და ორბირთვიანი პროცესორებისთვის 1 GB მეხსიერების ტევადობით, ასევე 2 GB.

ბრინჯი. 18

მეტი ძლიერი პროცესორიმიუხედავად იმისა, რომ რესურსების ნაკლებობისას გარკვეული დატვირთვა აიღო, მთლიანობაში შესამჩნევი უპირატესობები არ შეუქმნია. ეს გამოწვეულია იმით, რომ 1C არ საჭიროებს პროცესორის დიდ რესურსებს.

დასკვნები.

1. 1C-ის ნელი მუშაობის მთავარი მიზეზი არის ოპერატიული მეხსიერების ნაკლებობა, რის გამოც დატვირთვა გადადის მყარ დისკზე და ნაწილობრივ პროცესორზე.
2. ნაწილობრივ გავლენას ახდენს ქსელის მუშაობა. 100-მბიტიანი არხი შეიძლება იყოს სერიოზული შემზღუდველი ფაქტორი ოპერაციისთვის, თუმცა თხელი კლიენტის რეჟიმს შეუძლია დააბალანსოს ეს მინუსი.
3. SSD-ის შეძენა - გამოსავალი კარგია, მაგრამ ძვირი. უფრო იაფია დისკის შეცვლა იმავე ტიპის უფრო თანამედროვეთი.
4. სწრაფი პროცესორი კარგია, მაგრამ არ არის აუცილებელი 1C-ის აჩქარება.) გარდა იმ შემთხვევისა, როდესაც კომპიუტერი გამოიყენება "მძიმე" ოპერაციებისთვის.

ჩატარებული კვლევისა და გამოტანილი დასკვნების საფუძველზე, შეგიძლიათ საკმაოდ ეფექტურად მოაგვაროთ 1C სიჩქარის პრობლემა თქვენთვის.

IN ბოლო დროსმომხმარებლები და ადმინისტრატორები სულ უფრო და უფრო იწყებენ ჩივილს, რომ მართული აპლიკაციის საფუძველზე შემუშავებული ახალი 1C კონფიგურაციები ნელია, ზოგიერთ შემთხვევაში მიუღებლად ნელი. ნათელია, რომ ახალი კონფიგურაციები შეიცავს ახალ ფუნქციებს და შესაძლებლობებს და, შესაბამისად, უფრო მოთხოვნადია რესურსებით, მაგრამ მომხმარებელთა უმეტესობას არ ესმის, რა გავლენას ახდენს პირველ რიგში 1C-ის მუშაობაზე ფაილის რეჟიმში. შევეცადოთ გამოვასწოროთ ეს ხარვეზი.

ჩვენში ჩვენ უკვე შევეხეთ დისკის ქვესისტემის მუშაობის გავლენას 1C სიჩქარეზე, თუმცა ამ კვლევასშეშფოთებული ადგილობრივი გამოყენებაპროგრამები ცალკე კომპიუტერზე ან ტერმინალის სერვერზე. ამავდროულად, მცირე განხორციელების უმეტესობა მოიცავს ფაილების მონაცემთა ბაზასთან მუშაობას ქსელში, სადაც მომხმარებლის ერთ-ერთი კომპიუტერი ან გამოყოფილი კომპიუტერი გამოიყენება სერვერად. ფაილის სერვერიეფუძნება ჩვეულებრივ, ყველაზე ხშირად ასევე იაფ კომპიუტერს.

1C-ზე რუსულენოვანი რესურსების მცირე შესწავლამ აჩვენა, რომ ამ საკითხს გულმოდგინედ აარიდებთ თავს, თუ პრობლემები წარმოიქმნება, ჩვეულებრივ რეკომენდებულია კლიენტ-სერვერზე ან ტერმინალის რეჟიმში გადასვლა. ასევე თითქმის საყოველთაოდ მიღებულია, რომ მართულ აპლიკაციაზე კონფიგურაციები ჩვეულებრივზე ბევრად ნელა მუშაობს. როგორც წესი, არგუმენტები "რკინაა": "ბუღალტრული აღრიცხვა 2.0 უბრალოდ გაფრინდა და "ტროიკა" ძლივს გადავიდა, რა თქმა უნდა, ამ სიტყვებში არის გარკვეული სიმართლე, ასე რომ, მოდით შევეცადოთ გაერკვნენ.

რესურსის მოხმარება, ერთი შეხედვით

სანამ ამ კვლევას დავიწყებდით, ჩვენ საკუთარ თავს დავსახავდით ორ მიზანს: გაერკვია, არის თუ არა მართული აპლიკაციებზე დაფუძნებული კონფიგურაციები უფრო ნელი ვიდრე ჩვეულებრივი კონფიგურაციები, და რომელ კონკრეტულ რესურსებს აქვთ პირველადი გავლენა შესრულებაზე.

ტესტირებისთვის ჩვენ ავიღეთ ორი ვირტუალური მანქანა Windows კონტროლისერვერი 2012 R2 და Windows 8.1, შესაბამისად, მათ აძლევს მასპინძელი Core i5-4670 2 ბირთვს და 2 GB ოპერატიული მეხსიერებას, რაც შეესაბამება დაახლოებით საშუალო საოფისე მანქანას. სერვერი განთავსდა RAID 0 მასივზე ორიდან, ხოლო კლიენტი განთავსდა ზოგადი დანიშნულების დისკების მსგავს მასივზე.

როგორც ექსპერიმენტული საფუძვლები, ჩვენ შევარჩიეთ Accounting 2.0, გამოშვების რამდენიმე კონფიგურაცია 2.0.64.12 , რომელიც შემდეგ განახლდა 3.0.38.52 , ყველა კონფიგურაცია ამოქმედდა პლატფორმაზე 8.3.5.1443 .

პირველი, რაც ყურადღებას იპყრობს, არის ტროიკის საინფორმაციო ბაზის გაზრდილი ზომა, რომელიც მნიშვნელოვნად გაიზარდა, ისევე როგორც RAM-ის გაცილებით დიდი მადა:

ჩვენ მზად ვართ მოვისმინოთ ჩვეულებრივი: "რატომ დაამატეს ეს ამ სამს", მაგრამ ნუ ვიჩქარებთ. კლიენტ-სერვერის ვერსიების მომხმარებლებისგან განსხვავებით, რომლებიც საჭიროებენ მეტ-ნაკლებად კვალიფიციურ ადმინისტრატორს, ფაილის ვერსიების მომხმარებლები იშვიათად ფიქრობენ მონაცემთა ბაზის შენარჩუნებაზე. ასევე, ამ მონაცემთა ბაზების მომსახურე (წაიკითხეთ განახლება) სპეციალიზებული კომპანიების თანამშრომლები ამაზე იშვიათად ფიქრობენ.

იმავდროულად, 1C საინფორმაციო ბაზა არის საკუთარი ფორმატის სრულფასოვანი DBMS, რომელიც ასევე მოითხოვს შენარჩუნებას, და ამისათვის არსებობს ინსტრუმენტიც კი ე.წ. საინფორმაციო ბაზის ტესტირება და კორექტირება. შესაძლოა, სახელმა სასტიკი ხუმრობა შეასრულა, რაც გარკვეულწილად გულისხმობს, რომ ეს არის ინსტრუმენტი პრობლემების გადასაჭრელად, მაგრამ დაბალი შესრულება ასევე პრობლემაა, ხოლო რესტრუქტურიზაცია და რეინდექსირება, ცხრილის შეკუმშვასთან ერთად, ცნობილი ინსტრუმენტებია მონაცემთა ბაზების ოპტიმიზაციისთვის ნებისმიერი DBMS ადმინისტრატორისთვის. . შევამოწმოთ?

არჩეული მოქმედებების გამოყენების შემდეგ, მონაცემთა ბაზამ მკვეთრად "დაკარგა წონა", კიდევ უფრო პატარა გახდა, ვიდრე "ორი", რომელიც არავის არასდროს ჰქონია ოპტიმიზირებული და RAM-ის მოხმარება ასევე ოდნავ შემცირდა.

შემდგომში, ახალი კლასიფიკატორებისა და დირექტორიების ჩატვირთვის, ინდექსების შექმნის შემდეგ და ა.შ. მონაცემთა ბაზის ზომა გაიზრდება, მთლიანობაში მონაცემთა ბაზა იქნება "სამი" მეტი ბაზა"ორი". თუმცა, ეს არ არის უფრო მნიშვნელოვანი, თუ მეორე ვერსია კმაყოფილი იყო 150-200 მბ ოპერატიული მეხსიერებით, მაშინ ახალ გამოცემას სჭირდება ნახევარი გიგაბაიტი და ეს მნიშვნელობა უნდა იქნას გათვალისწინებული პროგრამასთან მუშაობისთვის საჭირო რესურსების დაგეგმვისას.

წმინდა

ქსელის გამტარუნარიანობა ერთ-ერთი ყველაზე დიდია მნიშვნელოვანი პარამეტრებიქსელური აპლიკაციებისთვის, განსაკუთრებით, როგორიცაა 1C ფაილის რეჟიმში, მნიშვნელოვანი რაოდენობის მონაცემების გადატანა ქსელში. მცირე საწარმოების ქსელების უმეტესობა აგებულია იაფი 100 მბიტი/წმ აღჭურვილობის საფუძველზე, ამიტომ ჩვენ დავიწყეთ ტესტირება 1C შესრულების ინდიკატორების შედარებით 100 მბიტ/წმ და 1 გბიტ/წმ ქსელებში.

რა ხდება, როდესაც ქსელში ამუშავებთ 1C ფაილების მონაცემთა ბაზას? კლიენტი ჩამოტვირთავს საკმაოდ დიდ ინფორმაციას დროებით საქაღალდეებში, განსაკუთრებით თუ ეს პირველი, „ცივი“ დაწყებაა. 100 მბიტ/წმ-ზე, მოსალოდნელია, რომ არხის სიგანეზე გადავიდეთ და ჩამოტვირთვას შეიძლება მნიშვნელოვანი დრო დასჭირდეს, ჩვენს შემთხვევაში დაახლოებით 40 წამი (გრაფიკის გაყოფის ღირებულებაა 4 წამი).

მეორე გაშვება უფრო სწრაფია, რადგან ზოგიერთი მონაცემი ინახება ქეშში და იქ რჩება გადატვირთვამდე. გიგაბიტიან ქსელზე გადასვლამ შეიძლება მნიშვნელოვნად დააჩქაროს პროგრამის ჩატვირთვა, როგორც „ცივი“ და „ცხელი“, ასევე დაცულია მნიშვნელობების თანაფარდობა. ამიტომ, ჩვენ გადავწყვიტეთ გამოგვეხატა შედეგი ფარდობითი მნიშვნელობებით, თითოეული გაზომვის უდიდესი მნიშვნელობა 100%-ად ავიღეთ:

როგორც გრაფიკებიდან ხედავთ, Accounting 2.0 იტვირთება ნებისმიერი ქსელის სიჩქარით ორჯერ უფრო სწრაფად, 100 მბიტ/წმ-დან 1 გბიტ/წმ-ზე გადასვლა საშუალებას გაძლევთ ოთხჯერ დააჩქაროთ ჩამოტვირთვის დრო. ამ რეჟიმში ოპტიმიზებული და არაოპტიმიზებული „ტროიკის“ მონაცემთა ბაზებს შორის განსხვავება არ არის.

ჩვენ ასევე შევამოწმეთ ქსელის სიჩქარის გავლენა მძიმე რეჟიმებზე მუშაობაზე, მაგალითად, ჯგუფური გადარიცხვების დროს. შედეგი ასევე გამოიხატება ფარდობით მნიშვნელობებში:

აქ უფრო საინტერესოა, 100 მბიტ/წმ ქსელში "სამი" ოპტიმიზირებული ბაზა მუშაობს იმავე სიჩქარით, როგორც "ორი", ხოლო არაოპტიმიზებული ორჯერ ცუდ შედეგს აჩვენებს. გიგაბიტზე კოეფიციენტები იგივე რჩება, არაოპტიმიზებული "სამი" ასევე ნახევრად ნელია, ვიდრე "ორი", ხოლო ოპტიმიზებული ერთი მესამედით ჩამორჩება. ასევე, 1 გბიტ/წმ-ზე გადასვლა საშუალებას გაძლევთ სამჯერ შეამციროთ შესრულების დრო 2.0 გამოცემისთვის და ნახევრად 3.0 გამოცემისთვის.

იმისათვის, რომ შევაფასოთ ქსელის სიჩქარის გავლენა ყოველდღიურ მუშაობაზე, ჩვენ გამოვიყენეთ შესრულების გაზომვათითოეულ მონაცემთა ბაზაში წინასწარ განსაზღვრული მოქმედებების თანმიმდევრობის შესრულება.

ფაქტობრივად, ყოველდღიური ამოცანებისთვის, ქსელის გამტარუნარიანობა არ არის შეფერხება, არაოპტიმიზებული "სამი" მხოლოდ 20% -ით ნელია ვიდრე "ორი", და ოპტიმიზაციის შემდეგ აღმოჩნდება დაახლოებით იგივე უფრო სწრაფი - მუშაობის უპირატესობა. გამხდარი კლიენტი. 1 გბიტ/წმ-ზე გადასვლა არ აძლევს ოპტიმიზებულ ბაზას რაიმე უპირატესობებს და არაოპტიმიზებული და ორივე იწყებს მუშაობას უფრო სწრაფად, რაც აჩვენებს მცირე განსხვავებას მათ შორის.

ჩატარებული ტესტებიდან ირკვევა, რომ ქსელი ახალი კონფიგურაციებისთვის არ არის ბარიერი და მართული აპლიკაცია ჩვეულებრივზე უფრო სწრაფად მუშაობს. თქვენ ასევე შეგიძლიათ რეკომენდაცია გაუწიოთ 1 გბიტ/წმ-ზე გადართვას, თუ მძიმე ამოცანები და მონაცემთა ბაზის ჩატვირთვის სიჩქარე გადამწყვეტია თქვენთვის, ახალი კონფიგურაციები საშუალებას გაძლევთ ეფექტურად იმუშაოთ თუნდაც 100 Mbit/s ნელი ქსელებში.

რატომ არის 1C ნელი? ჩვენ მას შემდგომში განვიხილავთ.

სერვერის დისკის ქვესისტემა და SSD

წინა სტატიაში ჩვენ მივაღწიეთ 1C შესრულების ზრდას SSD-ზე მონაცემთა ბაზების განთავსებით. იქნებ სერვერის დისკის ქვესისტემის მუშაობა არასაკმარისია? ჩვენ გავზომეთ დისკის სერვერის მუშაობა ჯგუფური მუშაობის დროს ერთდროულად ორ მონაცემთა ბაზაში და მივიღეთ საკმაოდ ოპტიმისტური შედეგი.

მიუხედავად შემავალი/გამომავალი ოპერაციების შედარებით დიდი რაოდენობით წამში (IOPS) - 913, რიგის სიგრძე არ აღემატებოდა 1,84-ს, რაც ძალიან კარგი შედეგია ორდისკიანი მასივისთვის. ამის საფუძველზე შეგვიძლია ვივარაუდოთ, რომ ჩვეულებრივი დისკებისგან დამზადებული სარკე საკმარისი იქნება 8-10 ქსელის კლიენტის ნორმალური მუშაობისთვის მძიმე რეჟიმში.

ასე რომ, საჭიროა SSD სერვერზე? ამ კითხვაზე პასუხის საუკეთესო საშუალება იქნება ტესტირება, რომელიც ჩვენ განვახორციელეთ მსგავსი მეთოდით, ქსელის კავშირი ყველგან არის 1 გბიტი/წმ, შედეგიც გამოიხატება ფარდობით მნიშვნელობებში.

დავიწყოთ მონაცემთა ბაზის ჩატვირთვის სიჩქარით.

ზოგიერთისთვის შეიძლება გასაკვირი ჩანდეს, მაგრამ სერვერზე SSD არ ახდენს გავლენას მონაცემთა ბაზის ჩატვირთვის სიჩქარეზე. აქ მთავარი შემზღუდველი ფაქტორი, როგორც წინა ტესტმა აჩვენა, არის ქსელის გამტარუნარიანობა და კლიენტის შესრულება.

გადავიდეთ გადაკეთებაზე:

ზემოთ უკვე აღვნიშნეთ, რომ დისკის შესრულება საკმაოდ საკმარისია მძიმე რეჟიმებში მუშაობისთვისაც კი, ამიტომ SSD-ის სიჩქარეზეც არ იმოქმედებს, გარდა არაოპტიმიზებული ბაზისა, რომელიც SSD-ზე დაეწია ოპტიმიზებულს. სინამდვილეში, ეს კიდევ ერთხელ ადასტურებს, რომ ოპტიმიზაციის ოპერაციები აწყობს ინფორმაციას მონაცემთა ბაზაში, ამცირებს შემთხვევითი I/O ოპერაციების რაოდენობას და ზრდის მასზე წვდომის სიჩქარეს.

ყოველდღიურ ამოცანებში სურათი მსგავსია:

მხოლოდ არაოპტიმიზებული მონაცემთა ბაზა სარგებლობს SSD-ით. თქვენ, რა თქმა უნდა, შეგიძლიათ შეიძინოთ SSD, მაგრამ ბევრად უკეთესი იქნება, იფიქროთ მონაცემთა ბაზის დროულ შენარჩუნებაზე. ასევე, არ დაივიწყოთ დანაყოფის დეფრაგმენტაცია საინფორმაციო ბაზებისერვერზე.

კლიენტის დისკის ქვესისტემა და SSD

ჩვენ გავაანალიზეთ SSD-ის გავლენა ადგილობრივად დაყენებული 1C-ის მუშაობის სიჩქარეზე, რაც ითქვა, ასევე მართებულია ქსელის რეჟიმში მუშაობისთვის. მართლაც, 1C საკმაოდ აქტიურად იყენებს დისკის რესურსებს, მათ შორის ფონური და რუტინული ამოცანებისთვის. ქვემოთ მოყვანილ სურათზე ხედავთ, თუ როგორ წვდება Accounting 3.0 საკმაოდ აქტიურად დისკზე ჩატვირთვის შემდეგ დაახლოებით 40 წამის განმავლობაში.

მაგრამ ამავე დროს, უნდა იცოდეთ, რომ სამუშაო სადგურისთვის, სადაც აქტიური მუშაობა ხორციელდება ერთი ან ორი საინფორმაციო მონაცემთა ბაზის საშუალებით, ჩვეულებრივი მასობრივი წარმოების HDD-ის შესრულების რესურსები საკმაოდ საკმარისია. SSD-ის შეძენამ შეიძლება დააჩქაროს ზოგიერთი პროცესი, მაგრამ თქვენ ვერ შეამჩნევთ რადიკალურ აჩქარებას ყოველდღიურ მუშაობაში, რადგან, მაგალითად, დატვირთვა შეზღუდული იქნება გამტარუნარიანობაქსელები.

ნელ მყარ დისკს შეუძლია შეანელოს ზოგიერთი ოპერაცია, მაგრამ თავისთავად არ შეიძლება გამოიწვიოს პროგრამის შენელება.

ოპერატიული მეხსიერება

იმისდა მიუხედავად, რომ ოპერატიული მეხსიერება ახლა უხამსად იაფია, ბევრი სამუშაო სადგური აგრძელებს მუშაობას იმ მეხსიერების რაოდენობით, რომელიც იყო დაინსტალირებული შეძენისას. სწორედ აქ ელის პირველი პრობლემები. უკვე იმის საფუძველზე, რომ საშუალო "ტროიკა" მოითხოვს დაახლოებით 500 მბ მეხსიერებას, შეგვიძლია ვივარაუდოთ, რომ 1 GB ოპერატიული მეხსიერების საერთო რაოდენობა არ იქნება საკმარისი პროგრამასთან მუშაობისთვის.

ჩვენ შევამცირეთ სისტემის მეხსიერება 1 გბ-მდე და გავუშვით ორი საინფორმაციო ბაზა.

ერთი შეხედვით, ყველაფერი არც ისე ცუდია, პროგრამამ მადა დაიკლო და კარგად ჯდება ხელმისაწვდომ მეხსიერებაში, მაგრამ არ უნდა დაგვავიწყდეს, რომ ოპერატიული მონაცემების საჭიროება არ შეცვლილა, მაშ სად წავიდა? გადატვირთეთ დისკზე, ქეშზე, სვოპზე და ა.შ., ამ ოპერაციის არსი არის ის, რომ მონაცემები, რომლებიც არ არის საჭირო მომენტში, იგზავნება სწრაფი ოპერატიული მეხსიერებიდან, რომლის რაოდენობაც საკმარისი არ არის, დისკის მეხსიერების შენელებისთვის.

რას გამოიწვევს ეს? ვნახოთ, როგორ გამოიყენება სისტემის რესურსები მძიმე ოპერაციებში, მაგალითად, დავიწყოთ ჯგუფური გადაცემა ერთდროულად ორ მონაცემთა ბაზაში. პირველი სისტემაზე 2 GB ოპერატიული მეხსიერებით:

როგორც ვხედავთ, სისტემა აქტიურად იყენებს ქსელს მონაცემების მისაღებად და პროცესორი დისკის დამუშავების დროს უმნიშვნელოა, მაგრამ არ არის შემზღუდველი ფაქტორი;

ახლა მოდით შევამციროთ მეხსიერება 1 გბ-მდე:

სიტუაცია რადიკალურად იცვლება, ძირითადი დატვირთვა ახლა მყარ დისკზე მოდის, პროცესორი და ქსელი უმოქმედოა, ელოდება სისტემას, რომ წაიკითხოს საჭირო მონაცემები დისკიდან მეხსიერებაში და იქ გაგზავნოს არასაჭირო მონაცემები.

ამავდროულად, სუბიექტური მუშაობაც კი ორ ღია მონაცემთა ბაზაზე 1 GB მეხსიერების სისტემაზე აღმოჩნდა უკიდურესად არასასიამოვნო დირექტორიები და ჟურნალები, რომლებიც იხსნება მნიშვნელოვანი დაგვიანებით და დისკზე აქტიური წვდომით. მაგალითად, საქონლისა და მომსახურების ჟურნალის გახსნას დაახლოებით 20 წამი დასჭირდა და მთელი ამ ხნის განმავლობაში თან ახლდა დისკის მაღალი აქტივობა (ხაზგასმულია წითელი ხაზით).

იმისათვის, რომ ობიექტურად შევაფასოთ RAM-ის გავლენა მართულ აპლიკაციაზე დაფუძნებული კონფიგურაციების შესრულებაზე, ჩვენ განვახორციელეთ სამი გაზომვა: პირველი მონაცემთა ბაზის ჩატვირთვის სიჩქარე, მეორე მონაცემთა დატვირთვის სიჩქარე და ჯგუფის ხელახალი გაშვება ერთ-ერთ მონაცემთა ბაზაში. . ორივე მონაცემთა ბაზა სრულიად იდენტურია და შეიქმნა ოპტიმიზებული მონაცემთა ბაზის კოპირებით. შედეგი გამოიხატება ფარდობით ერთეულებში.

შედეგი თავისთავად მეტყველებს: თუ დატვირთვის დრო იზრდება დაახლოებით მესამედით, რაც ჯერ კიდევ საკმაოდ ასატანია, მაშინ მონაცემთა ბაზაში ოპერაციების შესრულების დრო სამჯერ იზრდება, ასეთ პირობებში რაიმე კომფორტულ სამუშაოზე საუბარი არ არის საჭირო. სხვათა შორის, ეს ის შემთხვევაა, როდესაც SSD-ის ყიდვამ შეიძლება გააუმჯობესოს სიტუაცია, მაგრამ ბევრად უფრო ადვილია (და იაფიც) გაუმკლავდე მიზეზს და არა შედეგებს და უბრალოდ იყიდო RAM-ის სწორი რაოდენობა.

ოპერატიული მეხსიერების ნაკლებობა არის მთავარი მიზეზი, რის გამოც ახალ 1C კონფიგურაციებთან მუშაობა არასასიამოვნო აღმოჩნდება. კონფიგურაციები ბორტზე 2 გბ მეხსიერებით უნდა ჩაითვალოს მინიმალურად შესაფერისად. ამასთან, გაითვალისწინეთ, რომ ჩვენს შემთხვევაში შეიქმნა „სათბურის“ პირობები: მუშაობდა სუფთა სისტემა, მხოლოდ 1C და სამუშაო მენეჯერი. რეალურ ცხოვრებაში, ბრაუზერი ჩვეულებრივ ღიაა სამუშაო კომპიუტერზე, საოფისე კომპლექტი, ანტივირუსი მუშაობს და ა.შ. და ა.შ., ასე რომ, განაგრძეთ 500 მბ საჭიროება მონაცემთა ბაზაზე პლუს გარკვეული ზღვარი, რათა მძიმე ოპერაციების დროს არ შეგხვდეთ მეხსიერების ნაკლებობა და შესრულების მკვეთრი დაქვეითება.

CPU

გაზვიადების გარეშე, ცენტრალურ პროცესორს შეიძლება ეწოდოს კომპიუტერის გული, რადგან ეს არის ის, რომელიც საბოლოოდ ამუშავებს ყველა გამოთვლას. მისი როლის შესაფასებლად, ჩვენ ჩავატარეთ ტესტების კიდევ ერთი ნაკრები, იგივე რაც RAM-ისთვის, რაც შევამცირეთ ხელმისაწვდომი რაოდენობა. ვირტუალური მანქანაბირთვები ორიდან ერთამდე, ხოლო ტესტი ჩატარდა ორჯერ 1 GB და 2 GB მეხსიერების მოცულობით.

შედეგი საკმაოდ საინტერესო და მოულოდნელი აღმოჩნდა: უფრო მძლავრმა პროცესორმა საკმაოდ ეფექტურად იკისრა დატვირთვა რესურსების ნაკლებობის დროს, დანარჩენ დროს რაიმე ხელშესახები უპირატესობის მინიჭების გარეშე. 1C Enterprise (ფაილის რეჟიმში) ძნელად შეიძლება ეწოდოს აპლიკაციას, რომელიც აქტიურად იყენებს პროცესორის რესურსებს. რთულ პირობებში კი პროცესორი იტვირთება არა იმდენად თავად აპლიკაციის მონაცემების გაანგარიშებით, არამედ ზედნადები ხარჯების სერვისით: დამატებითი შეყვან/გამომავალი ოპერაციები და ა.შ.

დასკვნები

მაშ, რატომ არის 1C ნელი? უპირველეს ყოვლისა, ეს არის ოპერატიული მეხსიერების ნაკლებობა, ამ შემთხვევაში, ძირითადი დატვირთვა მოდის მყარ დისკზე და პროცესორზე. და თუ ისინი არ ანათებენ შესრულებით, როგორც ეს ჩვეულებრივ ხდება საოფისე კონფიგურაციებში, მაშინ მივიღებთ სტატიის დასაწყისში აღწერილ სიტუაციას - "ორი" კარგად მუშაობდა, მაგრამ "სამი" უღმერთო ნელია.

მეორე ადგილზეა ქსელის შესრულება ნელი 100 მბიტი/წმ არხი შეიძლება იქცეს ნამდვილ ბოსტნეულად, მაგრამ ამავდროულად, თხელი კლიენტის რეჟიმს შეუძლია შეინარჩუნოს მუშაობის საკმაოდ კომფორტული დონე ნელ არხებზეც კი.

მაშინ ყურადღება უნდა მიაქციოთ დისკზე SSD-ის ყიდვა ნაკლებად სავარაუდოა, რომ იყოს კარგი ინვესტიცია, მაგრამ დისკის ჩანაცვლება უფრო თანამედროვეთ კარგი იდეა იქნება. განსხვავება თაობებს შორის მყარი დისკებიშეიძლება შეფასდეს შემდეგი მასალის გამოყენებით: .

და ბოლოს პროცესორი. უფრო სწრაფი მოდელი, რა თქმა უნდა, არ იქნება ზედმეტი, მაგრამ მისი შესრულების გაზრდას აზრი არ აქვს, თუ ეს კომპიუტერი არ გამოიყენება მძიმე ოპერაციებისთვის: ჯგუფური დამუშავება, მძიმე ანგარიშები, თვის ბოლოს დახურვა და ა.შ.

ვიმედოვნებთ, რომ ეს მასალა დაგეხმარებათ სწრაფად გაიგოთ კითხვა "რატომ არის 1C ნელი" და მოაგვაროთ ის ყველაზე ეფექტურად და ზედმეტი ხარჯების გარეშე.

• ტეგები:

გთხოვთ, ჩართოთ JavaScript სანახავად