应对信息泛滥

罗素以前说过有的人二十多岁就死去了,此后只不过重复以往的生活,八十岁才死去,从三十岁的角度来看,似乎我也开始走入这么一种怪圈,成为以前自己或许不会喜欢的无趣的人;而究其原因,我想信息泛滥导致失焦,而自己思考出利他度已或者以佛法来说的布施 这样的人生目标的时间还较短,也就容易被如今泛滥的信息所迷失,别人玩微博时我自己也玩微博,别人刷朋友圈时我自己也刷,今日头条好时我自己也用今日头条,但似乎除了不断地被动接受新的咨讯外,一种空虚感也随之而来;我想,是时候理一理头绪,对信息 进行一定的管控了。 从利他度已或布施的角度来看,前提是自己需要有一定的有,我想这些泛滥的信息中,的确有精华在,但如果少了有针对性的过滤,那么必然将疲于应付,最终沉淀的不多,因而能汇聚起来的有就少,这样将如何帮助他人或者布施呢? 结合自己近年来的兴趣与需求,我想除开技术上大的上我需要在如下两块信息上进行筛选,其他的信息基本上要做到忽略,以形成下意识过滤的习惯。 首先则是财经类的信息,这方面应当包括基础的知识,如宏观、微观经济的一些基础知识,国家与党的相关政策,我们生活在经济社会中,了解经济社会的运转规律,对于投资或者机会的把握,都会有很大的作用。 其次则是生特医疗类的信息,从投资上来看,我个人比较倾向于生活医疗类的公司,目前看基因新兴技术、医药新兴技术相比之前有了很大规模的发展,甚至一些癌症都可以得到有效的发展,因此,结合自己年幼时曾想学习生物的愿望,在今后的时光里,再投入一些精力去 学习,也不失为一件美好的事情。 当然,我也需要对于自己的主业技术进行一定的信息筛选,仍将关注点放在网络技术相关的深化,以及对于新兴网络技术的理解与把握中,以便指导自己将来与同道的相关朋友,做出一摊事业来。 定目标相对简单,更重要的则是执行,有时候我会想起自己在初中时早上四点超床晚上十点准时入睡的时光,那时的精力似乎是无穷尽的,且我给自己定了严格的学习计划,现在回忆起来,在信息泛滥失焦的状态下,基本上每天都是随信息漂流而活,我想,这很难使得自己 上述的目标得到执行,从佛法的角度来看,也即几无精进;因此,后续我需要针对上述的筛选出的信息类别,将对每周的时间进行初步的划分,合理的分配工作、家庭、学习的时间,以期让三十岁到四十岁这样的十年,自己在知识层面,能够得到更大的提升。 相信自己。

June 26, 2016 · 1 min · fortitude.zhang

linux max open files限制过小导致openvswitch工作异常

上篇分析了linux内核的netdev_max_backlog默认设置导致了openvswitch在大量virtual port转发异常的问题,本篇再额外记录一处与大量virtual port相关的调优点。 自openvswitch 2.x版本开始,ovs引入了多线程的支持,在非dpdk即传统的ovs应用模式下,多线程主要用于处理内核fastpath lookup miss的流表,此过程称为upcall;并对这些流表进行统计、老化处理,此过程称为revalidate。 upcall和revalidate的线程数量计算,以openvswitch 2.3.x为例,代码中的判断是将物理核数约3/4分配给upcall,而revalidate则占1/4,这个分配直观上是合理的,毕竟upcall处理转发,要尽可能的快,处理能力也要更强。 而我们知道openvswitch datapath对用户态的每个virtual port都会在linux内核datapath中创建一个vport,内核datapath通过netlink发送消息给upcall,为了更快的处理每个vport的upcall请求,openvswitch将会为每个virtual port分配等同upcall线程数量的netlink socket,内核datapath根据flow hash将同一vport的upcall分发给不同的netlink socket,实现不同upcall线程间的并发处理,提升upcall性能。 从这里可以看出,openvswitch在优化性能方面确实做足了功夫,但这里确存在一个值得考虑的地方,我们知道linux process存在一个max open files的限制,当限制达到后,新的fd将无法被分配,导致建立文件、创建socket等需要用到fd资源的操作无法执行。 那么我们可以估计一个24 physical core的系统上,如果有2000个virtual port,openvswitch将会有多少个netlink socket,24 3/4 2000即36000,也即单音用于处理vport的netlink socket就占用了36000个fd,如果对openvswitch的max open files限制过小,很容易导致在大量virtual port下,出现各种工作异常。 对于此问题主要的优化思路如下: 调整ovs-vswitchd进程的max open files limit上限,可按照前述算法估量 openvswitch提供了一个n-handler-threads的配置,可通过ovs-vsctl持久化配置,根据性能需求适当的减少upcall线程数量

