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
