Mazmunga o'tish
Tez Base

1C unumdorligini optimallashtirish

1C nega sekin ishlayotganining haqiqiy sababini va uning ishini qanday tezlashtirish mumkinligini topamiz - taxmin bilan emas, texnologik jurnal va soʻrov rejalari orqali. Hujjat oʻtkazish, hisobotlar va almashinuvlarni bir necha barobar tezlashtiramiz. Qozogʻiston va MDH boʻylab masofadan.

WhatsApp orqali yozish Bepul ekspress-audit olish

soatlar → daqiqalar "ogʻir" operatsiyalar boʻyicha odatiy natija

150 000 ₸ dan narxi · loyiha uchun soliqlarsiz bepul auditdan keyin qat'iy belgilanadi

Scan нашли, где тормозит

Tanish muammolarmi?

Hujjatlar daqiqalab oʻtkaziladi

Realizatsiyani oʻtkazish yoki oyni yopish shu qadar choʻzildiki, foydalanuvchilar choy ichib ulguradi. Bundan keyin yanada yomonlashadi.

Foydalanuvchilar bloklashlarga duch keladi

"Bloklash konflikti", "kutish vaqti oshib ketdi" - bazada odam koʻp boʻlganda, ayniqsa eng band kunlarda ish toʻxtab qoladi.

Hisobotlar juda uzoq shakllanadi

Boshqaruv hisobotlari va katta davrlar boʻyicha aylanma-qoldiq vedomosti oʻnlab daqiqa quriladi yoki taymaut bilan yiqiladi.

Serverni kuchaytirdingiz - foyda boʻlmadi

Kuchliroq server sotib olindi, lekin ish tezlashmadi. Demak, gap temirda emas - soʻrovlar, indekslar yoki arxitekturada.

1C nega sekin ishlaydi va nega yangi server odatda yordam bermaydi

Birinchi qoida - yangi server sotib olmang. Oʻn holatning sakkizida 1C sekin ishlashining sababi temirda emas: millionlab ortiqcha satrni oʻqiydigan soʻrovlar, mavjud boʻlmagan indekslar, maʼlumotlar bazasini boshqarish tizimi (MBBT)ning eskirgan statistikasi yoki foydalanuvchilar oʻrtasidagi bloklashlar. Bularning barchasi instrumental tarzda tashxislanadi: 1C texnologik jurnali va SQL soʻrov rejalari aybdorni kod satrigacha aniqlik bilan koʻrsatadi.

Sababni qanday izlaymiz

  • 1C texnologik jurnali - uzoq davom etadigan soʻrovlar va bloklashlardagi kutishlar boʻyicha hodisalar yigʻishni sozlaymiz; qaysi operatsiyalar va kimning kodi vaqtni yeyayotganining aniq manzarasini olamiz.
  • SQL soʻrov rejalari - MBBT ogʻir soʻrovlarni aslida qanday bajarayotganini koʻramiz: indeks boʻyicha qidiruv oʻrniga skanerlash, ortiqcha birlashtirishlar, nooptimal ichma-ich soʻrovlar.
  • MBBT kutishlar statistikasi - server nimaga tiralayotganini aniqlaymiz: disklar, protsessor, bloklashlar, xotira.
  • Asosiy operatsiyalar boʻyicha APDEX oʻlchovlari - tezlikni “oʻrtacha koʻrsatkichlar” bilan emas, foydalanuvchi koʻzi bilan qayd etamiz.

Odatiy topilmalar

Yillar davomida “aybdorlar” roʻyxati takrorlanadi: sikldagi soʻrovlar, tanlovlarsiz virtual jadvallar bilan birlashtirishlar, oʻtkazish tranzaksiyasi ichida qoldiqlarni olish, indekslanmagan maydonlar boʻyicha tanlovlar, ommaviy yuklashlardan keyin eskirgan statistika, oʻzi yozilgan koddagi ortiqcha bloklashlar. Deyarli barchasi temirni almashtirmasdan va yangi konfiguratsiyaga oʻtmasdan hal boʻladi.

