Archive for December, 2013

作者:AngryFox 分类: Uncategorized December 29th, 2013 暂无评论


BSS段:(bss segment)通常是指用来存放程序中未初始化的全局变量的一块内存区域。BSS是英文Block Started by Symbol的简称。BSS段属于静态内存分配。

数据段:数据段(data segment)通常是指用来存放程序中已初始化的全局变量的一块内存区域。数据段属于静态内存分配。

代码段:代码段(code segment/text segment)通常是指用来存放程序执行代码的一块内存区域。这部分区域的大小在程序运行前就已经确定,并且内存区域通常属于只读, 某些架构也允许代码段为可写,即允许修改程序。在代码段中,也有可能包含一些只读的常数变量,例如字符串常量等。

堆(heap):堆是用于存放进程运行中被动态分配的内存段,它的大小并不固定,可动态扩张或缩减。当进程调用malloc/free等函数分配内存时,新分配的内存就被动态添加到堆上(堆被扩张)/释放的内存从堆中被剔除(堆被缩减)

栈(stack):栈又称堆栈, 存放程序的局部变量(但不包括static声明的变量,static意味着在数据段中存放变量)。除此以外,在函数被调用时,栈用来传递参数和返回值。由于栈的先进先出特点,所以栈特别方便用来保存/恢复调用现场。

作者:AngryFox 分类: Uncategorized December 28th, 2013 暂无评论

PHP RSA类

RSA_demo

