Optimització del rendiment

lippycat inclou valors per defecte raonables, però els desplegaments en producció sovint es beneficien d’ajustos. Aquest capítol presenta les opcions de rendiment disponibles: comença pels perfils de rendiment TCP (la millora més senzilla) i continua amb l’acceleració GPU i els algorismes de cerca de patrons. Cada apartat es basa en els conceptes de captura i distribució de les parts II i III.

Perfils de rendiment TCP

Els perfils de rendiment TCP són conjunts de paràmetres preajustats que configuren entre 17 i 19 opcions internes amb un sol indicador. Controlen el comportament del reassemblatge TCP, l’assignació de memòria, les estratègies de memòria intermèdia i els fils d’E/S. Si no teniu requisits específics, triar el perfil adequat és l’optimització individual amb més impacte.

Triar un perfil

Establiu el perfil amb --tcp-performance-mode en les ordres que fan reassemblatge local de SIP sobre TCP. sniff voip utilitza balanced, throughput, latency i memory; tap voip utilitza minimal, balanced, high_performance i low_latency.

sudo lc sniff voip -i eth0 --tcp-performance-mode balanced

Per a tap voip, els quatre perfils corresponen a situacions d’ús diferents:

Mínim — Per a dispositius encastats (Raspberry Pi), entorns de prova o desplegaments amb menys de 10 trucades simultànies. Utilitza memòries intermèdies de mida fixa i un sol fil d’E/S per mantenir-se per sota de 25 MB de RAM. La contrapressió està activada per evitar l’esgotament de la memòria.

Equilibrat (per defecte) — L’opció adequada per a la majoria de desplegaments en producció amb entre 10 i 100 trucades simultànies i entre 2 i 8 GB de RAM disponible. La mida adaptativa de les memòries intermèdies i l’ajust automàtic permeten adaptar-se als patrons de trànsit durant l’execució.

Alt rendiment — Desplegaments en centres de dades amb entre 100 i 1.000 trucades simultànies o més. Les memòries intermèdies circulars, el doble de fils d’E/S i la contrapressió desactivada maximitzen el cabal a costa d’un consum de memòria superior (fins a 500 MB). Els lots més grans augmenten lleugerament la latència per paquet.

Baixa latència — Anàlisi en temps real, detecció de frau o supervisió de la qualitat de les trucades on importa processar en menys d’un segon. Una mida de lot d’1 significa que cada paquet es processa immediatament. L’ajust automàtic està desactivat per mantenir un comportament previsible.

Sobreescriure paràmetres individuals

Els perfils estableixen una configuració de base. Podeu sobreescriure qualsevol paràmetre individual:

Utilitzeu el perfil equilibrat amb més memòries intermèdies per a una xarxa amb ràfegues de trànsit:

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode balanced \
  --max-tcp-buffers 10000

Utilitzeu el perfil d’alt rendiment amb la contrapressió reactivada per seguretat:

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode throughput \
  --enable-backpressure

Utilitzeu el perfil de memòria amb un temps d’espera del flux més llarg per a diàlegs SIP lents:

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode memory \
  --tcp-stream-timeout 300s

Els mateixos paràmetres funcionen en fitxers de configuració YAML:

voip:
  tcp_performance_mode: "balanced"
  max_tcp_buffers: 10000

Triar un perfil per a nodes distribuïts

En un desplegament distribuït (capítol 6), els nodes Hunter i els processadors tenen necessitats d’ajust diferents:

• Els nodes Hunter utilitzen ajustos del temps d’espera d’inactivitat de SIP TCP i filtres gestionats pel processador, però no ofereixen --tcp-performance-mode.
• Els processadors reben paquets ja reassemblats per gRPC, de manera que el perfil TCP afecta principalment qualsevol captura local que pugui fer el processador (rellevant en mode Tap, capítol 9).
• Els nodes Tap combinen tots dos rols. Adapteu el perfil al volum de trànsit local.

Fragments de reassemblatge TCP en mode Tap

