Jeg håper optimalisering av ipdevpoll står på lista over oppgaver.
Vi kjører i dag 'ipdevpoll -m', altså 8 parallelle jobber som alle har 10 forbindelser åpne mot databasen. navcron 36782 1 36781 36781 0 S - 19:16.14 python /usr/local/nav/bin/ipdevpolld -m (python2.7) navcron 36783 36782 36781 36781 0 S - 10099:09.26 python /usr/local/nav/bin/ipdevpolld -J 5minstats -f -s -P --threadpoolsize=10 (python2.7) navcron 36784 36782 36781 36781 0 S - 9812:19.26 python /usr/local/nav/bin/ipdevpolld -J 1minstats -f -s -P --threadpoolsize=10 (python2.7) navcron 36785 36782 36781 36781 0 S - 8824:16.25 python /usr/local/nav/bin/ipdevpolld -J topo -f -s -P --threadpoolsize=10 (python2.7) navcron 36786 36782 36781 36781 0 I - 782:36.65 python /usr/local/nav/bin/ipdevpolld -J ip2mac -f -s -P --threadpoolsize=10 (python2.7) navcron 36787 36782 36781 36781 0 S - 1086:00.12 python /usr/local/nav/bin/ipdevpolld -J inventory -f -s -P --threadpoolsize=10 (python2.7) navcron 36788 36782 36781 36781 0 R - 9951:01.96 python /usr/local/nav/bin/ipdevpolld -J dns -f -s -P --threadpoolsize=10 (python2.7) navcron 36789 36782 36781 36781 0 S - 2040:33.93 python /usr/local/nav/bin/ipdevpolld -J snmpcheck -f -s -P --threadpoolsize=10 (python2.7) navcron 36790 36782 36781 36781 0 R - 10437:55.65 python /usr/local/nav/bin/ipdevpolld -J statuscheck -f -s -P --threadpoolsize=10 (python2.7)
I fjor på denne tida hadde jeg et problem med at enkeltspørringer mot bokser tok for lang tid (mer enn ett minutt). Dette løste vi ved å justere ned max_concurrent_jobs til 20 siden et (mye) større tall gjorde at enkeltjobbene blei stående å henge på manglende forbindelse mot databasen.
Det jeg så starten på i da, men som er blitt meir og meir uttalt i løpet av året er at spesielt 1minstats ikke greier å snurre raskt nok. Grep(1) i loggen viser at vi i løpet av ett minutt greier å trøkke gjennom mellom 170-200 jobber. Når vi har 645 (GW,SW,GSW) sier det seg selv at dette ikke funker. Vi får hullete grafer.
Hva kan gjøres? Jeg tror ikke utfordringa ligger i CPU/minne, men i selve implementasjonen.
Dersom løsninga er å øke antall oppkoplinger mot databasen må man samtidig gjøre det mulig å tune dette per jobb. De mindre jobbene som f.eks. topo, dns, ip2mac trenger strengt tatt ikke å kjøre som separate jobber og i allefall ikke å ta opp masse ressurser mot databasen.
--Ingeborg