编辑如下文件/etc/yum.repos.d/CentOS-Base.repo

cat /etc/yum.repos.d/CentOS-Base.repo

# CentOS-Base.repo
#
# The mirror system uses the connecting IP address of the client and the
# update status of each mirror to pick mirrors that are updated to and
# geographically close to the client.  You should use this for CentOS updates
# unless you are manually picking other mirrors.
#
# If the mirrorlist= does not work for you, as a fall back you can try the 
# remarked out baseurl= line instead.
#
#
 
[base]
name=CentOS-6 - Base - mirrors.aliyun.com
failovermethod=priority
baseurl=http://mirrors.aliyun.com/centos/6/os/$basearch/
        http://mirrors.aliyuncs.com/centos/6/os/$basearch/
        http://mirrors.cloud.aliyuncs.com/centos/6/os/$basearch/
gpgcheck=1
gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-6
 
#released updates 
[updates]
name=CentOS-6 - Updates - mirrors.aliyun.com
failovermethod=priority
baseurl=http://mirrors.aliyun.com/centos/6/updates/$basearch/
        http://mirrors.aliyuncs.com/centos/6/updates/$basearch/
        http://mirrors.cloud.aliyuncs.com/centos/6/updates/$basearch/
gpgcheck=1
gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-6
 
#additional packages that may be useful
[extras]
name=CentOS-6 - Extras - mirrors.aliyun.com
failovermethod=priority
baseurl=http://mirrors.aliyun.com/centos/6/extras/$basearch/
        http://mirrors.aliyuncs.com/centos/6/extras/$basearch/
        http://mirrors.cloud.aliyuncs.com/centos/6/extras/$basearch/
gpgcheck=1
gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-6
 
#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-6 - Plus - mirrors.aliyun.com
failovermethod=priority
baseurl=http://mirrors.aliyun.com/centos/6/centosplus/$basearch/
        http://mirrors.aliyuncs.com/centos/6/centosplus/$basearch/
        http://mirrors.cloud.aliyuncs.com/centos/6/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-6
 
#contrib - packages by Centos Users
[contrib]
name=CentOS-6 - Contrib - mirrors.aliyun.com
failovermethod=priority
baseurl=http://mirrors.aliyun.com/centos/6/contrib/$basearch/
        http://mirrors.aliyuncs.com/centos/6/contrib/$basearch/
        http://mirrors.cloud.aliyuncs.com/centos/6/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=http://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-6


yum clean all
yum makecache

在各种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。

其详细算法如上文引用。

因为都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 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 生命周期阶段的目的是减少每个主发行版本 ⁱ 之间变化的程度，以便更好预期新的发行版本和内容。 ⁱⁱ

TomCat 迁移步骤简述以及案例

tomcat迁移步骤案例

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

今年早些时候，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…]

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

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

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

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

[Read more…]

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…]