April 24, 2016 · 1 min · fortitude.zhang

linux内核netdev_max_backlog设置在极端情况下导致openvswitch转发不通

近期在调试问题时,遇到了一个从配置上看openvswitch无任何问题,但却导致转发不通的问题,特此记录下说,说明在openvswitch在大规模部署时,仍需要有较多调优之处。 设想如下openstack场景,大量tenant router通过linux namespace即仿真vrouter访问外网,此namespace中通过openvswitch internal port(或veth,如果不追求转发性能)连接到另一公网namespace,此时如果公网namespace中接口数量过多,比如说2000个(比如openstack中的qg-*接口),将有可能面临转发不通的情况。 从openvswitch的角度,我们知道openvswitch在内核态存在一个datapath,负责生成内核流表,实现高性能转发,对于一个拥有上千个port的ovs bridge来说,比如对应于上面的公网namespace,收到一个arp请求报文,由于是广播,报文通守openvswitch在userspace命中默认的normal流表后将推送广播至其他所有成员端口的内核流表,此后arp报文广播复制逻辑将在内核datapath模块处执行,最终命中以下内核代码: :::c /* * enqueue_to_backlog is called to queue an skb to a per CPU backlog * queue (may be a remote CPU queue). */ static int enqueue_to_backlog(struct sk_buff *skb, int cpu, unsigned int *qtail) { struct softnet_data *sd; unsigned long flags; sd = &per_cpu(softnet_data, cpu); local_irq_save(flags); rps_lock(sd); if (skb_queue_len(&sd->input_pkt_queue) <= netdev_max_backlog) { if (skb_queue_len(&sd->input_pkt_queue)) { enqueue: __skb_queue_tail(&sd->input_pkt_queue, skb); input_queue_tail_incr_save(sd, qtail); rps_unlock(sd); local_irq_restore(flags); return NET_RX_SUCCESS; } /* Schedule NAPI for backlog device * We can use non atomic operation since we own the queue lock */ if (!__test_and_set_bit(NAPI_STATE_SCHED, &sd->backlog.state)) { if (!rps_ipi_queued(sd)) ____napi_schedule(sd, &sd->backlog); } goto enqueue; } sd->dropped++; rps_unlock(sd); local_irq_restore(flags); atomic_long_inc(&skb->dev->rx_dropped); kfree_skb(skb); return NET_RX_DROP; } 可以注意到在上面的代码中有一个对sd->input_pkt_queue的检查过程,而sd是每个cpu核心net rx soft irq用于维护待处理报文的队列,netdev_max_backlog则是内核所提供的一个配置选项,默认为1000。 ...

April 23, 2016 · 1 min · fortitude.zhang

观音莲与心经

佛教里讲无常与缘起,近来反复背诵心经,走路时背诵,健身时背诵,之前难以坚持的事情,因着背诵,也能坚持起来,冥冥中遇上佛经,也算缘份的例子了。 晚上与同事外出就餐,顺便想去超市买个杯子,而路上遇到售卖绿植的,心想回来路上再遇到,就买一小盆回家,装点一下自己在这陌生城市小屋的一角,然而超市里因为活动人头攒动,而也无适合的杯子,于是出来折返,所幸卖绿植的老人还在,看中一株只卖十元的看似莲花的小绿植,欣然买来,回家查阅后,原来名为“观音莲”,而心经中开首句即为“观自在菩萨”,也再算缘份的另一个例子了。 附上心经原文,此后仍将信心持诵,以期远离颠倒梦想,心无挂碍。 般若波罗蜜多心经 观自在菩萨行深般若波罗蜜多时 照见五蕴皆空度一切苦厄 舍利子 色不异空空不异色 色即是空空即是色 受想行识亦复如是 舍利子 是诸法空相不生不灭 不垢不净不增不减 是故空中无色无受想行识 无眼耳鼻舌身意无色声香味触法 无眼界乃至无意识界 无无明亦无无明尽 乃至无老死亦无老死尽 无苦集灭道无智亦无得 以无所得故 菩提萨陲依般若波罗蜜多故 心无挂碍无挂碍故 无有恐怖 远离颠倒梦想究竟涅盘 三世诸佛依般若波罗蜜多故 得阿耨多罗三藐三菩提 故知般若波罗蜜多 是大神咒是大明咒 是无上咒 是无等等咒能除一切苦 真实不虚 故说般若波罗蜜多咒 即说咒曰揭谛揭谛 波罗揭谛 波罗僧揭谛菩提娑婆诃

