IBM Linux组电面总结

tinyfisher 发表于 2013-09-22

下午四点多的突然接到IBM Linux电面,找了个安静的地方开始面试,对面GG比较友好,首先自我介绍,然后说了说项目,面试官还是很互动的,氛围比较轻松,还介绍了Linux组主要是做社区这一块,内核神马的。之后开始技术问题狂轰滥炸:

1.大小端问题

这个才看过,总结下:小端是指低地址在低字节,正常比较容易理解的就是小端;大端是指高位在低字节,低位在高字节(比较绕)。。。
举个例子:0x1234,如果是小端,假设左边是内存高位,右边是内存低位,则小端存储如下:0x12,0x34;反之大端则是:0x34,0x12

2.fork特点

这个回答的还不错,fork会有两个返回值,返回值为0的为子进程,返回值不为0的为父进程,其数值含义是子进程的pid

3.僵尸进程

这个答错了,面试官问“是这样吗”之后,我就知道答错了,记混淆了。
我的错误回答:父进程比子进程先结束,子进程由init进程管理,子进程成为僵尸进程
错误原因:我混淆了孤儿进程和僵尸进程的概念,我说的其实是孤儿进程。那么什么是僵尸进程呢?

关于僵尸进程
1.僵尸进程是怎么产生的?

由于子进程的结束和父进程的运行是一个异步过程,即父进程永远无法预测子进程到底什么时候结束. 那么会不会因为父进程太忙来不及wait子进程,或者说不知道子进程什么时候结束,而丢失子进程结束时的状态信息呢? 不会。因为UNIX提供了一种机制可以保证只要父进程想知道子进程结束时的状态信息,就可以得到。这种机制就是: 在每个进程退出的时候,内核释放该进程所有的资源,包括打开的文件,占用的内存等。 但是仍然为其保留一定的信息(包括进程号the process ID,退出状态the termination status of the process,运行时间the amount of CPU time taken by the process等)。直到父进程通过wait / waitpid来取时才释放. 但这样就导致了问题,如果进程不调用wait / waitpid的话, 那么保留的那段信息就不会释放,其进程号就会一直被占用,但是系统所能使用的进程号是有限的,如果大量的产生僵死进程,将因为没有可用的进程号而导致系统不能产生新的进程. 此即为僵尸进程的危害,应当避免。
总结一下:一个子进程在其父进程还没有调用wait()或waitpid()的情况下退出。这个子进程就变成僵尸进程。

2.僵尸进程的处理
任何一个子进程(init除外)在exit()之后,并非马上就消失掉,而是留下一个称为僵尸进程(Zombie)的数据结构,等待父进程处理。这是每个子进程在结束时都要经过的阶段。如果子进程在exit()之后,父进程没有来得及处理,这时用ps命令就能看到子进程的状态是“Z”。如果父进程能及时 处理,可能用ps命令就来不及看到子进程的僵尸状态,但这并不等于子进程不经过僵尸状态。如果父进程在子进程结束之前退出,则子进程将由init接管。init将会以父进程的身份对僵尸状态的子进程进行处理。

4.git

面试关看我的博客是在github上写的,于是又问了我git的问题,git rebase是干什么用的?
我知道git add,commit,push,pull,checkout,reset,还真没用过rebase。。。

首先回顾一下git基本命令
git init 初始化代码仓库
git add file 将工作目录里的file文件修改提交到本地暂存区
git commit -m “commit” 将暂存区里的文件提交,备注“commit”,同时生成快照,就是一个hash值
git checkout file 把file回滚到修改前的状态,注意这个针对还没有提交到本地暂存区的文件,即git add之前的文件 git reset HEAD file 把file从暂存区撤离,即git add 的反操作
git revert <$id> 返回到commit id为<$id>的状态,本次也是一个动作,需要commit
git reset –hard HEAD~1 彻底回到倒数第二个commit,倒数第一个的commit会消失,文件内容也回到上个版本 git reset –soft HEAD~1 将最后一个commit撤销,但文件内容没变,只需要重新commit即可 git diff 查看本地文件和暂存区文件差别 git log 查看commit记录
git status 查看git文件暂存区状态 git pull 抓取远程仓库所有分支更新并合并到本地
git push push所有分支到远程仓库 git push origin master 将本地主分支推到远程主分支
git branch 显示所有分支
git branch newbranch 创建分支
git checkout branchname 切换到分支

关于git rebase
下面这篇blog写的比较不错,之前没有多人开发git的经验,还是挺难理解的.