Real loyihalardan soʻnggi natijalar

  • Kassir oldidagi cheklar roʻyxati: 25 soniya → bir zumda (505 410 → 4 mantiqiy oʻqish) - kassa operatsiyalari uchun indekslar hamda kirishni cheklash mexanizmi tahlili.
  • Oltita ogʻir boshqaruv hisoboti: vaqt boʻyicha −22…−42 % - toʻliq bir xil maʼlumotlarda: “oldin” va “keyin” natijasi “koʻz bilan” emas, SHA-256 nazorat summasi bilan solishtirildi.
  • “Kassalarning kechki qotib qolishi”: bloklashlar nol boʻlib chiqdi - 48 yadroli serverda SQL ning agressiv parallelizmi tormozlagan (zavod sozlamalari: cost threshold = 5, MAXDOP = 0). Ikkita sozlama - va pik lotereya boʻlishdan qoldi. Nega avval oʻlchab, keyin temir sotib olinishining klassik misoli.
  • 2 daqiqa “oʻtkazilmay turgan” hujjat → 17 soniya - har bir satr boʻyicha sikldagi qoldiqlar soʻrovi bitta set-based soʻrovga qayta yozildi.
  • Tahlildan soʻng hisobotlarning bir qismi oʻzgarishsiz qoldirildi - tor joy soʻrovda emas edi va qayta yozish yutuq bermasdi. Tezlashmaydigan narsaga byudjetingizni sarflamaslik ham natija.

Eng yirik loyihaning batafsil tahlili - “4,2 TB bazani 105 GB gacha kesish” keysida.

SQL serverda 1C ni tezlashtirish

Alohida yoʻnalish - MBBTni 1C uchun sozlash: xotira va parallellik parametrlari, tempdb, statistikani avtomatik yangilash, indekslarga xizmat koʻrsatish. “Standart” sozlamalar mavhum yuklamaga moʻljallangan, 1C profiliga emas. MS SQL ni ham, PostgreSQL ni ham sozlaymiz - biridan ikkinchisiga migratsiyalar bilan birga.

Siz nima olasiz

  • Raqamlar bilan diagnostika: qaysi operatsiya qancha vaqt olyapti va nima uchun
  • Optimallashtirilgan soʻrovlar va kod - "oldin/keyin" oʻlchovlari bilan
  • MBBT darajasida sozlangan indekslar va statistika
  • Bloklashlardagi kutishlarni tahlil qilish va bartaraf etish
  • Sozlangan texnologik jurnal va nazorat metodikasi
  • Arxitektura va uskuna boʻyicha tavsiyalar hisoboti - faqat chindan zarur joyda

Biz qanday ishlaymiz

  1. 01

    Oʻlchash va simptomlarni qayd etish

    Sekin operatsiyalar roʻyxatini tuzamiz va joriy koʻrsatkichlarni oʻlchaymiz - samarani shulardan boshlab hisoblaymiz.

  2. 02

    Diagnostika

    Texnologik jurnal, SQL soʻrov rejalari, kutishlar statistikasi. Aybdor kod satrlari va soʻrovlarni aniq topamiz.

  3. 03

    Optimallashtirish

    Soʻrovlar va kodni tuzatamiz, indekslarni sozlaymiz, bloklashlarni bartaraf etamiz. Har bir oʻzgarishni oʻlchov bilan tekshiramiz.

  4. 04

    Natija nazorati

    Roʻyxatdagi har bir operatsiya boʻyicha "oldin/keyin"ni koʻrsatamiz. Degradatsiya oldindan koʻrinishi uchun monitoring sozlaymiz.

1C tizimingiz uchun bepul ekspress-audit

1-2 kun ichida bazangizni ko'rib chiqamiz, unumdorlik qayerda yo'qolayotganini topamiz va nima qilish kerakligini aytamiz. Majburiyatsiz.

Bepul ekspress-audit olish

Ko'p so'raladigan savollar

1C tormozlayapti - balki shunchaki kuchliroq server olish kerakdir?

Koʻpincha bu yordam bermaydi: sabab odatda temirda emas, soʻrovlar, indekslar yoki bloklashlarda boʻladi. Avval diagnostika - u tor joy qayerdaligini aniq koʻrsatadi. Agar gap chindan temirda boʻlsa, buni ochiq aytamiz va qaysi yangilash samara berishini hisoblab beramiz.