March 6, 2016 · 1 min · fortitude.zhang

emacs与konsole不对付的那点事

作为Linux重度用户,折腾过各式各样的WM/DE,最终还是觉得KDE PLASMA的易用性和美观程度是最佳的,考虑到不折腾的缘故,一直使用KDE至今,虽则时有crash,但总体上不优点大于缺点,瑕不掩瑜。 在linux上,存在较多的终端仿真器,即terminal emulator,所谓的仿真器就是把图形系统即X窗口上的键盘输入,转化成virtual terminal的输入,传送给那些将标准输入关联在/dev/pts这些伪终端设备上的控制台程序,使得这些控制台程序能够像在文本模式下那样工作。 这些仿真器中就包括KDE自带的konsole。 但konsole有一个问题就是,如果我们在终端仿真器里进行emacs -nw即文本模式的emacs(图形模式下不存在下面所述问题),则ctrl+2/ctrl+2这个emacs默认用来激活mark的命令大概率不能用,当然ctrl+space也可以用,但对于中文用户而言,ctrl+space大多绑定到输入法中英文切换,相应的键不能用,还是带来了诸多不便。 由于konsole可以通过手工设置key binding,因此可以手工将ctrl+2这个键绑定到发送\0这个控制序列给终端程序,来解决此问题,但对于适应了ctrl+@这个相似功能的键位的用户来说,目前key binding无法设置,仍是非常不便。 https://bugs.kde.org/show_bug.cgi?id=341157 KDE社区有人提了类似的bug,且已经解决,但似乎只解决了西语用户所关注的ctrl+space问题,但ctrl+@这个仍未解决,我已经提供了相关的反馈,期待进一步的进展。 :::console fortitude@fortitude:~$ konsole -version QCoreApplication::arguments: Please instantiate the QApplication object first Qt: 5.5.1 KDE Frameworks: 5.19.0ppp Konsole: 15.12.2 由于C++代码不够熟悉,自己也没有过我的精力去钻研这里,就先写在这里,供遇到相似问题的朋友参考关注。

March 1, 2016 · 1 min · fortitude.zhang

当下与将来

近来在读关于正念的一书中,因正念源自《大念处经》,其中正念的一个首要的修行法门即所谓的“四念处”,其中一处即观心无常,简单说就是要知道心念潮起潮落,因此正念的核心就是通过了知心念变幻,因此也将心所控制住,停留在某事某物,也即住于当下。 对我而言,这点让我思考了许久,近年来,生活上发生很多的变化,因此也接触到更多人与事,烦恼也随之而来,尽管我不常怀旧甚至之前提到有些担心怀旧,但对于将来的思量,无法是憧憬或者担忧,总让我似乎难以住于当下,每每做事时,往往容易心念起伏,因此当下种种,往往难以深入体味并了解,不是我过生活,而是被生活所过。 刚过去的春节里,因为妻子需要上班的缘故,我在陪伴她之余,罕见的花了时间读了一些书籍,这些与佛教多少有关的书籍带给我了一种全新的视角,相比之前看过诸多活在当下的书籍,或许是我的心绪变化,抑或是年纪增长的原因,突然觉得如今算是少有所悟的感觉,因此我也愿自己能够在此刻,以及以后的每天,能够更踏实的度过每分每秒,与生活紧密的融合。

February 16, 2016 · 1 min · fortitude.zhang

初一之思

佛经里讲究因缘际会,农历初一前回家,妻子因工作仍需上班,我独坐书房,因不愿常对电脑,书架上找来似乎是当年于北京八大处所领的几本佛经,其中一本为《金刚经●心经》,其中《金刚经》为佛教经典,随手读来,竟然十分有趣,而先前为解自己心理问题,买得《图解正念》一书并读来十分受用,而“正念”概念,恰是来自于从佛教开辟的概念,两者前后忽应,莫不是让我开始了解佛经以求解脱的契机? 前些时常思量此生应如何度过,终得利他度已这样的想法,而如今以《金刚经》中所提布施是积累福报之途径,从这点来看,我给自己定的人生目标与佛经教化更为契合,实为一幸事。 因工作前往杭州,而暂居苏州,苏杭两地,寺院殊多,将会为我之修心带来不少便利,此为地利。 《金刚经》中的核心为四句偈“一切有为法,如梦幻泡影,如露亦如电,应作如是观”,大学时似乎听人讲过,印象深刻,但大多停留于词藻,如今读经而思,方知停留于词藻之肤浅,亦难对无住之意;未来出世入世,需好好思量。 记于猴年初一。

