Cisco Catalyst 9000系列交换机已成为许多企业选择的选择，包括我工作的环境，其中Cisco Catalyst 9300 24-和48端口交换机运行直布罗陀-16.12.3代码已成为访问层的标准需要超过12个港口。
这是大约两年前的，一年左右，我们开始从现场位置接收通知，即在网站上有间歇性的网络中断和性能下降。这是我们如何找到解决方法的解决方法，直到思科提供永久性修复。
我们开始解决问题，并找到了我们以前从未见过的以下Syslog消息：
- ％平台-3-Element_TMPFS_CRICTE：机箱1 R0 / 0：SMAND：1 / RP / 0：TMPFS值超过临界水平50％。
- ％平台-4-Element_Warning：Switch 2 R0 / 0：Smand：1 / RP / 0：使用的存储器值95％超过警告级别90％。
一旦我们发现这些，我们就会在思科技术援助中心（TAC）开设了一个案例，并描述了一些症状：高CPU流程，慢速性能和由交换机崩溃和重新启动的网络中断。Cisco Tac告诉我们，直布罗陀-16.12.3代码中存在一个错误 - TMPFS中的内存泄漏，它将其所有文件保存在虚拟内存中。他们还告诉我们问题没有解决问题。
我们使用Cisco Bug搜索工具来了解更多并发现：“由于TMPFS（RAMDisk）中的内存泄漏，Catalyst 9300可能重新加载。在输出“显示平台软件安装开关活动R0“/ TMP使用的内存不断增加。泄漏正在影响所有堆栈成员。“
我们还发现，此问题启动了直布罗陀16.11.1代码发布，当时我们意识到它，没有确认的修复，但我们确实提出了两个解决方法，帮助让问题不那么严重。
夜间重新加载
我们注意到一些交换机将崩溃并重新启动自己，这会将它们恢复到正常的CPU利用率，因此其中一个管理员有希望利用嵌入的事件管理器（Cisco IOS的一部分）来暂停计划的重新启动其中一个开关。管理员使用此命令写了一个脚本：“活动计时器Cron cron-intnt”其次是时候重新加载交换机，然后发出“行动重新加载”命令。
在一些测试之后，我们发现这使我们允许我们在夜间重新加载交换机，这清空了内存并工作以使CPU使用不受第二天的不堪重力，防止交换机崩溃。根据您的环境，策略和程序，您可能无法夜间重新启动交换机，因为它会在需要网络时导致它们不可用。在我们的情况下，某些建筑物是24x7的人员，因此无法使用此脚本重新加载交换机而不会导致中断。
Splunk Alert.
对于无法允许夜间重新加载的网站，我们发现了一种方法可以在崩溃似乎可能进行碰撞时被警告。
其中一名技术人员在Splunk创建了一个警报，它将查找TMPFS阈值Syslog消息，并将向团队发送电子邮件，以通知我们CPU飙升75％。然后我们只能在必要时重启交换机，有时会远程，但有时物理地进入机器。（这花了很多时间并为网络团队造成了挫折，以及不得不等待交换机及其设备在线回来的最终用户。）
Splunk Monitoring还允许我们记录哪些交换机达到75％的阈值以及发生的频率。
解决
当直布罗陀16.12.4代码发布时，我们安装了它，但它没有解决问题。我们继续与Cisco TAC沟通问题，并继续重新加载交换机，并接收关于TMPFS阈值的Splunk通知作为变通方法。经过几个月的与TAC保持联系，我们被告知直布罗陀16.12.5代码将被释放，我们希望它能解决TMPFS问题。我们将实验室交换机升级到新代码，密切监视它们，发现这是一个巨大的成功。将代码升级到16.12.5解决了内存泄漏。
到目前为止，我们已将超过60％的交换机迁移到16.12.5，并且存在较少的问题和更好的性能。
（找到有关如何升级到直布罗陀16.12.5和16.12.5B的更多信息这里。）