Ports的make参数说明

FreeBSD::ports::make参数说明,哈哈,很多地方都用到哦
make fetch # 只抓取软件包
make extract # 只解开软件包
make patch # 解开软件包并补上官方的patch
make install # 安装一个新port
make clean # 清除中间生成的文件
make package # 将安装完的软件做成package
make distclean # 全部删除,包括/usr/ports/distfiles下的源码包
make all-depends-list  # 显示所有相关的依赖
make pretty-print-build-depends-list  # 显示编译期间所需要的依赖
make pretty-print-run-depends-list  # 显示执行时需要的依赖
make deinstall # 删除软件
make deinstall-depends # 连同依赖一起删除
pkg_version -c # 列出所有可升级的ports
make PREFIX=/usr/local/XXX # 指定一个安装路径
make showconfig make rmconfig
make search key=XXXX # 查找ports
make index # 更新index
make fetchindex # 更新index
make readmes # 网页的方式察看

基于libfdk库的FreeBSD系统优化

1> kern.ipc.maxsockets

设定系统最大可以开启的 socket 数目。与libfdk中session管理的最大客户端数目。

然而,这个值必须在系统一开机就设定好,所以如果要修改这项设定,我们必须修改 /boot/loader.conf 才行。例如,我们要将它改成最多同时可以有 16424 个 socket,则必须在 /boot/loader.conf 中加入下列这一行:

kern.ipc.maxsockets=”16424”

2> net.inet.ip.portrange.*

libfdk中的UDP服务器框架有可能使用到工作端口范围4000-8000,所以我们必须手动调整一下 net.inet.ip.portrange.last 这个值,将它调为 10000、20000、甚至 40000 都是合理的。如果要在一开机就调整这个值,我们可以修改 /etc/sysctl.conf,并增加下列这一行:

net.inet.ip.portrange.last=40000

3> kern.ipc.shm_use_phys

kern.ipc.shm_use_phys 这个选项预设为 0 (关闭),我们可以将它设为 1 (打开)。如果我们将它设成 1,这个功能允许内核通过将共享内存页锁定在核心存储中而消除大量的内部内存管理和页面跟踪的开销,使得它们不可被换出,如果我们有大量的程序 (数百个) 需要共同分享一个小的共享内存空间,或者是共享内存空间很大时,我们可以将这个值打开。

这个值可以在开机完成后才设定,因此只要放在 /etc/sysctl.conf 中即可:

kern.ipc.shm_use_phys=1

4> vfs.vmiodirenable

这个选项预设被设为 1,也就是打开的状态。它被用来决定一个目录中的结构 (目录下的其它文件名称等等) 被快取在内存中的行为。一般的目录结构可能都不大,而这些目录结构会被快取在物理内存中。物理内存中所存放的目录结构快取有限,所以不管我们的物理内存有多大,预设都只会快取一定大小的目录结构。如果我们将这个选项打开,系统将 buffer cache 放在虚拟内存的快取中,目录结构也就会被存放在虚拟内存中。这样的好处是所有的内存空间都可以被拿来做目录的快取,而缺点是最小用来存放目录结构的快取会从 512 bytes 变成 4K。

如果您的系统物理内存空间有限,建议您将这个选项关闭。但如果您的系统需要进行大量档案操作,例如 proxy、多人使用的邮件服务器、或是 news server 等,建议将这个选项打开。

5> vfs.write_behind

这个选项预设为 1,也就是打开的状态。在打开时,在系统需要写入数据在硬盘或其它储存设备上时,它会等到收集了一个 cluster 单位的数据后再一次写入,否则会在一个暂存区空间有写入需求时就立即写到硬盘上。这个选项打开时,对于一个大档案写入速度非常有帮助。但如果您遇到有很多行程延滞在等待写入动作时,您可能必须关闭这个功能。

6> vfs.hirunningspace

