好吧，为了开始，我是Oracle DB的全新。 微软产品（boo）和Ubuntu linux的许多经验，但是RHEL和Oracle对我来说是非常新的。
环境… Oracle DB 10g标准版v10.2.0.1.0 – 64位，RedHat Enterprise Linux 5.数据库总大小小于8GB。
问题…每天晚上20 点15分 ，服务器的内存下降到零。 我们以前在服务器上有4GB的内存，所以我们的内存统计总是显示〜100MB可用。 直到最近我们才知道除了内存不足之外还有一个问题。 有一天，我们升级了4GB – > 12GB，并看到一些合法的内存可用。 详情请参考附件。
每日内存使用情况 ：该图显示了24小时的时间段，其中从20.15开始显示了白天的内存使用情况（当用户严重冲击服务器时）。 20.15时，所有的用户离开大楼超过2小时后，内存几乎消失，直到服务器重新启动。
每周内存使用情况 ：此图显示升级内存之前的时间以及升级后的三天。 正如你所看到的，在升级之前基本上没有任何物理内存可用，尽pipe内存被用于caching。 升级之后，我们拥有大量的可用内存和caching – 直到20.15，两者都消失。 每次你看到RAM的跳跃量是在重新启动之后立即进行的。 这个可用的RAM可以持续到20.15。
build立这个服务器的供应商对我们来说绝对没有答案。 事实上，他们告诉我们的是绝对荒谬的，使他们显得无能为力。 他们真的不知道什么，这是显而易见的。 所以我们不可能以这种方式得到答案。 大约一个星期前，我们确信服务器不需要更多的内存，并拥有足够的资源。 它也build立了只有两个物理硬盘（2x146GB 15K RPM），我相信设置为RAID1。
我已经检查了（我相信是）所有的调度程序作业，所有的cron作业，以及我可能find的任何其他定时任务/作业。 我已经断开所有闲置的数据库会话无济于事。 我能find的唯一证据就是罪魁祸首是一个Oracle进程，在20.15之后开始占用CPU的50％左右。 白天有几十个（〜40+）Oracle进程，每个进程显示大约2.2GB的虚拟机使用情况 – 在重新启动之后，以及在20.15“事件”之后，这个过程都立即生效。
我无法抗拒。 而我们的软件/硬件供应商是毫无价值的。
任何build议或帮助将不胜感激！ 谢谢！ 〜拉兹·彼得森
首先，甲骨文员工所说的不是一个“可笑的答案”，那就是甲骨文当时正在执行一些内务pipe理任务，可能是通过cron 。 如果时间不方便，您应该问问如何重新安排时间。
你的内存使用情况看起来不错。 当Linux将数据加载到内存中时，它将一直存在，直到需要其他空间（这是free(1)报告的caching/缓冲区）为止。 这背后的逻辑是删除它是明确的工作; 如果数据再次需要，它是免费的。 那里有2GiB真的免费。 除非这个变化（即内存泄漏的地方），我现在不担心。
带两个Statspack快照，20:00和00:00。 在它们之间生成一个报告。 它会告诉你是什么原因导致高负荷。 尤其是查找“前5个定时事件”，然后查询SQL引起的问题。 另外看看甲骨文的内存“咨询”的额外build议。
根据目前可用的细节，我认为内存消耗本身不是问题。 一些负载消耗事务从20:15开始，这导致从交换中获取缓冲的数据。
在http://www.redhat.com/f/pdf/rhel/Oracle-10-g-recommendations-v1_2.pdf中查看红帽对Oracle的build议。 特别是将“swappiness”设置为0（或closures）并使用巨大页面。