tap voip utilitza un fragment de reassemblatge TCP per defecte. Això conserva el comportament d’un únic reassemblador i també és la configuració de retorn. En sistemes on els perfils mostren que el reassemblador és el coll d’ampolla, les connexions TCP independents es poden repartir entre nuclis:

sudo lc tap voip -i eth0 --tcp-reassembly-shards 4 --insecure

Totes dues direccions i tots els paquets d’una connexió s’encaminen al mateix fragment, de manera que l’ordre per flux no canvia. El límit global de pàgines en memòria intermèdia es divideix entre els fragments en lloc de multiplicar-se, i el límit per connexió no canvia. La telemetria informa de la suma de discontinuïtats de reassemblatge i d’alliberaments per retenció limitada de tots els fragments. Cada fragment afegeix un reassemblador i un conjunt de fluxos; compareu, per tant, paquets/s, CPU, memòria dinàmica, assignacions, discontinuïtats i tots els comptadors de descart de captura i flux amb 1, 2, 4 i 8 fragments i una combinació representativa de fluxos. Ajusteu processor.detection_workers juntament amb el nombre de fragments; els fragments addicionals no ajuden si massa pocs treballadors els alimenten. Torneu a --tcp-reassembly-shards 1 si empitjoren l’ús de recursos o la telemetria d’integritat.

Prioritat de captura SIP i els seus límits

La memòria intermèdia de captura proporciona a la senyalització SIP reconeguda una via prioritària amb mida independent. En mode automàtic (sip_buffer_size: 0 o --sip-buffer-size 0), la capacitat de paquets coincideix amb la de la memòria intermèdia de captura ordinària. Un valor positiu és una sobreescriptura explícita: els valors més grans donen marge per a ràfegues limitades i consumeixen més memòria, mentre que els més petits redueixen la memòria i permeten degradar la prioritat abans. Per a SIP sobre TCP, el reconeixement manté estat: després d’observar una línia inicial SIP creïble, els segments posteriors de capçalera i cos en totes dues direccions de la connexió utilitzen la via prioritària. El classificador de fluxos conserva com a màxim 65.536 entrades, manté com a màxim 1 KiB de possible prefix de línia inicial per direcció, fa caducar les entrades inactives al cap de dos minuts i les elimina amb TCP FIN o RST.

Aquesta protecció només comença després d’un inici SIP recognoscible. Quan la captura s’incorpora a una connexió TCP ja establerta, o mentre una línia inicial encara està dividida entre segments incomplets, aquests paquets utilitzen la via ordinària. Per tant, es poden descartar en sobrecàrrega abans que el flux adquireixi prioritat. Un inici complet recognoscible posterior encara pot donar prioritat a la connexió.

La via prioritària és limitada i no garanteix absència de pèrdues. Quan és plena, un paquet SIP reconegut passa a la via ordinària. Si totes dues vies són plenes, el paquet es rebutja i es compta com a descart SIP de la memòria intermèdia de captura; el desbordament de la via ordinària es compta separadament. Aquests comptadors distingeixen quina via ha perdut el paquet, però per si sols no identifiquen una causa a la xarxa anterior o al nucli. Si augmenten els descarts SIP, reduïu el trànsit ofert amb un filtre BPF, augmenteu la capacitat de servei posterior o investigueu les altres etapes identificades de pèrdua de captura i processament abans d’atribuir una causa arrel.

sip_priority_classified és el nombre inclusiu de paquets reconeguts i encaminats per la via de prioritat SIP. Inclou els paquets acceptats per aquesta via, els comptats per capture_buffer_sip_demotions després de passar a la via ordinària i els comptats per capture_buffer_sip_drops després que totes dues vies d’entrada els rebutgin. Les degradacions indiquen un servei de prioritat deteriorat; només els descarts SIP finals contribueixen als totals de pèrdua de paquets.

Capacitat i retenció del detector

El detector de protocols té per defecte 100.000 contextos de flux actius i 100.000 resultats en memòria cau. Configureu els límits de manera independent:

detector:
  max_flows: 100000
  max_cache_entries: 100000

