Serveri i bazës së të dhënave me burim të hapur shton grumbullimin e thread-eve në 26.7.0 dhe 9.7.2
Grumbullimi i thread-eve të bazës së të dhënave ka mbërritur në edicionin komunitar falas të lëshimit të korrikut të serverit relacional të bazës së të dhënave me burim të hapur, versionet 26.7.0 dhe 9.7.2. Inxhinieri i softuerit të Percona-s, Bogdan Degtyariov, shkruan në një postim të 5 tetorit 2026 se para këtij lëshimi, shtojca zyrtare e grumbullimit të thread-eve të serverit ekzistonte vetëm për klientët që paguajnë të edicionit të ndërmarrjes së të njëjtit server të bazës së të dhënave. Alternativat kryesore falas me grumbullim thread-esh ishin serveri i bazës së të dhënave i Percona-s, i cili e shpërndante si shtojcë, një fork komunitar i të njëjtit motor me grumbullim thread-esh të integruar në server, dhe një shtojcë GitHub nga palë të treta. Kjo pjesë e parë e analizës së Degtyariov mbulon se çfarë është grumbullimi i thread-eve dhe si e implementon serveri i bazës së të dhënave i Percona-s; një krahasim i performancës midis serverit të bazës së të dhënave të Percona-s dhe serverit të bazës së të dhënave me burim të hapur shfaqet në Pjesën 2.
Grumbullimi i thread-eve është një teknikë që ripërdor një numër fiks thread-esh të parakrijuar për të trajtuar lidhje të shumta klientësh dhe për të ekzekutuar deklarata brenda një baze të dhënash. Në një konfigurim të parazgjedhur të serverit relacional të bazës së të dhënave me burim të hapur, të quajtur një-thread-për-lidhje, serveri krijon një thread të dedikuar sa herë që një klient lidhet, ekzekuton pyetjet e atij klienti dhe më pas shkatërron thread-in. Kur numri i lidhjeve rritet shumë, kjo metodë e parazgjedhur shkakton rënie të ndjeshme të performancës sepse krijimi, shkatërrimi dhe ndërrimi i vazhdueshëm midis mijëra thread-eve, një proces i quajtur ndërrim konteksti, harxhon burime të sistemit dhe krijon konkurrencë, që do të thotë se shumë procese konkurrojnë për të njëjtin CPU dhe memorie. Vadim Tkachenko i Percona-s ka përdorur një analogji të kontrollit të trafikut për të shpjeguar grumbullimin e thread-eve në një postim të veçantë, dhe dokumentacioni i Percona-s e mbulon më tej. Degtyariov shton një paralajmërim të qartë: grumbullimi i thread-eve nuk është një përshpejtues universal i bazës së të dhënave. Është një mjet i avancuar që duhet përdorur me kuptim të plotë të ngarkesës së punës; përndryshe rezultatet mund të jenë larg nga perfektja.
Grumbullimi i thread-eve organizon punën në grupe thread-esh. Çdo grup i caktohet një bërthame specifike CPU, kështu që numri i grupeve shpesh përputhet me numrin e bërthamave fizike ose logjike. Lidhjet hyrëse të klientëve shpërndahen në mënyrë të barabartë nëpër këto grupe me një metodë round-robin, që do të thotë se çdo lidhje e re dërgohet te grupi tjetër me radhë. Brenda çdo grupi, një thread dëgjues monitoron pyetjet hyrëse dhe i vendos ato ose në një radhë me prioritet të lartë, si pyetjet brenda një transaksioni aktiv, ose në një radhë normale me prioritet të ulët. Thread-et punëtorë më pas marrin pyetjet nga radhët, duke trajtuar gjithmonë artikujt me prioritet të lartë së pari, i ekzekutojnë ato dhe presin për kërkesën tjetër në vend që të mbyllen. Ky ripërdorim eliminon koston e krijimit dhe shkatërrimit të një thread-i për çdo lidhje.
Benchmark-u i përshkruar nga Degtyariov teston disa cilësime të grumbullimit të thread-eve. Baza fillestare përdor thread_handling=one-thread-per-connection, ndërsa ekzekutimet e grumbulluara përdorin thread_handling=pool-of-threads. Parametri thread_pool_size testohet në 10, 20, 40, 80, 120 dhe 160; autori vëren se një vlerë prej 5 u testua gjithashtu por performanca ishte e pakënaqshme dhe nuk është përfshirë. Një çift i dytë parametrash, thread_pool_max_threads / thread_pool_max_active_query_threads, është fiksuar në 12000 si numri maksimal i thread-eve në grumbull. Një çift i tretë, thread_pool_oversubscribe / thread_pool_query_threads_per_group, teston vlerat 2, 3 dhe 4, të cilat përcaktojnë se sa thread-e mund të jenë aktivë në të njëjtën kohë brenda një grupi të vetëm.
Ngarkesa e punës së testit është Sysbench OLTP Read-Write, një mjet i zakonshëm i linjës së komandës që gjeneron ngarkesë të përpunimit të transaksioneve online. Serveri ekzekutohet në një Intel Xeon Gold 6230 me dy procesorë 20-bërthamësh, hyper-threading që jep 80 CPU logjike, 187 GiB memorie DDR4 dhe një SSD Intel NVMe 2.9 TB (modeli SSDPE2KE032T8). Sistemi operativ është Ubuntu 24.04 me kernel 6.8.0-60-generic. Motorët e bazës së të dhënave të krahasuar janë serveri i bazës së të dhënave i Percona-s 9.7.1-1 dhe serveri i bazës së të dhënave me burim të hapur 26.7.0, të dy ndërtime lëshimi. Baza e të dhënave e testit përmban 24 GB të dhëna, ose 100 milionë rreshta, të shpërndara nëpër 20 tabela në të gjitha ekzekutimet. Skema është e disponueshme si një skedar SQL i shkarkueshëm në https://percona-lab-results.github.io/2026-interactive-metrics/schema_dump.sql.
Konkurrenca është një dimension tjetër: benchmark-u drejton 40, 80, 120, 160, 320, 640, 1280, 2560 dhe 5120 thread-e konkurruese. Tre raporte buffer-ndaj-të-dhënave përdoren: 1:12 për një ngarkesë pune të kufizuar nga I/O, 1:2 për një ngarkesë pune pjesërisht të buferuar dhe 1:1 për një ngarkesë pune plotësisht të buferuar, të cilat korrespondojnë me madhësi të InnoDB buffer pool prej 2 GB, 12 GB dhe 32 GB. Para çdo matjeje, përdoret një fazë rritjeje prej 600 sekondash, ose 10 minutash, dhe postimi thotë se kohët e rritjes u përcaktuan eksperimentalisht derisa rritja e mëtejshme e tyre nuk prodhoi ndryshime të rëndësishme. Dritarja aktuale e matjes është 900 sekonda, ose 15 minuta, bazuar në përvojën e mëparshme të benchmark-ut për të mbajtur kohën totale të testimit të arsyeshme. Çdo konfigurim ekzekutohet një herë sepse suita e plotë tashmë kërkon shumë kohë.
Disa cilësime të tjera të bazës së të dhënave renditen si të rëndësishme. InnoDB buffer pool, zona e memories ku serveri relacional i bazës së të dhënave me burim të hapur ruan në cache faqet e të dhënave dhe indekseve, është vendosur në 2 GB, 12 GB ose 32 GB në varësi të raportit. Ngarkimi i buffer pool në fillim dhe hedhja në mbyllje janë të dyja të fikura (OFF). Stack-u i thread-it është 512K, madhësia e cache-it të thread-eve është 256 dhe backlog-u i lidhjeve është 4096. Kapaciteti I/O i InnoDB është vendosur në 10000, me maksimum 20000, dhe thread-et e leximit I/O janë vendosur në 16. Postimi vëren se skedarët e plotë të konfigurimit për çdo ekzekutim mund të shkarkohen nga grafikët e tij interaktivë.
Pjesa 1 qëllimisht nuk përmban rezultate të performancës. Ajo vendos mekanikën dhe mjedisin e testimit në mënyrë që lexuesit të kuptojnë saktësisht se çfarë do të matet. Krahasimi i performancës midis serverit të bazës së të dhënave të Percona-s me grumbullimin e tij të thread-eve dhe serverit të bazës së të dhënave me burim të hapur me aftësi të re është subjekt i Pjesës 2. Për ekipet që ekzekutojnë baza të dhënash në prodhim, infrastruktura e menaxhuar e cloud-it dhe e të dhënave si AEU Data ofron baza të dhënash të menaxhuara, kopje rezervë të automatizuara, ruajtje të enkriptuar, monitorim dhe blloqe ndërtimi me disponueshmëri të lartë, kështu që një eksperiment me grumbullim thread-esh nuk duhet të rrezikojë kopjet rezervë ose kohën e funksionimit.