08年的时候,荷兰TU/e的团队根据王小云团队的思想,实现了两个MD5值相同但执行结果不同的程序,并开发出来MD5冲突工具(详见http://www.win.tue.nl/hashclash/),使用这个工具可以在几分钟内对一个普通文件产生MD5碰撞。这个时候有一部分程序员开始不再相信MD5,转向了SHA-1。

关于SHA-1的不安性
其实SHA-1也不是绝对安全,在05年的时候SHA-1就被证明存在2^63的碰撞攻击。
微软在一个安全通报中表示,将在2016年1月1日后将签名算法从SHA-1切换到SHA-2(详见http://technet.microsoft.com/zh-cn/security/advisory/2880823)。
目前SHA-2被认为是绝对安全,尚未发现可能的碰撞攻击。

如果想要获得ECC算法实现,需要调用硬件完成加密/解密(ECC算法相当耗费资源,如果单纯使用CPU进行加密/解密,效率低下)
对称加密算法用来对敏感数据等信息进行加密,常用的算法包括:

DES(Data Encryption Standard):数据加密标准,速度较快,适用于加密大量数据的场合。

3DES(Triple DES):是基于DES,对一块数据用三个不同的密钥进行三次加密,强度更高。

AES(Advanced Encryption Standard):高级加密标准,是下一代的加密算法标准,速度快,安全级别高;
算法原理

AES 算法基于排列和置换运算。排列是对数据重新进行安排,置换是将一个数据单元替换为另一个。AES 使用几种不同的方法来执行排列和置换运算。

AES 是一个迭代的、对称密钥分组的密码,它可以使用128、192 和 256 位密钥,并且用 128 位(16字节)分组加密和解密数据。与公共密钥密码使用密钥对不同,对称密钥密码使用相同的密钥加密和解密数据。通过分组密码返回的加密数据的位数与输入数据相同。迭代加密使用一个循环结构,在该循环中重复置换和替换输入数据

非对称算法

常见的非对称加密算法如下:

RSA:由 RSA 公司发明,是一个支持变长密钥的公共密钥算法,需要加密的文件块的长度也是可变的;

DSA(Digital Signature Algorithm):数字签名算法,是一种标准的 DSS(数字签名标准);

ECC(Elliptic Curves Cryptography):椭圆曲线密码编码学。

ECC与RSA的比较

ECC和RSA相比,在许多方面都有对绝对的优势,主要体现在以下方面:

Ø 抗攻击性强。相同的密钥长度,其抗攻击性要强很多倍。
Ø 计算量小,处理速度快。ECC总的速度比RSA、DSA要快得多。
Ø 存储空间占用小。ECC的密钥尺寸和系统参数与RSA、DSA相比要小得多,意味着它所占的存贮空间要小得多。这对于加密算法在IC卡上的应用具有特别重要的意义。
Ø 带宽要求低。当对长消息进行加解密时,三类密码系统有相同的带宽要求,但应用于短消息时ECC带宽要求却低得多。带宽要求低使ECC在无线网络领域具有广泛的应用前景。
SHA-1是一种数据加密算法,该算法的思想是接收一段明文,然后以一种不可逆的方式将它转换成一段(通常更小)密文,也可以简单的理解为取一串输入码(称为预映射或信息),并把它们转化为长度较短、位数固定的输出序列即散列值(也称为信息摘要或信息认证代码)的过程。

单向散列函数的安全性在于其产生散列值的操作过程具有较强的单向性。如果在输入序列中嵌入密码,那么任何人在不知道密码的情况下都不能产生正确的散列值,从而保证了其安全性。SHA将输入流按照每块512位(64个字节)进行分块,并产生20个字节的被称为信息认证代码或信息摘要的输出。
对称与非对称算法比较

以上综述了两种加密方法的原理,总体来说主要有下面几个方面的不同:

Ø 在管理方面:公钥密码算法只需要较少的资源就可以实现目的,在密钥的分配上,两者之间相差一个指数级别(一个是n一个是n2)。所以私钥密码算法不适应广域网的使用,而且更重要的一点是它不支持数字签名。
Ø 在安全方面:由于公钥密码算法基于未解决的数学难题,在破解上几乎不可能。对于私钥密码算法,到了AES虽说从理论来说是不可能破解的,但从计算机的发展角度来看。公钥更具有优越性。
Ø 从速度上来看:AES的软件实现速度已经达到了每秒数兆或数十兆比特。是公钥的100倍,如果用硬件来实现的话这个比值将扩大到1000倍。
由于非对称加密算法的运行速度比对称加密算法的速度慢很多,当我们需要加密大量的数据时,建议采用对称加密算法,提高加解密速度。
RSA建议采用1024位的数字,ECC建议采用160位,AES采用128为即可。

作者:AngryFox 分类: Uncategorized December 26th, 2013 暂无评论

扩展: https://www.ibm.com/developerworks/cn/linux/l-linux-slab-allocator/

slab分配器
slab是Linux操作系统的一种内存分配机制。其工作是针对一些经常分配并释放的对象,如进程描述符等,这些对象的大小一般比较小,如果直接采用伙伴系统来进行分配和释放,不仅会造成大量的内碎片,而且处理速度也太慢。而slab分配器是基于对象进行管理的,相同类型的对象归为一类(如进程描述符就是一类),每当要申请这样一个对象,slab分配器就从一个slab列表中分配一个这样大小的单元出去,而当要释放时,将其重新保存在该列表中,而不是直接返回给伙伴系统,从而避免这些内碎片。slab分配器并不丢弃已分配的对象,而是释放并把它们保存在内存中。当以后又要请求新的对象时,就可以从内存直接获取而不用重复初始化。
对象高速缓存的组织如右下图所示,高速缓存的内存区被划分为多个slab,每个slab由一个或多个连续的页框组成,这些页框中既包含已分配的对象,也包含空闲的对象。
在cache和object中加入slab分配器,是在时间和空间上的折中方案。
2slab分配算法
slab分配算法采用cache 存储内核对象。当创建cache 时,起初包括若干标记为空闲的对象。对象的数量与slab的大小有关。开始,所有对象都标记为空闲。当需要内核数据结构的对象时,可以直接从cache 上直接获取,并将对象初始化为使用。
下面考虑内核如何将slab分配给表示进程描述符的对象。在Linux系统中,进程描述符的类型是struct task_struct ,其大小约为1.7KB。当Linux 内核创建新任务时,它会从cache 中获得struct task_struct 对象所需要的内存。Cache 上会有已分配好的并标记为空闲的struct task_struct 对象来满足请求。
Linux 的slab 可有三种状态:

满的:slab 中的所有对象被标记为使用。
空的:slab 中的所有对象被标记为空闲。
部分:slab 中的对象有的被标记为使用,有的被标记为空闲。

slab 分配器首先从部分空闲的slab 进行分配。如没有,则从空的slab 进行分配。如没有,则从物理连续页上分配新的slab,并把它赋给一个cache ,然后再从新slab 分配空间。

作者:AngryFox 分类: Uncategorized December 24th, 2013 暂无评论

内存管理一般会包括以下内容:

是否有足够的内存供我们的程序使用;
如何从足够可用的内存中获取部分内存;
对于使用后的内存,是否可以将其销毁并将其重新分配给其它程序使用
只是这些内容在ZEND内核中是以宏的形式作为接口提供给外部使用。 后面两个操作分别对应emalloc宏,efree宏,
Zend MM内存块查找判断顺序依次是小块内存列表,大块内存列表,剩余内存列表。
PHP自身的内存管理, 这部分主要的内容就是引用计数, 写时复制, 等等面向应用的层面的管理。php生命周期只有那么一次响应,运行完之后无论你unset与否,所有内存都立即释放。

设置过期时间的时候是否需要将过期时间散列
共享内存是一种在相同机器中的应用程序之间交换数据的有效方式。一个进程可创建一个可供其他进程访问的内存段,只要它分配了正确的权限。每个内存段拥有一个惟一的 ID(称为 shmid),这个 ID 指向一个物理内存区域,其他进程可在该区域操作它。创建并提供了合适的权限之后,同一台机器中的其他进程就可以操作这些内存段:读取、写入和删除。共享内存的使用是一种在进程之间交换数据的快速方法,主要因为在创建内存段之后传递数据,不会涉及内核。这种方法常常称为进程间通信 (IPC)。其他 IPC 方法包括管道、消息队列、RPC 和套接字。
PHP的数组、关联数组、对象属性、函数表、符号表等等都是用HashTable来做为容器的。
PHP的HashTable采用的拉链法来解决冲突
算法的核心思想就是:
hash(i) = hash(i-1) * 33 + str[i]

static inline ulong zend_inline_hash_func(char *arKey, uint nKeyLength)
{
    register ulong hash = 5381;

    /* variant with the hash unrolled eight times */
	for (; nKeyLength >= 8; nKeyLength -= 8  ) {
        hash = ((hash << 5) + hash) + *arKey++;
        hash = ((hash << 5) + hash) + *arKey++;
        hash = ((hash << 5) + hash) + *arKey++;
        hash = ((hash << 5) + hash) + *arKey++;
        hash = ((hash << 5) + hash) + *arKey++;
        hash = ((hash << 5) + hash) + *arKey++;
        hash = ((hash << 5) + hash) + *arKey++;
        hash = ((hash << 5) + hash) + *arKey++;
    }
    switch (nKeyLength) {
        case 7: hash = ((hash << 5) + hash) + *arKey++; /* fallthrough... */
        case 6: hash = ((hash << 5) + hash) + *arKey++; /* fallthrough... */
        case 5: hash = ((hash << 5) + hash) + *arKey++; /* fallthrough... */
        case 4: hash = ((hash << 5) + hash) + *arKey++; /* fallthrough... */
        case 3: hash = ((hash << 5) + hash) + *arKey++; /* fallthrough... */
        case 2: hash = ((hash << 5) + hash) + *arKey++; /* fallthrough... */
        case 1: hash = ((hash << 5) + hash) + *arKey++; break;
        case 0: break;
EMPTY_SWITCH_DEFAULT_CASE()
    }
    return hash;
}

相比在Apache和Perl中直接采用的经典Times 33算法:

hashing function used in Perl 5.005:
# Return the hashed value of a string: $hash = perlhash("key")
# (Defined by the PERL_HASH macro in hv.h)
sub perlhash
{
    $hash = 0;
    foreach (split //, shift) {
        $hash = $hash*33 + ord($_);
    }
    return $hash;
}

PHP底层对内存的管理, 围绕着小块内存列表(free_buckets)、 大块内存列表(large_free_buckets)和 剩余内存列表(rest_buckets)三个列表来分层进行的。 ZendMM向系统进行的内存申请,并不是有需要时向系统即时申请, 而是由ZendMM的最底层(heap层)先向系统申请一大块的内存,通过对上面三种列表的填充, 建立一个类似于内存池的管理机制。 在程序运行需要使用内存的时候,ZendMM会在内存池中分配相应的内存供使用。 这样做的好处是避免了PHP向系统频繁的内存申请操作

作者:AngryFox 分类: Uncategorized December 24th, 2013 暂无评论

为了保护共享数据,需要一些同步机制,如自旋锁(spinlock),读写锁(rwlock),简单且有效的同步机制,硬件发展,获得这种锁的开销相对于CPU的速度在成倍地增加,CPU的速度与访问内存的速度差距越来越大,而这种锁使用了原子操作指令,原子地访问内存,也就说获得锁的开销与访存速度相关,另外在大部分非x86架构上获取锁使用了内存栅(Memory Barrier),这会导致处理器流水线停滞或刷新,因此它的开销相对于CPU速度而言就越来越大。

RCU(Read-Copy Update),顾名思义就是读-拷贝修改,它是基于其原理命名的。对于被RCU保护的共享数据结构,读者不需要获得任何锁就可以访问它,但写者在访问它时首先拷贝一个副本,然后对副本进行修改,最后使用一个回调(callback)机制在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作。

1.概念理解:
如果有对某一变量上写锁, 就不能在不获得相应的锁时对其进行读取操作。 也就是说, 内存栅的作用在于保证内存操作的相对顺序, 但并不保证内存操作的严格时序。 换言之, 内存栅并不保证 CPU 将本地快取缓存或存储缓冲的内容刷写回内存, 而是在锁释放时确保其所保护的数据, 对于能看到刚释放的那个锁的 CPU 或设备可见。 持有内存栅的 CPU 可以在其快取缓存或存储缓冲中将数据保持其所希望的、 任意长的时间, 但如果其它 CPU 在同一数据元上执行原子操作, 则第一个 CPU 必须保证, 其所更新的数据值, 以及内存栅所要求的任何其它操作, 对第二个 CPU 可见。
  例如, 假设在一简单模型中, 认为在主存 (或某一全局快取缓存) 中的数据是可见的, 当某一 CPU 上触发原子操作时, 其它 CPU 的存储缓冲和快取缓存就必须对同一快取缓存线上的全部写操作, 以及内存栅之后的全部未完成操作进行刷写。
  这样一来, 在使用由原子操作保护的内存单元时就需要特别小心。 例如, 在实现 sleep mutex 时, 我们就必须使用 atomic_cmpset 而不是 atomic_set来打开 MTX_CONTESTED 位。 这样做的原因是, 我们需要把 mtx_lock 的值读到某个变量, 并据此进行决策。 然而, 我们读到的值可能是过时的, 也可能在我们进行决策的过程中发生变化。 因此, 当执行 atomic_set 时, 最终可能会对另一值进行置位, 而不是我们进行决策的那一个。 这就必须通过atomic_cmpset 来保证只有在我们的决策依据是最新的时, 才对相应的变量进行置位。
  最后, 原子操作只允许一次更新或读一个内存单元。 需要原子地更新多个单元时, 就必须使用锁来代替它了。 例如, 如果需要更新两个相互关联的计数器时, 就必须使用锁, 而不是两次单独的原子操作了。

http://cnsnap.cn.freebsd.org/doc/zh_CN.GB2312/books/arch-handbook/smp-design.html

(freebsd系统手册)
2.实现
内核中定义的内存屏障原语有:

#define barrier() __asm__ __volatile__("": : :"memory")
#define mb() alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2)
#define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", X86_FEATURE_XMM2) 

#ifdef CONFIG_SMP
#define smp_mb() mb()
#define smp_rmb() rmb()
#define smp_wmb() wmb()
#define smp_read_barrier_depends() read_barrier_depends()
#define set_mb(var, value) do { (void) xchg(&var, value); } while (0)
#else
#define smp_mb() barrier()
#define smp_rmb() barrier()
#define smp_wmb() barrier()
#define smp_read_barrier_depends() do { } while(0)
#define set_mb(var, value) do { var = value; barrier(); } while (0)
#endif

1). smp_xxx()和xxx()的区别

为了给其它CPU也提供相关的barrier宏。 例如x86的rmb()是用了lfence指令,但其它CPU不能用这个指令。

2). 关于barrier()宏,jkl大师是这么说的:

