简介
本文档介绍当CPU消耗量增加到100-150%时所需的网络服务协调器(NSO)数据收集。
先决条件
要求
本文档没有任何特定的要求。
使用的组件
本文档不限于特定的软件和硬件版本。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。
背景信息
当从NB处理多个事务时，NSO CPU消耗增加到正常消耗的约100-150%。发生这种情况时，您需要找出导致CPU性能下降的原因。同时，NSO不会正确响应RESTCONF（如果使用）查询。
本文重点介绍在问题期间需要收集的所有重要数据，以便正确解决问题并提出一些补救步骤。
要收集的数据
从Linux的角度来看：
- lscpu
- 顶部
- free -h
- vmstat
- cat /proc/meminfo
- pstree -c
- ps auxw | 排序
注意：您可以定期捕获这些详细信息（除了“lscpu”），以便了解当请求来自NB时系统的行为。
从NSO的角度来看：
- 每隔“n”秒捕获一次下一信息（它可作为脚本运行）：
seq=0
当ncs —status >& /dev/null；执行
ncs —debug-dump ncs.dd.$(seq++);
ncs — 状态> ncs.stat.$(seq++);
睡眠30;#Configured according 到用户
done
接下来是一些补救步骤，也可以执行这些步骤来缓解此问题：
- 按如下方式限制会话数量（目前，您没有此设置）：
<session-limits>
<session-limit>
<context>rest</context>
<max-sessions>100</max-sessions>
</session-limit>
</session-limits>
b.启用审核规则，以确定NSO流程是否被某事破坏，如果是，则将其记录在audit.log中：
sudo auditctl -a exit，always -F arch=b64 -S kill -k audit_kill
要进行故障排除和分析，您需要以前的详细信息以及audit.log、devel.log（最好设置为level=trace）、ncs-java-vm.log和NB日志。
其他信息
问：NSO实际上如何处理来自NB应用的RESTCONF请求？
A.当北向应用发送RESTCONF请求时，根据NSO将其视为唯一事务。这意味着NSO可以锁定整个CDB，并且在当前事务完成之前不允许任何其他事务。如果执行此操作，将保留NSO的事务性质，并确保在出现任何问题时可以执行回滚。
NSO commit-queue可以在每个后续事务请求完成时对其进行处理，并且可以在事务开始/完成时在devel.log中跟踪事务锁定。在使用情况下，如果执行大量查询，这会在NSO中引入大量开销；而事务在提交队列中的时间比预期长。如果RESTCONF请求被分组，吞吐量将增加，因为事务开销会减少。此外，NSO可以在单个交易中同时执行尽可能多的操作。例如，如果事务包含2个设备配置更改，则NSO可以锁定CDB，同时访问和编辑两个设备，然后完成事务。这与每个包含1个设备且两者都更改的2个事务不同；因为NSO可以锁定第一个事务的CDB，编辑第一个设备，完成事务，然后对第二个设备执行相同的步骤。
相关信息
反馈