C++抛exception会主动让出CPU吗?

September 10th, 2014 No comments

虽然我自己并不是很喜欢使用exception.但是在有的场合用exception比return code让代码更具可阅读性.一直以来,我都认为throw exception不会大幅度降低程序的性能, 但是最近线上发生的一件事情却把exception这个东西牵扯了进来.
事情很简单, 现场报说有的请求timeout(500ms超时). 查看log以后发现一部分代码可能造成这个问题,但是当时并无法肯定是哪一个调用造成的耗时长. 后来做了一系列的实验以后发现居然是一个查找部分的代码会很耗时(最长可达1s), 但是这个查找的代码的实现及其的简单.基本上就是这个样子:

void findXXX( ) {
    find in a std::map<std::string, std::string> instance;
    if not found {
        throw InvalidParameter();
    }
}

而当时的情况是, map中是没有数据的,也就是说一定会出发抛出异常. 开始我怎么都觉得throw exception会那么耗时.可是多次的测试下来却发现总是在这个点上可能耗时很长.那么无论如何这个抛异常看起来都有点问题.
于是我做了一个小程序,就是很简单的抛异常100w次.但是没有发现耗时很长的情况发生(至少和我预期是一样的). 那么为何线上程序总是在这个抛异常的地方出现问题呢? 于是对比了自己的模拟程序和线上程序,发现了一个很大的不同点,那就是线上程序是多线程的,而且线程相当多(500+),而我的测试程序是单线程的.那么有没有可能是抛异常会导致线程切换,最终引发耗时长呢?
于是我修改了一下测试程序,加入线程,线程run里面就是不断的++一个long long,过一会儿sleep 30ms. 我一共new了800个线程(我也是够猛的). 这次测试程序我做了两个版本,一个是抛异常的,另外一个是不抛异常,取而代之的是循环++10次,然后return的.
从这两个版本的测试结果来看,在同一个环境(CentOS5, 4core cpu, 16G mem)上测试10次,平均下来,抛异常的版本运行时间为26s,而不抛异常的版本运行时间为1.5s左右. 同时抛异常的版本中能监测到有很50+次调用函数耗时达1ms以上的.而不抛异常的版本平均只有2次不到.
基于这些测试, 我猜测很可能抛异常会引发context switch. 同时由于线程数量巨大,线程切换十分频繁. 最终造成这个简单的findXXX耗时很大.
当然了,这个只是我的猜测,没有证实. 希望以后可以继续看看是不是真的造成了主动的线程切换.

PS: google了好一阵, 还没有直接证据可以证明throw exception可能导致线程上下文切换. 以后有空倒是可以看看libstdc++的实现.

Categories: programming Tags: ,

一个简单的rolling filelog,written in go

August 29th, 2014 No comments

使用了go-logging但是发现它只有logging format部分,没有数据输出部分(直接使用os.File进行输出). 所以自己做了一个简单的rolling file log. 可以设置保留的log文件个数,每一个log文件的最大字节数,强制flush的时间间隔.
使用方法如下:

func main() {
    l := rolling_filelog.LogFile{BaseName: "./test.log",
                MaxSize: 5*1024*1024,
                FileCount: 10,
                FlushInterval: 2*time.Second,
                BufferSize: 10*1024,
                BufferCount: 3}
    err := l.Open()
    if err != nil {
        fmt.Printf("failed to open log file,%s: %s\n", l.BaseName, err)
        return
    }
    data := make([]byte,10)
    copy(data[:],"1234567890")

    for i := 0 ; i < 10000000; i ++ {
        n,err := l.Write(data)
        if err != nil {
            fmt.Printf("failed to write data to %s :%s\n", l.BaseName, err )
            return
        }
        if n <= 0 {
            fmt.Printf("failed to write data to %s : %s\n", l.BaseName, "0 bytes written")
            return
        }
    }
    l.Close()

当然了,这个是用作其他logging的backend的,例go-logging

 logFile := utils.LogFile{BaseName: "./test.log",
                MaxSize: 8*1024,
                FileCount: 3,
                FlushInterval: 2*time.Second,
                BufferSize: 1*1024,
                BufferCount: 3}
    if logFile == nil {
        fmt.Println("failed to open log file")
        return nil
    }

    logger := logging.MustGetLogger("")
    if logger == nil {
        logFile.Close()
        return nil
    }

    logging.SetFormatter(logging.MustStringFormatter(" %{level:.4s} %{message}"))
    logBackend := logging.NewLogBackend( logFile, "", stdlog.LstdFlags|stdlog.Lmicroseconds)
    logging.SetBackend(logBackend)
    logging.SetLevel(logging.INFO,"")

这样以来, 日志文件就会保持在FileCount指定的数量上滚动, 以防止日志文件的无限制增长而吃光存储空间.

Categories: programming Tags: , ,

不要随意设置SO_LINGER为0

August 26th, 2014 No comments

我们的一个应用频繁的使用http协议传输数据, 由于一开始没有使用keep-alive. 导致server端有大量的TIME_WAIT的socket, 当时server端的解决办法是设置SO_LINGER为{l_onoff=1,l_linger=0}.这样close的时候就会直接发送RST而不是FIN,绕过了TIME_WAIT这个状态. 经过一些简单测试,看起来是解决了TIME_WAIT的问题. 但其实这样做是非常不妥的.
当设置SO_LINGER=0以后,我们调用close, tcp会直接丢弃当前在write buffer中的数据,而直接发送RST到对端. 那么意味着如果你在调用close的时候,不管何种原因导致write buffer还有数据没有被发送的话,那么对端将无法接收到完整的数据.
我们来看看linux是如何处理close的

void tcp_close(struct sock *sk, long timeout)
{
       ...

       while ((skb = __skb_dequeue(&sk->sk_receive_queue)) != NULL) {
                u32 len = TCP_SKB_CB(skb)->end_seq - TCP_SKB_CB(skb)->seq -
                          tcp_hdr(skb)->fin;
                data_was_unread += len;
                __kfree_skb(skb);
        }

        sk_mem_reclaim(sk);

        ...

         if (data_was_unread) {
                /* Unread data was tossed, zap the connection. */
                NET_INC_STATS_USER(sock_net(sk), LINUX_MIB_TCPABORTONCLOSE);
                tcp_set_state(sk, TCP_CLOSE);
                tcp_send_active_reset(sk, sk->sk_allocation);
        } else if (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime) {
                /* Check zero linger _after_ checking for unread data. */
                sk->sk_prot->disconnect(sk, 0);
                NET_INC_STATS_USER(sock_net(sk), LINUX_MIB_TCPABORTONDATA);
        } else if (tcp_close_state(sk)) {

            ...
            tcp_send_fin(sk);
        }
        ...
}

int tcp_disconnect(struct sock *sk, int flags)
{
        /* ABORT function of RFC793 */
        if (old_state == TCP_LISTEN) {
                inet_csk_listen_stop(sk);
        } else if (tcp_need_reset(old_state) ||
                   (tp->snd_nxt != tp->write_seq &&
                    (1 << old_state) & (TCPF_CLOSING | TCPF_LAST_ACK))) {
                /* The last check adjusts for discrepancy of Linux wrt. RFC
                 * states
                 */
                tcp_send_active_reset(sk, gfp_any());
                sk->sk_err = ECONNRESET;
        } else if (old_state == TCP_SYN_SENT)
                sk->sk_err = ECONNRESET;
        ...
         tcp_clear_xmit_timers(sk);
        __skb_queue_purge(&sk->sk_receive_queue);
        tcp_write_queue_purge(sk);
        __skb_queue_purge(&tp->out_of_order_queue);
        ...
}

void tcp_send_active_reset(struct sock *sk, gfp_t priority)
{
        struct sk_buff *skb;

        /* NOTE: No TCP options attached and we never retransmit this. */
        skb = alloc_skb(MAX_TCP_HEADER, priority);
        if (!skb) {
                NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTFAILED);
                return;
        }

        /* Reserve space for headers and prepare control bits. */
        skb_reserve(skb, MAX_TCP_HEADER);
        tcp_init_nondata_skb(skb, tcp_acceptable_seq(sk),
                             TCPCB_FLAG_ACK | TCPCB_FLAG_RST);
        /* Send it off. */
        TCP_SKB_CB(skb)->when = tcp_time_stamp;
        if (tcp_transmit_skb(sk, skb, 0, priority))
                NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTFAILED);

        TCP_INC_STATS(sock_net(sk), TCP_MIB_OUTRSTS);
}
void tcp_send_fin(struct sock *sk)
{
        ...
       if (tcp_send_head(sk) != NULL) {
                TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_FIN;
                TCP_SKB_CB(skb)->end_seq++;
                tp->write_seq++;
        } else {
                ...
                tcp_queue_skb(sk, skb);
        }
        __tcp_push_pending_frames(sk, mss_now, TCP_NAGLE_OFF);
}

