Linux内存使用的FREE命令 改进 添加available项 进一步避免FREE内存不足的误会

在各种QQ群里有大量同学会问,为什么LINUX/UNIX上free内存太少会不会有问题。

为了避免这种不必要的误会,不同的OS版本,采用了不同的策略。

例如最狠的是Solaris SUNOS ,在Solaris 8中将文件系统缓存直接算作free内存:

 

 

而Linux中从大约2014年  , 内核版本kernels 2.6.27+开始引入了MemAvailable ,其解释为:

[oracle@master ~]$ free -h
total used free shared buff/cache available
Mem: 31G 9.1G 422M 5.8G 21G 15G
Swap: 15G 11G 3.8G

available

Estimation of how much memory is available for starting new applications, without swapping. Unlike the data provided by the cache or free fields, this field takes into account page cache and also that not all re-claimable memory slabs will be reclaimed due to items being in use (MemAvailable in /proc/meminfo, available on kernels 3.14, emulated on kernels 2.6.27+, otherwise the same as free)

 

Linux Kernel 的GIT中,有比较明确的概述:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773
/proc/meminfo: provide estimated available memory
Many load balancing and workload placing programs check /proc/meminfo to
estimate how much free memory is available.  They generally do this by
adding up "free" and "cached", which was fine ten years ago, but is
pretty much guaranteed to be wrong today.
It is wrong because Cached includes memory that is not freeable as page
cache, for example shared memory segments, tmpfs, and ramfs, and it does
not include reclaimable slab memory, which can take up a large fraction
of system memory on mostly idle systems with lots of files.
Currently, the amount of memory that is available for a new workload,
without pushing the system into swap, can be estimated from MemFree,
Active(file), Inactive(file), and SReclaimable, as well as the "low"
watermarks from /proc/zoneinfo.
However, this may change in the future, and user space really should not
be expected to know kernel internals to come up with an estimate for the
amount of free memory.
It is more convenient to provide such an estimate in /proc/meminfo.  If
things change in the future, we only have to change it in one place.
Signed-off-by: Rik van Riel <riel@redhat.com>
Reported-by: Erik Mouw <erik.mouw_2@nxp.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat
-rw-r--r--	Documentation/filesystems/proc.txt	9	
-rw-r--r--	fs/proc/meminfo.c	37	
2 files changed, 46 insertions, 0 deletions
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 22d89aa3..8533f5f 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -767,6 +767,7 @@ The "Locked" indicates whether the mapping is locked in memory or not.
MemTotal:     16344972 kB
MemFree:      13634064 kB
+MemAvailable: 14836172 kB
Buffers:          3656 kB
Cached:        1195708 kB
SwapCached:          0 kB
@@ -799,6 +800,14 @@ AnonHugePages:   49152 kB
MemTotal: Total usable ram (i.e. physical ram minus a few reserved
bits and the kernel binary code)
MemFree: The sum of LowFree+HighFree
+MemAvailable: An estimate of how much memory is available for starting new
+              applications, without swapping. Calculated from MemFree,
+              SReclaimable, the size of the file LRU lists, and the low
+              watermarks in each zone.
+              The estimate takes into account that the system needs some
+              page cache to function well, and that not all reclaimable
+              slab will be reclaimable, due to items being in use. The
+              impact of those factors will vary from system to system.
Buffers: Relatively temporary storage for raw disk blocks
shouldn't get tremendously large (20MB or so)
Cached: in-memory cache for files read from the disk (the
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index a77d2b2..24270ec 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -26,7 +26,11 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
unsigned long committed;
struct vmalloc_info vmi;
long cached;
+	long available;
+	unsigned long pagecache;
+	unsigned long wmark_low = 0;
unsigned long pages[NR_LRU_LISTS];
+	struct zone *zone;
int lru;
/*
@@ -47,12 +51,44 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
for (lru = LRU_BASE; lru < NR_LRU_LISTS; lru++) pages[lru] = global_page_state(NR_LRU_BASE + lru); + for_each_zone(zone) + wmark_low += zone->watermark[WMARK_LOW];
+
+	/*
+	 * Estimate the amount of memory available for userspace allocations,
+	 * without causing swapping.
+	 *
+	 * Free memory cannot be taken below the low watermark, before the
+	 * system starts swapping.
+	 */
+	available = i.freeram - wmark_low;
+
+	/*
+	 * Not all the page cache can be freed, otherwise the system will
+	 * start swapping. Assume at least half of the page cache, or the
+	 * low watermark worth of cache, needs to stay.
+	 */
+	pagecache = pages[LRU_ACTIVE_FILE] + pages[LRU_INACTIVE_FILE];
+	pagecache -= min(pagecache / 2, wmark_low);
+	available += pagecache;
+
+	/*
+	 * Part of the reclaimable swap consists of items that are in use,
+	 * and cannot be freed. Cap this estimate at the low watermark.
+	 */
+	available += global_page_state(NR_SLAB_RECLAIMABLE) -
+		     min(global_page_state(NR_SLAB_RECLAIMABLE) / 2, wmark_low);
+
+	if (available < 0)
+		available = 0;
+
/*
* Tagged format, for easy grepping and expansion.
*/
seq_printf(m,
"MemTotal:       %8lu kB\n"
"MemFree:        %8lu kB\n"
+		"MemAvailable:   %8lu kB\n"
"Buffers:        %8lu kB\n"
"Cached:         %8lu kB\n"
"SwapCached:     %8lu kB\n"
@@ -105,6 +141,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
,
K(i.totalram),
K(i.freeram),
+		K(available),
K(i.bufferram),
K(cached),
K(total_swapcache_pages()),

 

 

其中提到的是大量 对内存敏感的程序 是简单的将 /proc/meminfo 接口中的FREE+CACHED 的2者相加,算作可用的内存。而我们国内的同学的大多内存焦虑症,是只将FREE算作可用内存。

按照Linux Kernel Rik van Riel <riel@redhat.com>的口径是,这2种算法都是不合理的。后者是焦虑症,前者没考虑部分cache的内存未必可以被释放重用。 any load balancing and workload placing programs check /proc/meminfo to estimate how much free memory is available. They generally do this by adding up “free” and “cached”, which was fine ten years ago, but is pretty much guaranteed to be wrong today. It is wrong because Cached includes memory that is not freeable as page cache, for example shared memory segments, tmpfs, and ramfs, and it does not include reclaimable slab memory, which can take up a large fraction of system memory on mostly idle systems with lots of files.

因为在2014年,物理内存已经比较大了,更少地使用SWAP了,所以其展望未来,希望有一个接口能提供有效的评估。However, this may change in the future, and user space really should not be expected to know kernel internals to come up with an estimate for the amount of free memory. It is more convenient to provide such an estimate in /proc/meminfo. If things change in the future, we only have to change it in one place.

 

于是添加了 接口MemAvailable, 明确说明其是 评估的可以给新程序用的内存空间大小,考虑了 MemFree、SReclaimable、 the size of the file LRU lists、low watermarks in each zone。

+MemAvailable: An estimate of how much memory is available for starting new
+ applications, without swapping. Calculated from MemFree,
+ SReclaimable, the size of the file LRU lists, and the low
+ watermarks in each zone.
+ The estimate takes into account that the system needs some
+ page cache to function well, and that not all reclaimable
+ slab will be reclaimable, due to items being in use. The
+ impact of those factors will vary from system to system.

其详细算法如上文引用。

 

因为都9102年了,可以让小伙伴不要再看 free memory了, 基本上关注 available memory 就可以了!对领导也耐心解释下,看available更有意义!

 

另有同学问,为什么有free内存的情况下,会用到SWAP空间。  stackexchange上有大量相关的解释,这里引用高赞的回答:

It is normal for Linux systems to use some swap even if there is still RAM free. The Linux kernel will move to swap memory pages that are very seldom used (e.g., the getty instances when you only use X11, and some other inactive daemon).

Swap space usage becomes an issue only when there is not enough RAM available, and the kernel is forced to continuously move memory pages to swap and back to RAM, just to keep applications running. In this case, system monitor applications would show a lot of disk I/O activity.

用一句话说 就是有free memory情况下,用SWAP很正常;很少用到的内存页就会被换出去,交换导致性能不好的情况是 内存真不够了,SWAP一会换出一会换入,造成I/O开销;否则问题不大。

 

 

Red Hat Enterprise Linux 生命周期

Red Hat Enterprise Linux 5、6 和 7

红帽提供的订阅服务涵盖 Red Hat Enterprise Linux 每个主发行版本的全部四个生命周期阶段 — 这四个阶段分别为完全支持阶段、维护支持 1 阶段、维护支持 2 阶段,以及延长生命周期阶段。

  • Red Hat Enterprise Linux 5、6 和 7 都提供 10 年支持(除非在以下的例外章节中有其他说明),并分为完全支持阶段、维护支持 1 阶段、维护支持 2 阶段,以及后续的延长生命阶段。另外,Red Hat Enterprise Linux 5 和 6 的用户还可以购买“延长生命周期支持(Extended Life-cycle Support,简称 ELS)”订阅服务,这可以把有限的订阅服务扩展到维护支持 2 阶段以后。

例外

  • 在 Red Hat Enterprise Linux version 7 的生命周期内,红帽对 Red Hat Enterprise Linux Atomic Host、Red Hat Enterprise Linux for ARM、Red Hat Enterprise Linux for Power LE (POWER9) 和 Red Hat Enterprise Linux for IBM System z (Structure A) 的每个发行版本只提供完全支持阶段的支持,以及一个后续的延长生命阶段(不提供维护支持 1 阶段和维护支持 2 阶段)。

生命周期viii:

Red Hat Enterprise Linux 8

红帽非常了解产品生命周期的规划对于我们的客户、合作伙伴、ISV 以及整个 Red Hat Enterprise Linux 生态系统的重要性。随着 Red Hat Enterprise Linux 8 的推出,红帽把 RHEL 产品的生命周期阶段由 4 个简化为以下 3 个:完全支持阶段、维护阶段,以及延长生命阶段。我们同时还会提供预计发行的时间以及会提供延长支持服务的次版本的信息。

  • Red Hat Enterprise Linux 8 提供 10 年的生命周期,包括完全支持阶段、维护支持阶段以及一个后续的延长生命阶段。另外,用户还可以为 Red Hat Enterprise Linux 8 购买一个名为“延长生命周期支持(Extended Life-cycle Support,简称 ELS)”的附件服务订阅。这个服务订阅为用户在维护支持阶段以后扩展了有限的订阅服务。

生命周期viii:

采用 Red Hat Enterprise Linux 生命周期阶段的目的是减少每个主发行版本 i 之间变化的程度,以便更好预期新的发行版本和内容。 ii

详情

在每个主发行版本的生命周期内,Red Hat Enterprise Linux 的软件更新通过红帽客户门户网站(Red Hat Customer Portal)iii 或其他授权的红帽门户网站,以独立更新(称为勘误公告(errata advisories)的形式提供。勘误公告可根据需要单独发布,也可以将其整合到次发行版本中。勘误公可包含安全修复(红帽安全公告,或 RHSA),程序错误修复(红帽程序错误修复公告,或 RHBA),或功能增强(红帽增强公告,或 RHEA)。所有勘误公告都已在相应的 Red Hat Enterprise Linux 主发行版本中进行了测试。(例如:Red Hat Enterprise Linux 8 RHSA 将会被累计添加到 Red Hat Enterprise Linux 8 的最新发行版本及补丁集中)。 具有有效订阅的用户在 Red Hat Enterprise Linux 的整个生命周期中都可以访问已发布的勘误公告。在 Red Hat Enterprise Linux 的每个主发行版本中,任何勘误公告(包括次要发行本中的勘误)都会被累计添加到 Red Hat Enterprise Linux 的最新发行版本(包括补丁集)。

在主 Red Hat Enterprise Linux 发行版本生命周期中,红帽会以合理的商业投入保证在所有次发行版本及勘误公告中的内核运行时环境都具有二进制兼容性。但是如有必要,红帽会就安全影响级别为“关键(Critical)”的安全问题或者其他严重问题在兼容性方面做例外处理。另外,Red Hat Enterprise Linux 的主发行版本会包含一组在上一个主发行版本中使用的有限向后兼容库,以便简化应用程序的迁移。通常,红帽会在应用这些更改时以尽量减少变化并保持二进制兼容性。在某些情况下,受控软件包复位(re-base)可能会有例外。 二进制兼容性也适用于在某个应用程序容器中使用的 Red Hat Enterprise Linux。 但是,这不适用于 Red Hat Enterprise Linux Atomic Host,或可能在主机之上运行的应用程序容器,因为它们都可能包含 Red Hat Enterprise Linux 最新版本未提供的软件包或软件包版本。 如果需要更详细的信息,请参阅 Red Hat Enterprise Linux 7: Application Compatibility Guide 或 Red Hat Enterprise Linux 8: Application Compatibility Guide

下表列出了订阅服务详情,其中包括在 Red Hat Enterprise Linux 生命周期的各个阶段提供的支持和软件维护:

Red Hat Enterprise Linux 生命周期
描述 完全支持 维护
支持 1
(RHEL 5、6 和 7)12
维护
支持(RHEL 8)13维护
支持 2
(RHEL 5、6 和 7)12
延长生命阶段 7 延长生命周期支持(ELS)附加服务8 延长更新支持(EUS)附加服务8
通过红帽客户门户网站访问之前发布的内容
通过红帽客户门户网站进行自助服务
技术支持 1 无限 无限 无限 有限 9 无限 无限
异步安全勘误(RHSA) 10 11 是 8 是 8
异步程序错误修复勘误 2 11
次发行版本
更新的硬件启用支持3 原生 有限4原生 使用虚拟化 使用虚拟化 使用虚拟化 使用虚拟化
软件增强 5 是 6
更新的安装镜像
  1. 技术支持覆盖的范围取决于您的 Red Hat Enterprise Linux 订阅所包括的服务等级。
  2. 在生成程序错误修复勘误公告(RHBA)期间,红帽可选择提供热修复(Hotfix)作为临时方法处理严重影响客户业务的问题。
  3. 原生硬件启用是通过将硬件驱动程序反向移植(backporting)到 Red Hat Enterprise Linux 的相应版本来实现的。使用虚拟化的硬件启用是通过在较新版本的 Red Hat Enterprise Linux 中运行一个较早版本的 Red Hat Enterprise Linux 作为虚拟客户机实现的。详情请查看以下虚拟化描述。注:硬件认证(包括相关的硬件限制)适用于作为主机使用的 Red Hat Enterprise Linux 版本。
  4. 维护支持 1 阶段中的原生硬件启用(Hardware Enablement)仅限于那些不需要大量软件更改的硬件启用。详情请查看以下维护支持 1 阶段描述。
  5. 软件增强是指修正程序缺陷外的新增加的功能,或在新一代硬件中启用之前存在的功能。
  6. 主发行版本是提供主要软件增强的方式,一些影响不大的软件增强也可能会通过次发行版本提供。
  7. 请查看下述延长生命周期阶段
  8. 延长更新支持(EUS)和延长生命周期支持(ELS)是可选的附加服务(add-on)。请查看下述 EUS 和 ELS
  9. 只适用于现有安装。其他限制请查看以下详细说明。
  10. 有关安全严重性分级的信息,请参考问题严重性分级页。
  11. 红帽对所有提供的勘误拥有自由裁量权。
  12. 适用于 RHEL 主发行版本 5、6 和 7。不适用于 RHEL 8。
  13. RHEL 8 只有一个维护支持阶段,相当于以前版本的维护支持 2 阶段。

Red Hat Enterprise Linux 产品生命周期阶段

完全支持阶段iv:

在完全支持阶段中,会发布级别为关键(Ctitical)和重要(Important)的安全勘误公告(RHSA),以及优先级为“紧急(Urgent)”和红帽选择的优先级为“高(High)”的程序错误修复公告(RHBA)。其他勘误公告可根据具体情况发布。

新的或者改进的硬件启用及精选的增强软件功能可根据红帽的自由裁量在次发行版本中提供。红帽可自由裁量在次发行本之外提供那些不需要大量软件更改的硬件启用。

次发行版本还包括可用且合格的勘误公告(RHSA、RHBA 和 RHEA)。次发行版本的内容是累计的,包括之前所发布更新的内容。在此阶段,次发行版本着重解决中、高等级的问题。

在完全支持阶段会为次发行版本提供更新的安装镜像。

维护支持 1 阶段v:

在维护支持 1 阶段中,会发布级别为关键(Ctitical)和重要(Important)的安全勘误公告(RHSA),以及优先级为“紧急(Urgent)”的程序错误修复公告(RHBA)。其他勘误公告可根据具体情况发布。

红帽通常会在次发行版本中自由裁量提供不需要大量软件更改的硬件启用(Hardware Enablement)。在这个阶段不会提供新的软件功能。

次发行版本还会包括所有可用的有效勘误。次发行版本会包括以前发布的次发行版本中的勘误公告,其中包括那些在完全支持阶段中的公告。在此阶段,次发行版本着重解决具有紧急或高优先级的程序错误。

只有因安装程序(installer)变化而需要时,红帽才会在维护支持 1 阶段自由裁量为次发行版本提供更新的安装镜像。

维护支持阶段(RHEL 8)/ 维护支持 2 阶段(RHEL 5、6、7)vi:

在 Red Hat Enterprise Linux 8 的维护支持阶段以及 Red Hat Enterprise Linux 5、6 和 7 的维护支持 2 阶段中,会发布级别为关键(Ctitical)的安全勘误公告(RHSA),以及红帽选择的优先级为“紧急(Urgent)”的程序错误修复公告(RHBA)。其他勘误公告可根据具体情况发布。

在维护支持阶段(RHEL 8)及维护支持 2 阶段(RHEL 5、6 和 7)一般不会发布新的功能及新的硬件启用。在这个阶段可能会提供带有更新安装镜像的次发行版本。

延长生命周期:

在延长生命周期阶段,通过 Red Hat Enterprise Linux 订阅还可以继续在 红帽客户门户网站中访问之前发布的内容以及其他内容,如文档及红帽知识库。另外,在此阶段,可能还会提供迁移到目前所支持的 Red Hat Enterprise Linux 版本的建议。

对于处于延长生周阶段的产品,红帽会提供有限的技术支持。 在此阶段,不会提供程序错误修复、安全修复、硬件启用(Hardware Enablement)或根本原因分析,同时只对现有安装提供支持。

红帽保留在延长生命周期阶段随时终止对 Red Hat Enterprise Linux 某个特定版本提供支持的权利。

Red Hat Enterprise Linux 8 生命周期

红帽为 Red Hat Enterprise Linux 用户、合作伙伴及 ISV 提供以下信息以供参考。下图提供了次版本计划发行的时间,以及哪些次发行版本会包括扩展的更新支持服务以及 Update Services for SAP Solutions 服务。在整个完全支持阶段,计划每 6 个月发布一个次发行版本。

RHEL 8 计划指南viii

Red Hat Enterprise Linux 8 Application Streams 生命周期

Red Hat Enterprise Linux version 8 中大多数软件包(包括绝大多数的 Application Streams)将会在 Red Hat Enterprise Linux 8 整个 10 年的生命周期中被维护。但是,一些具有特定生命周期的组件的维护时间可能会少于 10 年。这些特定的生命周期通常与上游社区指定的生命周期相匹配。

Application Streams 将遵循主发行版本产品生命周期阶段的勘误标准。例如,在维护支持阶段,为 RHEL 8 的 Application Stream 发布的勘误是影响级别为“关键(Critical)”的安全公告(RHSA),以及红帽选择的级别为“紧急(Urgent)”的程序错误修复公告(RHBA)。另外,在维护支持阶段和延长生命阶段也不会推出新的 Application Stream,这是因为在这些阶段中不提供软件增强功能5。但是,为了实现 RHEL 的 10 年支持标准,每个 Application Stream 的一个版本都会在维护支持阶段开始时被标注,这个版本将会根据支持阶段的标准获得维护。

例如,大多数数据库都被上游社区支持 5 年,在 RHEL 8 中对它们的模块流的维护将与上游社区的支持一致。PostgreSQL 的每个流版本都会被维护 5 年,所以 PostgreSQL 模块流在 RHEL 8 中就会出现重叠。 用户可以根据自己的需要选择适当的模块流。用户可以根据自己的具体情况,选择安装一个较老的版本,或安装一个较新的版本,并使用选择的版本 5 年,或在出现新版本时升级到新版本。 用户不会被强制升级,而是可以根据自己的需要在适当的情况下进行升级。 如果客户需要在一个模块流特定生命周期以外的支持,则可能需要升级到一个更新的模块流来获得相应的程序错误修正及 CVE 公告。

请参阅 Red Hat Enterprise Linux 8 Application Streams 生命周期 页来获得更详细的信息。

Red Hat Enterprise Linux 更长支持周期附加服务

延长更新支持附加服务vii

红帽为需要在延长阶段中标准化某个次发行本的客户在其 Red Hat Enterprise Linux 订阅中提供延长的更新支持(EUS)附加组件。这个 EUS 附加组件可让客户灵活地决定何时采用 Red Hat Enterprise Linux 的新功能,其中包括新硬件启用。

Red Hat Enterprise Linux 订阅会为当前有效的次发行版本提供所有可用的 RHSA 和 RHBA,直到发行了下一个次发行版本。而针对某个特定次发行版本的 EUS 服务,可以在该次发行版本已不是最新的次版本后(已发布了新的次版本),仍然为这个版本提供影响级别为“关键(Critical)” 的 RHSA 以及红帽选择的级别为“紧急(Urgent)”的 RHBA。有关 EUS 中包含的软件包列表,请查看 这里

从每个次发行版本发行时间开始 24 个月内,会提供相关的 Red Hat Enterprise Linux EUS 流。

Red Hat Enterprise Linux 7 for ARM、Red Hat Enterprise Linux 7 for Power LE (POWER9) 以及 Red Hat Enterprise Linux for IBM System z (Structure A) 不提供 EUS。

请注意: EUS 附加服务已包括在 RHEL Server Premium 订阅中。具有 RHEL Server Standard 订阅的用户可以额外购买 EUS 附加服务。使用 RHEL Server Self-Support、RHEL Desktop 和 RHEL Workstation 订阅的用户无法购买 EUS 附加服务。

Red Hat Enterprise Linux 7 的以下版本提供 EUS:

  • 7.1(2017 年 3 月 31 日结束)
  • 7.2 (2017 年 11 月 30 日结束)
  • 7.3(2018 年 11 月 30 日结束)
  • 7.4(2019 年 8 月 31 日结束)
  • 7.5(2020 年 4 月 30 日结束)
  • 7.6 (2020 年 10 月 31 日结束)
  • 7.7 (2021 年 8 月 30 日结束;最后的 RHEL 7 EUS 版本)

对于 Red Hat Enterprise Linux 8,计划对 RHEL 8.1、8.2、8.4、8.6 和 8.8 提供 EUS(请参阅上面的图)。

有关 EUS 的详情请参考这篇知识库文章

Update Services for SAP Solutions 附加服务

红帽为那些需要对特定次发行版本的延长阶段进行标准化的,具有 Red Hat Enterprise Linux for SAP Solutions 订阅的用户,提供了一个 Update Services for SAP Solutions 的附件服务。通过使用 Update Services for SAP Solutions 附加服务,客户可以灵活地决定何时进行升级来使用 Red Hat Enterprise Linux 的新功能,包括新硬件启用(Hardware Enablement)。

Red Hat Enterprise Linux 订阅会为当前有效的次发行版本提供所有可用的 RHSA 和 RHBA,直到发行了下一个次发行版本。而针对某个特定次发行版本的 EUS 及 Update Services for SAP Solutions 服务,可以在该次发行版本已不是最新的次版本后(已发布了新的次版本),仍然为这个版本独立提供影响级别为“关键(Critical)” 的 RHSA 以及红帽选择的级别为“紧急(Urgent)”的 RHBA。对于 EUS 以及 Update Services for SAP Solutions 服务订阅用户,红帽通常会在客户请求之外,不断为其主动提供级别为“关键(Critical)”的 RHSA。有关 EUS 中包含的软件包列表,请查看 这里

从每个次发行版本发行时间开始 48 个月内,会提供相关的 Red Hat Enterprise Linux Update Services for SAP Solutions 流。

注意:RHEL 8.0 的 Update Services for SAP Solutions 服务会提供到 2020 年 5 月 31 日,以便客户能够更轻松地迁移到更新版本的 RHEL 8 for SAP Solutions。

对于 Red Hat Enterprise Linux for SAP Solutions,以下版本提供了 Update Services for SAP Solutions 服务:

  • 7.2(2019 年 11 月 30 日结束)
  • 7.3(2020 年 11 月 30 日结束)
  • 7.4(2021 年 8 月 31 日结束)
  • 7.6 (2022 年 10 月 31 日结束)
  • 7.7(2023 年 8 月 30 日结束。最后的 RHEL 7 Update Services for SAP Solutions 版本)
  • 8.0 (2020 年 5 月 31 日结束)

在通过 SAP 认证后,支持 Update Services for SAP Solutions 服务的 Red Hat Enterprise Linux 7 发行版本将添加到上述列表中。

延长生命周期支持附加服务(ELS):

延长生命周期支持(ELS)是为某些 Red Hat Enterprise Linux 订阅提供的自选附加订阅。在 Red Hat Enterprise Linux 5 和 6 的延长生命周期阶段,ELS 附加服务会提供特定的影响级别为“关键(Critical)”的安全修正,以及红帽选择的优先级为“紧急(Urgent)”的程序错误修正。另外,还会为最后一个次发行版本提供故障排除服务。在 Red Hat Enterprise Linux 5 中,ELS 附加订阅包括 IBM z 系统和 x86 架构( 32 位和 64 位,Itanium 架构除外)。在 Red Hat Enterprise Linux 6 中,ELS 附加订阅包括 IBM z 系统和 x86 架构的 32 位和 64 位变体。ELS 不提供对附加服务(Add-On)的支持。

如需了解如何通过红帽的服务来满足您业务的需要,请联络红帽咨询。查看 ELS 中包括的软件包列表

请注意: 只有 RHEL Server Standard 或 Premium 订阅才提供 ELS 服务。 RHEL Desktop 及 RHEL Workstation 订阅没有 ELS 服务

虚拟化

虚拟化为虚拟客户操作系统提供硬件抽象层。使用该抽象层可轻松在支持最新服务器硬件的虚拟化主机上,部署运行可能不支持最新服务器硬件的 Red Hat Enterprise Linux 旧版本的虚拟机。通过这个方法,可以在使用最新一代处理器的 Red Hat Enterprise Linux 6 系统上运行 Red Hat Enterprise Linux 4 虚拟机。

红帽旨在支持那些,仍处于产品阶段或者延长生命周期阶段的、并作为一个虚拟客户机运行于新版本 Red Hat Enterprise Linux 系统主机上的 Red Hat Enterprise Linux 版本。

Red Hat Enterprise Linux 虚拟化支持表格提供所支持的操作系统、版本及硬件架构组合详情。

生命周期日期

所有“完全支持阶段终止”和“维护支持 1 阶段终止”中提及的将来日期都是大概日期,而不是绝对日期,它们有可能变化。

版本 公开发行 完全支持结束 维护支持 1 阶段结束 维护支持或维护支持 2 阶段结束(产品过期) 延长生命周期支持终止 延长生命周期阶段终止 最终

发行版本
4 2005 年 2 月 14 日 2009 年 3 月 31 日 2011 年 2 月 16 日 2012 年 2 月 29 日 2017 年 3 月 31 日 持续 4.9
5 2007 年 3 月 15 日 2013 年 1 月 8 日 2014 年 1 月 31 日 2017 年 3 月 31 日 2020 年 11 月 30 日 持续 5.11
6 2010 年 11 月 10 日 2016 年 5 月 10 日 2017 年 5 月 10 日 2020 年 11 月 30 日 2024 年 6 月 30 日 持续 6.10
7 2014 年 6 月 10 日 2019 年 8 月 6 日 2020 年 8 月 6 日 2024 年 6 月 30 日 不适用 持续 待定
7 (ARM) 2017 年 11 月 13 日 2020 年 11 月 30 日 不适用 不适用 不适用 持续 7.6
7 (POWER9) 2017 年 11 月 13 日 2020 年 11 月 30 日 不适用 不适用 不适用 持续 7.6
7 (System z (Structure A)) 2018 年 4 月 10 日 2020 年 11 月 30 日 不适用 不适用 不适用 持续 7.6
8 2019 年 5 月 2024 年 5 月 不适用于 RHEL 8 2029 年 5 月 待定 待定 待定

要查看不再提供维护更新的较旧的主版本、次版本和较长支持附加服务版本的生命周期日期,请参阅 https://access.redhat.com/articles/4038291

其他相关产品

有关 Red Hat Software Collections 的生命周期请参考 https://access.redhat.com/site/support/policy/updates/rhscl/

有关 Red Hat Enterprise Linux Extras 的生命周期详情,请参考 https://access.redhat.com/site/support/policy/updates/extras/

有关 Red Hat Enterprise Linux Extras 生命周期详情请查看 https://access.redhat.com/site/support/policy/updates/extras/

  1. i.主发行版本采用整数表示,比如 Red Hat Enterprise Linux 6。
  2. ii.红帽公布这份生命周期旨在努力提供信息的透明度,同时在与这些政策有冲突时保留采用例外处理的权利。
  3. iii.您可以通过 红帽客户门户网站访问红帽网络(Red Hat Network,RHN)。
  4. iv.完全支持阶段以前被称为“产品 1(Production 1)”阶段。
  5. v.维护支持 1 阶段以前被称为 “产品 2” 阶段。
  6. vi.维护支持 2 阶段以前被称为 “产品 3” 阶段。
  7. vii.如需了解更多关于 EUS 附加服务的信息,请参阅 https://access.redhat.com/node/4082531
  8. viii.生命周期时间跨度和相关日期可能会有变化。

TomCat 迁移步骤简述以及案例

TomCat 迁移步骤简述以及案例

tomcat迁移步骤案例

诗檀软件-tomcat迁移步骤案例 2015-08-10.pdf

Oracle + x86/64 Enterprise Linux(包括redhat、centos、oracle linux)兼容矩阵

Oracle + x86/64 Enterprise Linux(包括redhat、centos、oracle linux)兼容矩阵

注意所谓认证兼容是官方给出的组合certifications ,在这个certifications基础上安装出了问题,官方给出solution来解决。对于不满足certifications的组合,可以认为oracle官方不支持这种安装组合。

注意10.2.0.5不认证linux 6,但实际可以安装上去 ,详见:https://www.askmaclean.com/archives/%E5%9C%A8oracle-linux-6-5%E4%B8%8A%E5%AE%89%E8%A3%85oracle-10gr2-%E7%9A%84%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5%E3%80%90maclean%E7%89%88%E3%80%91.html

oracle+linux

版本 Linux 3 Linux 4 Linux 5 Linux 6 Linux 7
oracle 10.2.0.1 认证兼容的 认证兼容的 认证兼容的 不认证兼容的 不认证兼容的
oracle 10.2.0.5 认证兼容的 认证兼容的 认证兼容的 不认证兼容的 不认证兼容的
oracle 11.2.0.1 不认证兼容的 认证兼容的 认证兼容的 不认证兼容的 不认证兼容的
oracle 11.2.0.3 不认证兼容的 认证兼容的 认证兼容的 认证兼容的 不认证兼容的
oracle 11.2.0.4 不认证兼容的 认证兼容的 认证兼容的 认证兼容的 认证兼容的
oracle 12.1.0.2 不认证兼容的 不认证兼容的 认证兼容的 认证兼容的 认证兼容的

Engine Yard云平台推出基于Docker的商业PAAS服务

今年早些时候,Engine Yard 云平台收购了Deis,一个开源的Platform-as-a-Service项目。

Engine Yard的Support服务闻名已久,并且从今天开始,该公司还将提供商家购买Deis 支持的选择。

Deis是基于Docker和核心操作系统建立起来的平台,目的是让开发人员可以访问私人托管的Heroku。对于当前未使用Docker的用户,它甚至还支持Heroko  buildpacks运行Ruby, Python, Node.js, Java, PHP, Perl和Go等语言。 因为它以Docker为基础,所以很容易衡量和方便移动, 用户也可以在Dockerfile 和Docker image的帮助下迅速部署任何应用程序。

 

目前Deis的用户包括Mozilla和Coinbase。

 

新的支持服务将有两种:标准型和高级型。标准支持服务将在正常营业时间内提供网络和电子邮件支持,而高级支持服务将提供24×7的电话支持,保证30分钟的响应时间 。

 

此外,Engine Yard还将提供安装支持服务,培训以及现有的自定义平台帮助。

[Read more…]

YC项目Livecoding.tv要做代码编程领域的Twitch.tv

Livecoding.tv是YC的初创项目之一,Livecoding.tv的愿景是要做代码编程领域的Twitch.tv, 其通过直播形式帮助程序员快速掌握语言编程技能。

 

Livecoding 的工作原理非常简单。开发者通过视频流的方式直播自己制作的视频,观看的用户可以问问题或者给与反馈。

 

从2月份的beta到现在,Livecoding 已经有来自162个不同国家的40000人报名。使用不同母语:葡萄牙语,俄语,德语的用户基于不同的编程语言:C#, Python, and PHP,通过视频流来交流。

 

任何想视频流直播其编程过程的人,不管是专家还是第一次开发JAVA游戏的11岁儿童,都可以做到。同Periscope 和Meerkat相似,你可以追踪个体用户以及发布信息告知用户开启新的流视频。

对于专业的程序员,Livecoding是一个寻求beta用户和快速获得APP反馈的好地方。例如知名开发者/物理学家Stephen Wolfram,上周在Livecoding上推销他的新编程语言,他的演示吸引了4000多名观众。

 

[Read more…]

软件行业正在侵蚀就业市场

根据美国劳工部的信息显示,当前的美国经济背景下企业人才招聘正处在最佳势头上。对于人才的有着激烈争夺,因此对于雇主、求职者、企业主而言了解一些就业市场增长迅速的职业背后的动力显得尤为重要。

 

对于具有大学本科及以上学历的成年人2015年五月的失业率仅为2.7%,关于中等技能工作“技能缺口”的国家叙事往往侧重于依赖短期或职业培训- 但更有趣的压力点可以说是在专业水平,这已经占据了最近几年太多的美国经济的工资和雇用的增长。在这里,科技对于众多专业的职业和行业的影响是令人印象深刻的。

软件侵占就业市场software is eating the world

 

2011年,Netscape和Andreessen Horowitz的联合创始人Marc Andreessen在他的文章上创造了“software is eating the world”这一说法,阐述了他的假设,即经济价值渐渐被以软件为重点的企业扰乱,影响了广泛的行业领域。近四年后,有趣的是在美国就业市场大约每20个岗位就有1个职位涉及软件开发/工程。

 

软件开发人员的短缺是显而易见的,并引起越来越多的讨论。它催生了一次关于经济机会的重要的全国对话,鼓励更多的青年,妇女,任职人数偏低的群体追求计算机事业- 由于雇主正在寻求熟练掌握编程语言如Python,JavaScript和SQL的个人。

[Read more…]

YC支持的Cymmetria公司使用虚拟机作诱饵并检测黑客

YC(Y Combinator)支持的Cymmetria公司在一年的网络安全业务启动之后现出了它的真身,希望转变传统的安全可能性,通过给系统受到攻击的企业一个“主场优势”,让黑客感到弱势并如临大敌。

 

它是如何动态地翻转攻击者和被攻击者的局势呢?通过创建嵌入到网络,并且旨在吸引黑客的诱饵,使其更快更简单地为一个企业检测和减轻安全漏洞,而黑客​​更难知道什么是什么。

 

“我一直抱着这个想法好几年了,真的,等待着合适的时机,说:”联合创始人人员Gadi Evron说道,他曾经领导以色列政府的网络安全的运行,还曾在普华永道和卡巴斯基担任高级安全人员。

“我在一定程度上对安全行业感到筋疲力尽。从各个方面。这使我们经常感到有一种失败主义的蔓延 – 我们天天上班,知道攻击者只要想达到目的就一定会成功的事实。他们最终将黑入系统。两年半前,人们开始说一个词叫“假设的妥协”。假设攻击者已经进入。然后突然大家都发现,这不只是一个感知而就是事情如何工作的真实写照。

 

[Read more…]

redis lab获得1500万美元B轮融资,将进一步发展其in-memory内存和NOSQL数据库服务

redis lab是一家基于开源数据库NOSQL 数据库redis 和 memcached对象缓存系统,提供企业级别服务的公司。 近期其公开已完成了B轮融资,资本方包括 贝恩风投(Bain Capital Ventures)和卡梅尔风投(Carmel Ventures)。 硅谷银行也参与了本轮融资。

redis lab总部位于以色列共计融资2800万美元,计划利用本轮融资来扩展其销售和市场。

Redis Labs着力于为企业提供极为快速的数据库处理能力。redis本身是一个in-memory database内存数据库,redis的速度要比传统的基于磁盘的数据库处理速度快得多。redis lab 官方宣传其将专注于发展in-memory 内存处理能力,获得远超过其他NOSQL 数据库例如CouchBase 和Cassandra的性能,当然性能不是选择数据库种类的唯一依据。redis lab的高性能显然十分适合于企业的实时分析和互联网数据IOT。

 

[Read more…]

寻找教育创新的下一个浪潮

我开门见山地说,很少有领域像教育创新一样充满希望又令人失望。

 

教育可能是在现今社会中最为重要的功能,但它仍然是最不能理解的,尽管风险投资和政府投资的水平令人难以置信。为什么学生源源不断地教室出现或开始学习在线课程?我们如何引导学生需要的正确知识?

我们可能有一些经验和直觉,但我们仍然缺少任何根本性的见解。

 

这真令人失望。随着互联网的兴起,教育似乎在彻底改革的风口浪尖。虽然今天你如果看不清二十年前和现在我们的学习方式的区别仍然情有可原。

 

我在两个以前的文章中试图梳理出教学的挑战,比较现代大学现有的教学模式和我们在未来的学习方式。随着时间的推移,一个越来越清晰的论断是,我们都忽略了教育的人性化方面,取而代之的是“给他们药片,他们将学习”的心态。

 

教育创新的下一个浪潮将不是用大量科技来解决这个问题。相反,它将来自与人深刻交往并赋予他们能自己进行所有学习能力。

 

刚刚过去的这个月,我与两个人讨论了教育的提高,两人的观点恰恰相反。Jodi Goldstein,本月正式成为哈佛的i-lab公司孵化中心负责人,讨论把创业的心态进入美国最古老的大学的机会和挑战。

Mattan Griffel,OneMonth(基于订阅的网络教育的新公司)的创始人,在从另一个方面思考问题,在MOOC爆炸的余波中重新思考网络教育。 “[在线教育]已经超越其目前效力,”他认为,“每个人都在说通过画这幅画有些什么可能,但绘画的工具还没有达到这一步呢。”

 

总之,这两个先驱和许多其他类似的人们开始创造教育创新的下一个浪潮 – 并在过程中潜移默化地改变我们社会。

[Read more…]

沪ICP备14014813号

沪公网安备 31010802001379号