5.kmalloc和vmalloc区别

没用过,不知道,查了下:
kmalloc和vmalloc是分配的是内核的内存,malloc分配的是用户的内存

kmalloc保证分配的内存在物理上是连续的,vmalloc保证的是在虚拟地址空间上的连续

kmalloc能分配的大小有限,vmalloc和malloc能分配的大小相对较大

内存只有在要被DMA访问的时候才需要物理上连续,即kmalloc

kmalloc和 kfree管理内核段内分配的内存,这是真实地址已知的实际物理内存块。vmalloc和vfree是对内核使用的虚拟内存进行分配和释放

6.malloc调用的系统调用

不知道,查了下是brk,参见这篇blog

7.fork的优化

这个依然不知道,fork实现的时候并不是完全复制父进程的数据段和堆栈,而是采用了写时复制(copy-on-write)COW技术。数据段和堆栈有父子进程共享,内核将他们的访问权限设为只读,父子进程中的任何一个试图修改这些区域,此时内核只为那些修改的区域的那块内存做一个副本,通常是一个page。

8.C/C++遇到的坑

这个说了我之前遇到的链接错误,参见我的博文makefile 编写问题记录

9.从IBM发ip包到北邮要查那些表,子网掩码干什么的?

这个知道,route表和arp表,子网掩码区分网络号和主机号,若网络号一致,表明在一个网段

10.gdb怎么调试段错误

没怎么用过,面试官说用backtrace

11.C和Python比较

水过,python方便,c执行效率高

12.中断的上部和下部(没听过啊)

真不知道,听都没听过啊

总结:由于linux组做的都是驱动方面的,所以问的可能比较深,很多都没用过,没听过,估计悲剧,所以还是尽量深的去学习研究吧,不然怎么坑蒙拐骗面试官~

Mongodb学习整理之内存映射机制

tinyfisher 发表于 2013-09-21

sql数据库在数据量达到百万级的时候性能直线下降,在建立索引的表上做一个条件查询甚至达到分钟级别查询时间,这是无法忍受的,瓶颈在于大量的磁盘i/o操作,而这些i/o操作无疑使很耗费时间的。mongodb之所以对海量数据的查询如此高效,是因为他使用了内存映射机制,避免了大量的磁盘i/o,从而大大提高了查询效率,但相应的对内存要求也比较高。ok,下面我们来看看什么是内存映射机制

官网的说法:

What are memory mapped files?

A memory-mapped file is a file with data that the operating system places in memory by way of the mmap() system call. mmap() thus maps the file to a region of virtual memory. Memory-mapped files are the critical piece of the storage engine in MongoDB. By using memory mapped files MongoDB can treat the contents of its data files as if they were in memory. This provides MongoDB with an extremely fast and simple method for accessing and manipulating data.

How do memory mapped files work?

Memory mapping assigns files to a block of virtual memory with a direct byte-for-byte correlation. Once mapped, the relationship between file and memory allows MongoDB to interact with the data in the file as if it were memory.

How does MongoDB work with memory mapped files?

MongoDB uses memory mapped files for managing and interacting with all data. MongoDB memory maps data files to memory as it accesses documents. Data that isn’t accessed is not mapped to memory.

What are page faults?

Page faults will occur if you’re attempting to access part of a memory-mapped file that isn’t in memory.

If there is free memory, then the operating system can find the page on disk and load it to memory directly. However, if there is no free memory, the operating system must:

find a page in memory that is stale or no longer needed, and write the page to disk.

read the requested page from disk and load it into memory.

This process, particularly on an active system can take a long time, particularly in comparison to reading a page that is already in memory.

我的理解:

首先,“映射”这个词,就和数学课上说的“一一映射”是一个意思,就是建立一种一一对应关系,在这里主要是只硬盘上文件的位置与进程逻辑地址空间中一块大小相同的区域之间的一一对应(按字节对应),如过程1所示。这种对应关系纯属是逻辑上的概念,物理上是不存在的,原因是进程的逻辑地址空间本身就是不存在的。在内存映射的过程中,并没有实际的数据拷贝,文件没有被载入内存,只是逻辑上被放入了内存,这个过程由系统调用mmap()实现,所以建立内存映射的效率很高。

hello
既然建立内存映射没有进行实际的数据拷贝,那么进程又怎么能最终直接通过内存操作访问到硬盘上的文件呢?那就要看内存映射之后的几个相关的过程了。

