刷centos centos如何安装软件

大家好，感谢邀请，今天来为大家分享一下刷centos的问题，以及和centos如何安装软件的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！

如何让CentOS服务器磁盘io性能翻倍

如何让CentOS服务器磁盘io性能翻倍

这一期我们来看一下有哪些办法可以减少linux下的文件碎片。主要是针对磁盘长期满负荷运转的使用场景（例如http代理服务器）；另外有一个小技巧，针对互联网图片服务器，可以将io性能提升数倍。如果为服务器订制一个专用文件系统，可以完全解决文件碎片的问题，将磁盘io的性能发挥至极限。对于我们的代理服务器，相当于把io性能提升到3-5倍。

在现有文件系统下进行优化linux内核和各个文件系统采用了几个优化方案来提升磁盘访问速度。但这些优化方案需要在我们的服务器设计中进行配合才能得到充分发挥。

文件系统缓存linux内核会将大部分空闲内存交给虚拟文件系统，来作为文件缓存，叫做page cache。在内存不足时，这部分内存会采用lru算法进行淘汰。通过free命令查看内存，显示为cached的部分就是文件缓存了。

如果能找到当前使用场景下，文件被访问的统计特征，针对性的写一个淘汰算法，可以大幅提升文件缓存的命中率。对于http正向代理来说，一个好的淘汰算法可以用1GB内存达到lru算法100GB内存的缓存效果。如果不打算写一个新的淘汰算法，一般不需要在应用层再搭一个文件cache程序来做缓存。

最小分配

最小分配的副作用是会浪费一些磁盘空间（分配了但是又没有使用）

如果当前使用场景下小文件很多，把预分配改大就会浪费很多磁盘空间，所以这个数值要根据当前使用场景来设定。似乎要直接改源代码才能生效，不太记得了，09年的时候改的，有兴趣的同学自己google吧。

io访问调度

如何针对性优化：io访问调度能大幅提升io性能，前提是应用层同时发起了足够的io访问供linux去调度。怎样才能从应用层同时向内核发起多个io访问呢？方案一是用aio_read异步发起多个文件读写请求。

小提示：将文件句柄设置为非阻塞时，进程还是会睡眠等待磁盘io，非阻塞对于文件读写是不生效的。在正常情况下，读文件只会引入十几毫秒睡眠，所以不太明显；而在磁盘io极大时，读文件会引起十秒以上的进程睡眠。详见内核源代码do_generic_file_read会调用lock_page_killable进入睡眠，但是不会判断句柄的非阻塞标志。

预读取linux内核可以预测我们“将来的读请求”并提前将数据读取出来。通过预读取可以减少读io的次数，并且减小读请求的延时。

当文件扩大，需要分配磁盘空间时，可以不立即进行分配，而是暂存在内存中，将多次分配磁盘空间的请求聚合在一起后，再进行一次性分配。

延迟分配的副作用有几个：1如果应用程序每次写数据后都通过fsync等接口进行强制刷新，延迟分配将不起作用2延迟分配有可能间歇性引入一个较大的磁盘IO延时（因为要一次性向磁盘写入较多数据）

如何针对性优化：

“让每个目录下的文件连续存储”是一个极有价值的功能。假设一个网页上有10张图片，这10张图片虽然存在10个文件中，但其实是几乎同时被用户访问的。如果能让这10张图片存储在连续的磁盘空间中，就能把io性能提升10倍（一次寻道就可以读10个文件了）传统的做法是通过拼接图片来将这10张图片合并到一张大图中，再由前端将大图切成10张小图。有了e4defrag后，可以将需连续访问的文件放在同一个文件夹下，再定期使用e4defrag进行磁盘整理。

实现自己的文件系统我们曾经写过一款专用文件系统，针对代理服务器，将磁盘io性能提升到3-5倍。在大部分服务器上，不需要支持“修改文件”这个功能。一旦文件创建好，就不能再做修改操作，只支持读取和删除。在这个前提下，我们可以消灭所有文件碎片，把磁盘io效率提升到理论极限。

大于16MB的文件，服务器创建文件时告诉文件系统分配16MB磁盘空间。后续每次扩大文件大小时，要么是16MB，要么就是文件终结。不允许在文件未终结的情况下分配非16MB的空间。读写文件时，每次读写16MB或者直到文件末尾。