February 8, 2016 · 1 min · fortitude.zhang

OpenStack网络方案近期状态分析

目前OpenStack网络方案存在有较多的选择,liberty发布已经有大半多时间,mikata版本也快要发布,有必要比较一下近期各种openstack网络方案的状态。 主流方案介绍 当前,比较主流的方案有如下几种: ovs-agent ofagent ovn dragonflow midonet/opencontrail 除此之外,还有一些闭源的商业方案,如nsx、plumgrid,以及一些试验性的开源方案如networking-odl等,本次分析暂不考虑。 现有网络方案特性集及特点 ovs-agent 功能点支持情况备注L2 isolation using overlayY支持vlan/vxlan/grearp responderY要求ovs 2.1 + l2pop使能L3 DVRY要求每台计算节点都需要安装l3-agent,通过netns及linux协议栈实现ovsdb nativeY独立功能,与openflow native无关,可单独开启,有一定的性能提升openflow nativeYovs-agent将内置ryu,运行一个of app用来处理与本地ovs的交互,基本逻辑与原ovs-agent相似,通过driver机制实现不同方式的bridge操作,目前仍处于实验阶段security groupY目前仍基于iptables,随着ovs conntrack功能的完善,可以演进至基于ovs conntrack实现dhcpY仍采用dhcp agentnorth-sourth流量Y仍采用l3agent进行集中式转发,即便在dvr模式下 ofagent 如同ofagent在openstack上的wiki所述: OFAgent is a neutron core-plugin, implemented as ML2 mechanism driver. It aims to support pure OpenFlow1.3 switches. ofagent关注的更多是指向向设备(如vswitch/pswitch)可移植性,因此基于纯openflow协议进行实现,而纵观业界,基本上没有基于纯openflow的openstack网络方案(目前仍成功商用的则是bigswitch的big fabric,但其采用了深度修改的openflow),因此这种方式可能是过于理想化的方案,可能并不一定能够容易落地。 从ovs的状态来看,ovs 2.5中为支持conntrack,引入了ct_state/ct这样的match/atction,这些nicira扩展落入openflow spec的时间点可能还比较长,而为了实现dv足够多的功能,ovs将会继续引入扩展,如果基于纯openflow实现的话,这些功能都将难以利用。 从wiki上的比较来看,ofagent也不支持dvr,实现上同样基于ryu,而部署模式上与ovs-agent相似,在compute/network节点都需部署。 ovn ovn是由vmware所主导的新项目,其介绍如下所示: OVN, the Open Virtual Network, is a system to support virtual network abstraction. OVN complements the existing capabilities of OVS to add native support for virtual network abstractions, such as virtual L2 and L3 overlays and security groups. Services such as DHCP are also desirable features. Just like OVS, OVN’s design goal is to have a production-quality implementation that can operate at significant scale. ...

January 31, 2016 · 2 min · fortitude.zhang

关于网卡VXLAN offload能力的误解