mmap()会返回一个指针ptr,它指向进程逻辑地址空间中的一个地址,这样以后,进程无需再调用read或write对文件进行读写,而只需要通过ptr就能够操作文件。但是ptr所指向的是一个逻辑地址,要操作其中的数据,必须通过内存管理单元MMU将逻辑地址转换成物理地址,如图1中过程2所示。这个过程与内存映射无关。

前面讲过,建立内存映射并没有实际拷贝数据,这时,MMU在地址映射表中是无法找到与ptr相对应的物理地址的,也就是MMU失败,将产生一个缺页中断,缺页中断的中断响应函数会在swap中寻找相对应的页面,如果找不到(也就是该文件从来没有被读入内存的情况),则会通过mmap()建立的映射关系,从硬盘上将文件读取到物理内存中,如图1中过程3所示。这个过程与内存映射无关。

如果在拷贝数据时,发现物理内存不够用,则会通过虚拟内存机制(swap)将暂时不用的物理页面交换到硬盘上,如图1中过程4所示。这个过程也与内存映射无关。

所以当mongodb读取数据库文件的时候,首先做内存映射,读取文件变成了读取内存操作,所以mongodb的查询效率相当高,当然,如果你的内存不够大,经常发生缺页中断,那么效率会大打折扣了

ICAP RFC3507 部分章节翻译

tinyfisher 发表于 2013-09-21

之前项目中用到了icap协议,成功实现了对http数据包的内容修改,增加等功能,现将一些协议中一些字段进行总结,参考了RFC3507,ok,让我们首先看一个icap报文

REQMOD  icap://127.0.0.1:1344/greasyspoon_req ICAP/1.0\r\n       
Host:127.0.0.1:1344\r\n                                     
Date:Wed, 08 May 2013 15:47:28 GMT\r\n                         
Encapsulated:req-hdr=0, null-body=336\r\n                                                      
Preview:0\r\n                                                    
Allow:204\r\n                               
\r\n                                     
GET   http://202.168.1.13/1.html HTTP/1.1\r\n                  
Host:   202.168.1.13\r\n                          
User-Agent:  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 
Firefox/17.0\r\n                        
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n  
Accept-Language:   en-US,en;q=0.5\r\n                  
Accept-Encoding:   gzip, deflate\r\n                    
Referer:  http://202.168.1.13/support.html\r\n                    
\r\n

其中1到7行为icap头,剩下的是我们常见的http头,我们一条一条看一下:
第一行中REQMOD表示icap工作在请求模式,icap还有一种模式叫RESPMOD,意思是工作在响应模式,简单的说,请求模式主要针对http请求报文进行匹配修改增值,响应模式主要针对http响应报文进行匹配修改增值icap://127.0.0.1:1344/greasyspoon_req ICAP/1.0说的是资源url和版本号1.0,其中greasyspoon是指icap服务器的具体名称,icap服务器还有c-icap等。
hostdate这里就不详细说了
Encapsulated:req-hdr=0, null-body=336\r\n 说的是封装了http请求包,http头偏移量为0,这个请求包只有头,没有body,所以null-body=336,336是指body的偏移量;如果有请求包的body的话,例如post消息,会出现下面的情况:
Encapsulated: req-hdr=0, req-body=412,意思是头偏移长度0,bdoy偏移长度为412,通过这个可以得到http头和消息体的开始位置,总结一下,Encapsulated这个字段主要用来定位http消息的header和body。

再来看preview字段的用途,首先看一下RFC3507中对他的描述:

ICAP REQMOD or RESPMOD requests sent by the ICAP client to the ICAP server may include a "preview". This feature allows an ICAP server to see the beginning of a transaction, then decide if it wants to opt-out of the transaction early instead of receiving the remainder of the request message.   

翻译如下:icap客户端发送给服务端的REQMOD或者RESPMOD请求可能包含“preview” 字段,它能让icap服务端看到事务的最开始的一些信息,从而决定是否直接退出这个事务,而不是等到将所有的请求信息接收完毕再做判断。说白了就是预览icap封装消息body的前n个字节,来判断是否对这个消息进行处理,而不是接收完所有消息再判断。举个例子(RFC上的):

If an ICAP server wants to transcode all GIF87 files into GIF89 files, then the GIF87 files could quickly be detected by looking at the first few body bytes of the file.   翻译:如果icap服务器想要把所有gif87的文件转码成gif89文件,gif87的文件可以通过body的前几行检测出来。

这里由于我们的包里只有http header,没有http body,所以preview为0

最后Allow:204,我们先看看RFC上怎么说:
An ICAP client MAY include “Allow: 204” in its request headers,indicating that the server MAY reply to the message with a “204 NoContent” response if the object does not need modification.