在这里的代码, 从tcp_close里面可以看到,

  1. 在close的时候如果socket上还有数据没有被读取,那么会直接调用tcp_send_active_reset发送RST到对端.
  2. 如果设置linger为0,那么调用disconnect函数,在这里是tcp_disconnect
  3. 第三种情况会调用tcp_send_fin
    tcp_diconnect也会调用 tcp_send_active_reset函数(我们只关心established的socket的close). 而我们看看tcp_send_active_reset可以发现它是直接发送RST包,也就是并没有把数据包加入到sending window里面.调用完tcp_send_active_reset以后我们回到tcp_disconnect函数,可以发现这是socket的write buffer已经清空.当然这个动作对于对端来说没法意义,因为对端已经收到RST了.
    对于调用tcp_send_fin的情况,就是完全不一样的情景了.在tcp_send_fin里面要么给未flush的数据加上FIN标志,要么生成一个新的FIN数据包,加入到write队列中. 然后强制发送当前未发送的数据.

所以特别是对于发送数据的一段,不要轻易的设置SO_LINGER=0,否则有一定的概率出现对端收不到完整的数据的情况. 而应该使用长连接(keep-alive)并且由数据接收端来判断数据是否接受完整从而决定是否关闭连接

Categories: programming Tags: , , ,

daemon平滑升级

March 15th, 2014 No comments

对于socket server来说,平滑升级对于用户体验是一个很好的加分。这样可以不对用户操作造成任何影响。而平滑升级的最直接最核心的应该就是不在升级的过程中关掉listen端口,也不断掉当前的连接,同时还可以接受新的连接,所有的已被接受的请求必须要完整的执行完毕,不能因为升级步骤而终止.

为了到达以上几点,一般来说可以如下来达到平滑升级的目的。
1. 分区域升级。 首先在总控部分,禁掉某些部分server接受新请求的能力。然后等待这些server的当前请求全部执行完毕以后开始升级这些server上的服务。采用这种方法逐步升级所有的server
2. 采用类似nginx的平滑升级的方法。

第一种方法对于那些直接面对客户端的server是行不通的,因为一旦停掉一会儿,客户端就无法正常连接了。还有就是即便是分布式的后台加上一个proxy, 也可能会因为某些特定的请求很难在短时间内完成而无法升级(例如,一个广播流的频道请求),对于这些特定的就需要在指定的维护窗口时间强行升级服务了。
第二种方法看起来比较的容易接受。google了一下nginx的平滑升级的办法。其主要使用到了如下几点技术:

1. 未设置FD_CLOEXEC 属性的文件描述符在fork以后会被child process继承,一般来说除了listen socket和log以外的fd都会设置这个属性
2. 把需要在child process里面使用的文件描述符通过env或者命令行参数在调用execv的时候传入新的process
3. 在启动child process之前,停止accept新的请求。
4. parent process一直服务到所有的请求执行完毕以后正常退出。
5. child process在收到传入的文件描述符(通常是用于listen的那个socket的fd)以后使用这个fd来做accept操作。

这个方法解决了socket连接的平滑升级,但是对于log的问题,我还不是特别肯定。如果parent process和child process都是用同一个log文件的描述符,那么必然会造成打印出的日志是混乱的。当然如果你的日志写入是严格按照一个信息块的方式写入的话(也就是不是几个字节几个自己的写入),而vfs_write又是对inode加锁的,那么虽然会有parent process和child process的日志混杂在一起,但是每一条日志内容本身应该是有完整信息的。(这个还需要核实)。