CPU越过内存屏障后,将刷新自己对存储器的缓冲状态。这条语句实际上不生成任何代码,但可使gcc在
barrier()之后刷新寄存器对变量的分配。

也就是说,barrier()宏只约束gcc编译器,不约束运行时的CPU行为。 举例:

1 int a = 5, b = 6;
2 barrier();
3 a = b;

在line 3,GCC不会用存放b的寄存器给a赋值,而是invalidate b的Cache line,重新读内存中的b值,赋值给a。

3). mb() vs. rmb() vs. wmb()

rmb()不允许读操作穿过内存屏障;wmb()不允许写操作穿过屏障;而mb()二者都不允许。

看IA32上wmb()的定义:
#ifdef CONFIG_X86_OOSTORE
#define wmb() alternative(“lock;addl $0,0(%%esp)”, “sfence”, X86_FEATURE_XMM);
#else
#define wmb() __asm__ __volatile__ (“”: : :”memory”);
#endif

Intel和AMD都没有在IA32 CPU中实现乱序写(Out-Of-Order Store),所以wmb()定义为空操作,不约束CPU行为;但
有些IA32 CPU厂商实现了OOO Store,所以就有了使用sfence的那个wmb()实现。

4). 内存屏障的体系结构语义

4.1) 只有一个主体(CPU或DMA控制器)访问内存时,无论如何也不需要barrier;但如果有两个或更多主体访问内存,且
其中有一个在观测另一个,就需要barrier了。