这个值决定了系统可以将多少数据放在写入储存设备的等候区。通常使用默认值即可,但当我们有多颗硬盘时,我们可以将它调大为 4MB 或 5MB。但必须注意的是,太大的值反而会造成效能低落。

7> net.inet.tcp.sendspace 及 net.inet.tcp.recvspace

这二个选项分别控制了网络 TCP 联机所使用的传送及接收暂存区的大小。预设的传送暂存区为 32K,而接收暂存区为 64K。如果需要加速 TCP 的传输,可以将这二个值调大一点,但缺点是太大的值会造成系统核心占用太多的内存。如果我们的机器会同时服务数百或数千个网络联机,那么这二个选项最好维持默认值,否则会造成系统核心内存不足。但如果我们使用的是 gigabite 的网络,将这二个值调大会有明显效能的提升。传送及接收的暂存区大小可以分开调整,例如,假设我们的系统主要做为网页服务器,我们可以将接收的暂存区调小一点,并将传送的暂存区调大,如此一来,我们就可以避免占去太多的核心内存空间。

还有要注意的是,除了这二个选项可以控制网络传输暂存区大小外,route 这个指令也可以用来依路由路径的不同指定暂存区大小。另外 ipfw 等防火墙软件也可以用来限制每个联机所能使用的网络频宽。

如果我们将传送或接收的暂存区设为大于 65535,除非我们的服务器本身及客户端所使用的操作系统支持 TCP 协议的 windows scaling extension (请参考 RFC 1323 文件)。FreeBSD 预设已支援 rfs1323 (即 sysctl 的 net.inet.tcp.rfc1323 选项)。

8> net.inet.tcp.always_keepalive

当这个选项打开时,系统会定期送出「keepalives」以检查一个 TCP 联机是否中断。在打开的状况下,所有运作的网络程序都会有定时检查联机是否中断的功能,否则只有当应用程序本身支持时才有此功能。这个选项打开的好处是让系统更便于管理网络联机,尤其是当我们系统中常有一些莫名其妙就中断联机的使用者时。例如,当一个使用者利用拨接连到系统时,很可能在完成一个完整的 TCP 联机之前,就因为拨接中断而造成联机异常中断。当然,在某些情况下,也有可能会造成系统误判网络联机已中断而结束这个 TCP 联机。

9> net.inet.tcp.delayed_ack

TCP 协议有一个特性,就是当收到客户端的数据时,会传回一个 ACK (acknowledgement) 的封包,以确认已收到数据。然而,我们也可以将 ACK 封包和所要回传的资料一起送出。例如,当我使用 telnet 进入系统时,在输入指定时,当我们在键盘上敲打一个字符,系统会送回一个表示已接收到该字符的 ACK 封包,并传回一个含有该字符的封包以在终端机上显示。当 net.inet.tcp.delayed_ack 打开时,系统会将 ACK 和显示该字符的封包一传送,而不需分成二个封包。所以这个选项打开时,可以将封包数量减少一半,以加速网络传输。其它的网络服务,例如,WWW、 SMTP、POP3 等也都具有这种特性。
在高速网络和低负载的情况下会略微提高性能,但在网络连接较差的时候,对方计算机得不到应答会持续发起连接请求,反而会降低性能。

10> kern.ipc.somaxconn

这个选项控制了 TCP 联机等候区最多可以等待的联机数量,其默认值为 128,不过这个值对于一台忙碌的服务器而言可能小了点。例如大型的网页服务器、邮件服务器,我们可以将它设为 1024。要注意的是在一些网络服务的程序中,如 Apache 及 sendmail 也有自己的等待数量设定,我们可能也要在那些软件上做一些设定才会让 kern.ipc.somaxconn 发生作用。将这个选项的值调大一点还有一个好处,就是在面对 Denial of service 的攻击时,有较好的防卫能力。

11> kern.maxfiles