在这里有相关的测试代码

 

Written with StackEdit.

Categories: programming Tags:

program killed by signal 4

March 4th, 2014 No comments

一个跑在linux上的程序crash了,coredump的文件名显示是被signal 4干掉的。哎呀,第一次见到signal 4. 赶紧kill -l看了一下,原来4是指SIGILL,就是invalid instruction. 一般来说我会认为这个东西是stack buffer overflow。 对我们自己的程序来说最可能出错的地方就是打印日志的时候参数类型和format里面指定的类型不一致。特别是fmt=”%s”但是传入了一个sd::string。但是我记得以前这种问题貌似都不会是SIGILL,要么SIGABORT要么SIGSEGV。那么这次是咋回事呢。

上gdb,同时把symbol文件放上去了。看了一下callstack。



(gdb) bt

0x00000000004ab9cc in waitForResponse (this=0x7f12e80804d8, cseq=2)

0x0000000000525920 in SsServiceImpl::doCommit (ss=..., ctx=..., )

0x0000000000570ecd in SsStreamCommitRequest::run (this=0x7f125c001330)

0x00007f12f51318ca in SlaveThread::run (this=0x7f12e80260d0)

0x00007f12f5120fc2 in NativeThread::_execute (thread=0x7f12e80260d0)

0x00007f12f2dba851 in start_thread () from /lib64/libpthread.so.0

0x00007f12f30b767d in clone () from /lib64/libc.so.6

其中waitForResponse里面主要是等待一个信号量。检查其代码没有发现啥问题,而且该函数内部没有任何日志打印的调用。

在老半天没有进展的境况下,我尝试着看了一下反汇编的结果



(gdb) set disassembly-flavor intel

(gdb) disas

...

   0x00000000004ab9ca <+256>:   leave

   0x00000000004ab9cb <+257>:   ret

=> 0x00000000004ab9cc <+258>:   ud2a

   0x00000000004ab9ce <+260>:   mov    ebx,edx

   0x00000000004ab9d0 <+262>:   mov    r12,rax

   0x00000000004ab9d3 <+265>:   lea    rax,[rbp-0x40]

箭头所指的地方就是crash的点,但是,但是ud2a是个神马玩意儿,对汇编不甚了解啊。

还是求助于google大神吧。

一阵瞎找以后看到了这篇文章里面解释了gcc在遇到format里面的参数类型和传入参数类型不匹配的时候报了warning,但是同时可能会产生出ud2a之类的代码,让程序在运行时挂掉。

例如:



struct A {

    int a,b,c,d;

};

A a;

log.info("What a stupid error [%p]",a);

呵呵,我们的代码中就犯了这样的错误。

修改以后让同事们多加注意代码问题以及build时候的warning.



t.c:9:2: warning: format ‘%p’ expects argument of type ‘void *’, but argument 2 has type ‘struct AA’ [-Wformat=]

  log.info("What a stupid error [%p]\n",a);

  ^

Written with StackEdit.

Categories: Uncategorized Tags:

go的测试程序,与预期不符合。不知道是哪里理解不正确了

March 1st, 2014 No comments

在学习go的时候,按照[go语言编程]第94页的例子写了一个测试程序,如下

package main
import  (
    "fmt"
)
func Count( ch chan int, value int ) {
    ch <- value
    fmt.Println("Counting")
}
func main( ) {
    chs :=make( []chan int, 10 )
    for i := 0; i < 10; i++ {
        chs[i] = make(chan int) //请注意这一行
        go Count(chs[i],i)
    }
    var value int
    for _, ch := range(chs) {
        value = <-ch
        fmt.Printf("got value %d\n",value)
    }
}


但是运行的时候发现结果与我预期的不一样。本来我认为这个程序会打印10行Counting, 但实际上只有1行Counting出现。
于是我把标示那一行改成

chs[i] = make(chan int,1)