4.2) IA32 CPU调用有lock前缀的指令,或者如xchg这样的指令,会导致其它的CPU也触发一定的动作来同步自己的Cache。
CPU的#lock引脚链接到北桥芯片(North Bridge)的#lock引脚,当带lock前缀的执行执行时,北桥芯片会拉起#lock
电平,从而锁住总线,直到该指令执行完毕再放开。 而总线加锁会自动invalidate所有CPU对 _该指令涉及的内存_
的Cache,因此barrier就能保证所有CPU的Cache一致性。

4.3) 接着解释。
lock前缀(或cpuid、xchg等指令)使得本CPU的Cache写入了内存,该写入动作也会引起别的CPU invalidate其Cache。
IA32在每个CPU内部实现了Snoopying(BUS-Watching)技术,监视着总线上是否发生了写内存操作(由某个CPU或DMA控
制器发出的),只要发生了,就invalidate相关的Cache line。 因此,只要lock前缀导致本CPU写内存,就必将导致
所有CPU去invalidate其相关的Cache line。

两个地方可能除外:
-> 如果采用write-through策略,则根本不存在缓存一致性问题(Linux对全部内存采用write-back策略);
-> TLB也是Cache,但它的一致性(至少在IA32上)不能通过Snoopying技术解决,而是要发送
INVALIDATE_TLB_VECTOR这个IPI给其它的CPU。

4.4) 进一步解释,MESI协议

包括IA32的许多体系结构的CPU,为了保证缓存一致性,实现了MESI协议。

M: Modified,已修改
E: Exclusive,排他
S: Shared,共享
I: Invalid,无效

IA32 的CPU实现了MESI协议来保证Cache coherence。 CPU的总线监测单元,始终监视着总线上所有的内存写操作,
以便随时调整自己的Cache状态。

-> Modified。 本CPU写,则直接写到Cache,不产生总线事物;其它CPU写,则不涉及本CPU的Cache,其它CPU
读,则本CPU需要把Cache line中的数据提供给它,而不是让它去读内存。

-> Exclusive。只有本CPU有该内存的Cache,而且和内存一致。 本CPU的写操作会导致转到Modified状态。

-> Shared。 多个CPU都对该内存有Cache,而且内容一致。任何一个CPU写自己的这个Cache都必须通知其它
的CPU。

