centos mysql mongodb mongodb安装
今天给各位分享centos mysql mongodb的知识，其中也会对mongodb安装进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
Out of memory: Kill process 解决
环境：Centos7
现象：Linux测试服务器上部署了很多程序mysql、mongodb、java等等。程序操作mongodb经常进程被杀死的情况，导致业务中断，mongodb的logs无提示信息。查看系统日志message后，发现对应时间点，系统自动kill掉了mongodb进程，如下
Out of memory: Kill process 5372(mongod) score 130 or sacrifice child
Killed process 5372(mongod), UID 0, total-vm:2539052kB, anon-rss:2117096kB, file-rss:0kB, shmem-rss:0kB
Linux分配内存策略
Linux内核根据应用程序的要求来分配内存，由于进程实际上并不会将分配的内存全部使用，所以，为了提高性能，内核采用了一种过度分配内存（over-commit-memory）的策略，来间接利用进程的空闲内存，提高内存的使用效率。一般来说，这没问题。但如果大多数进程都耗光自己的内存，就有麻烦了。因此此时，所有应用程序的内存之和大于物理内存。所以，必须杀掉一部分进程，一般来说，是选内存占用最大的进程杀掉。
挑选原理
挑选的过程由linux/mm/oom_kill.c里的 oom_badness()函数决定，挑选的算法很直接：是那个最占用内存的进程。
/**
test 2334 1.6 2.1 623800 4876? Ssl 09:52 0:00/usr/sbin/test
0
当然，也可以完全关闭 OOM killer，但线上生产环境最好不要这么做。
OOM_killer是Linux自我保护的方式，当内存不足时不至于出现太严重问题，有点壮士断腕的意味
在kernel 2.6，内存不足将唤醒oom_killer，挑出/proc/<pid>/oom_score最大者并将之kill掉
为了保护重要进程不被oom-killer掉，我们可以：echo-17>/proc/<pid>/oom_adj,-17表示禁用OOM
我们也可以对把整个系统的OOM给禁用掉：
sysctl-w vm.panic_on_oom=1（默认为0，表示开启）
sysctl-p
值得注意的是，有些时候 free-m时还有剩余内存，但还是会触发OOM-killer，可能是因为进程占用了特殊内存地址
平时我们应该留意下新进来的进程内存使用量，免得系统重要的业务进程被无辜牵连
可用 top M查看最消耗内存的进程，但也不是进程一超过就会触发oom_killer
参数/proc/sys/vm/overcommit_memory可以控制进程对内存过量使用的应对策略
当overcommit_memory=0允许进程轻微过量使用内存，但对于大量过载请求则不允许(默认）
当overcommit_memory=1永远允许进程overcommit
当overcommit_memory=2永远禁止overcommit
参考：
mysql安装环境要求
在安装MySQL之前，有几个基本的要求需要考虑：
首先，关于系统环境：MySQL能够运行在多种常见的操作系统上，包括Windows、Linux（如Ubuntu、CentOS、Debian等）以及MacOSX等。如果打算在Linux系统上安装，可能需要以root或具有sudo权限的用户身份进行。这一步骤确保了安装过程能够顺利完成。
其次，内存方面：安装MySQL时，它可能需要额外的内存来运行。对于大多数系统，建议至少有256MB的可用内存。虽然内存需求不高，但这仍然是一个重要的考虑因素。
接着，磁盘空间：尽管MySQL数据库本身通常体积不大，但安装过程可能会消耗一些磁盘空间。通常，安装过程需要大约10MB到20MB的可用磁盘空间。因此，确保有足够的空间是必要的。
此外，网络连接：MySQL服务器需要能够访问互联网，以下载必要的文件和库。确保网络连接正常，以便安装过程顺利进行。
在兼容性方面：确保你的硬件和操作系统的版本与MySQL的版本兼容。例如，MySQL8.0及以上版本在Windows上需要64位系统，而在Linux上需要支持的硬件架构（如x86或ARM）。这一步骤确保了安装后MySQL能够正常运行。
另外，在某些特定的环境中，如Docker或Kubernetes，可能需要根据特定需求来选择安装和使用哪种MySQL版本。这些环境可能对内存和CPU有特定要求，或可能使用特定版本的库或工具包。因此，了解这些要求对于选择合适的安装方法至关重要。
同时，还需要考虑系统中的其他服务可能对安装过程产生影响。例如，防火墙设置、其他数据库服务（如PostgreSQL或MongoDB）可能会影响到MySQL的安装和运行。因此，在安装前，确保所有相关设置都正确配置。
最后，建议访问MySQL官方网站或咨询相关专业人士，获取更具体的信息。这将帮助你更好地了解安装过程中需要注意的细节，确保安装顺利进行。
linux下的mongodb服务自动关闭,不知道什么原因
你好，原因如下：
为解决频繁的数据插入和更新问题（这些数据的可靠性要求不高，不需要事务），赶上NoMysql的热潮，选择目前最热门的Mongodb，在测试中充分感受到mongodb安装的简单性和客户端调用API的便捷。
但在生产环境下（操作系统CentOS 6.2，内存64G，CPU 12核），却出现频繁的宕机，有时候一天就要宕2次，虽然设置了replica sets，却很容易挂掉2台，导致不可用。
查看mongod.log，发现每次宕机时都会打印Got signal: 11(Segmentation fault)，但从这个查找不到能够解决问题的资料。
有人认为mongodb频繁宕机大多数是因为在并发查询的压力下，因为热数据没有在内存中，被迫到文件系统读取数据，很容易出现timeout的问题，之后会造成进程锁死，经过验证，如果把查询（只有通过主键查一条记录的查询）的客户端关闭掉，宕机的概率小非常多。查看每台mongodb的内存(通过mongodb命令控制台的db.serverStatus()看“mem”部分的“resident”)，发现mongodb热数据的内存只占用不到2G，而数据文件有近200G，可能也是因为频繁的宕机，导致热数据一直未全部加载。
但还是会出现宕机，为了不需要人工重启，就在每个replica的服务器上用Linux Shell脚本写了一段每隔1分钟检测mongodb进程死掉自动重启的进程，虽然能够解决mongodb一直在运行的状态，但发现mongodb的collections中出现很多损坏的数据，甚至出现一些自动创建的异常collections，如一个collections的名称是“jingdong”，则会出现多个“ingdong”、"jing"、“jingdon”之类的collections。
不得已只好把mongodb的定时检测启动脚本关闭掉，顺着这个现象找问题，终于在mongodb官网的JIRA看到有个用户反馈的现象跟我们完全一致，最后他解决的方法是把mongodb客户端的java驱动jar包由2.9.1回退至2.8.0，我们也按照这样处理后，果然不会再出现crash问题。