Quan arriba una clau nova a una estructura plena, el detector expulsa un lot amb el 10% de les entrades més antigues (almenys una) i després admet la clau. Aquesta histèresi evita el cost d’expulsar en cada inserció posterior. Els fluxos expulsats són els de darrera activitat més antiga; les entrades de cau expulsades són les que caduquen abans. La pressió de capacitat és, per tant, un senyal de retenció, no una prova que s’hagin descartat paquets.

Reduir detector.max_flows disminueix la memòria i la durada d’una pausa individual d’expulsió, però conserva l’historial de protocols de menys fluxos. Amb un conjunt de treball superior al límit, augmenta la reclassificació i un flux de llarga durada poc actiu pot perdre l’estat. Un límit més alt millora la retenció i redueix la freqüència d’expulsió a costa de memòria i lots del 10% més grans. detector.max_cache_entries té el mateix compromís entre memòria i reclassificació. Els valors zero o negatius desactiven el límit corresponent i només s’han d’utilitzar amb un altre límit de memòria fiable.

Ajusteu-ho amb trànsit representatiu d’alta cardinalitat i canvieu un sol límit cada vegada. Una bona configuració estabilitza la memòria resident sense pressió recurrent en cada senyal de vida ni empitjorament de la pèrdua de captura.

Criteris d’acceptació

L’evidència per a una versió de producció ha d’incloure proves de rendiment sostingut al límit per a fluxos i cau amb 1.000, 10.000 i 100.000 entrades, i una prova amb treballadors del detector concurrents. Entre esdeveniments de lot, la inserció en règim estable no ha de créixer linealment amb el límit. Amb el valor per defecte de 100.000 entrades, un lot d’expulsió s’ha de completar en 100 ms en cada classe de maquinari de producció compatible. Aquest és el pressupost de latència de la memòria intermèdia de paquets que correspon al temps d’espera de lot per defecte de Hunter/Tap.

Registreu el cabal mitjà, la latència de cua de les insercions i la latència dels lots d’expulsió. El resultat de 100 ms de temps real és evidència de versió vinculada a l’amfitrió, la cadena d’eines, la compilació, el nombre de treballadors i les dades de prova; no és un llindar de CI portable. La CI ha de comprovar, en canvi, l’escalabilitat amb la cardinalitat i el comportament de les assignacions.

Telemetria de capacitat

La telemetria del detector apareix sota HunterStats.detector en cada senyal de vida; Tap utilitza els mateixos camps per a la font local:

Els comptadors són monòtons durant la vida d’un detector i es reinicien quan s’inicia un detector nou o un procés de captura nou. Els senyals de vida són instantànies; no sumeu, doncs, un comptador entre informes successius. Calculeu diferències no negatives per font i tracteu un valor inferior com un reinici. Per a una visió del conjunt de nodes, sumeu els darrers indicadors per font i les diferències dels comptadors per font durant el mateix interval. Tingueu en compte les fonts que s’incorporen o surten de l’agregat i manteniu separats els valors de flux i de cau.

La darrera durada d’expulsió i la darrera mida de lot descriuen l’esdeveniment completat més recent i substitueixen els valors anteriors. No sumeu aquests camps del darrer esdeveniment ni en calculeu taxes. Conserveu mostres externament si són importants la mitjana, el màxim o la latència de cua.

Observeu la tendència de flow_last_eviction_duration_ns mentre els indicadors d’entrades es mantenen a prop del límit. Amb el límit per defecte de 100.000 fluxos, els lots milloren el cabal i el treball total sota bloqueig, però els episodis individuals d’expulsió de fluxos observats han mantingut el bloqueig exclusiu durant 27–44 ms, davant d’uns 7 ms abans de l’agrupació en lots. Reduïu detector.max_flows quan aquesta pausa sigui massa llarga per a la càrrega; tornar a l’expulsió amb recorregut complet del mapa en cada inserció restitueix la regressió de cabal. Correlacioneu la pressió del detector amb l’ocupació de la memòria intermèdia de paquets i els comptadors de descart identificats.

Acceleració GPU

L’acceleració GPU agilitza la cerca de coincidències dels filtres d’aplicació en el costat de captura sobre valors ja extrets pels analitzadors de protocols. No analitza SIP ni extreu Call-IDs; aquestes operacions continuen a la CPU.

