centos sam，centos8关闭图形界面

大家好，今天来为大家解答centos sam这个问题的一些问题点，包括centos8关闭图形界面也一样很多人还不知道，因此呢，今天就来为大家分析分析，现在让我们一起来看看吧！如果解决了您的问题，还望您关注下本站哦，谢谢~

CentOS7常用命令之 用户和用户组管理

在Linux系统中，用户账号的管理主要涉及添加、修改和删除账号。使用useradd命令添加新账号，其语法如下：

实例1：使用-d和-m选项创建用户sam，主目录为/home/sam。

实例2：新建用户gem，登录Shell为/bin/sh，属于group用户组，同时属于adm和root用户组。

若需新建组，可以使用groupadd命令。常用操作包括删除账号（使用userdel命令，常用选项-r删除主目录），修改账号（使用usermod命令，包含-c、-d、-m、-g、-G、-s、-u等选项），及用户口令管理（使用passwd命令修改口令，选项-l用于锁定账号，-x用于设置口令过期时间）。

用户组管理主要涉及添加、删除和修改用户组。通过groupadd和groupdel命令操作。组的修改使用groupmod命令，包含标识号修改和名称修改等。

用户管理涉及的关键系统文件包括/etc/passwd、/etc/shadow、/etc/group。/etc/passwd文件记录用户的基本属性，如用户名、口令、标识号、组标识号、注释性描述、主目录及登录Shell。/etc/shadow文件存储加密后的用户口令。/etc/group文件记录用户组信息，包括组标识号、组名、组成员等。

为简化批量用户管理，Linux提供了新用户导入工具，如新用户导入命令newusers。首先编辑文本用户文件，每一行按照/etc/passwd格式书写，确保用户名、UID、宿主目录不重复，密码栏可留空或输入x。然后执行newusers命令导入数据，创建用户。使用pwunconv命令解码shadow密码并回写到passwd文件，编辑每个用户的密码对照文件，使用chpasswd命令创建密码，并使用pwconv命令编码为shadow格式。完成创建后，检查用户宿主目录权限设置，登录验证密码。

solr和elasticsearch对比,有啥差别吗

从两个方面对ElasticSearch和Solr进行对比，从关系型数据库中的导入速度和模糊查询的速度。

单机对比

1. Solr发布了4.0-alpha，试了一下，发现需要自己修改schema，好处是它自带一个data importer。在自己的计算机上测试了一下，导入的性能大概是：14分钟导入 3092730条记录，约合 3682条/秒。

2. 3百万条记录的情况下，模糊查询和排序基本都在1秒内返回

3.刚才的测试，是每个field单独存储，现在修改了一下配置文件，增加了一个copyField，所有的field都拷贝一份到text这个field里面去，导入的性能大概是：19分钟导入了3092730条记录，约合 2713条/秒

4. 3百万条记录的情况下，针对text的模糊查询基本在1秒内返回，但是针对所有记录的排序，大概要2~3秒

5.使用 elasticsearch 0.19.8，缺省配置，用单任务导入，导入性能是：20分钟导入了3092730条记录，约合2577条/秒

6. 3百万条记录的情况下，查询基本上在1秒内返回，但是模糊查询比较慢，第一次要10秒，后来大概要1~3秒。加上排序大概需要5秒，整体排序基本100ms

查询及排序的指令：

{

"query":{

"query_string":{

"query":"*999*"

}

},

"sort": [

{

"TIME_UP":{

"order":"asc"

}

}

]

}

7. Es0.19.8，用两个任务导入，导入性能是：13分钟导入了3092730条记录，约合3965条/秒

8. Solr全部建好索引后，占用磁盘空间是1.2G，es占用磁盘空间是4G

单机对比2

在一台Intel i7，32G内存的机器上，重新跑这两个的对比。不过有个重大的区别在于，Solr是在这台性能很好的机器上跑，而es的导入进程则是在一台Intel四核 2.5G，4G内存的机器上跑的，也许会有性能的差异。ES版本0.19.8，Solr版本4.0-ALPHA。

1. Solr的导入性能：3400万条记录，用时62分钟，平均9140条/秒，占用空间12.75G

2.使用*999*这样的模糊查询，3秒以内返回，稍长一点的查询条件*00100014*，也是2~3秒返回

3. Es的导入性能（设置Xmx为10G）：3400万条记录，用时40分钟，平均14167条/秒，占用空间33.26G，客户端采用4个并发。

4.使用*999*这样的模糊查询，9秒返回，稍长一点的查询条件*00100014*，11.8秒返回

5.如果不是针对所有字段查询，而是针对某个特定字段，比如 SAM_CODE:*00100014*，那么也是1秒以内返回。

6.结论：es的查询效率也可以很高，只是我们还不会用。

7.结论2：es有个设置是把所有字段放一块的那个，缺省是放一起，但是不知道为什么没起到应有的作用。

备注：

1. Solr第一次的那个内存使用的是缺省设置，这次改为10G，结果导入性能反而变差了，400万条记录，用了8分钟，平均8333条/秒，不知道为什么。

2.改回缺省的内存配置，导入速度仍然慢。

3.重启Linux，用10G的内存配置，再导入，5030万条记录，用时92分，约9112条/秒，说明导入速度和内存配置没有大差别

