Zabbix pergalek çavdêriyê ye. Mîna her pergalek din, ew bi sê pirsgirêkên sereke yên hemî pergalên çavdêriyê re rû bi rû dimîne: berhevkirin û hilberandina daneyan, tomarkirina dîrokê, û paqijkirina wê.
Qonaxên wergirtin, hilgirtin û tomarkirina daneyan dem digire. Ne pir, lê ji bo pergalek mezin ev dibe sedema derengiyên mezin. Pirsgirêka hilanînê pirsgirêkek gihîştina daneyê ye. Ew ji bo rapor, kontrol û tehlîlan têne bikar anîn. Derengiya gihîştina daneyê jî bandorê li performansê dike. Dema ku databas mezin dibin, pêdivî ye ku daneyên negirêdayî werin jêbirin. Rakirin operasyonek dijwar e ku hin çavkaniyan jî dixwe.
Pirsgirêkên dereng di dema berhevkirin û hilanînê de li Zabbix bi cachkirinê têne çareser kirin: çend celeb cache, caching di databasê de. Ji bo çareserkirina pirsgirêka sêyemîn, caching ne maqûl e, ji ber vê yekê Zabbix TimescaleDB bikar anî. Ew ê ji we re behsa wê bike Andrey Gushchin - endezyar piştgiriya teknîkî . Andrey ji 6 salan zêdetir piştgirî dide Zabbix û bi performansê re xwedan ezmûnek rasterast e.
TimescaleDB çawa dixebite, ew dikare li gorî PostgreSQL-ya birêkûpêk çi performansê bide? Zabbix ji bo databasa TimescaleDB çi rola dilîze? Meriv çawa ji sifrê dest pê dike û meriv çawa ji PostgreSQL koç dike û kîjan veavakirinê performansa çêtir heye? Li ser van hemûyan di bin birîn.
Zehmetiyên Berhemdariyê
Her pergala çavdêriyê bi pirsgirêkên performansa taybetî re rû bi rû ye. Ez ê li ser sê ji wan bipeyivim: berhevkirin û hilanîna daneyan, hilanîn, û paqijkirina dîrokê.
Komkirina daneyan û pêvajoyek bilez. Pêdivî ye ku pergalek çavdêriya baş zû hemî daneyan werbigire û wê li gorî vegotinên tetikê - li gorî pîvanên xwe bişopîne. Piştî pêvajoyê, pêdivî ye ku pergal ji bo karanîna paşê jî zû van daneyan di databasê de hilîne.
Depokirina Dîrokê. Pergalek çavdêriya baş divê dîrokê di databasek de hilîne û gihîştina metrîkan hêsan peyda bike. Dîrok hewce ye ku di rapor, grafîkan, kêşan, bend û hêmanên daneyên hişyariyê yên hesabkirî de were bikar anîn.
Paqijkirina dîrokê. Carinan rojek tê ku hûn ne hewce ne ku metrîkan hilînin. Çima ji we re daneyên ku 5 sal berê, mehek an du meh hatine berhev kirin hewce ne: hin girêk hatine jêbirin, hin hoste an metrîk êdî ne hewce ne ji ber ku ew kevnar in û nema têne berhev kirin. Pergalek çavdêriya baş divê daneyên dîrokî hilîne û dem bi dem jê bibe da ku databas mezin nebe.
Paqijkirina daneyên rawestayî pirsgirêkek krîtîk e ku pir bandor li performansa databasê dike.
Caching li Zabbix
Di Zabbix de, bangên yekem û duyemîn bi karanîna cachkirinê têne çareser kirin. RAM ji bo berhevkirin û pêvajoykirina daneyan tê bikar anîn. Ji bo hilanînê - dîrok di tetik, graf û hêmanên daneya hesabkirî de. Li aliyê databasê ji bo vebijarkên bingehîn hin caching heye, mînakî, grafîk.
Caching li kêleka servera Zabbix bixwe ev e:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Li wan bêtir balkêş bikin.
ConfigurationCache
Ev cache-ya sereke ye ku em metrîkan, mêvandar, hêmanên daneyê, tetikan hilînin - her tiştê ku em ji bo PreProcessing û berhevkirina daneyan hewce ne.
Hemî ev di ConfigurationCache de têne hilanîn da ku di databasê de pirsên nehewce çênebin. Piştî ku server dest pê dike, em vê cache-ê nûve dikin, mîhengan diafirînin û dem bi dem nûve dikin.
Komkirina daneyan
Diagram pir mezin e, lê ya sereke di wê de ye pickers. Ev cûrbecûr "pollers" - pêvajoyên kombûnê ne. Ew ji cûrbecûr kombûnê berpirsiyar in: ew daneyan bi SNMP, IPMI berhev dikin, û hemî wan vediguhezînin PreProcessing.
Berhevkar bi porteqalî hatine xêzkirin.
Zabbix hêmanên berhevkirinê yên ku ji bo berhevkirina kontrolan hewce ne hesab kiriye. Ger em wan hebin, em daneyên ji bo wan rasterast ji ValueCache digirin.
PreProcessing HistoryCache
Hemî berhevkar ConfigurationCache bikar tînin da ku karan bistînin. Dûv re ew wan vediguhezînin PreProcessing.
PreProcessing ConfigurationCache bikar tîne da ku gavên PreProcessing bistîne. Ew van daneyan bi awayên cûrbecûr pêvajoyê dike.
Piştî ku daneyan bi karanîna PreProcessing hilberandin, em wê ji bo pêvajoyê di HistoryCache de hilînin. Ev berhevkirina daneyan bi dawî dike û em li Zabbix diçin pêvajoya sereke - syncer dîrokê, ji ber ku ew mîmariyek yekparêz e.
Nîşe: PreProcessing operasyonek pir dijwar e. Bi v 4.2 re ew li proxy hatîye bar kirin. Ger we Zabbixek pir mezin heye ku bi hejmareke mezin hêmanên daneyê û frekansa berhevkirinê re heye, wê hingê ev kar pir hêsantir dike.
ValueCache, cache dîrok & trend
Hevdengkirina Dîrokê pêvajoya sereke ye ku bi atomî her elementek daneyê, ango, her nirxê pêvajoyê dike.
Hevdengkera Dîrokê nirxan ji HistoryCache digire û Veavakirinê ji bo hebûna kêşeyên ji bo hesaban kontrol dike. Ger hebin, ew hesab dike.
Hevdengkirina Dîrokê bûyerek, mezinbûnek diafirîne da ku heke ji hêla veavakirinê û tomarkirinê ve hewce be hişyariyan biafirîne. Ger ji bo pêvajoyek paşerojê vekêşan hebin, wê hingê ew vê nirxê li ValueCache hilîne da ku negihîje tabloya dîrokê. Bi vî rengî ValueCache bi daneyên ku ji bo hesabkirina kêşan û hêmanên hesabkirî hewce ne tije ye.
Syncera Dîrokê hemî daneyan li databasê dinivîse, û ew li ser dîskê dinivîse. Pêvajoya pêvajoyê li vir bi dawî dibe.
Caching di databasê de
Dema ku hûn dixwazin grafîkan an raporên li ser bûyeran bibînin, li ser milê databasê caşên cihêreng hene:
Innodb_buffer_poolli aliyê MySQL;shared_buffersli aliyê PostgreSQL;effective_cache_sizeli aliyê Oracle;shared_poolli aliyê DB2.
Gelek kaşên din hene, lê ji bo hemî databasên sereke ev in. Ew dihêlin ku hûn daneyên di RAM-ê de ku pir caran ji bo pirsan hewce ne hilînin. Ji bo vê teknolojiyên xwe hene.
Performansa databasê krîtîk e
Pêşkêşkara Zabbix bi berdewamî daneyan berhev dike û dinivîse. Dema ku ji nû ve tê destpêkirin, ew ji dîrokê jî dixwîne da ku ValueCache tije bike. Skrîpt û raporan bikar tîne Zabbix API, ku li ser navgîniya Webê hatî çêkirin. Zabbix API digihîje databasê û daneyên pêwîst ji bo grafîkan, rapor, navnîşên bûyeran û pirsgirêkên herî dawî vedigire.
Ji bo dîtinê - Grafana. Ev di nav bikarhênerên me de çareseriyek populer e. Ew dikare rasterast bi navgîniya Zabbix API û databasê daxwaziyan bişîne, û ji bo wergirtina daneyan pêşbaziyek diyar diafirîne. Ji ber vê yekê, birêkûpêktir û çêtir a databasê hewce ye ku bi radestkirina bilez a encam û ceribandinê re têkildar be.
Housekeeper
Pirsgirêka performansa sêyemîn a li Zabbix paqijkirina dîrokê bi karanîna Housekeeper e. Ew hemî mîhengan dişopîne - hêmanên daneyê destnîşan dikin ka di çend rojan de dînamîkên guheztinê (meyldaran) çiqas dirêj tê hilanîn.
Em TrendsCache di firînê de hesab dikin. Dema ku dane digihîjin, em wê ji bo saetekê berhev dikin û ji bo dînamîkên guheztinên trendê di tabloyan de tomar dikin.
Housekeeper bi karanîna "hilbijarkên" adetî agahdariya ji databasê dest pê dike û jê dike. Ev her gav ne bandorker e, wekî ku ji grafikên performansê yên pêvajoyên navxweyî tê dîtin.
Grafika sor nîşan dide ku syncera Dîrokê bi domdarî mijûl e. Grafika porteqalî ya li jor Housekeeper e, ku bi domdarî dimeşe. Ew li benda databasê ye ku hemî rêzikên ku wî diyar kirine jê bibe.
Kengê divê hûn Housekeeper neçalak bikin? Mînakî, "Nasnameya Babetê" heye û divê hûn di demek diyarkirî de 5 hezar rêzên paşîn jêbikin. Bê guman, ev ji hêla indexê ve dibe. Lê bi gelemperî databas pir mezin e, û databas hîn jî ji dîskê dixwîne û wê dixe nav cache. Ev her gav ji bo databasê operasyonek pir biha ye û, li gorî mezinahiya databasê, dikare bibe sedema pirsgirêkên performansê.
Xizmetkara malê hêsan e ku meriv neçalak bike. Di navgîniya Webê de ji bo Housekeeper mîhengek di "Rêveberiya Giştî" de heye. Em ji bo dîroka meyla hundurîn Xanîparêziya navxweyî neçalak dikin û ew êdî wê îdare nake.
Housekeeper hate qewirandin, grafîk hatin ast kirin - di vê rewşê de çi pirsgirêk dikarin hebin û çi dikare bibe alîkar ku pirsgirêka performansa sêyemîn çareser bike?
Parvekirin - dabeşkirin an dabeşkirin
Bi gelemperî, dabeşkirin li ser her databasa pêwendiya ku min navnîş kiriye bi rengek cûda tête mîheng kirin. Her yek teknolojiya xwe heye, lê ew bi gelemperî dişibin hev. Afirandina dabeşek nû pir caran dibe sedema hin pirsgirêkan.
Bi gelemperî, dabeş li gorî "sazkirinê" têne mîheng kirin - hêjeya daneyên ku di rojekê de têne afirandin. Wekî qaîdeyek, Parvekirin di rojekê de tê derxistin, ev herî kêm e. Ji bo meylên komek nû - 1 meh.
Heke "sazkirin" pir mezin be dibe ku nirx biguhezin. Ger "sazkirinek" piçûk heya 5 nvps be (nirxên nû serê saniyeyê), ya navîn ji 000 heta 5 e, wê hingê ya mezin ji 000 nvps re ye. Ev sazûmanên mezin û pir mezin in ku hewcedarî bi baldarî veavakirina databasê ne.
Li ser sazkirinên pir mezin, heyama yek rojê dibe ku ne çêtirîn be. Min rojane dabeşên MySQL yên 40 GB an jî zêdetir dîtiye. Ev hejmareke pir mezin a daneyan e ku dibe sedema pirsgirêkan û pêdivî ye ku were kêm kirin.
Dabeşkirin çi dide?
Tabloyên dabeşkirinê. Pir caran ev pelên cuda yên li ser dîskê ne. Plana lêpirsînê yek partîsiyonê çêtirîn hildibijêre. Bi gelemperî dabeşkirin ji hêla rêzê ve tê bikar anîn - ev ji bo Zabbix jî rast e. Em li wir "demjimêr" bikar tînin - dem ji destpêka serdemê ve. Ev ji bo me hejmarên asayî ne. Hûn destpêk û dawiya rojê destnîşan dikin - ev dabeşek e.
Rakirina bilez - DELETE. Pelek/subtablek tê hilbijartin, li şûna bijartina rêzan ji bo jêbirinê.
Bi girîngî bilezkirina daneyan zêde dike SELECT - ji tabloya tevahî, yek an çend dabeşan bikar tîne. Ger hûn xwe bigihînin daneya ku du roj berê ne, ew ji databasê zûtir tê derxistin ji ber ku hûn tenê hewce ne ku pelek li kaşê bar bikin û vegerînin, ne tabloyek mezin.
Bi gelemperî gelek databas jî têne lez kirin INSERT - têketina nav maseya zarokan.
TimescaleDB
Ji bo v 4.2, me bala xwe da TimescaleDB. Ev pêvekek ji bo PostgreSQL bi navgînek xwemalî ye. Berfireh bi daneyên rêzikên demê re bi bandor dixebite, bêyî ku feydeyên databasên têkildar winda bike. TimescaleDB jî bixweber dabeş dibe.
TimescaleDB têgehek heye hypertable (hîpertable) ku hûn diafirînin. Dihewîne perçe - partîsiyonên. Parçe bixweber perçeyên hîpertabloyê ne ku bandorê li perçeyên din nakin. Her perçeyek dema xweya xwe heye.
TimescaleDB vs PostgreSQL
TimescaleDB bi rastî bi bandor dixebite. Hilberînerên pêvekê îdîa dikin ku ew algorîtmayek hilberandina pirsê rasttir bikar tînin, bi taybetî inserts . Her ku mezinahiya têketina databasê mezin dibe, algorîtma performansa domdar diparêze.
Piştî 200 mîlyon rêzikan, PostgreSQL bi gelemperî dest pê dike ku bi girîngî bişewitîne û performansê digihîje 0. TimescaleDB dihêle hûn ji bo her mîqdara daneyê bi rengek bikêrhatî "navdêran" têxin nav xwe.
mîhengê
Sazkirina TimescaleDB ji bo her pakêtê pir hêsan e. LI her tişt bi hûrgulî tête diyar kirin - ew bi pakêtên fermî PostgreSQL ve girêdayî ye. TimescaleDB jî dikare bi destan were çêkirin û berhev kirin.
Ji bo databasa Zabbix em tenê pêvekê çalak dikin:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Hûn çalak bikin extension û wê ji bo databasa Zabbix biafirînin. Pêngava paşîn çêkirina hîpertable ye.
Koçkirina tabloyên dîrokê li TimescaleDB
Ji bo vê fonksiyonek taybetî heye create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Fonksiyon sê parameteran hene. Yekem - tabloya di databasê de, ji bo ku hûn hewce ne ku hîpertable çêbikin. Duyem - zevî, li gorî ku hûn hewce ne ku çêbikin chunk_time_interval - navbera perçeyên dabeşkirinê yên ku têne bikar anîn. Di doza min de, navber rojek e - 86.
Parametreya sêyemîn - migrate_data. Ger hûn saz bikin true, wê hingê hemî daneyên heyî li perçeyên pêş-afirandî têne veguheztin. Min bi xwe bi kar anî migrate_data. Nêzîkî 1 TB min hebû, ku zêdetirî saetekê girt. Tewra di hin rewşan de, di dema ceribandinê de, min daneyên dîrokî yên celebên karakterê ku ji bo hilanînê ne hewce ne jêbirin, da ku wan neguhezînim.
Pêngava dawî - UPDATE: di db_extension raxistan timescaledbda ku databas fêm bike ku ev pêvek heye. Zabbix wê çalak dike û bi rast hevoksazî û pirsnameyên databasê bikar tîne - ew taybetmendiyên ku ji bo TimescaleDB hewce ne.
Veavakirina hardware
Min du server bikar anîn. Yekem - makîneya VMware. Ew pir piçûk e: 20 Intel® Xeon® CPU E5-2630 v 4 pêvajoyên 2.20GHz, 16 GB RAM û 200 GB SSD.
Min PostgreSQL 10.8 li ser wê bi Debian 10.8-1.pgdg90+1 OS û pergala pelê xfs saz kir. Min her tişt bi hindiktirîn mîheng kir ku vê databasa taybetî bikar bîne, ji bilî tiştê ku Zabbix bixwe dê bikar bîne.
Li ser heman makîneyê serverek Zabbix, PostgreSQL û ajanên barkirinê. 50 ajanên min ên çalak hebûn ku bikar tînin LoadableModuleku pir zû encamên cûda çêbike: jimar, rêz. Min databas bi gelek daneyan tije kir.
Di destpêkê de veavakirin dihewand 5 hêmanên daneyên per host. Hema hema her hêmanek tetikek vedihewîne da ku ew mîna sazûmanên rastîn çêbike. Di hin rewşan de ji yekê zêdetir teşqele hebû. Ji bo yek girêka torê hebûn 3-000 tetikan.
Navbera Nûvekirina Babetê Dane − 4-7 seconds. Min barkirin bixwe bi karanîna ne tenê 50 ajanan, lê lê zêdekirina bêtir verast kir. Di heman demê de, bi karanîna hêmanên daneyê, min bi dînamîk barkirin rast kir û navbera nûvekirinê daxist 4 seqeyan.
PostgreSQL. 35 nvps
Yekem xebitandina min a li ser vê hardware li ser PostgreSQL-ya paqij bû - 35 hezar nirx di çirkeyê de. Wekî ku hûn dibînin, danîna daneyan perçeyên çirkeyê digire - her tişt baş û bilez e. Tiştek tenê ev e ku dîskek SSD ya 200 GB zû tijî dibe.
Ev tabloyek performansa servera Zabbix standard e.
Grafika şîn a yekem hejmara nirxan di saniyeyê de ye. Grafika duyemîn li rastê barkirina pêvajoyên avakirinê ye. Ya sêyemîn barkirina pêvajoyên avakirina navxweyî ye: hevdengên dîrokê û Housekeeper, ku ev demek dirêj e li vir dimeşîne.
Grafika çaremîn karanîna HistoryCache nîşan dide. Berî ku têxin nav databasê, ev celebek tampon e. Grafika pêncemîn a kesk karanîna ValueCache nîşan dide, ango çendîn ValueCache ji bo teşqeleyan lêdixe - ev çend hezar nirx di çirkeyê de ye.
PostgreSQL. 50 nvps
Dûv re min barkirinê li ser heman hardware di saniyeyê de 50 hezar nirx zêde kir.
Dema ku ji Housekeeper barkirin, têxistina 10 hezar nirxan 2-3 saniyeyan girt.
Kevana malê jixwe dest bi mudaxeleya xebatê dike.
Grafika sêyemîn nîşan dide ku, bi gelemperî, barkirina li ser xefik û hevrêzên dîrokê hîn jî di %60 de ye. Di grafiya çaremîn de, HistoryCache jixwe di dema operasyona Housekeeper de bi rengek çalak dest pê dike. Ew 20% tije ye, ku bi qasî 0,5 GB ye.
PostgreSQL. 80 nvps
Dûv re min barkirinê di saniyeyê de 80 hezar nirx zêde kir. Ev bi qasî 400 hezar hêmanên daneyê û 280 hezar tetikan e.
Mesrefa barkirina sî hevrêzên dîrokê jixwe pir zêde ye.
Min pîvanên cihêreng jî zêde kir: hevrêzên dîrokê, kaş.
Li ser hardware min, barkirina hevrêzên dîrokê herî zêde zêde bû. HistoryCache zû bi daneyan dagirtî - daneyên ji bo pêvajoyê di tamponê de kom bûne.
Hemî vê demê min dît ku çawa pêvajo, RAM û pîvanên pergalê yên din têne bikar anîn, û min dît ku karanîna dîskê herî zêde ye.
Min bi kar anî herî zêde şiyanên dîskê li ser vê hardware û li ser vê makîneya virtual. Bi vî rengî tundî, PostgreSQL dest pê kir ku daneyan bi rengek çalak paqij bike, û dîskê êdî wextê nivîsandin û xwendinê nema.
Pêşkêşkara duyemîn
Min serverek din hilda, ku berê 48 pêvajoyê û 128 GB RAM hebû. Min ew birêkûpêk kir - ew li ser 60 syncera dîrokê danî, û performansa pejirandî bi dest xist.
Di rastiyê de, ev jixwe sînorê hilberînê ye ku divê tiştek were kirin.
TimescaleDB. 80 nvps
Karê min ê sereke ceribandina kapasîteyên TimescaleDB li hember barkirina Zabbix e. 80 hezar nirx di çirkeyê de pir e, frekansa berhevkirina metrîkan (bê guman ji bilî Yandex) û "sazkirinek" pir mezin e.
Di her grafîkê de kêmbûnek heye - ev bi rastî koça daneyê ye. Piştî têkçûnên di servera Zabbix de, profîla barkirinê ya syncera dîrokê pir guherî - ew sê caran daket.
TimescaleDB destûrê dide te ku hûn daneyan hema 3 carî zûtir têxin nav xwe û kêmtir HistoryCache bikar bînin.
Li gorî vê yekê, hûn ê di wextê xwe de daneyan bistînin.
TimescaleDB. 120 nvps
Dûv re min hejmara hêmanên daneyê zêde kir 500 hezar. Karê sereke ceribandina kapasîteyên TimescaleDB bû - min nirxek hesabkirî ya 125 hezar nirx di çirkeyê de wergirt.
Ev "sazkirinek" xebitîn e ku dikare ji bo demek dirêj bixebite. Lê ji ber ku dîska min tenê 1,5 TB bû, min ew di nav çend rojan de tijî kir.
Ya herî girîng ev e ku di heman demê de dabeşên nû yên TimescaleDB hatin afirandin.
Ev ji bo performansê bi tevahî nayê dîtin. Mînakî, dema ku dabeş di MySQL de têne afirandin, her tişt cûda ye. Ev bi gelemperî bi şev diqewime ji ber ku ew têketina gelemperî asteng dike, bi tabloyan re dixebite û dikare hilweşîna karûbarê biafirîne. Ev bi TimescaleDB re ne wusa ye.
Wek nimûne, ez ê yek grafiyek ji gelek di civakê de nîşan bidim. Di wêneyê de, TimescaleDB çalak e, ji ber vê yekê barê karanîna io.weight li ser pêvajoyê daketiye. Bikaranîna hêmanên pêvajoya navxweyî jî kêm bû. Wekî din, ev makîneyek virtual ya asayî ye li ser dîskên pancake yên normal, ne SSD.
vebiguherin
TimescaleDB ji bo "sazkirina" piçûk çareseriyek baş e, ku bandorê li performansa dîskê dike. Ew ê bihêle ku hûn baş bixebitin heya ku databas bi lez û bez veguhezîne hardware.
TimescaleDB veavakirina hêsan e, destkeftiyên performansê dide, bi Zabbix re baş dixebite û li ser PostgreSQL avantajên xwe hene.
Heke hûn PostgreSQL bikar tînin û plan nakin ku wê biguhezînin, ez pêşniyar dikim PostgreSQL bi dirêjkirina TimescaleDB re bi Zabbix re bikar bînin. Ev çareserî heya "saziyek navîn" bi bandor dixebite.
Dema ku em dibêjin "performansa bilind" mebesta me ye . Hûn ê demek dirêj li bendê nemînin ku hûn li ser teknolojiyê û pratîkên ku karûbaran dihêlin ku bi mîlyonan bikarhêneran re xizmetê bikin fêr bibin. Rêzkirin ji bo 7 û 8ê Mijdarê me berê berhev kiriye, lê li vir bêtir dikare were pêşniyar kirin.
Aboneya me bibin и , ku tê de em taybetmendiyên konferansa pêşeroj eşkere dikin, û fêr dibin ka meriv çawa herî zêde jê sûd werdigire.
Source: www.habr.com