Selecció del motor

lippycat comprova els motors disponibles per ordre de prioritat i selecciona el millor:

flowchart LR
    Auto["--gpu-backend auto"] --> CUDA{CUDA\navailable?}
    CUDA -->|Yes| UseCUDA[Use CUDA]
    CUDA -->|No| SIMD["Use CPU SIMD\n(always available)"]

Seleccioneu un motor explícitament o deixeu que el triï la detecció automàtica:

Detecteu automàticament el motor (recomanat):

sudo lc sniff voip -i eth0 --gpu-backend auto

Forceu CUDA:

sudo lc sniff voip -i eth0 --gpu-backend cuda

Forceu CPU SIMD:

sudo lc sniff voip -i eth0 --gpu-backend cpu-simd

Desactiveu completament l’acceleració:

sudo lc sniff voip -i eth0 --gpu-backend disabled

Per a sniff voip, hunt i tap, aquests indicadors GPU només es registren en compilacions CUDA. watch live ofereix els seus propis indicadors GPU en compilacions estàndard.

Requisits dels motors

El motor CPU SIMD utilitza instruccions AVX2 quan estan disponibles i recorre a SSE4.2 en cas contrari. No requereix maquinari ni controladors especials i ofereix bon rendiment en CPU modernes.

El valor opencl continua acceptant-se per compatibilitat de configuració, però el motor OpenCL no està implementat. La detecció automàtica l’omet, i una selecció explícita recorre a la cerca de coincidències per CPU després que falli la inicialització.

Resultats de les proves de rendiment

Proves de rendiment mesurades en un Intel i9-13900HX amb 64 paquets per lot:

Ajust de la mida del lot

La mida del lot controla el compromís entre cabal i latència:

Per a monitoratge en temps real de baixa latència:

--gpu-batch-size 256

Per a un ús general equilibrat en producció:

--gpu-batch-size 1024

Per al cabal màxim en captures de gran volum:

--gpu-batch-size 4096

Els lots més grans amortitzen el cost per lot però afegeixen latència (els paquets esperen fins que el lot s’omple o venç un temps d’espera). Per a la supervisió VoIP on importa la visibilitat en temps real, manteniu-vos entre 256 i 1024. Per a l’anàlisi massiva de PCAP o la captura perifèrica d’alt cabal, utilitzeu entre 2048 i 4096.

Configuració YAML

gpu:
  enabled: true
  backend: "auto"
  device_id: 0
  max_batch_size: 1024
  pinned_memory: true
  stream_count: 4

Algorismes de cerca de patrons

Quan filtreu trànsit amb conjunts grans de noms d’usuari SIP, números de telèfon o altres identificadors, l’elecció de l’algorisme de cerca de patrons té un gran impacte en el rendiment.

Opcions d’algorisme

Establiu l’algorisme amb --pattern-algorithm:

On n és la longitud de l’entrada, m és la longitud total dels patrons i z és el nombre de coincidències.

En mode auto, lippycat passa a Aho-Corasick quan el nombre de patrons arriba a 100. Per sota d’aquest llindar, el recorregut lineal evita el cost de construir l’autòmat.

Rendiment a escala

La diferència esdevé molt marcada quan augmenta el nombre de patrons:

El temps de cerca de coincidències d’Aho-Corasick es manté gairebé constant independentment del nombre de patrons perquè tots es compilen en un autòmat finit que processa cada byte d’entrada exactament una vegada.

Configuració

Utilitzeu la selecció automàtica en la majoria de desplegaments:

sudo lc sniff voip -i eth0 --pattern-algorithm auto

Forceu Aho-Corasick per a llistes grans de filtres:

sudo lc hunt voip --processor central:55555 \
  --pattern-algorithm aho-corasick \
  --pattern-buffer-mb 128

Utilitzeu un recorregut lineal per a uns quants patrons:

sudo lc sniff voip -i eth0 --pattern-algorithm linear

En YAML:

voip:
  pattern_algorithm: "auto"
  pattern_buffer_mb: 64