Optimallashtirish vaqtida ishni toʻxtatish kerakmi?

Yoʻq. Diagnostika ishlab turgan tizimda olib boriladi va foydalanuvchilarga xalaqit bermaydi. Kod va indekslardagi oʻzgarishlar nusxada ishlab chiqiladi va kelishilgan oynalarda - odatda tunda - produktivga oʻtkaziladi.

Bizda nostandart (qayta ishlangan) konfiguratsiya. Bu muammomi?

Aksincha, bu odatiy holat: unumdorlik muammolarining aksariyati aynan qayta ishlovlarda yashaydi. Texnologik jurnal va soʻrov rejalari aybdorni kod satrigacha aniqlik bilan koʻrsatadi - konfiguratsiya standartmi yoki oʻzi yozilganmi, farqi yoʻq.

Qanday samara kutish mumkin?

"Ogʻir" operatsiyalar boʻyicha odatiy natija - bir necha barobar tezlashish: hisobotlar oʻnlab daqiqadan daqiqalargacha, oʻtkazish daqiqalardan soniyalargacha. Boshlashdan oldin oʻlchovlarni qayd etamiz, tugagach har bir operatsiya boʻyicha "oldin/keyin"ni koʻrsatamiz. Siz tasdiqlangan natija uchun toʻlaysiz.

1C yangilanishdan keyin tormozlay boshladi. Yordam berasizmi?

Ha, bu tez-tez uchraydigan stsenariy: yangilanishdan keyin soʻrovlar oʻzgaradi va MBBT statistikasi ishdan chiqadi. Aynan nima oʻzgarganini topamiz va tezlikni qaytaramiz - bu odatda bir necha kundan boshlanadi.

1C nega hujjatlarni uzoq oʻtkazadi?

Odatda aybdor maʼlumotlar hajmi emas, oʻtkazish kodi qanday yozilgani: hujjat satrlari boʻyicha sikldagi qoldiq soʻrovlari, tranzaksiya ichida qoldiqlarni olish, ortiqcha bloklashlar, MBBTning eskirgan statistikasi. Bizning amaliyotimizda 2 daqiqa "oʻtkazilmay turgan" hujjat mantiqni set-based soʻrovga qayta yozgandan keyin 17 soniyada oʻtkaziladigan boʻldi. Texnologik jurnal boʻyicha diagnostika aybdorni kod satrigacha aniqlik bilan koʻrsatadi.

1C hisobotlarni uzoq shakllantiradi - nima qilish kerak?

Avval hisobot soʻrovini oʻlchab, tahlil qilish kerak: tez-tez uchraydigan sabablar - registrlar boʻyicha ortiqcha oʻtishlar, maʼlumotnomalarga satrma-satr murojaat, filtrlar dublikati, dolzarb boʻlmagan statistika. Tor joylarni qayta yozamiz va maʼlumotlar aynanligini SHA-256 nazorat summasi bilan isbotlaymiz - "oldin" va "keyin" baytma-bayt mos keladi. Ogʻir hisobotlarning odatiy tezlashishi - 22-42 % ga, ayrim veb-yuklamalar - 3-8 barobar.

Agar 1C osilib qolsa, nima qilish kerak?

"Osilib qolish" - koʻpincha bloklashlardagi kutish yoki seansni ushlab turgan ogʻir operatsiya. Texnologik jurnal va kutishlar statistikasi yigʻishni sozlaymiz, kim va nimani bloklab turganini topamiz. Bitta loyihada "kassalarning kechki osilib qolishi" bloklashlar emas (ular nol edi), 48 yadroli serverda SQL ning agressiv parallelizmi boʻlib chiqdi - pik "yopishib qolishdan" toʻxtashi uchun ikkita sozlama yetdi.

Vazifani muhokama qilamiz

Eng tezi WhatsApp: vazifa haqida bir-ikki qator yozing, ish kuni davomida javob beramiz.

[email protected]

Arizani forma orqali qoldirish qulayroq

O'xshash xizmatlar