网络技术这个行业里,厂商通常会对一些技术做出高大上的包装,像网卡VXLAN offload这种技术,就是一个典型的例子,然而其底层技术,也许并不像想象中的那么神秘。 做为网络交换机的开发人员,近年来一直从事数据中心网络虚拟化的相关工作,最近读取一篇关于青云SDN 2.0的文章,里面提到了采用网卡VXLAN offload这种技术后overlay情形下的虚拟网络性能得到了较大规模的提升,考虑到后续我亦将加入云计算公司进行网络虚拟化相关的研发,自然也十分想了解这种技术的底层实现如何,以便从理论上分析其性能是否具有较大的价值。 分析之前,稍微VXLAN的封装格式进行简单的说明,本质上VXLAN类似于一种l2vpn技术,即将二层以太报文封装在udp报文里,从而跨越underlay L3网络,实现不同服务器或不同数据中心间的互联,其格式总结如下: |ETH_HEADER|IP_HEADER|UDP_HEADER|VXLAN_HEADER|INNER_ETH_HEADER|INNER_IP_HEADER|…| 在采用VXLAN技术后,由于vm/docker的报文被封装于外层的UDP报文中予以传输,使得以往的TCP SEGMENT OPTIMIZATION、TCP CHECKSUM OFFLOAD等功能对于内层VM的TCP数据收发失效,较大地影响了VM间通信的性能,给最终用户带来了很差的用户体验。 下面我们来看看不同的方案都是如何实现的: 支持Overlay的交换机 目前较新的万兆交换机大多支持Overlay功能,即支持将以太报文封装在VXLAN报文中予以转发,也即将VXLAN封装功能放在专用的网络设备上,来提供确定性的线速转发性能,但这很明显增加了交换机与服务器之间的耦合,给管理维护带来了一定的复杂度。 NIC VXLAN OFFLOAD 而网卡VXLAN offload则不像Overlay交换机那样要求对组网方案进行较大的变更,而是对于网卡的能力进行了增加,与网卡驱动配合,使得网卡能够知晓VXLAN内部以太报文的位置,从而使得TSO、TCP CHECKSUM OFFLOAD这些技术能够对内部以太报文生效,从而提升TCP性能。 以TSO为例,内核封装出的TCP报文如下: |ETH_HEADER|IP_HEADER|UDP_HEADER|VXLAN_HEADER|INNER_ETH_HEADER|INNER_IP_HEADER|INNER_TCP_HEADER|INNER_TCP_DATA_NEED_TSO| 该报文的内部TCP数据需要进行TSO处理,即切成满足网卡MTU的报文,内核驱动将报文通过DMA送给网卡后(同时要提供一些元信息,如VXLAN头位置等),网卡负责将内部的TCP报文转换为多个内部TCP报文,封装相同的外层VXLAN头后进行转发,从而减少CPU的干预,大规模提升性能。 小结 个人认为VXLAN OFFLOAD这个名字不如用VXLAN-AWARE OPTIMIZATION比较直观,但厂商为了吸引眼球,自然是需要适当的包装,可以理解。 从实现的角度来说,万兆甚至更高性能的网卡本来就比较贵,这样的优化可能并不一定导致过高的复杂度,但在实现上却能够不依赖于OVERLAY交换机更实现性能的提升,应该是做为优化OVERLAY性能的首选方案。

January 9, 2016 · 1 min · fortitude.zhang

三十而立

今年阴历生日与阳历生日巧妙的重合了,按理说在这样的时间里,我是适合来写篇文章留做纪念的,然而总不能抽出时间给自己思考,或者说自己潜意识里在抗拒着思考,于是拖了半周,终于想起来这个未完的事情,在这寒冷的冬夜里,与自己对对话,写点给未来自己看的话来。 买房装修是一件非常花时间的事情,一五年似乎除了搬进新家,没有太多能够留在记忆里的事情,前些时间加了四五年前在北京时的旧同事,提到一些共事不久的旧同事,我似乎都已经想不起来了,我打上大学时就觉得自己记忆很短暂,比方说那时我就很难记起自己的童年时光,仿佛那些光阴都被时间抹成了空白,或许这样挺好,使我总能够不被过去所累,能够更好的向前前行。 三十岁到来前,我做了很多思考,始终还没能弄清楚自己在这既长又短暂的人生中的使命,子曰四十不惑,或许我修为未到,亦或圣人在年老时回忆过去,也发现自己三十与四十之间,仍有很多的疑问未能够解答吧,我想这思考求索的本身,也许也是使命的一种。 上周末老友来苏,借着周末陪同他逛了苏州的网师园,雨天的园林静美,我对园林中的对联及字画感到十分有兴致,加之近来我回忆起十多年前买书时首次读到的甪直古镇,使得自己定居苏州得到了合理的解释,这似乎是多年心愿的达成,只是我需要更多的时间来解读这个自己过去便种下渴望的城市。 展望未来五年,我对自己的期望是首先能够准备好心态,迎接孩子加入我和妻子的二人世界,让这个家里多些孩子笑声所带来的温暖与快乐;其次是自己能够更多的创造出更多的让自己觉得惊喜的事情,能够让自己体会到创造的乐趣。 未来是有无限可能的,但我想还是要脚踏实地,幻想在二十多岁的年纪是可以的,而三十岁后,应该更多靠智慧与拼搏。 加油,未来。

November 29, 2015 · 1 min · fortitude.zhang