L’ús de memòria d’Aho-Corasick és modest: 100.000 patrons de 20 caràcters de mitjana consumeixen menys de 100 MB per a l’autòmat complet. Per a càrregues d’intercepció legal amb desenes de milers d’objectius (capítol 17), Aho-Corasick és l’única opció viable.

Filtres BPF

Els filtres BPF (Berkeley Packet Filter) s’executen en l’espai del nucli i descarten paquets no desitjats abans que arribin a lippycat. És la forma més eficient de filtratge perquè els paquets rebutjats mai no travessen el límit entre el nucli i l’espai d’usuari.

Captureu només trànsit SIP:

sudo lc sniff voip -i eth0 -f "port 5060"

Captureu SIP i un interval de ports RTP:

sudo lc hunt voip --processor central:55555 \
  -i eth0 -f "port 5060 or portrange 10000-20000"

Captureu trànsit d’un amfitrió específic:

sudo lc sniff voip -i eth0 -f "host 192.168.1.100 and port 5060"

En desplegaments VoIP, les restriccions explícites de ports SIP i RTP són la manera més segura de reduir la càrrega de l’espai d’usuari sense descartar SIP sobre TCP:

sudo lc hunt voip --processor central:55555 \
  -i eth0 --sip-port 5060 --rtp-port-range 10000-20000

Consulteu l’apèndix C: referència de filtres BPF per a la sintaxi completa dels filtres.

Escalabilitat distribuïda

Els desplegaments distribuïts (capítol 6) introdueixen dimensions d’ajust addicionals: els paràmetres de lot controlen l’eficiència de gRPC, el filtratge VoIP a la perifèria redueix l’amplada de banda i les topologies jeràrquiques reparteixen la càrrega entre nivells.

Paràmetres de lot dels nodes Hunter

Els nodes Hunter agrupen els paquets en lots abans d’enviar-los al processador per gRPC. Ajusteu --batch-size i --batch-timeout segons el compromís entre latència i cabal que necessiteu:

Per a supervisió de baixa latència amb poques trucades:

sudo lc hunt voip --processor central:55555 \
  --batch-size 16 --batch-timeout 50

Per a la configuració equilibrada per defecte en producció:

sudo lc hunt voip --processor central:55555 \
  --batch-size 64 --batch-timeout 100

Per a captura massiva d’alt cabal:

sudo lc hunt voip --processor central:55555 \
  --batch-size 256 --batch-timeout 500

Els lots més grans redueixen el cost de gRPC per paquet, però augmenten el temps màxim que un paquet espera abans de transmetre’s (el temps d’espera del lot, en mil·lisegons).

Filtratge a la perifèria

Una de les millores de rendiment més grans en mode distribuït és el filtratge a la perifèria. Quan els nodes Hunter utilitzen subordres específiques de VoIP i filtratge accelerat per GPU, poden reduir més d’un 90% el volum de trànsit transmès al processador:

Creeu el filtre perifèric:

lc set filter -P central:55555 --tls-ca ca.crt \
  --type sip_user --pattern alicent

Inicieu el node Hunter amb filtratge perifèric i acceleració GPU:

sudo lc hunt voip --processor central:55555 \
  --sip-port 5060 \
  --rtp-port-range 10000-20000

El processador envia el filtre d’usuari SIP alicent al node Hunter. Aquest manté les trucades en memòria intermèdia a la perifèria i només transmet les que coincideixen, de manera que el processador rep una fracció del trànsit brut.

Capacitat del processador

Els processadors supervisen la càrrega interna (profunditat de la cua d’escriptura PCAP, treball pendent cap a l’amunt) i senyalitzen control de flux als nodes Hunter quan estan sobrecarregats:

Si veieu senyals SLOW o PAUSE als registres del processador (capítol 12), el processador s’està convertint en un coll d’ampolla. Opcions:

1. Afegiu més processadors i repartiu-hi els nodes Hunter.
2. Activeu el filtratge perifèric per reduir el volum d’entrada.
3. Utilitzeu el mode jeràrquic: els processadors regionals agreguen dades dels nodes Hunter locals i després les transmeten a un processador central.

Topologies jeràrquiques

