我们在嵌入式（Arm）linux产品上获得了一夜之间的锁定，但是无法将其固定下来。通电需要12-16小时才能显现问题。我已经安装了sysstat，所以我可以运行sar日志记录，而且我有一堆数据，但是我在解释结果时遇到了麻烦。
目标只有512Mb RAM（我们有其他型号有1Gb，但他们经常看到这个问题），并且没有磁盘交换文件以避免佩戴eMMC。
某种寻呼/虚拟内存事件正在引发问题。在sar日志中，pgpin / s，pgnscand / s和pgsteal / s以及majflt / s都会在滚雪球之前稳步上升到疯狂的水平。这使CPU相应地处于高水平（双核心臂芯片上为30-60）。与此同时，frmpg / s值非常消极，而campg / s则非常积极。结果是系统试图一次性分配大量缓存页面。我不明白为什么会这样。
目标然后基本上锁定，直到它重新启动或有人杀死主GUI进程或它崩溃并重新启动（我们有一个单片GUI应用程序，一直运行，通常对产品进行所有认真的工作）。网络关闭，telnet永远阻塞，/ proc文件系统查询和依赖它的东西就像top一样。本测试中主应用程序的内存分配配置文件主要是从文件读取数据并使用OpenGL ES 2.0将其作为LRU中视频内存（与主RAM共享）中的纹理进行缓存。大多数情况下它将访问单个文件（它们的大小约为50Mb），但我想它可以通过不得不突然使用新文件并尝试一次性缓存所有50Mb来触发。我还没有完成测试（更多的登录）来将这个事件与这些系统效果联系起来。
奇怪的是，实际的免费和缓存RAM级别并没有显示明显的内存不足（我已经看到oom-killer在使用＆gt; 100Mb free和40Mb缓存RAM杀死主应用程序时）。主要应用程序的内存使用情况看起来相当不错，VmRSS值看起来非常稳定。 Valgrind没有发现在操作过程中会发生任何渐进性泄漏。
这种行为看起来像一个系统疯狂地交换到磁盘并使一切运行速度变慢，但我不知道这是否是免费的＆lt; - ＆gt;缓存RAM交换系统中的已知效果。
我的问题表面上与问题相似：linux high kernel cpu usage on memory initialization但问题似乎是由磁盘交换文件管理驱动的。但是，对于我的问题，脏页面刷新似乎是合理的。
我还没有尝试过使用/ proc / sys / vm下的各种vm文件。 vfs_cache_pressure和可能的swappiness看起来很适合进行一些调整，但是我想在这里尝试一些有价值的洞察力。 vfs_cache_pressure似乎定义不明确，将其设置为200而不是10000之间的差异将是定量的。
另一个有趣的事实是，这是一个进步的问题。第一次效果可能需要12个小时。如果主应用程序被杀死并重新启动，那么似乎每隔3小时就会发生这种情况。但是，完整的缓存清除可能会将其撤回。
这是一个带有两个文件的日志数据的链接，sar1.log，它是sar -A的完整输出，overview.log，free / cache mem的提取，CPU加载，MainGuiApp内存统计，以及-B和-R sar在午夜和凌晨3:40之间的有趣时段输出：
https://drive.google.com/folderview?id=0B615EGF3fosPZ2kwUDlURk1XNFE&usp=sharing
总而言之，我最好的计划是什么？调整vm往往更频繁地回收页面，使其不那么突发？根据日志数据，我对发生的事情的假设是否有效？是否有更聪明的方法来处理这种内存使用模型？
感谢您的帮助。
2013年6月5日更新： 我已经尝试过蛮力方法，并且每小时都会写一个回显3到drop_caches的脚本。这似乎是维持系统的稳定状态，并且sar -B统计数据保持在平坦部分，主要故障很少，0.0 pgscand / s。但是，我不明白为什么保持缓存RAM非常低可以缓解内核尝试将Universe添加到缓存RAM的问题。