Exchange Queue Velocity

Maradva egy kicsit az elozo bejegyzésem témájánál a Transport-nál, a mai bejegyzésem egy új Queue attribútumról szól, a Velocity értékrol. Ha egy Exchange Server 2013-as kiszolgálón a get-queue parancs segítségével szeretnénk a queue tartalmát megnézni, akkor feltunhet egy érdekes új érték: Velocity.

Ennek mibenlétét fejtjük meg a mai bejegyzésben.

Mikor van tele a queue?

Másként, kicsit hosszabban is feltehetném az elozo kérdést. Mi az üzemszeru muködés egy Transport szerver esetén?

• Ha a queue-ban levo elemek száma (MessageCount) mindig 0?
• Ha a MessageCount értéke kevesebb mint 10, 100, 500, 1000?

Biztosan sokan monitorozzák üzemszeruen a levelezorendszerüket. Mi is azt tesszük az adatközpontjainkban levo szerverekkel. És innen (is) a tapasztalat, illetve a gondolkodás eredménye: a queue-ban álló levelek száma (MessageCount) akár pillanatnyi, akár átlagolt érték, nem mond el valójában semmi érdekeset számunkra a szerver aktuális állapotát illetoen. Sem a csökkeno, sem a növekvo MessageCount érték nem hordoz elég információt ahhoz, hogy eldöntsük, a szerver valójában jól végzi-e a dolgát, vagy sem.

Nézzünk néhány példát,:

• Azt látjuk, hogy a MessageCount értéke 0. – azonban a szerverhez beérkezo, kézbesítendo levelek száma is nulla! Joggal hihetnénk, hogy a szerver egészséges, de nem tudjuk meghatározni, lehet, hogy ha 1 levelet is kapna, nem tudná kézbesíteni, de az is lehet, hogy igen. Teljes a tanácstalanság, pedig joggal hihetnénk, hogy minden rendben.
• Azt látjuk, hogy a MessageCount értéke 1000. – azonban a szerver épp most kapott 5000 levelet, amibol 4000-t az elmúlt 2 percben kézbesített és a következo 1000-t a következo 30mp-ben kézbesíteni fogja. Baj van? Nincs, hiszen minden üzemszeru.
• Azt látjuk, hogy a MessageCount értéke konstans 100 körül van. – igen, jó pár célkiszolgáló az Interneten épp elérhetetlen. Baj van? Nem.

Talán látható a fenti példákból, hogy a MessageCount összességében nem árulja el számunkra azt, hogy mekkora a baj. Legalább a Status oszlopot is hozzá kell olvasni, ami az adott Queue-hoz tartozóan leírja, hogy mi az állapota.

Csökken, vagy no a queue?

A Velocity (sebesség) értéket annak meghatározására találtuk ki a queue figyeléshez, hogy egyszeruen megállapítható legyen, hogy egy adott queue épül, vagy csökken. A csökkeno tendenciát mutató queue, legyen is bármekkora a mérete, nem jelent komoly veszélyt. Egy épülo (növekvo) queue viszont annál inkább.

De mikor épül és mikor csökken egy queue? Akkor ha több vagy éppen kevesebb elem van benne mint korábban? Nem szükségszeruen. Egy adat még hiányzik és az elozo bekezdésben is erre próbáltam kihegyezni a példákat. A queue méretéhez érdemes ismernünk azt, hogy egyébként mennyi volt a queue-ba bemeno és az abból kimeno elemek száma:

• Ha bement 100 levél, kiment 90 levél és bent maradt 10 levél, akkor a queue épül (kevesebb levél ment ki, mint amennyi bement)
• Ha bement 100 levél, kiment 110 levél és bent maradt 23 levél, akkor a queue csökken (több ment ki, mint amennyi be)

Elég egyszeru számtan ez. Ha több levél megy ki, mint amennyi be, akkor csökken a Queue, ha fordítva, akkor viszont épül, vagyis no a queue.

A Velocity érték ezt a sebességkülönbséget fejezi ki. Méghozzá úgy, hogy két értéket tart számon a szerver minden queue-hoz tartozóan:

• IncomingRate – az elmúlt 1 percben beérkezett levelek száma a következo képlet alapján számítva: (i1+i2+i3+i4+i5+i6)/6, ahol in = 5 másodperc alatt beérkezett levelek átlaga.
• OutgoingRate – az elmúlt 1 percben kiküldött levelek száma a következo képlet alapján számítva: (o1+o2+o3+o4+o5+o6)/6, ahol on = 5 másodperc alatt kiküldött levelek átlaga.

Elméleti példa:

• IncomingRate – egy levél érkezett be egy 5mp-s idoablakban: (1/5)/6= 0.016666666666667
• OutgoingRate – két levél ment ki egy 5mp-s idoablakban: (2/5)/6=0.0666666666666667
• Velocity = ((2/5)/6) – ((1/5)/6) = 0.05

 

A Velocity = OutgoingRate – IncomingRate. A Velocity érték a következot fejezi ki számunkra:

• Ha az értéke nagyobb 0-nál, akkor a queue-ból gyorsabban mennek ki a levelek, mint ahogy beérkeznek.
• Ha az értéke 0, akkor két lehetoség van. Vagy inactive a queue, vagy pontosan olyan ütemben jönnek be a levelek, amilyen ütemben kimennek.
• Ha az értéke kisebb 0-nál, akkor lassabban mennek ki a levelek, mint ahogy beérkeznek.

Fontos azt kiemelni, hogy ha negatív értéket látunk a Velocity esetében és az nagyon közel van a nullához, az nem jelez komoly queue problémát.

Például, egy –0.02-es érték elég alacsonynak tekintheto!

Gyakorlati példa (épülo queue):

A Get-queue parancs segítségével lekérdezhetjük az IncomingRate és az OutgoingRate értékét. Láthatóan egy épülo Queue van, mert a Velocity értéke –0.01, ami 0.02-0.03 végeredménye.

Gyakorlati példa (csökkeno queue):

Zárszó

Elég törpe értékeket sikerült itt bemutatnom, de éles környezetrol nem készíthetek a blogba képernyofelvételeket. A lényeg, talán így is értheto ami pedig nem más, hogy van egy új értékünk a Velocity amire érdemes odafigyelni és nem átsiklani felette. Többet árul el, mint önmagában a MessageCount érték.