就这样,运行的时候就可以打印出10行Counting来了。是在不明白这个到底是咋回事啊。
继续修改有标示的那一行发现,如果make( chan int, 0 )或者make( chan int)那么就只会打印一行Counting.如果make的第二个参数>= 1,那么就会如预期一般打印10行Counting.
这让我更加糊涂了,按照书上所讲。make( chan int, x)的方式是建立一个有缓冲区且大小为x的channel。而且测试程序始终能够输出如下:

got value 0
got value 1
got value 2
got value 3
got value 4
got value 5
got value 6
got value 7
got value 8
got value 9

 

那么至少代表建立的10个 go routine是开始执行了的。看起来当make( chan int, 0)的时候只有一个Count的go routine在向channel写入数据以后被切换回去继续执行了,而剩下的Count的go routine都没有得到执行机会。不过这个不能解释为何make( chan int, x) x >=1 的时候所有的go routine就都机会执行完毕了。

嗯,我的go的版本是:

$ go version
go version go1.2 linux/amd64

Written with StackEdit.

Categories: programming Tags: ,

为何多线程程序占用这么多内存(linux)(续)

January 26th, 2014 2 comments

上一篇文章指出了在Centos6.4 x86_64下面多线程程序会相当占用内存资源。经过一番google和代码查看。终于知道了原来是glibc的malloc在这里捣鬼。请看developerworks该文章指出在glibc 2.10以上的版本会有这个问题,我的glibc版本是2.12

lrwxrwxrwx 1 root root 12 Oct 21 21:29 /lib64/libc.so.6 -> libc-2.12.so

glibc为了分配内存的性能的问题,使用了很多叫做arena的memory pool,缺省配置在64bit下面是每一个arena为64M,一个进程可以最多有 cores * 8个arena。假设你的机器是4核的,那么最多可以有4 * 8 = 32个arena,也就是使用32 * 64 = 2048M内存。 当然你也可以通过设置环境变量来改变arena的数量.例如export MALLOC_ARENA_MAX=1
hadoop推荐把这个值设置为4。当然了,既然是多核的机器,而arena的引进是为了解决多线程内存分配竞争的问题,那么设置为cpu核的数量估计也是一个不错的选择。设置这个值以后最好能对你的程序做一下压力测试,用以看看改变arena的数量是否会对程序的性能有影响。

后记:如果你打算在程序代码中来设置这个东西,那么可以调用mallopt(M_ARENA_MAX, xxx)来实现,不过很奇怪的是我在centos6.4上面居然看不到mallopt的man page,最后实在我的ubuntu 12.04的虚拟机上看到这个函数解释,而且里面并没有M_ARENA_MAX这个宏的解释。最后我实在glibc2.12的malloc/malloc.c的mALLOPt函数实现中才看到M_ARENA_MAX的。

Categories: programming Tags: , ,

记一个subclass gevent.Greenlet遇到的问题

January 22nd, 2014 No comments

打算子类化gevent.Greenlet,大致样子如下:


from gevent import Greenlet
class Runner( Greenlet ):
  def __init__(self):
      Greenlet.__init__(self)
  def _run( self ):
      self.run() # invoke the real run

class Downloader( Runner ):
  def __init__(self):
      Runner.__init__(self)
  def run(self):
      print "processing ..."

d = Downloader()
d.start()
d.join()

结果一运行就出错了,

processing ...
Traceback (most recent call last):
  File "test.py", line 30, in <module>
    d.join()
  File "/usr/local/lib/python2.7/dist-packages/gevent/greenlet.py", line 290, in join
    result = self.parent.switch()
  File "/usr/local/lib/python2.7/dist-packages/gevent/hub.py", line 331, in switch
    return greenlet.switch(self)
gevent.hub.LoopExit: This operation would block forever

一时间没有搞懂是怎么回事,于是google了一下,但是看起来别人的问题和我这个不相关。
于是看了一下greenlet.py里面的Greenlet的时间,结果发现一个问题Greenlet里面有一个run函数。所以我这里的Downloader申明run函数以后覆盖了Greenlet本身的run,结果就出现了你看到的这个错误。 所以解决方法也很简单,就是不要用run这个名字。