这个选项控制了系统中支持最多开启的档案数量,这个值通常是几千个档,但对于一台忙碌的数据库系统或是会开启许多档案的服务器而言,我们可以将它调高为一、二万。

12> kern.maxusers

这是用来控制系统内部表格(internal system tables)大小的参数,它的值大约是您期望系统同一时间会上线使用的使用者数量。我们在核心设定档中有一个 maxusers 的选项,如果您使用的是 FreeBSD 4.5 以上的版本,建议您只要在核心设定档中将它 0 即可,系统会在一开机时自动依您的内存大小调整这个值。如果我们使用的是 FreeBSD

4.5 以后的版本,要调整这个值时,我们可以在 /boot/loader.conf 中加入该选项的设定,例如:

kern.maxusers=256

如果您使用 FreeBSD 4.4 以前的版本,则只能重新编译核心以改变这项设定。

这个值一定要设定大于四,maxusers 的值决定了处理程序所容许的最大值,20+16*maxusers 就是你将得到的所容许处理程序。系统一开机就必须要有 18 个处理程序 (process),即便是简单的执行指令 man 又会产生 9 个 process,所以将这个值设为 64 应该是一个合理的数目。如果你的系统会出现 proc table full 的讯息的话,可以就把它设大一点,例如 128。除非您的系统会需要同时开启很多档案,否则请不要设定超过 256。

13> kern.ipc.nmbclusters

这个值用来调整系统在开机后所要分配给网络 mbufs 的 cluster 数量,由于每个 cluster 大小为 2K,所以当这个值为 1024 时,也是会用到 2MB 的核心内存空间。我们可以简单的估计出大约需要的大小,例如,假设我们的网页同时约有 1000 个联机,而 TCP 传送及接收的暂存区大小都是 16K,则最糟的情况下,我们会需要 (16K+16K) * 1024,也就是 32MB 的空间,然而所需的 mbufs 大概是这个空间的二倍,也就是 64MB,所以所需的 cluster 数量为 64MB/2K,也就是 32768。对于内存有限的机器,建议值是 1024 到 4096 之间,而当拥有海量存储器空间时,我们可以将它设定为 4096 到 32768 之间。我们可以使用 netstat 这个指令并加上参数 -m 来查看目前所使用的 mbufs 数量。

当我们要修改这个值是,必须在一开机就修改,所以只能在 /boot/loader.conf 中加入修改的设定,例如:

kern.ipc.nmbclusters=16384

14> net.inet.ip.fastforwarding

如果打开的话每个目标地址一次转发成功以后它的数据都将被记录进路由表和arp数据表,节约路由的计算时间,但会需要大量的内核内存空间来保存路由表。

基于TCP的分布式IM架构

IM框架由一个根网关服务器RootServer和一个数据中心DataCenter以及多个分布式服务器集群ChatServerCluster组成;

RootServer:根网关服务器,基于libfdk的高并发TCP服务器fdkrootserver;
DataCenter:在FreeBSD上搭建PostgreSQL;

