device defaults or phone load field on phone device) As this environment has two nodes affected but based on the 8.5 and 8.6 OVAs from CCO.Įither DRF needs to be run at a lower priority process or there needs to be a *new* purge tool that cleans out firmware from the tftp directory that is not listed within the dependancy records (ie. My opinion is, the bug CSCtu18692 is not actually just an issue with the 8.5 OVA. To date, only the PUB and SUB3 experience the issue during the DRF schedule, and only sometimes during a 6 day schedule (CPUPegging is raised one or twice a fortnight/month). SUB3 was built on the 8.6 OVA as we had numerous bugs with 8.5 and patched to 8.6 before SUB3 was able to be built.Īfter each upgrade to a 8.6 ES, we see the TAR archive grow on the ftp server, mainly being a large TFTP tar archive. PUB, SUB1, and SUB2 were built on UCS using the 8.5 OVA, but later updated with 8GB RAM and 2 vCPU. I have an interesting issue here as well with only two nodes in the cluster (of 4) that experience this issue. Any ideas or insight would be appreciated. If anyone has encounted this issue please let me know how it was resolved. I have restarted DRF services and will observe to see if I get the alert again. Memory_Info: %Mem Used= 59, %VM Used= 39. Configured high threshold is 90 % CiscoDRFLocal (52 percent) uses most of the CPU.įor processor instance _Total: %CPU= 99, %User= 57, %System= 8, %Nice= 31, %Idle= 0, %IOWait= 0, %softirq= 2, %irq= 0.įor processor instance 0: %CPU= 99, %User= 57, %System= 8, %Nice= 31, %Idle= 0, %IOWait= 0, %softirq= 2, %irq= 0. Processor load over configured threshold for configured duration of time. We have been getting the following alert daily,
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |