Op deze pagina
Kernpunten
- Benoem de gemeten laagIP-bytes, Ethernetframes en lijnbezetting leveren verschillende Gbit/s-cijfers op.
- Bekijk afzonderlijke queues en coresEen laag CPU-gemiddelde kan een overbelast deel van het ontvangstpad verbergen.
- Kwalificeer het echte beleidDoorsturen, droppen, status bijhouden en inspecteren zijn verschillende werklasten.
Kleine pakketten kunnen een andere grens blootleggen
Een hoge pakketsnelheid vraagt veel ontvangst-, analyse-, zoek- en doorstuurbeslissingen per seconde. Afhankelijk van de implementatie draait een deel in hardware en gebruikt een ander deel CPU, geheugenbandbreedte of gedeelde status. Kleine pakketten kunnen een verwerkingsgrens bereiken voordat de nominale lijnbandbreedte vol is.
Het symptoom alleen identificeert de beperkende component niet. Verlies kan ontstaan bij de upstreamoverdracht, NIC-queue, worker, statustoewijzing of uitgang. Vind de eerste falende stap voordat u hardware of filterframework vervangt.
Koppel Mpps aan een duidelijke framegrootte
Voor nominale Ethernetlijnbezetting in één richting geldt: Gbit/s = Mpps × (framebytes + 20) × 8 / 1000. Het frame bevat hier FCS; de extra 20 bytes staan voor preambule en interframetijd. Dit is een rekenmodel, geen behaalde filterbenchmark.
Een capture kan FCS weglaten en een IP-teller bevat geen Ethernetoverhead. Schrijf op wat de grafiek telt voordat u vergelijkt. De voorbeelden bevatten geen aparte PHY/FEC-berekening en garanderen niet dat een echte interface het theoretische maximum vasthoudt.
| Frame inclusief FCS | Bij 10 Mpps | Nominaal maximum op 100 Gbit/s |
|---|---|---|
| 64 bytes | 6,72 Gbit/s | 148,81 Mpps |
| 128 bytes | 11,84 Gbit/s | 84,46 Mpps |
| 512 bytes | 42,56 Gbit/s | 23,50 Mpps |
| 1518 bytes | 123,04 Gbit/s | 8,13 Mpps |
Verminder werk vóór de uitgeputte stap
Is upstreambandbreedte uitgeput, verplaats de reductie dan upstream of verander het afleverontwerp. Is lokale verwerking de gemeten beperking, onderzoek ondersteunde vroege filtering, queues, workerplaatsing en regelkosten. Een late drop maakt eerder verricht werk niet ongedaan.
XDP, een DPDK-applicatie, VPP en een apparaat-ACL zijn verschillende uitvoeromgevingen, geen universele prestatievolgorde. Vergelijk het benodigde beleid op de echte hardware. Leg parserondersteuning, statusgedrag, updates en gedrag bij ontbrekende functies of gestopte processen vast.
Meet verdeling, niet alleen totalen
Receive-side scaling verdeelt pakketten meestal met een hash van headervelden over queues. Veel flows kunnen goed verdelen, terwijl een andere mix werk concentreert. Eén drukke ontvangstqueue of worker kan pakketten verliezen terwijl het CPU-gemiddelde laag blijft. Controleer echte toewijzing en queuetellers; meer cores betekenen niet automatisch gelijke verdeling.
Neem NUMA-localiteit, NIC-plaatsing, PCIe-capaciteit, workeraffiniteit en zendqueues op in het dossier. Hun invloed hangt af van platform en implementatie. Kopieer geen tuningrecept zonder het huidige pad te meten en een terugdraaibare configuratie te bewaren.
Voorbeeld: 100 Mpps vraagt om een precieze omschrijving
Bij Ethernetframes van 64 bytes vertegenwoordigt 100 Mpps nominaal 67,2 Gbit/s lijnbezetting. Bij 1518 bytes vertegenwoordigt dezelfde pakketsnelheid 1230,4 Gbit/s. Een claim van 100 Mpps zonder framegrootte, richting en werklast is dus onvolledig.
Deel bij een hypothetische opstelling met twee nodes de aangeboden last niet simpelweg door twee. Test verkeerssturing en ongelijke verdeling, daarna de storing die de dienst moet verdragen. Kan al het beschermde verkeer naar één overblijvende node gaan, dan hebben die node en zijn ontvangstverbindingen een afzonderlijk gekwalificeerd bereik nodig.
Maak een reproduceerbaar capaciteitsdossier
Beschrijf het systeem
Noteer NIC, firmware, driver, CPU, geheugen, NUMA-indeling, softwareversies, poorten en actieve functies. Vermeld of resultaten één richting of een totaal betreffen.
Beschrijf het verkeer
Noteer framegroottes, protocollen, aantal flows, statusaanmaak, verhouding legitiem en ongewenst verkeer en duur. Gebruik een geautoriseerde geïsoleerde opstelling met gesynchroniseerde metingen.
Meet nuttige forwarding
Verzamel aangeboden, gedropte en doorgestuurde pakketten op benoemde punten. Meet ook geslaagde legitieme transacties, latentie en verlies. Snel alleen droppen is geen resultaat voor stateful forwarding.
Vind en controleer de operationele marge
Test de bedoelde belasting, gecontroleerde veranderingen en gespecificeerde uitval. Houd het productiebereik onder de aangetoonde grens en documenteer de gekozen marge.
Lees grafieken in hun beheercontext
- Tel ontvangst en verzending niet op om dat als ingangscapaciteit in één richting te presenteren.
- Leid de drukste seconde niet af uit een vijfminutengemiddelde of factureringspercentiel.
- Neem niet aan dat flowsampling elke korte piek ziet of dezelfde teller als de NIC oplevert.
- Noem gedropte pakketten geen verwerkt schoon verkeer zonder de verwerking te benoemen.
- Een geslaagde test met grote frames bewijst geen capaciteit met minimale frames.
Maak van een benchmark een bruikbare capaciteitskeuze
Houd theoretische lijnlimieten, gemeten datapadcapaciteit en applicatieresultaten apart. Laat ontbrekende metingen onbekend. Een calculator controleert rekenen en verbindingsgrenzen; alleen een relevante test kwalificeert het filtersysteem.
Vragen en antwoorden
Is een hoog Gbit/s-cijfer voldoende om een filter te dimensioneren?
Nee. Pakketgrootte, pakketsnelheid, beleid, statusaanmaak en verdeling bepalen de last. Meet de configuratie die werkelijk wordt gebruikt.
Betekent lage totale CPU-belasting dat de server ruimte over heeft?
Niet noodzakelijk. Een queue, worker, geheugenpad of externe verbinding kan beperken terwijl andere cores niets doen.
Mag de theoretische Ethernetrate als filtercapaciteit worden verkocht?
Nee. Het is een lijnbezettingslimiet onder vastgelegde aannames. Een productclaim vereist metingen voor het relevante verkeer en de actieve functies.
