1C optimallaşdırması: yavaş 1C-i sürətləndiririk

1C performansının optimallaşdırılması

1C-in yavaşlamasının əsl səbəbini tapırıq — təxminlə yox, texnoloji jurnal və sorğu planları ilə. Sənədlərin keçirilməsini, hesabatları və mübadilələri dəfələrlə sürətləndiririk.

Pulsuz ekspress-audit əldə edin

saatlar → dəqiqələr «ağır» əməliyyatlar üzrə tipik nəticə

Tanış problemlərdir?

Sənədlər dəqiqələrlə keçirilir

Satış sənədinin keçirilməsi və ya ayın bağlanması o qədər uzanır ki, istifadəçilər çay içməyə macal tapır. Bundan sonra daha da pis olacaq.

İstifadəçilər kilidlənmələrə «düşür»

«Kilidlənmə konflikti», «gözləmə vaxtı aşılıb» — bazada adam çox olanda, xüsusən pik günlərdə iş dayanır.

Hesabatlar əbədiyyət qədər qurulur

İdarəetmə hesabatları və böyük dövrlər üzrə dövriyyə-qalıq cədvəli onlarla dəqiqə çəkir və ya taymautla çökür.

Avadanlığı gücləndirdiniz — kömək etmədi

Daha güclü server aldınız, amma sürət artmadı. Deməli, məsələ avadanlıqda deyil — sorğularda, indekslərdə və ya arxitekturadadır.

1C yavaşlayır: nə etməli

Birincisi — yeni server almamaq. On haldan səkkizində 1C-in yavaş işləməsinin səbəbi avadanlıqda deyil: milyonlarla artıq sətir oxuyan sorğularda, çatışmayan indekslərdə, VBİS-in köhnəlmiş statistikasında və ya istifadəçilər arasındakı kilidlənmələrdədir. Bütün bunlar alətlərlə diaqnostika olunur: 1C-in texnoloji jurnalı və SQL sorğu planları günahkarı kod sətrinə qədər dəqiq göstərir.

Səbəbi necə axtarırıq

1C-in texnoloji jurnalı — uzun sorğular və kilidlənmə gözləmələri üzrə hadisələrin toplanmasını sazlayırıq; hansı əməliyyatların və kimin kodunun vaxtı yediyi barədə dəqiq mənzərə alırıq.
SQL sorğu planları — VBİS-in ağır sorğuları əslində necə icra etdiyinə baxırıq: indekslə axtarış əvəzinə skanlamalar, artıq birləşmələr, qeyri-optimal daxili sorğular.
VBİS gözləmə statistikası — serverin nəyə dirəndiyini müəyyən edirik: disklər, prosessor, kilidlənmələr, yaddaş.
Əsas əməliyyatlar üzrə APDEX ölçmələri — sürəti «orta göstərici» ilə yox, istifadəçinin gözü ilə qeydə alırıq.

Tipik tapıntılar

İllər ərzində «günahkarlar» siyahısı təkrarlanır: dövr içində sorğular, seçimsiz virtual cədvəllərlə birləşmələr, keçirilmə tranzaksiyası içində qalıqların alınması, indekslənməmiş sahələr üzrə seçimlər, kütləvi yükləmələrdən sonra köhnəlmiş statistika, öz yazılmış kodda artıq kilidlənmələr. Demək olar ki, hamısı avadanlığı dəyişmədən və yeni konfiqurasiyaya keçmədən müalicə olunur.

SQL serverində 1C-in sürətləndirilməsi

Ayrıca istiqamət — VBİS-in 1C üçün sazlanması: yaddaş və paralellik parametrləri, tempdb, statistikanın avtomatik yenilənməsi, indekslərə xidmət. «Defolt» quraşdırmalar abstrakt yükə hesablanıb, 1C profilinə yox. Həm MS SQL, həm də PostgreSQL sazlayırıq — birindən digərinə miqrasiyalar da daxil olmaqla.

Nə əldə edirsiniz

Rəqəmlərlə diaqnostika: hansı əməliyyat nə qədər çəkir və niyə

Optimallaşdırılmış sorğular və kod — «əvvəl/sonra» ölçmələri ilə

VBİS səviyyəsində sazlanmış indekslər və statistika

Kilidlənmə gözləmələrinin araşdırılması və aradan qaldırılması

Sazlanmış texnoloji jurnal və nəzarət metodikası

Arxitektura və avadanlıq üzrə tövsiyələrlə hesabat — yalnız həqiqətən lazım olan yerdə

Necə işləyirik

Ölçmə və simptomların qeydə alınması

Yavaş əməliyyatların siyahısını toplayır və cari göstəriciləri ölçürük — effekti onlardan hesablayacağıq.

Diaqnostika

Texnoloji jurnal, SQL sorğu planları, gözləmə statistikası. Konkret kod sətirlərini və günahkar sorğuları tapırıq.

Optimallaşdırma

Sorğuları və kodu düzəldirik, indeksləri sazlayırıq, kilidlənmələri aradan qaldırırıq. Hər dəyişikliyi ölçmə ilə yoxlayırıq.

Nəticəyə nəzarət

Siyahıdakı hər əməliyyat üzrə «əvvəl/sonra» göstəririk. Deqradasiya öncədən görünsün deyə monitorinq qururuq.

Tez-tez verilən suallar

1C yavaşlayır — bəlkə sadəcə daha güclü server alaq?

Çox vaxt bu kömək etmir: səbəb adətən avadanlıqda yox, sorğularda, indekslərdə və ya kilidlənmələrdədir. Əvvəlcə diaqnostika — o, dar yerin harada olduğunu dəqiq göstərəcək. Məsələ həqiqətən avadanlıqdadırsa, bunu açıq deyəcəyik və hansı yenilənmənin effekt verəcəyini hesablayacağıq.

Optimallaşdırma müddətində işi dayandırmaq lazımdırmı?

Xeyr. Diaqnostika işlək sistemdə aparılır və istifadəçilərə mane olmur. Kod və indeks dəyişiklikləri nüsxə üzərində hazırlanır və razılaşdırılmış pəncərələrdə — adətən gecə — produktivə köçürülür.

Bizdə qeyri-tipik (təkmilləşdirilmiş) konfiqurasiya var. Bu, problemdirmi?

Əksinə, bu tipik haldır: performans problemlərinin çoxu məhz təkmilləşdirmələrdə yaşayır. Texnoloji jurnal və sorğu planları günahkarı kod sətrinə qədər dəqiq göstərir — konfiqurasiya standart olsun, ya öz yazılmış, fərq etmir.

Hansı effekti gözləmək olar?

«Ağır» əməliyyatlar üzrə tipik nəticə — dəfələrlə sürətlənmə: hesabatlar onlarla dəqiqədən dəqiqələrə, sənəd keçirilməsi dəqiqələrdən saniyələrə enir. Başlamazdan əvvəl ölçmələri qeydə alırıq, sonda hər əməliyyat üzrə «əvvəl/sonra» göstəririk. Təsdiqlənmiş nəticəyə görə ödəyirsiniz.

1C yenilənmədən sonra yavaşlamağa başladı. Kömək edərsinizmi?

Bəli, bu, tez-tez rast gəlinən ssenaridir: yenilənmədən sonra sorğular dəyişir və VBİS statistikası pozulur. Nəyin dəyişdiyini tapır və sürəti geri qaytarırıq — adətən bu, bir neçə gün çəkir.