-> Invalid。 一旦Cache line进入这个状态,CPU读数据就必须发出总线事物,从内存读。

5) 考虑到DMA

5.1). Wirte through策略。 这种情形比较简单。

-> 本CPU写内存,是write through的,因此无论什么时候DMA读内存,读到的都是正确数据。
-> DMA写内存,如果DMA要写的内存被本CPU缓存了,那么必须Invalidate这个Cache line。下次CPU读它,就
直接从内存读。

5.2). Write back策略。 这种情形相当复杂。

-> DMA读内存。被本CPU总线监视单元发现,而且本地Cache中有Modified数据,本CPU就截获DMA的内存读操作,
把自己Cache Line中的数据返回给它。

-> DMA写内存。而且所写的位置在本CPU的Cache中,这又分两种情况:
a@ Cache Line状态未被CPU修改过(即cache和内存一致),那么invalidate该cache line。
b@ Cache Line状态已经被修改过,又分2种情况:

<1> DMA写操作会替换CPU Cache line所对应的整行内存数据,那么DMA写,CPU则invalidate
自己的Cache Line。
<2> DMA写操作只替换Cache Line对应的内存数据的一部分,那么CPU必须捕获DMA写操作的新
数据(即DMA想把它写入内存的),用来更新Cache Line的相关部分。

http://groups.google.com/group/linux.kernel/browse_thread/thread/18a59e3c9d8f6310/cdfbcb70e9c48cd0#cdfbcb70e9c48cd0

Linux 2.6内核中新的锁机制–RCU

http://www.ibm.com/developerworks/cn/linux/l-rcu/

作者:AngryFox 分类: Uncategorized December 24th, 2013 暂无评论

微服务架构(MSA)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。从概念上来说,MSA并不难理解,不过从实践上来说,它会引发很多问题。
[root@ZN_10_1_16_1 glua]# go test -v
# _/opt/glua
/usr/bin/ld: cannot find -lluajit-5.1
collect2: ld returned 1 exit status
FAIL _/opt/glua [build failed]

[root@ZN_10_1_16_1 LuaJIT-2.0.2]# file /usr/local/lib/libluajit-5.1.so.2.0.2
/usr/local/lib/libluajit-5.1.so.2.0.2: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped

http://www.cmake.org/cmake/resources/software.html

http://www.cmake.org/files/v2.8/cmake-2.8.12.1.tar.gz

Makefile选项CFLAGS,LDFLAGS,LIBS
CFLAGS 表示用于 C 编译器的选项,
CXXFLAGS 表示用于 C++ 编译器的选项。
这两个变量实际上涵盖了编译和汇编两个步骤。

CFLAGS: 指定头文件(.h文件)的路径,如:CFLAGS=-I/usr/include -I/path/include。同样地,安装一个包时会在安装路径下建立一个include目录,当安装过程中出现问题时,试着把以前安装的包的include目录加入到该变量中来。

LDFLAGS:gcc 等编译器会用到的一些优化参数,也可以在里面指定库文件的位置。用法:LDFLAGS=-L/usr/lib -L/path/to/your/lib。每安装一个包都几乎一定的会在安装目录里建立一个lib目录。如果明明安装了某个包,而安装另一个包时,它愣是说找不到,可以抒那个包的lib路径加入的LDFALGS中试一下。

LIBS:告诉链接器要链接哪些库文件,如LIBS = -lpthread -liconv

简单地说,LDFLAGS是告诉链接器从哪里寻找库文件,而LIBS是告诉链接器要链接哪些库文件。不过使用时链接阶段这两个参数都会加上,所以你即使将这两个的值互换,也没有问题。

有时候LDFLAGS指定-L虽然能让链接器找到库进行链接,但是运行时链接器却找不到这个库,如果要让软件运行时库文件的路径也得到扩展,那么我们需要增加这两个库给”-Wl,R”:

LDFLAGS = -L/var/xxx/lib -L/opt/mysql/lib -Wl,R/var/xxx/lib -Wl,R/opt/mysql/lib

如果在执行./configure以前设置环境变量export LDFLAGS=”-L/var/xxx/lib -L/opt/mysql/lib -Wl,R/var/xxx/lib -Wl,R/opt/mysql/lib” ,注意设置环境变量等号两边不可以有空格,而且要加上引号(shell的用法)。那么执行configure以后,Makefile将会设置这个选项,链接时会有这个参数,编译出来的可执行程序的库文件搜索路径就得到扩展了。

亚马逊的就是实时分析然后推送 …..
获取多台机器访问日志合并分析

BerkeleyDB使用B树,会一直写新的,内部不会有文件重新组织;这样会导致文件越来越大;大的时候需要进行文件归档,归档的操作要定期做;
这样,就需要有一定的down time; Redis作为存储并提供查询,后台不再使用mysql,解决数据多份之间的一致性问题; 增加一些配置, 分流, 比如: 1,2,3,4, 机器1处理%2=1的, 机器2处理%2=0的.
低于内存的1/2使用量, 否则就扩容(建议Redis实例使用的数据,最大不要超过内存的80%)
我们线上96G/128G内存服务器不建议单实例容量大于20/30G。
分布式系统的两个核心问题: A.路由问题 B.HA问题。响应时间超时目前设置为5s