If an ICAP server receives a request that does not have "Allow: 204",it MUST NOT reply with a 204. In this case, an ICAP server MUST return the entire message back to the client, even though it is identical to the message it received.

翻译:”Allow: 204”是可选的,加上这个选项表示:如果这个包不需要处理,则服务器返回”204 NoContent”给客户端,如果不加这个选项,服务器绝不会返回204,而是将整个消息返回给客户端
总结一下:这个allow:204主要是真针对不需要处理的数据包进行简单返回状态码204,从而减少了icap服务器和客户端的工作量

ok,到这里我们基本分析了icap的请求包,再来看看,icap服务器的返回包:

ICAP/1.0 200 OK\r\n 
ISTag:"GreasySpoon-1.0.8-01"\r\n                   
Host:0.0.0.0:1344\r\n                         
Encapsulated:req-hdr=0, null-body=333\r\n                 
Connection:close\r\n                          
\r\n                                     
GET http://202.168.2.34/2.html HTTP/1.1\r\n                 
Host:202.168.2.34\r\n                          
User-Agent:  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 
Firefox/17.0\r\n                         
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n     
Accept-Language:   en-US,en;q=0.5\r\n                   
Accept-Encoding:   gzip, deflate\r\n                     
Referer:http://202.168.1.13/support.html\r\n                   
\r\n                                     

前6行为icap响应包头,下面的是修改后的http请求,可以看到GET http://202.168.2.34/1.html HTTP/1.1\r\n改成了GET http://202.168.2.34/2.html HTTP/1.1\r\n,我们成功修改了http请求。下面具体看一下响应包的各个字段:

ICAP/1.0 200 OK\r\n 说的是icap的返回状态码200,表示http请求已经被成功修改,类似于http状态码200

ISTag(ICAP Service Tag)说的是我们用的icap service的具体名称和版本号,我们这里用的是greasyspoon

hostEncapsulated不再赘述了

Connection字段和http协议的connection一样,含义是当client和server通信时对于长链接如何进行处理。在http1.1中,client和server都是默认对方支持长链接的, 如果client使用http1.1协议,但又不希望使用长链接,则需要在header中指明connection的值为close;如果server方也不想支持长链接,则在response中也需要明确说明connection的值为close.

不论request还是response的header中包含了值为close的connection,都表明当前正在使用的tcp链接在当天请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的tcp链接了。

顺便再复习一下http报文里的各个字段的含义:

1、 Accept:告诉WEB服务器自己接受什么介质类型,/ 表示任何类型,type/* 表示该类型下的所有子类型,type/sub-type。

2、 Accept-Charset: 浏览器申明自己接收的字符集

Accept-Encoding: 浏览器申明自己接收的编码方法,通常指定压缩方法,是否支持压缩,支持什么压缩方法(gzip,deflate)

Accept-Language::浏览器申明自己接收的语言

语言跟字符集的区别:中文是语言,中文有多种字符集,比如big5,gb2312,gbk等等。

3、 Connection:请求:close(告诉WEB服务器或者代理服务器,在完成本次请求的响应后,断开连接,不要等待本次连接的后续请求了)。

keepalive(告诉WEB服务器或者代理服务器,在完成本次请求的响应后,保持连接,等待本次连接的后续请求)。

响应:close(连接已经关闭)。

keepalive(连接保持着,在等待本次连接的后续请求)。

Keep-Alive:如果浏览器请求保持连接,则该头部表明希望 WEB 服务器保持连接多长时间(秒)。例如:Keep-Alive:300

4、 Host:客户端指定自己想访问的WEB服务器的域名/IP 地址和端口号。例如:Host:rss.sina.com.cn

5、 Referer:浏览器向 WEB 服务器表明自己是从哪个 网页/URL 获得/点击 当前请求中的网址/URL。例如:Referer:http://www.sina.com/

6、 Server: WEB 服务器表明自己是什么软件及版本等信息。例如:Server:Apache/2.0.61 (Unix) 7、 User-Agent: 浏览器表明自己的身份(是哪种浏览器)。例如:User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2、0、0、14

阿里巴巴面试总结

tinyfisher 发表于 2013-09-20

15号接到阿里通知,18号上午去面试,研究生期间第一次面试,颇为激动,准备了一番,18号去了大望路那里。前台签到后,在大厅等了一会,面试官拿着我的简历叫我跟他走,到了一个会议室,里面人很多,面试官的花名叫易统,阿里每个人都有花名,武侠风浓烈,马云的花名叫风清扬。。。易统说欢迎来面试,让我自我介绍,期间点开了我的blog- -

后来主要是围绕简历上写得项目的技能,做了一些提问,主要是我在说,面试官如果感兴趣会深入问下去。时间在一个小时左右,易统十分友好,没有什么压力,问的问题待会详细记录。最后易统说今天的面试就到这里,让我回去了,我想完蛋了,因为之前得知如果面的好会直接二面的,看来是面挂了,而我自我感觉还不错,后来细想想,可能某些问题回答的不够深入,要反思了。问题总结如下:

tcp/ip三次握手

这个基本是滥问题了,答得还不错
####tcp有哪些机制保证了他的可靠性
这个答得不够好,这里总结下:

可靠性包括以下几个方面:

1.能够处理数据传输过程中被破坏问题。

2.能够处理重复数据接收问题。

3.能够发现数据丢失以及对此进行有效解决。

4.能够处理接收端数据乱序到达问题。

怎么保证解决上述问题?

TCP协议规范和当前绝大多数TCP 协议实现代码均采用数据重传和数据确认应答机制来完成TCP 协议的可靠性数据传输。数据超时重传和数据应答机制的基本前提是对每个传输的字节进行编号,即我们通常所说的序列号。数据超时重传是发送端在某个数据包发送出去,在一段固定时间后如果没有收到对该数据包的确认应答,则(假定该数据包在传输过程中丢失)重新发送该数据包。而数据确认应答是指接收端在成功接收到一个有效数据包后,发送一个确认应答数据包给发送端主机,该确认应答数据包中所包含的应答序列号即指已接收到的数据中最后一个字节的序列号加1,加1 的目的在于指出此时接收端期望接收的下一个数据包中第一个字节的序列号。数据超时重传、数据确认应答以及对每个传输的字节分配序列号是TCP 协议提供可靠性数据传输的核心本质。

1.解决数据传输中被破坏的问题

首先通过对所接收数据包的CRC校验,确认该数据包中数据是否存在错误。如果有,则简单丢弃或者发送一个应答数据包重新对这些数据进行请求。发送端在等待一段时间后,则会重新发送这些数据。本质上,数据传输错误的解决是通过数据重传机制完成的。

2.解决重复数据接收问题
接到数据包之后,查看序列号,如果数据包已经接收过,则丢弃该数据包,返回确认信息,主要是通过序列号解决这个问题

3.解决数据丢失问题
主要依靠tcp的重传机制来解决。TCP通过在发送数据报文时设置一个超时定时器来解决这种问题,如果在定时器溢出时还没有收到来自对端对发送报文的确认,它就重传该数据报文。

4.解决乱序问题
如果通信双方存在多条传输路径, 则有可能出现数据乱序问题,即序列号较大的数据先于序列号较小的数据到达,而发送端确实是按序列号由小到大的顺序发送的。数据乱序的本质是数据都成功到达了,但到达的顺序不尽如人意。对于收到的乱序报文并不丢弃,而是缓存下来(这样做是为了减少更多的重传),立即发送希望接受的报文确认。对这个问题的解决相对比较简单,只需对这些数据进行重新排序即可。本质上,对数据乱序问题的解决是通过排序数据序列号完成的。

syn flood 攻击

由于是安全专业的,面试官又问了我这个问题,答得一般,总结如下:

什么是synflood?

在TCP连接的三次握手中,假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源—-数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃—即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小),此时从正常客户的角度看来,服务器失去响应,这种情况我们称作:服务器端受到了SYN Flood攻击(SYN洪水攻击)。

怎么检测Syn flood?

1、服务端无法提供正常的TCP服务。连接请求被拒绝或超时;

2、通过 netstat -an 命令检查系统,发现有大量的SYN_RECV连接状态。

如何防范?

1.缩短SYN- Timeout时间

2.设置每秒最多3个syn封包进入

查看Linux CPU使用率命令

top

查看进程信息

ps -aux

vim从100到200行替换字符串

:100,200s/vivian/sky/g

总结:简历上写的尽量往深处了解,面试官可能追问具体的机制,例如我用到的几个工具,fluentd,mongodb,我只是简单的使用,不清楚里面的实现机制,往往不能令面试官满意。面试失败的还有一个原因是简历上写的一定是自己非常了解的,不是很懂的还是不要往上写了,或者写了赶紧去补功课,路漫漫其修远兮,找工作是一个虐心的过程,相信经过不断的积攒经验,一定能够拿到满意的offer,下一站:创新工场23号面试,加油!

Mongodb 学习整理之安装

tinyfisher 发表于 2013-07-15

下载

下载MongoDB,此处下载的版本是:mongodb-linux-i686-1.8.1.tgz.tar

安装

step1:解压文件到某目录下,然后重命名:

[root@localhost src]# tar -xzvf mongodb-linux-i686-1.8.1.tgz.tar    
[root@localhost src]# mv mongodb-linux-i686-1.8.1 /usr/local/mongodb/  

step2:查看安装后的文件情况:

[root@localhost src]# cd /usr/local/mongodb/   
[root@localhost mongodb]# ls   
bin  GNU-AGPL-3.0  README  THIRD-PARTY-NOTICES   
[root@localhost mongodb]# cd bin/   
[root@localhost bin]# ls   
bsondump  dbbak  mongo  mongod  mongodump  mongoexport  mongofiles  mongoimport  mongorestore mongos  mongosniff  mongostat    

bin下的mongod就是MongoDB的服务端进程,mongo就是其客户端,其它的命令用于MongoDB的其它用途如MongoDB文件导出等。

step3:启动MongoDB:

要先建立好MongoDB 存放数据文件和日志文件的目录,需要手动建立:

mkdir /data/mongodb_data
mkdir /data/mongodb_log
touch /data/mongodb_log/mongodb.log
[root@localhost etc]# cd /data/   
[root@localhost data]# ls   
mongodb_data  mongodb_log    

在MongoDB安装目录下的bin下使用mongod启动MongoDB

./mongod --dbpath=/data/mongodb_data/ --logpath=/data/mongodb_log/mongodb.log --logappend&  

等待启动成功后,可查看是否启动成功了,默认端口号是27017,当然在启动时也可以指定未使用的其它端口。先通过查看端口号看MongoDB是否启动了。

[root@localhost data]# netstat -lanp | grep "27017"  
tcp   0    0 0.0.0.0:27017      0.0.0.0:*     LISTEN      1573/mongod            
unix  2  [ ACC ]    STREAM   LISTENING    5874  1573/mongod   /tmp/mongodb-27017.sock    

可以看到,已启动成功,现在使用mongo客户端访问一下该数据库。

[root@localhost bin]# cd /usr/local/mongodb/bin/   
[root@localhost bin]# ./mongo   
MongoDB shell version: 1.8.1  
connecting to: test   

到这一步说明已经安装成功了。

额外工作

注意,上述我们启动MongoDB都是手动使用mongod来启动,这样关闭计算机后,下次再进来它又没启动了,所以还得手动启动,因此,为避免这种繁琐的工作,可以把mongod放到服务自启动项中,这样计算机一开启mongod服务也就启动了。编辑/etc/rc.local,加入下述代码然后再保存即可。 (也可以写一个脚本,然后开机自动运行)

#add mongonDB service   
/usr/local/mongodb/bin/mongod --dbpath=/data/mongodb_data/ --logpath=/data/mongodb_log/mongodb.log --logappend&    

或者编写开机自启动脚本start_mongodb.sh

cd /usr/local/mongodb-linux-i686-2.2.1/bin  //具体版本具体变化
./mongod --dbpath=/data/mongodb_data/ --logpath=/data/mongodb_log/mongodb.log --logappend&   

路径和你设置mongodb的datapath,logpath一致 我们重启计算机再看MongoDB是否启动,重启后可以直接使用 mongo命令登录,最终发现是可以成功的。

另外,我们使用mongo命令登录 MongoDB还要转到mongo命令所在目录再执行./mongo,这样是不是有些麻烦?因此,我们可以简化这点,将该命令文件copy到/usr/bin下,这样就可以在任何目录下使用mongo命令了。

[root@localhost bin]# ls   
bsondump  dbbak  mongo  mongod  mongodump  mongoexport  mongofiles  mongoimport  mongorestore mongos  mongosniff  mongostat   
[root@localhost bin]# cp mongo /usr/bin/    

转到任一目录试下mongo命令:

[root@localhost bin]# cd /   
[root@localhost /]# mongo   
MongoDB shell version: 1.8.1  
connecting to: test   

可以看到登录成功了,说明我们可以像使用ls命令一样使用mongo命令了。

安装图形化界面

mongoDB有许多图形化操作软件,我使用的是UMongo:

下载Umongo,解压文件,在终端运行launch-umongo.sh脚本文件即可

ok,至此我们已经安装好了MongoDB~