在我们的文件系统中，小文件完全无碎片，一次寻道就能搞定一个文件，达到了理论上最佳的性能。大文件每次磁头定位读写16MB，性能没有达到100%，但已经相当好了。有一个公式可以衡量磁盘io的效率：磁盘利用率=传输时间/（平均寻道时间+传输时间）对我们当时采用的磁盘来说（1T 7200转sata)，16MB连续读写已经可以达到98%以上的磁盘利用率。

centos平替体验之龙蜥、欧拉、Rocky、Alma

在寻找CentOS替代品的过程中，龙蜥、欧拉、RockyLinux和AlmaLinux成为了值得关注的对象。在搭建4节点的x86机器集群时，我尝试了这四个Linux发行版，对其CentOS兼容性进行了评价。以下内容基于实际体验和测试，对它们的兼容性进行分析。

在CentOS兼容性方面，龙蜥、RockyLinux和AlmaLinux表现良好，基本实现了与CentOS的无缝衔接，包括操作兼容性、仓库使用便利性等。欧拉则在内核版本和默认内核配置上有别于其他三个发行版，尽管内核版本更新较为激进，但兼容性上略显不足。迁移至欧拉的用户可能会遇到一些小问题，不过这些问题通常都能解决。

在内核版本的比较中，欧拉的内核版本较为先进，但这种激进性有时也会带来意想不到的问题，例如在使用docker启动CouchDB时会遇到长时间卡顿的问题。这一现象与欧拉上docker容器内ulimit-n的用户最大打开文件数配置有关。相较于其他发行版（Anolis/RockyLinux/AlmaLinux）的较小值（1048576），欧拉的设置为infinity，即无限制。因此，为解决这一问题，需要在欧拉的docker配置文件中添加限制，并重启docker服务。

对于yum仓库的兼容性，四个发行版的默认yum仓库均可以直接使用，但欧拉的刷新缓存和实际安装下载速度较慢。通过调整配置，将直接使用官方站点的baseurl注释掉，只保留使用镜像站点的metalink，可以显著提升速度。

在特定yum仓库的使用上，欧拉需要额外修改$releasever字段以适配特定软件的安装需求。这与欧拉版本号与CentOS或其他发行版的版本号不一致有关，因此在安装需要特定yum仓库文件的软件（如docker-ce）时，需要手动调整$releasever字段。

防火墙与selinux方面，四个发行版使用的是firewall，且默认都启用并支持selinux，开机启动。操作上不存在差异。

常用工具方面，龙蜥、RockyLinux、AlmaLinux与CentOS相比，目前未发现存在不一致之处。欧拉则在默认安装的软件上有所不足。

在docker相关功能上，除了欧拉安装docker时需要修改docker-ce的yum配置文件外，其他操作都正常。一般安装命令亦无差异。

对于mysql的处理，四个发行版均未默认安装mariadb或mysql，都可以通过dnf直接从默认yum仓库安装mysql。其中，欧拉的可安装版本为8.0.37，而其他三个发行版为8.0.36。在配置与初始化mysql方面，四个发行版均遵循类似流程，但在配置文件的组织和存放上存在差异，欧拉的配置文件仅在/etc/my.cnf.d下存在一个文件。

ssh配置方面，欧拉默认禁用了TCP端口转发，这在使用vscode远程连接时可能会导致问题。相比之下，其他三个发行版无此问题，需要在欧拉的sshd配置中进行适当调整。

centos7刷新dns缓存

DNS记录更改，使用systemd-resolved服务；DNS服务器故障，刷新DNS缓存等。

DNS记录更改，使用systemd-resolved服务：当centos7刷新dns缓存时，如果DNS服务器上的DNS记录（例如A记录、MX记录等）被更改，那么这些更改不会立即生效。为了使更改的记录生效，此时CentOS7默认使用systemd-resolved作为DNS解析器和缓存管理器。

DNS服务器故障，刷新DNS缓存：如果DNS服务器出现故障或者网络连接问题导致DNS服务器无法正常工作，那么客户端的DNS缓存可能包含过时或者无效的DNS记录。在这种情况下，需要刷新DNS缓存以清除无效的记录即可。