Categories: programming Tags: ,

为何多线程程序占用这么多内存(linux)

January 16th, 2014 No comments

我们的应用基本都是多线程的程序,程序启动以后如果在client发起命令之前内存占用量并不大,大概在几百兆左右,但是经过一段时间的运行呢,有的进程会占用到3~4G的内存。但是继续运行下去的话也不会继续增加了。由于增长到最高点以后内存使用量没有明显的大幅攀升,所以一直也没有特别的关注这个问题。最近呢,老大要看看这个问题究竟是咋回事,于是呢,有了本文。
一开始,我认为是程序逻辑分配了这么多内存。为了证明我的观点,我首先使用了ltrace。
ltrace -f -e “malloc,realloc,calloc,free” -p pid > trace 2>&1
上面是利用ltrace来检测程序对于malloc,realloc,calloc,free的调用情况。加上-f参数是因为是多线程的程序。当然,为了查看方便,我将上述命令的结果重定向到了一个文件。
当程序运行到了一个内存高点,例如3G的时候,取出trace文件,这个时候并没有让程序退出(否则可能会有很多free的调用)。trace文件大致是这个样子的:

[pid 21161] malloc(9) = 0x1b55a40
[pid 21161] malloc(9) = 0x1b58410
[pid 21161] free(0x1b55a40) =  <void>
于是,写了一个很简单的python脚本来分析程序的内存分配释放情况。最后得到的答案出乎我的意料。程序从启动稳定在300M左右到内存最高点期间的内存分配而没有释放的总量只有200k+,远小于1M。于是乎我怀疑自己统计错了。有重复做了几遍相同的操作,得到的答案都是一样的。

在多次使用ltrace无果以后,我开始怀疑程序内部是不是用到mmap之类的调用,于是使用strace对mmap,brk等系统函数的检测:
strace -f -e “brk,mmap,munmap” -p pid > trace 2>&1
测试方法同上,运行到内存高点以后查看strace文件。文件内容大致如下:
brk(0) = 0x6fd000
mmap(NULL, 4096, PROTREAD|PROTWRITE, MAPPRIVATE|MAPANONYMOUS, -1, 0) = 0x7f77f9853000
mmap(NULL, 82462, PROTREAD, MAPPRIVATE, 3, 0) = 0x7f77f9604000
我检查了一下trace文件也没有发现大量内存mmap动作,即便是brk动作引起的内存增长也不大。
于是乎我开始没有方向了 …
后来,我开始减少thread的数量开始测试,在测试的时候偶然发现一个很奇怪的现象。那就是如果进程创建了一个线程并且该线程运行以后内存使用量就会激增。我写了一个简单的程序,大致内容如下:

void* thread_run( void* ) {
    cout << "thread running,    VM SIZE:" << memusage() << " MB" << endl;
}

int main()
{
    cout << "process running,   VM SIZE:" << memusage() << " MB" << endl;

    pthread_t th;
    pthread_create(&th, 0, thread_run, 0);
    cout << "thread created,    VM SIZE:" << memusage() << " MB" << endl;

    pthread_join( th, 0 );

    cout << "after join thread, VM SIZE:" << memusage() << " MB" << endl;

    return 0;
}

以上调用的memusage()是用来获取当前进程的virtual memory usage的函数。
在我的机器上(CENTOS 6.4,X86-64)上运行结果如下:
process running, VM SIZE:13 MB
thread created, VM SIZE:23 MB
thread running, VM SIZE:87 MB
after join thread, VM SIZE:87 MB
也就是说,程序启动以后用了13M内存,创建了一个线程以后内存使用量增加了10M(这是因为64bit上缺省的线程stack size是10M,这个可以在创建线程的时候指定)。此时线程应该还没有运行,因为当前的主线程还没有被切换掉。当线程运行起来了以后,整个process的内存使用量立马又增加了64M。而且这个增加的64M内存在线程被join以后也没有被回收。

很神奇吧,反正我是没有反应过来是咋回事。接下来,让程序停在threadrun函数里面,然后使用pmap查看进程的内存情况。pmap -x的输出情况如下:


12346: ./test
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 8 8 8 r-x-- test
0000000000602000 4 4 4 rw--- test
000000000104e000 132 8 8 rw--- [ anon ]
0000003f71800000 128 104 0 r-x-- ld-2.12.so
0000003f71a1f000 4 4 4 r---- ld-2.12.so
0000003f71a20000 4 4 4 rw--- ld-2.12.so
0000003f71a21000 4 4 4 rw--- [ anon ]
0000003f72000000 1576 324 0 r-x-- libc-2.12.so
0000003f7218a000 2044 0 0 ----- libc-2.12.so
0000003f72389000 16 16 8 r---- libc-2.12.so
0000003f7238d000 4 4 4 rw--- libc-2.12.so
0000003f7238e000 20 16 16 rw--- [ anon ]
0000003f72400000 92 68 0 r-x-- libpthread-2.12.so
0000003f72417000 2048 0 0 ----- libpthread-2.12.so
0000003f72617000 4 4 4 r---- libpthread-2.12.so
0000003f72618000 4 4 4 rw--- libpthread-2.12.so
0000003f72619000 16 4 4 rw--- [ anon ]
0000003f72c00000 524 20 0 r-x-- libm-2.12.so
0000003f72c83000 2044 0 0 ----- libm-2.12.so
0000003f72e82000 4 4 4 r---- libm-2.12.so
0000003f72e83000 4 4 4 rw--- libm-2.12.so
0000003f7f000000 88 16 0 r-x-- libgccs-4.4.7-20120601.so.1
0000003f7f016000 2044 0 0 ----- libgccs-4.4.7-20120601.so.1
0000003f7f215000 4 4 4 rw--- libgccs-4.4.7-20120601.so.1
0000003f7fc00000 928 528 0 r-x-- libstdc++.so.6.0.13
0000003f7fce8000 2048 0 0 ----- libstdc++.so.6.0.13
0000003f7fee8000 28 28 28 r---- libstdc++.so.6.0.13
0000003f7feef000 8 8 8 rw--- libstdc++.so.6.0.13
0000003f7fef1000 84 12 12 rw--- [ anon ]
00007f7e4c000000 132 8 8 rw--- [ anon ]
00007f7e4c021000 65404 0 0 ----- [ anon ]
00007f7e50c2c000 4 0 0 ----- [ anon ]
00007f7e50c2d000 10260 28 28 rw--- [ anon ]
00007f7e51645000 12 8 8 rw--- [ anon ]
00007fffbb182000 84 12 12 rw--- [ stack ]
00007fffbb1ff000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
total kB 89820 1260 188

请注意65404这一行,种种迹象表明,这个再加上它上面那一行(在这里是132)就是增加的那个64M)。后来增加thread的数量,就会有新增thread数量相应的65404的内存块。(后来发现可能不全是65404,我看到过65400,但是加上该行之上的哪一行数据都是64M)
而且我们看,65404这一行里面的该内存区域的权限,全部turn off,也就是该内存是不可读,不可写,不可执行。实在是不明白这个内存块有啥用处。

还有一点,就是估计到了一定thread的数量以后,增加量就不是64M了。我测试的时候发现创建了一个100个thread,所有的线程都不退出的话进程的内存总量是2999M。当然了如果线程一个跑完了再创建另外一个的话那么只有开始这个64M的增长量了。

不过到这里,我们已经知道了这个多出来64M内存并不是我们的程序本身的行为(当然我现在还并不知道到底是什么地方产生出来的)。也许这个ntpl的行为,也许这个是内核的行为,现在我还不清楚而已。这个留作以后的作业吧。

