გოდეს ინტერნეტ დავთარი

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

როგორც ადრ ვყვებოდი, თემაში SQL Server 2005 და მისტიური Error 701 32 ბიტიან ოპერაციულ სისტემაში, სერიოზული პრობლემები შეიძლება შეგექმნათ მეხსიერებასთან დაკავშირებით. იქვე ნახავდით გამოსავალსაც, რომელიც იმ დროს ვიპოვნე. საქმე იმაშია, რომ გამოსავალმა თითქოს ყველაფერს უშველა, მაგრამ ბოლო პერიოდში მსგავსი შეცდომები იშვიათად, მაგრამ მაინც ხდებოდა და შემდეგ ლოგში დიდი ოდენობით რეგისტრირდებოდა AppDomain xxx is marked for unload due to memory pressure. ტიპის შეცდომები. საბოლოო ჯამში ერთადერთი გამოსავალი სერვერის გადატვირთვა იყო.

პრობლემა კვლავ მეხსიერებაშია, ოღონდ ამჯერად CLR პროცედურების მეხსიერების ბუფერში და არა დიდი ზომის მეხისერების ვირტუალურ დამისამართებაში. როგორც აღმოჩნდა, CLR პროცედურები, მეხსიერებას იღებენ არა buffer pool-იდან, არამედ თავისი, გარე მეხსიერების ბუფერიდან, რომელიც მეხსიერების ძირითადი მართვისგან დამოუკიდებელია. კიდევ უარესი ისაა, რომ 32 ბიტიან სისტემებზე ამ ბუფერის ზომა 256 მეგაბაიტია. ერთი შეხედვით 256 მეგაბაიტი საკმაოდ დიდი მოცულობაა CLR პროცედურებისათვის, მაგრამ მიუხედავად იმისა, რამდენად “სუფთა” კოდი გიწერიათ CLR პროცედურებში, მეხსიერების ბუფერის გადავსება პრობლემას არ წარმოადგენს დიდი დატვირთვების დროს. შედეგად, სწორედ ამ პრობლემასთან გვქონდა საქმე და გამოსავალიც საკმაოდ ბანალურია, სერვერის გაშვება სპეციალური პარამეტრით, რომელიც წინასწარ არეზერვებს უფრო დიდი მეხსიერების ბუფერს. ეს ჯადოსნური პარამეტრია: -g და შემდეგ მიყოლებით მეხსიერების ბუფერის ზომა, მაგალითად -g512 რაც ნიშნავს, რომ სერვერის სტარტისას, CLR-ისათვის გამოიყოფა 512 მეგაბაიტიანი მეხსიერების ბუფერი. ჩემს შემთხვევაში თითქოს პრობლემას ეშველა და 512 მეგაბაიტი საკმარისია დატვირთვების მომენტში.

პარამეტრის გასაწერად, SQL Server Configuration Manager-ში აირჩიეთ სერვისის ინსტანსი, და Advanced - ში მოძებნეთ სიაში Startup Parameters-ი. ბოლოში ამატებთ: ;-g512 გადატვირთავთ სერვერს და ეგაა