Per a desplegaments a gran escala (50 nodes Hunter o més), una jerarquia de dos nivells evita sobrecarregar un únic processador:

50 hunters --> 5 regional processors --> 1 central processor

Cada processador regional gestiona 10 nodes Hunter i aplica anàlisi de protocols abans de transmetre resums cap a l’amunt. Això redueix la càrrega del processador central en un ordre de magnitud. Consulteu el capítol 6 per configurar la topologia.

Ajust específic de l’entorn

Els diferents entorns de desplegament requereixen combinacions diferents de les tècniques anteriors. Aquí teniu configuracions provades per a situacions habituals.

Sistemes encastats (Raspberry Pi, SBC ARM)

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode memory \
  --memory-optimization

Preveieu entre 10 i 50 trucades simultànies. El perfil memory manté unes memòries intermèdies TCP conservadores. Activeu --memory-optimization per recuperar-les de manera agressiva.

Màquines virtuals

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode balanced \
  --max-tcp-buffers 5000

Ajusteu els límits de memòria intermèdia TCP segons la RAM assignada a la màquina virtual.

Servidors físics

sudo lc sniff voip -i eth0 \
  --tcp-performance-mode throughput \
  --max-tcp-buffers 20000

En maquinari dedicat amb 8 GB de RAM o més i una CPU moderna, utilitzeu el perfil throughput. Si teniu una GPU NVIDIA i heu compilat amb -tags cuda, afegiu --gpu-backend auto perquè la selecció CUDA o SIMD triï el millor motor. Per a interfícies de 10GbE o més, distribuïu la captura entre nodes Hunter addicionals.

Kubernetes / contenidors

# Pod resource limits
resources:
  limits:
    memory: "4Gi"
    cpu: "4"
  requests:
    memory: "2Gi"
    cpu: "2"

lc sniff voip -i eth0 \
  --tcp-performance-mode balanced \
  --max-tcp-buffers 5000

Adapteu el perfil TCP al límit de memòria del contenidor: els 100 MB del perfil balanced encaixen còmodament en un contenidor de 2 GB. L’accés directe a la GPU des dels contenidors és possible però complex.

Node Hunter distribuït a la perifèria amb recursos limitats

Per a nodes Hunter desplegats en dispositius perifèrics petits que transmeten a un processador central:

sudo lc hunt voip --processor central:55555 \
  --batch-size 32 --batch-timeout 200 \
  --sip-port 5060 --rtp-port-range 10000-20000 \
  --tls-ca ca.crt

Les restriccions de ports SIP/RTP redueixen la càrrega de captura sense descartar SIP TCP. Els lots petits mantenen l’ús de memòria previsible. Si utilitzeu una compilació CUDA, afegiu --enable-voip-filter --gpu-backend cpu-simd per accelerar la cerca de coincidències perifèrica sense maquinari GPU.

Anàlisi del perfil de memòria

Quan feu ajustos, és útil observar l’ús real de memòria. Activeu pprof per utilitzar l’analitzador de memòria integrat de Go:

sudo lc tap voip -i eth0 --debug-listen 127.0.0.1:6060

En un altre terminal, captureu un perfil de memòria dinàmica:

go tool pprof http://localhost:6060/debug/pprof/heap

L’indicador --debug-listen està disponible a tap, process i hunt, i accepta adreces de bucle local per defecte. Per exposar pprof en una altra adreça, afegiu --debug-allow-non-loopback. Els desplegaments existents poden continuar utilitzant LC_PPROF_ADDR=127.0.0.1:6060 si s’omet l’indicador.

Per a comprovacions ràpides sense pprof:

Observeu l’ús de memòria al llarg del temps:

watch -n 10 'ps -o rss,vsz,comm -p $(pgrep -f "lc (sniff|hunt|process|tap)")'

Si la memòria creix contínuament, comproveu si hi ha:

• Un temps d’espera de flux TCP massa alt (no s’alliberen les memòries intermèdies obsoletes)
• Un nombre de memòries intermèdies massa alt per a la RAM disponible
• Absència de l’indicador --memory-optimization en sistemes amb recursos limitats

Referència ràpida