后记:
我今天对测试程序做了一个strace,得到了如下结果:
strace -f -e “brk,mmap,munmap,mprotect” test
brk(0) = 0x228f000
mmap(NULL, 4096, PROTREAD|PROTWRITE, MAPPRIVATE|MAPANONYMOUS, -1, 0) = 0x7fab81e30000
mmap(NULL, 82462, PROTREAD, MAPPRIVATE, 3, 0) = 0x7fab81e1b000
mmap(0x3f72000000, 3745960, PROTREAD|PROTEXEC, MAPPRIVATE|MAPDENYWRITE, 3, 0) = 0x3f72000000
mprotect(0x3f7218a000, 2093056, PROTNONE) = 0
mmap(0x3f72389000, 20480, PROT
READ|PROTWRITE, MAPPRIVATE|MAPFIXED|MAPDENYWRITE, 3, 0x189000) = 0x3f72389000
mmap(0x3f7238e000, 18600, PROTREAD|PROTWRITE, MAPPRIVATE|MAPFIXED|MAPANONYMOUS, -1, 0) = 0x3f7238e000
mmap(NULL, 4096, PROT
READ|PROTWRITE, MAPPRIVATE|MAPANONYMOUS, -1, 0) = 0x7fab81e1a000
mmap(NULL, 4096, PROT
READ|PROTWRITE, MAPPRIVATE|MAPANONYMOUS, -1, 0) = 0x7fab81e19000
mmap(NULL, 4096, PROT
READ|PROTWRITE, MAPPRIVATE|MAPANONYMOUS, -1, 0) = 0x7fab81e18000
mprotect(0x3f72389000, 16384, PROT
READ) = 0
mprotect(0x3f71a1f000, 4096, PROTREAD) = 0
munmap(0x7fab81e1b000, 82462) = 0
brk(0) = 0x228f000
brk(0x22b0000) = 0x22b0000
mmap(NULL, 99158576, PROT
READ, MAP_PRIVATE, 3, 0) = 0x7fab7bf87000

从上面没有看出应用程序有调用分配出64M左右的空间且权限是PROTNONE,或者更改某个约64M大小的区域的权限到PROTNONE的请求。难道这个6神秘的64M真的来自内核?看来这个问题只能说 “未完,待续 …”

Categories: programming Tags: , ,

putty无密码登陆linux box

January 16th, 2014 No comments

工作的时候很多时间都是使用putty登陆到linux机器进行操作,由于需要每次登陆都要输入密码,这多多少少有点烦人,况且又在局域网内部。所以自然想到了不输入密码使用putty登陆ssh server。
网上的方法很多,基本上都是一致的。
首先,使用putty的keygen工具puttygen.exe生成公钥和密钥。点击Generate然后在空白区域瞎乱动鼠标就行了。在生成公钥和密钥的时候我选择的类型是ssh-2 RSA,key长度是1024bits.生成以后保存private key文件。保存private key文件的时候不要输入密码。其实这个文件里面既有公钥又有密钥。当然你还可以单独保存一个公钥文件。
然后将上一步保存的公钥文件上传到你需要登陆的机器的用户目录下的~/.ssh目录。假设你的公钥文件叫做rsa_pub.现在使用命令
ssh-keygen -i -f rsa_
pub > rsa.pub
接着保存rsa.pub到authorized_keys文件就可以了。
cat rsa.pub >> authorized_
keys
然后启动putty,找到你登陆目标机器的那个保存的session,如果没有的话那么现在新建一个。找到connection->ssh->auth
在右边的Private key file authentication里面输入在第一步生成的private key的全路径。
照理,这个时候你使用putty登陆该linux机器的时候就无需输入密码了。但是我在使用的时候发现无法自动登陆成功。
putty上显示 “server refused our key”,于是按照askubuntu上的方法,解决了。(虽然我使用的linux server是centos的,但是大体上在这件事情上没有太大差别)该方法大致如下:
修改.ssh目录权限为700,也就是当前用户可读,写,执行
修改authorizedkeys的权限是600,也就是当前用户可读,写
修改/etc/ssh/sshdconfig,是下面这一句生效,也就是去掉行首的’#’
AuthorizedKeysFile .ssh/authorized_
keys
然后重启sshd
service sshd restart
就可以了。

其实linux下面需要无密码登陆到其他机器的做法也是一样的,首先用ssh-keygen生成一个公钥密钥对,然后上传公钥到目标机器的目标用户目录,后面的工作和上面一样的了。
ssh-keygen -t rsa.
同样的,在生成文件的时候不要输入密码

Categories: programming Tags: ,