前言
很多情况下CentOS自带的glibc版本不够用。而glibc编译速度短时间内完成不了，特别是对初次编译的折腾玩家来说未知的恐惧不小。今日偶然需要编译一次glibc2.18，顺便写个文章。
笔者第一次编译glibc大概时七八年前了，当时就比较好奇，在编译的时候搜索 glibc编译需要多久 ，通过互联网找到了一堆 不靠谱 的结论，什么几个小时几天的。当然，对系统下手不是什么良策，因为各种依赖问题，操作后可能很多软件有可能会出现问题，不太建议对系统的glibc动手，相对来说docker/openvz/类似的虚拟环境或者更换操作系统是相对更加靠谱的主意。至于CentOS来说，许许多多的软件虽然没有内置源提供，但是相当多的软件都提供了可信来源的直接可用的二进制文件，直接复制到需要的路径即可使用，例如ffmpeg。
glibc编译过程中不需要通过互联网获取文件，下方测试结果不受网络环境差异。如果编译PHP之类的，例如低glibc版本的PHP的过程中可能有不少网络下载，而且资源天南海北有欧洲，还有的在美西，几乎么有服务器能痛快的下载全部资源的，特别是亚洲区域的服务器连接欧洲、美东网络延迟本身就很大，编译此类程序可以考虑提前下载这些文件避免网络导致的测试误差，glibc本身没有额外依赖，就不需要这个步骤了。
测试
wget http://ftp.gnu.org/gnu/libc/glibc-2.18.tar.gz
tar xvf glibc-2.18.tar.gz
cd glibc-2.18/
mkdir build
cd build
../configure --prefix=/usr --disable-profile --enable-add-ons --with-headers=/usr/include --with-binutils=/usr/bin
time make -j2
#make install
#安装，查看版本。
#strings /lib64/libc.so.6 | grep 2.18测试方式如上，操作系统统一使用CentOS 7，在不同平台测试所需时间。
编译版本2.18，由于普遍丐配云服务器都是双核的，故采用双线程方式。从经验来说这种状态处理器平均占用应该是70%左右，不影响轻量的线上服务运行。如果日常运行状态负荷就不低，且业务对响应相对敏感，显然应该先升级服务器的配置。
以下测试均进行3次排除偶然性。
正常的服务器编译glibc 2.18大概5分钟左右：
E5-2670v2 睿频2900MHz，DDR3 4通道，双空闲核心绑定的ESXi虚拟机，傲腾M10直通。
套路云编译glibc 2.18大概30分钟左右：
企业free套餐，套路云ECS u1m4 2核8G 2500MHz
良心云编译glibc 2.18大概7分钟左右：
未知套餐，Xeon(R) Gold 6148 CPU 2400MHz，2核2G
后续补充更多配置的编译速度，例如良心云EPYC 7K62，手头的是单核的就不参与对比了。
另补充说明：不同时期的同款产品，受限于邻居等各种情况，结果仅供参考。性能是一方面，可靠性是另一方面。
国内的云服务器，包括大厂，其实很多CPU资源仍然都是动态共享的，哪怕明示1个核心类似的表述，如果遇到了不太正经的邻居，特定情况下，处理器的缓存、内存性能会受到邻居干扰。另外想象中的云服务器底层通过RDMA之类的技术实现双机、多服务器集群高可用也是“梦里有”，国内的各云服务器更可能的一种定义是VPS，而不是各自各种定义的“云服务器”，而“轻量服务器”也都是差不多的东西。服务的可用性还是受到虚拟化底层的影响的，正常情况下来说可能自己的电脑也能几年几年不关机正常运行，但是信息产品的损坏就是突然性的，作为运维，应该不会有人不了解平均无故障时间真正的含义吧？
国内厂商的“云服务器”或者“轻量服务器”相对于传统的VPS来说，仅仅是提供了存储分离，存储三副本之类的特性。至于处理器资源可能都没有做好足够的预留，更别说更精细的计算性能隔离。经常有人收到“补偿邮件”，虚拟化底层单点故障导致服务被重置的通知。早些年笔者半年内碰上三次所在节点出现故障，国内某大厂的云服务器，当年还是xen虚拟化，能获得的补偿对于产品本身支付的费用来说都是毛毛雨，更别提万一有生产场景使用产生的损失了。因此，重要数据除了云计算厂商提供的保障，作为运维一定要有额外的手段去保护重要的服务可用性。
另举个例子描述平均无故障时间MTBF。无故障以为着正常使用，但是设备死机并非损坏，这个例子可能不太恰当。某款路由器笔者根据大量的设备统计，平均死机时间大概是500小时。意思是什么呢？如果手头只有1台，那么平均每个月都会死机一次，如果手头有500台同时运行，大概每个小时都会有一台路由器死机。设备所谓的譬如10万、100万小时无故障时间，描述的是设备正常生命周期内设备本身的可靠性，并不是设备本身使用寿命。指标为100万小时的设备在正常运行环境下比10万小时的靠谱10倍，而假如说你有10万台参数为10万小时的，每个小时都会有一个设备故障，设备的寿命与MTBF没有太大的关联性。