发出了包含多个指令的HTTP POST请求,下载一个伪装成PDF文件的 Perl 脚本,执行之后删除。为了确保成功,攻击者使用 curl、fetch、lwp-get请求重复上述步骤。Perl 脚本编程休眠一

段时间,猜测可能是避开管理员的耳目。最终被感染的机器连上一个中继聊天频道,下载执行另一个脚本。攻击者在服务器上安装了多个应用,包括 比特币和素数币挖矿程序,DDoS工具,扫

描其它存在已知漏洞的机器的工具。
Oceanbase

作者:AngryFox 分类: Uncategorized December 22nd, 2013 暂无评论

Node.js 的 GC 方式为分代 GC (Generational GC)。对象的生命周期由它的大小决定。对象首先进入占用空间很少的 new space (8MB)。大部分对象会很快失效,会频繁而且快速执行 Young GC (scavenging)*直接*回收这些少量内存。假如有些对象在一段时间内不能被回收,则进入 old space (64-128KB chunks of 8KB pages)。这个区域则执行不频繁的 Old GC/Full GC (mark-sweep, compact or not),并且耗时比较长。(Node.js 的 GC 有两类:Young GC: 频繁的小量的回收;Old GC: 长时间存在的数据)

Node.js 最新增量 GC 方式虽然不能降低总的 GC 时间,但是避免了过大的停顿,一般大停顿也限制在了几十 ms 。基于寄存器(如Lua)

对象对 小虚拟机 标记 清理
gc模型

#include <stdio.h>
#include <stdlib.h>

#define STACK_MAX 25600000

typedef enum {
  OBJ_INT,
  OBJ_PAIR
} ObjectType;

typedef struct sObject {
  ObjectType type;
  unsigned char marked;

  /* The next object in the linked list of heap allocated objects. */
  struct sObject* next;

  union {
    /* OBJ_INT */
    int value;

    /* OBJ_PAIR */
    struct {
      struct sObject* head;
      struct sObject* tail;
    };
  };
} Object;

typedef struct {
  Object* stack[STACK_MAX];
  int stackSize;

  /* The first object in the linked list of all objects on the heap. */
  Object* firstObject;

  /* The total number of currently allocated objects. */
  int numObjects;

  /* The number of objects required to trigger a GC. */
  int maxObjects;
} VM;

void assert(int condition, const char* message) {
  if (!condition) {
    printf("%s\n", message);
    exit(1);
  }
}

VM* newVM() {
  VM* vm = malloc(sizeof(VM));
  vm->stackSize = 0;
  vm->firstObject = NULL;
  vm->numObjects = 0;
  vm->maxObjects = 8;
  return vm;
}

void push(VM* vm, Object* value) {
  assert(vm->stackSize < STACK_MAX, "Stack overflow!");
  vm->stack[vm->stackSize++] = value;
}

Object* pop(VM* vm) {
  assert(vm->stackSize > 0, "Stack underflow!");
  return vm->stack[--vm->stackSize];
}

void mark(Object* object) {
  /* If already marked, we're done. Check this first to avoid recursing
     on cycles in the object graph. */
  if (object->marked) return;

  object->marked = 1;

  if (object->type == OBJ_PAIR) {
    mark(object->head);
    mark(object->tail);
  }
}

void markAll(VM* vm)
{
  int i;
  for (i = 0; i < vm->stackSize; i++) {
    mark(vm->stack[i]);
  }
}

void sweep(VM* vm)
{
  Object** object = &vm->firstObject;
  while (*object) {
    if (!(*object)->marked) {
      /* This object wasn't reached, so remove it from the list and free it. */
      Object* unreached = *object;

      *object = unreached->next;
      free(unreached);

      vm->numObjects--;
    } else {
      /* This object was reached, so unmark it (for the next GC) and move on to
       the next. */
      (*object)->marked = 0;
      object = &(*object)->next;
    }
  }
}

void gc(VM* vm) {
  int numObjects = vm->numObjects;

  markAll(vm);
  sweep(vm);

  vm->maxObjects = vm->numObjects * 2;

  printf("Collected %d objects, %d remaining.\n", numObjects - vm->numObjects,
         vm->numObjects);
}

Object* newObject(VM* vm, ObjectType type) {
  if (vm->numObjects == vm->maxObjects) gc(vm);

  Object* object = malloc(sizeof(Object));
  object->type = type;
  object->next = vm->firstObject;
  vm->firstObject = object;
  object->marked = 0;

  vm->numObjects++;

  return object;
}

void pushInt(VM* vm, int intValue) {
  Object* object = newObject(vm, OBJ_INT);
  object->value = intValue;

  push(vm, object);
}

Object* pushPair(VM* vm) {
  Object* object = newObject(vm, OBJ_PAIR);
  object->tail = pop(vm);
  object->head = pop(vm);

  push(vm, object);
  return object;
}

void objectPrint(Object* object) {
  switch (object->type) {
    case OBJ_INT:
      printf("%d", object->value);
      break;

    case OBJ_PAIR:
      printf("(");
      objectPrint(object->head);
      printf(", ");
      objectPrint(object->tail);
      printf(")");
      break;
  }
}