4.在10G配置的情况下，检索速度也差别不大。

5.为了搞清楚lucene4.0和solr4.0的进步有多大，下载了solr3.6.1，所幸的是4.0的配置文件在3.6.1上也可以用，所以很快就搭起来进行测试，导入性能为：3400万条记录，用时55分钟，约10303条/秒，占用空间13.85G。查询性能：*999*第一次11.6s，*00100014* 27.3s，相比4.0ALPHA的结果（5000万结果当中，*999*第一次2.6s，*00100014*第一次2.5s）来说，慢了很多，与es的性能差不多，因此，也许lucene4.0真的对性能有大幅提升？

集群对比：

采用4台同样配置（Intel i7，32G内存）的Centos 6.3组成的集群，进行对比。

1.首先是es，很方便的就组成了一个Cluster，等上一个3400万条的Index全部均衡负载之后进行测试，导入到另外一个Index当中。

2.导入性能：8500万条记录，用时72分钟，约为19676条/秒。在前5千万条记录导入时的速度在2万/条以上，初始的速度在2.2万/条。占用空间78.6G（由于有冗余，实际占用空间为157.2G）

3.查询性能：

*999*第一次13.5秒，第二次19.5秒，第三次7.4秒，第四次7.1秒，第五次7.1秒

*00100014*第一次17.2秒，第二次16.6秒，第三次17.9秒，第四次16.7秒，第五次17.1秒

SAM_CODE:*999*，0.8s，1.3s，0.02s，0.02s，0.02s

SAM_CODE:*00100014*，0.1s，0.1s，0.02s，0.03s，0.05s

4. Solr4.0-ALPHA，SolrCloud的配置还算简单，启动一个ZooKeeper，然后其他三台机器访问这个地址，就可以组成一个Cloud：

机器1： nohup java-Xms10G-Xmx10G-Xss256k-Djetty.port=8983-Dsolr.solr.home="./example-DIH/solr/"-Dbootstrap_confdir=./example-DIH/solr/db/conf/-Dcollection.configName=xabconf3-DzkRun-DnumShards=4-jar start.jar&

其他机器：nohup java-Xms10G-Xmx10G-Dsolr.solr.home="./example-DIH/solr/"-DzkHost=192.168.2.11:9983-jar start.jar&

但是在执行 data import的时候，频繁出现 OutOfMemoryError: unable to create new native thread。查了很多资料，把Linux的ulimit当中的nproc改成10240，把Xss改成256K，都解决不了问题。暂时没有办法进行。

结论

1.导入性能，es更强

2.查询性能，solr 4.0最好，es与solr 3.6持平，可以乐观的认为，等es采用了lucene4之后，性能会有质的提升

3. Es采用SAM_CODE这样的查询性能很好，但是用_all性能就很差，而且差别非常大，因此，个人认为在目前的es情况下，仍然有性能提升的空间，只是现在还没找到方法。

如何查看哪些进程使用了swap

swap查看有很多种方法，一一介绍下：

1.free

free-m

就能看出当前系统所使用的swap了。那么如何查看哪些进程使用了swap呢，这样好针对性的做出优化。

2.top

Centos（6.0之前）：

top只能看到swap总使用量

网上很多人说top+f+p能显示出来swap。可是按完f查看的时候，man top里面swap的解释是：

并不是实际的使用swap。而是VIRT-RES得来的。用我蹩脚的英文翻译就是，虚拟内存中所使用过的swap部分

3.Centos（6.0之后）：

man top

这样就明显看出是取出的每个进程的swap，能很方便的查看哪些进程使用了swap。从中也能看到一个信息。那就是读取了/proc/#/status

4.vmstat

vmstat-n 1也能查看到

仍旧无法查看到哪些进程使用了。但是能看到si、so

Memory（内存）：

swpd:使用虚拟内存大小

free:可用内存大小

buff:用作缓冲的内存大小

cache:用作缓存的内存大小

Swap：

si:每秒从交换区写到内存的大小

so:每秒写入交换区的内存大小

5.shell

在Linux内核 2.6.16中引入了一个系统内存接口特性，这个接口位于/proc/$pid/目录下的smaps文件中，一看内容发现是进程内存映像信息，比同一目录下的maps文件更详细些。

cat/proc/1/smaps

这里解释下samps里面的内容：

bfdca000-bfddf000是该虚拟内存段的开始和结束位置

rw-p内存段的权限，rw是指可读写，p是指私有，如果是s则为共享

bffea000该虚拟内存段在对应的映射文件中的偏移量

00：00文件的主设备和次设备号

0被映射到虚拟内存的文件的索引节点号

[stack]被映射到虚拟内存的文件名称

Size是进程使用内存空间，并不一定实际分配了内存(VSS)

Rss是实际分配的内存(不需要缺页中断就可以使用的)

Shared_Clean和其他进程共享的未改写页面

Shared_Dirty和其他进程共享的已改写页面

Private_Clean未改写的私有页面页面

Private_Dirty已改写的私有页面页面

Swap存在于交换分区的数据大小(如果物理内存有限，可能存在一部分在主存一部分在交换分区)

Pss是平摊计算后的使用内存(有些内存会和其他进程共享，例如mmap进来的)