一个服务器集群ServerCluster, 由
LoginServer(1#), GateServer(1#),
ChatServer(10#),
StateServer(2#), OfflineMsgServer(2#),
给 1M个用户提供正常的聊天服务;
除了登录验证, 不进行任何数据库操作, 在线状态管理全部交给分布式StateServer存储(Key-Value), 跨ChatServer的聊天通过GateServer检索StateServer确定Client的位置, 进行数据转发;
离线消息全部存储到 OfflineMsgServer中。

  1. LoginServer:登陆服务器, 基于libfdk的高并发TCP服务器fdkloginserver, 负责以下两个功能模块:
    • 用户登录验证, 向数据中心请求登陆验证信息;
    • 本集群内的聊天服务器负载平衡。
  2. GateServer:网关服务器, 基于libfdk的高并发TCP服务器fdkgateserver, 负责本集群内所有用户所在ChatServer的定位和查找,以及聊天消息的转发。
  3. ChatServer:聊天服务器, 基于libfdk的高并发TCP服务器fdkchatserver, 设计每一台服务于100K个客户端的聊天逻辑;
  4. StateServer:状态服务器,管理所有用户所在的服务器,由多台memcached组成分布式的位置信息管理 ;
  5. OfflineMsgServer:离线消息服务器,由多台memcached组成分布式的离线信息管理;

1)问题:每个集群的离线消息存储在本地,当客户端登录时,如何完整的获得离线消息?
SpriteRay:当用户B向离线用户A发送消息,ChatServer把B->A的离线消息存储在本地的OfflineMsgServer中,当A登录时,检索完在线用户后,顺带检索一下所有服务器集群,自然会获得所有离线消息,由客户端进行所有消息的排序。

libmemcache和queue.h的冲突

最近前段时间对libmemcache进行封装,准备加入到libfdk中,

由于memcached支持分布式查询,所以需要管理一个memcached服务器的列表,就想到了系统中自带的SLIST的宏,就在/usr/include/sys/queue.h中。

在编译的时候出现了一堆TAILQ的重复定义的错误。

less memcache.h,发现其中一堆从queue.h中截取的TAILQ的定义宏。

所以建议大家在编译的时候注意这个问题。

我的做法是,在memcache.h中加入#include <sys/queue.h>, 并注释掉那段对TAILQ定义的宏。

FreeBSD 8.0 新特性概览

前段时间在wiki.freebsdchina.org中看到了FreeBSD8.0的新特性,总结了自己关注的几个特点:

第一、AMD64平台内核的内存上限增加

现状:提交至CURRENT, 合并回STABLE
将出现在8.0: 确定
作者:Alan Cox
网址: 公告

一些时兴的功能(其中目前最引人注目的是 ZFS )需要大量的内核内存(与传统的磁盘高速缓存或系统可见内存容量无关) .直至目前为止,kmem_max 仅能分配到最高2 GB的空间,这点正在趋于紧缺。
此限制最近已增加至512 GB的。加上ARC 的 backpressur改善,这将会是ZFS 用户喜闻乐见的。

第二、内核级线程

现状:提交至CURRENT
将出现在8.0: 确定
作者:Julian Elischer
网址: 已提交信息

目前的内核线程实际上是“重量级”的进程在内核地址空间上运行。
这项改进引入了真正轻量级的内核线程, 消耗较少的底层资源(进程锁,内存映射表)。

第三、ULE 3.0: 为 SMP 优化的新调度器

现状:提交至CURRENT
将出现在8.0: 确定
作者:Jeff Roberson
网址: 已提交信息, 已提交信息, 公告

ULE 调度器的演变带来了支持细粒度的CPU粘着度的计算,同时将CPU的物理拓扑结构(缓存,多核,多socket )
并大大改善了线程绑定到CPU的支持.如此带来额外的功能(展现了分配特定 CPU 到 Jails 的可能性)和可观的性能改进。

第四、内核的NFS锁支持

现状:提交至CURRENT
将出现在8.0: 确定
作者:Doug Rabson
网址: 已提交信息, 公告

NFS的锁管理器改善了NFS锁(用来同步文件访问远程机器)在内核中的性能和行为。
新功能包括:多线程操作, 死锁检测, 与限定于服务器上的文档互动。

第五、NFSv4支持

现状:正在开发
将出现在8.0: 可能
作者:Rick Macklem
网址: 召唤测试者

NFSv4是NFS 协议的一个重大改动 ,它带来许多新的功能,如状态协议,性能方面的改进和更强大的安全特性( ACLs ,强认证). 直到最近, NFSv4支持在FreeBSD是不完整的(仅客户端),而且有些不稳定。新的开发目标是完成这一支持。
这一引进的 NFSv4 基础设施亦将采用新的取代原有的 NFSv2 和 NFSv3 服务端以及客户端。