bonjour tout le monde,
j'ai un script shell qui exécute une requếte snmp et renvoie le resultat dans un fichier
il met 15 min pour terminer son exécution car la requête snmp retourn plus que 400 000 lignes.
 
je voudrai trouver un moyen pour rendre ce temps d'éxécution de l'ordre de secondes
est ce que c'est possible???
 
merci

Passer par un parser externe plus performant.

désolé mai j'ai pas compris

peut être regarder si tu pourrais pas éliminer certaines choses dans tes 400 000 lignes, je veux dire, toutes les informations t'intéressent-elles ?
Est-ce vraiment un problème lié au script ou plutôt au réseau où à la requête snmp elle même ?
Et si possible, peut être mettre ton script ici pour que ceux qui connaissent bien puissent mieux cerner la chose

les lignes sont celles d'une table de routage internet donc oui je dois les avoir toute.
et non le probleme ne vient pas du script mais de l'éxécution de la commande snmp je veux trouver un moyen pour qu'elle retourne toutes ces ligne en un lapse de temps très court

Un parser, c'est en gros l'outil qui va mettre en forme ton fichier (si je raconte pas de bêtises)
Donc soit les lenteurs peuvent venir de la partie qui récupère, soit c'est la partie réseau. As tu fais des tests sur la partie réseau ? Vitesse du lien entre le PC qui exécute le script et le périphérique qui envoie les infos.Pas de problème de connectivité ? si tu te branches en direct live, ça va plus vite ou pas ? si tu sniffe le traffic en temps réel, t'as pas remarqué des "pauses" dans la récup des données ?
Est-ce que le périphérique qui envoi les données est saturé niveau puissance quand la requête est en cours ? (ressource CPU /RAM ?)

je vais essayer de voir merci

Au final, tu as trouver quels étaient les bons oid ?

Sinon pour ta question, pour moi SNMP n'est pas l'outils pour récupérer ces routes... snmp n'est pas conçu pour échanger les routes des tables pour faire du monitoring derrière. Tu as regardé la charge sur le routeur lorsque tu récupères ces routes ? Tu récupères tes routes entièrement tous les combien de temps ?

Pourquoi ne pas peerer en bgp entre ton routeur et ta station de supervision pour récupérer ces routes. En plus les updates se feront automatiquement.

(Ou mais ça m'étonnerait vérifier si ton routeur supporte BMP et regarder comment le gérer côté station de supervision)

+1 c'est vrai, récupérer la config des routes par snmp, c'est pas forcément un bon choix. A moins qu'elles changent vraiment constamment, le snmp à pour "but" d'informer d'un état d'un périphérique a un instant t (par les oid) plutôt que de donner de la configuration.

De ce que je comprends, ce n'est pas la configuration des routes. D'après ses autres topics, bloomingdals crée une station de supervision de routeur BGP. Là il souhaite récupérer les routes apprises via bgp. A priori ses routeurs se tapent la full routing table, 400k routes à récupérer en snmp... Les refresh ne seront pas automatiques, je suppose qu'il faut repoller en entier...  Je serais curieux de savoir ce qu'il y a en face comme routeur...

le taf snmp c'est de récupérer des indicateurs, des remontées d'alarme, éventuellement des modifications de conf, etc... mais pas du monitoring de table de cette dimension.

Je ne comprends pas ton "à moins qu'elle change vraiment constamment: amha, si elle change souvent, c'est encore plus lourd d'utiliser snmp...

 
Je voulais dire que c'était pas fait pour. A la limite si les routes changent méga super souvent, bon admettons...(et c'est comme utiliser un taille haies pour tondre la pelouse, ça pourrait le faire mais c'est pas trop fait pour à la base.)
Je suis donc d'accord avec toi mais mal exprimé ma pensée.

Mais pourquoi "à la limite" ? qu'est ce qui fait qu'un changement de la table fréquent renderait des get snmp intéressant à cette échelle

Au fait, bloomingdals, tu en fais quoi des routes après ?

A la limite = c'est son choix personnel, s'il veut vraiment continuer dans cette "voie".
En fait j'penses que c'est pas forcément évident de savoir s'il souhaite reconsidérer le type de solution déjà mise en place par quelque chose d'autre (même si c'est plus performant), du coup, j'suis plus dans la recherche de garder son système en essayant de trouver des solutions à sa demande originelle : accélérer la récupération
Malgré tout, tu as raison de vouloir revoir "à la base" l'environnement et les moyens techniques utilisés.
J'espère avoir été plus clair héhé
 

J'ajouterais aussi qu'il faudrait savoir la gueule du script en question.
Bash par exemple ce n'est pas fait pour ça. Python pareil.
Perl peut à la rigueur le faire, mais le top restera du C compilé. Ce n'est pas comme s'il n'y avait pas les outils pour faire un truc à peu près potable sous la majorité des *nix  
 
Après j'ai vu passé ça, mais ça ne change rien au fait que pour moi, bash ce n'est pas fait pour.