void test1() {
  printf("Test 1: Objects on stack are preserved.\n");
  VM* vm = newVM();
  pushInt(vm, 1);
  pushInt(vm, 2);

  gc(vm);
  assert(vm->numObjects == 2, "Should have preserved objects.");
}

void test2() {
  printf("Test 2: Unreached objects are collected.\n");
  VM* vm = newVM();
  pushInt(vm, 1);
  pushInt(vm, 2);
  pop(vm);
  pop(vm);

  gc(vm);
  assert(vm->numObjects == 0, "Should have collected objects.");
}

void test3() {
  printf("Test 3: Reach nested objects.\n");
  VM* vm = newVM();
  pushInt(vm, 1);
  pushInt(vm, 2);
  pushPair(vm);
  pushInt(vm, 3);
  pushInt(vm, 4);
  pushPair(vm);
  pushPair(vm);

  gc(vm);
  assert(vm->numObjects == 7, "Should have reached objects.");
}

void test4() {
  printf("Test 4: Handle cycles.\n");
  VM* vm = newVM();
  pushInt(vm, 1);
  pushInt(vm, 2);
  Object* a = pushPair(vm);
  pushInt(vm, 3);
  pushInt(vm, 4);
  Object* b = pushPair(vm);

  a->tail = b;
  b->tail = a;

  gc(vm);
  assert(vm->numObjects == 4, "Should have collected objects.");
}

void perfTest() {
  printf("Performance Test.\n");
  VM* vm = newVM();

  //Stack overflow!
  int i,j,k;
  for (i = 0; i < 100000; i++) {
    for (j = 0; j < 20000; j++) {
      pushInt(vm, i);
    }

    for (k = 0; k < 20000; k++) {
      pop(vm);
    }
  }
}

int main(int argc, const char * argv[]) {
  test1();
  test2();
  test3();
  test4();

  perfTest();

  return 0;
}
作者:AngryFox 分类: Uncategorized December 22nd, 2013 暂无评论

四种经典的垃圾回收算法,其中后三种经常称之为跟踪垃圾回收,因为引用计数算法能够平滑的进行垃圾回收,而不会出现“停止”现象,经常出现于一些实时系统中,但它无法解决环形问题;而基于跟踪的垃圾回收机制,在每一次垃圾回收过程中,要遍历或者复制所有的存活对象,这是一个非常耗时的工作,一种好的解决方案就是对堆上的对象进行分区,对不同区域的对象使用不同的垃圾回收算法,分代式垃圾回收器正是其中一种,CLR和JVM中都采用了分代式垃圾回收机制,但它们在处理上又有些不同

标记-清除算法

标记-清除(Mark-Sweep)算法依赖于对所有存活对象进行一次全局遍历来确定哪些对象可以回收,遍历的过程从根出发,找到所有可达对象,除此之外,其它不可达的对象就是垃圾对象,可被回收。整个过程分为两个阶段:标记阶段找到所有存活对象;清除阶段清除所有垃圾对象。

标记阶段:

清除阶段:

相比较引用计数算法,标记-清除算法可以非常自然的处理环形引用问题,另外在创建对象和销毁对象时时少了操作引用计数值的开销。它的缺点在于标记-清除算法是一种“停止-启动”算法,在垃圾回收器运行过程中,应用程序必须暂时停止,所以对于标记-清除算法的研究如何减少它的停顿时间,而分代式垃圾收集器就是为了减少它的停顿时间,后面会说到。另外,标记-清除算法在标记阶段需要遍历所有的存活对象,会造成一定的开销,在清除阶段,清除垃圾对象后会造成大量的内存碎片。

标记-缩并算法

标记-缩并算法是为了解决内存碎片问题而产生的一种算法。 它的整个过程可以描述为:标记所有的存活对象;通过重新调整存活对象位置来缩并对象图;更新指向被移动了位置的对象的指针。

标记阶段:

清除阶段:

标记-压缩算法最大的难点在于如何选择所使用的压缩算法,如果压缩算法选择不好,将会导致极大的程序性能问题,如导致Cache命中率低等。一般来说,根据压缩后对象的位置不同,压缩算法可以分为以下三种:

1. 任意:移动对象时不考虑它们原来的次序,也不考虑它们之间是否有互相引用的关系。
2. 线性:尽可能的将原来的对象和它所指向的对象放在相邻位置上,这样可以达到更好的空间局部性。
3. 滑动:将对象“滑动”到堆的一端,把存活对象之间的自由单元“挤出去”,从而维持了分配时的原始次序。

节点拷贝算法

节点拷贝算法是把整个堆分成两个半区(From,To), GC的过程其实就是把存活对象从一个半区From拷贝到另外一个半区To的过程,而在下一次回收时,两个半区再互换角色。在移动结束后,再更新对象的指针引用,GC开始前的情形:

GC结束后的情形:

节点拷贝算法由于在拷贝过程中,就可以进行内存整理,所以不会再有内存碎片的问题,同时也不需要再专门做一次内存压缩。,而它最大的缺点在于需要双倍的空间。

作者:AngryFox 分类: Uncategorized December 22nd, 2013 暂无评论


1. Stack和Heap

  每个线程对应一个stack,线程创建的时候CLR为其创建这个stack,stack主要作用是记录函数的执行情况。值类型变量(函数的参数、局部变量 等非成员变量)都分配在stack中,引用类型的对象分配在heap中,在stack中保存heap对象的引用指针。GC只负责heap对象的释 放,heap内存空间管理

2.标记释放
计算机实现收集的方式就是当机器需要分配一些内存,而内存又不足时,让它收集垃圾。要确保“不再被使用”对于编程语言来说是非常安全的。
关于”in use”的定义事实上非常简单:

任何被一个变量引用的对象,仍然在作用域内,就属于”in use”状态。
任何被另一个对象引用的对象,仍在使用中,就是”in use”状态。
最简单也是第一个被提出的算法就是”标记-清除”算法。它由John McCarthy——Lisp(列表处理语言)的发明者提出。

对”可访问性(reachability)”的定义完全一样:

从根节点开始,依次遍历整个对象图。每当你访问到一个对象,在上面设置一个”标记(mark)”位,置为true。
一旦搞定,找出所有标记位为”not”的对象集,然后删除它们。

3. Generational 分代算法
  程序可能使用几百M、几G的内存,对这样的内存区域进行GC操作成本很高,分代算法具备一定统计学基础,对GC的性能改善效果比较明显
  将对象按照生命周期分成新的、老的,根据统计分布规律所反映的结果,可以对新、老区域采用不同的回收策略和算法,加强对新区域的回收处理力度,争取在较短 时间间隔、较小的内存区域内,以较低成本将执行路径上大量新近抛弃不再使用的局部对象及时回收掉
  分代算法的假设前提条件:
  a). 大量新创建的对象生命周期都比较短,而较老的对象生命周期会更长
  b). 对部分内存进行回收比基于全部内存的回收操作要快
  c). 新创建的对象之间关联程度通常较强。heap分配的对象是连续的,关联度较强有利于提高CPU cache的命中率

三种内存分配方式:

1. 静态分配:静态变量和全局变量的分配形式
2. 自动分配:在栈中为局部变量分配内存的方法
3. 动态分配:在堆中动态分配内存空间以存储数据的方式

作者:AngryFox 分类: Uncategorized December 16th, 2013 暂无评论

Erlang中每个process有reduction,类似于 Linux kernel中process的time slice,Go是native执行,那么Go的runtime是如何控制每个goroutine的公平性呢?答案是没有,native执行的 goroutine无法像Erlang那样保证公平性,goroutine只能在syscall、io、channel read write操作时才能有机会重新执行schedule函数,以执行其余的goroutine。在concurrent语言中,如不能很好的解决公平调度和 优先级调度是个很大的问题。

erlang私有堆垃圾收集更高效。 内建轻量级进程(groutine)和消息传递(chan),可实现Actor模型。erlang直接支持,其他语言可以通过库实现,例如c++ CSP2以及d的Fiber和CSP。Erlang的实现基于虚拟机beam,Go是编译型语言。Erlang和SDL是基于process之间传递message,而Go是goroutine组成,再加上channel,Go通过把process和message解耦使得Go的设计更有通用性和灵活性,应用可以根据自己的需求决定是否需要channel的处理。routine加channel的设计在stackless python也有。
Erlang scheduler位于:https://github.com/yrashk/erlang/blob/master/erts/emulator/beam/erl_process.c
Go scheduler位于:http://golang.org/src/pkg/runtime/proc.c?h=proc.c

4)memory model 内存模型

Erlang中每个process有自己的heap,stack在heap的底部,这里的stack是Erlang process的stack,类似于Java中的操作数栈,stack向下增长,stack top如遇到heap top,则进行GC,GC后stack移到新的地方。

Go是native执行,goroutine的stack是segment stack,TNSDL的runtime也是使用这种segment stack,segment stack就是一个程序中有很多stack执行,stack的切换则通过setjmp,longjmp实现的。(setjmp和longjmp的一个主要应用就是concurrent,另一个是在C中模拟try catch)

5)GC垃圾回收

Erlang的GC属于分代算法,有个old heap,有minor gc和full sweep,总体来说和Java类似,只不过Erlang没有mark的过程,直接根据rootset找到所有Eterm放在新分配的heap的。

Go现在是mark-sweep,以后会使用IBM的低延时GC算法。

6)高可靠性

Erlang中有个builtin的高可靠性,如link和monitor机制。

Go是一个通用性的设计,虽没有built-in的link和monitor,goroutine则可使用defer来实现link的效果。

杀掉端口
netstat -anp | grep 8080 | awk ‘{print substr($7, 0, 4)}’ | xargs kill -9
svn checkout http://go-fastweb.googlecode.com/svn/trunk/

http://www-public.it-sudparis.eu/~berger_o/go-uriel/img/gophercolor.png

http://img.linux.net.cn/data/attachment/album/201209/25/14453322kovnj5jkwmt8nm.jpg