用NVME提高群晖NAS的性能

群晖的DSM有一个比较鸡肋的功能:SSD Cache,原因如下:

  1. 单条NVME只能做只读Cache,功能有限
  2. 一个SSD Cache只能加速一个存储池(DSM 6.2中的词汇,以前叫存储空间)
  3. 系统分区不在任何存储池里,所以系统分区上的东西都不能加速
  4. NVME只能做Cache,不能用来存数据

DMS的SSD Cache功能是基于Linux的dm-cache来实现的,理论上通过Hack是可以解决上面说的这些问题的,不过得摸透了DSM相关的所有逻辑才能搞,而且对DSM的侵入比较大。所以,有一个想法,直接解决第4条问题,想办法把NVME当成正常的磁盘来存数据。然后就可以按自己的想法,灵活地挑一些需要高速随机IO的数据放在NVME上,其它的数据还是放在磁盘上。

如果问群晖的技术支持可不可以这样做,回答是否定的——非常可以理解,在群晖的设备上,盘位就是钱,白给你增加两个盘位?想都别想。

研究了一番,找到了解决这个问题的办法,虽然不完美,但是可用,并且效果不错。以下内容基于DS918+的硬件,DSM 6.2,系统中所有的磁盘都是Basic模式。由于条件所限,我没有测试RAID或SHR的情况,但原理应该都是一样的,可以参考一下我的思路。DSM的RAID就是标准的Linux RAID,而SHR则是基于LVM搞出来的。

以下步骤请充分理解后自行操作,所有给出的命令仅供参考,切勿依样画葫芦。这里介绍的方法有可能会造成不可逆的数据损失,请自己评估风险。

1. 分区

安装NVME后,系统中会出现/dev/nvme0n*设备,并且在存储管理器中可以看到对应设备。不要在DSM中创建SSD Cache,因为我们准备自己管理这个硬件。

Basic模式下,DSM会把系统中的每块硬盘都分成三个区:

Device      Start         End     Sectors Size Type
/dev/sdd1    2048     4982527     4980480 2.4G Linux RAID
/dev/sdd2 4982528     9176831     4194304   2G Linux RAID
/dev/sdd3 9437184 11720840351 11711403168 5.5T Linux RAID

第一个分区用于存放DSM系统,第二个分区是SWAP,第三个分区是用户可用的存储空间。每块磁盘的前两个分区,分别组成/dev/md0和/dev/md1两个RAID设备,都是RAID 0的模式。

所以,我们也依样画葫芦,把NVME也用相同的方式分区(可以使用系统自带的parted工具),分出与别的磁盘大小一样的前两个分区,类型都设置为RAID。然后剩余的空间分为普通Linux分区,并格式化为你需要的文件系统(ext4或btrfs)。当然,如果你有多块NVME或者你愿意,你也可以把剩余空间分为RAID类型,创建md设备后再格式化。

2. 创建RAID组

分完区后,扩展md0和md1,把NVME的前两个分区,加到这两个RAID组中。

# 如果是2盘位的设备,大概只需要扩展成3就可以了 
$ sudo mdadm --grow --raid-devices=5 /dev/md0 
$ sudo mdadm --grow --raid-devices=5 /dev/md1
$ sudo mdadm --manage /dev/md0 --add /dev/nvme0n1p1
$ sudo mdadm --manage /dev/md1 --add /dev/nvme0n1p2

然后,把第三个数据分区mount到一个你喜欢的位置,比如:

sudo mount /dev/nvme0n1p3 /volume1/homes/admin/nvme

考虑到NVME和磁盘混合组成RAID,可以把所有磁盘(不包括NVME)的对应分区设为writemostly,这样可以让读操作尽量走NVME,提高性能:

sudo echo writemostly | tee /sys/block/md0/md/dev-sdX1/state
sudo echo writemostly | tee /sys/block/md1/md/dev-sdX2/state

这样做完以后,系统分区和SWAP分区都已经可以被NVME加速了。这一步是完全没有风险的,因为即使未来NVME从RAID 0组中意外丢失或损坏,也不会造成任何数据问题。

同时在DSM中,正常访问home/nvme就是访问NVME上的内容,这个目录可以当作普通的存储空间来使用,存放一些需要高速随机IO的数据。

3. 迁移数据

为了达到更好的性能,我们还应该把一些常用的对IO性能敏感的东西迁移到NVME上,包括但不限于:

  1. 系统的PostgreSQL/MariaDB数据库,通常位于/volume1/@database,但也可能分布在多块盘上
  2. 软件包,通常位于/volume1/@appstore,但也可能分布在多块盘上
  3. CloudSync的SQLite数据库,通常位于/volume1/@cloudsync
  4. Docker的镜像和容量数据,通常位于/volume1/@docker
  5. VMM的虚拟磁盘文件,通常位于/volume1/@Repository

迁移的方法很简单,先rsync,然后再mount –bind,比如:

sudo rsync -a /volume1/\@appstore/ /volume1/homes/admin/nvme/\@appstore/
sudo mount --bind /volume1/homes/admin/nvme/\@appstore /volume1/\@appstore

理想情况下,应该先把相关服务停止后(用synoservice命令可以启停服务)再迁移数据,避免迁移过程中有新数据写入造成不一致。为了保证万无一失,建议可以写个迁移脚本,在系统启动过程中所有服务还没有启动前运行一下这个脚本。

这一步是有风险的,因为万一未来某一次mount –bind没有成功或者没有做mount –bind,系统就无法访问到正确的数据了,这对于系统数据库之类的,还是有一定影响的,会造成数据不一致。

4. 重启自动生效

写一个脚本,用于在未来重启时重建RAID和mount相关目录,比如:

# 先把NVME上的数据盘mount起来
mount /dev/nvme0n1p3 /volume1/homes/admin/nvme
# 把SWAP的RAID 0扩容,并把NVME上的分区加进去
# 系统分区不需要,因为会自动完成。
# 但SWAP的RAID每次重启都会重建,所以每次都需要扩容。
mdadm --grow --raid-devices=5 /dev/md1
mdadm --manage /dev/md1 --add /dev/nvme0n1p2
# 把相关的目录mount --bind上去
mount --bind /volume4/homes/admin/nvme/\@appstore /volume4/\@appstore
mount --bind /volume4/homes/admin/nvme/\@cloudsync /volume4/\@cloudsync
mount --bind /volume4/homes/admin/nvme/\@database /volume4/\@database
mount --bind /volume4/homes/admin/nvme/\@docker /volume4/\@docker
mount --bind /volume4/homes/admin/nvme/\@Repository /volume4/\@Repository
# 重新设置RAID writemostly策略
echo writemostly > /sys/block/md0/md/dev-sda1/state
echo writemostly > /sys/block/md0/md/dev-sdb1/state
echo writemostly > /sys/block/md0/md/dev-sdc1/state
echo writemostly > /sys/block/md1/md/dev-sda2/state
echo writemostly > /sys/block/md1/md/dev-sdb2/state
echo writemostly > /sys/block/md1/md/dev-sdc2/state

修改/etc/rc,在SYNOINSTActionPostVolume这一行后面,增加一行对上述脚本的调用。SYNOINSTActionPostVolume执行完后,刚好是所有磁盘都mount好但是没有任何服务启动的时刻,所以这时做mount –bind是最合适的。如果你第三步数据迁移想在重启时做,也是加在这个位置。

这一步是比较不完美的,因为需要修改系统文件,而系统文件有可能会在更新DSM时被覆盖回去,万一被覆盖回去,系统启动后就是一个没有mount –bind的状态了,即使那时再改一遍脚本再重启,DB的一致性可能已经无法保证了。我暂时选用了一个带有一点防御性的做法(同样不是万无一失的):在更新DSM前,把/usr/sbin/reboot改名,这样更新完DSM后系统不会被自动重启,我就可以有机会检查/etc/rc有没有覆盖,如果被覆盖,可以自己改回来以后再重启系统。

5. 其它经验和坑

  • 数据迁移必须用mount –bind,不能用软链,已知有些应用组件在软链的情况下不能正常工作
  • /volume1/@tmp不能迁移到NVME,即使用mount –bind,也会造成Drive等组件不能正常工作
  • 现在的做法,NVME的第二个分区是后加到SWAP分区的RAID里的,所以每次重启都会有个重新同步的过程,IO会打高一会儿,并且完成后DSM会弹一个提示:一致性检查完成。但总体是可以忍的,所以我就没有去深究用什么方法可以在建立SWAP的RAID时就直接把它一起建进去了,因为我还是想尽可以少侵入DSM系统
  • 用户的共享文件夹也可以通过mount –bind迁到NVME上,但是这样做会造成在共享文件夹管理界面上不能正常查看共享文件夹相关信息,所以建议只对共享文件夹里的目录进行mount –bind
  • 如果你只有一条NVME,或者有两条但没有做RAID,那么迁移上去的那些系统文件都是单点(虽然原本在磁盘没有RAID的话是单点),需要留意其中的风险

2018新年好

2017年,我做了这些事:

– 网络生活

写了2篇博客,太懒了,除了开年的新年好和年末的新年音乐会两大作业文,2017年其它的内容居然什么都没写。其实有好几篇都在草稿箱里,只是都没有最终完成。博客空间总访问量31646 PageView(Google Analytics数据),数字下跌接近50%。跟前两年一样,依然是在吃老本,2010年和2013年写的几篇旧文章撑起了半边天。饭否发消息49条,其中包括照片16张。

calibre修了两个微不足道的豆瓣元数据获取的Bug,给Seastar修了一个微不足道的Bug。

继续维持Linux Kernel Patch Statistics网站的运行,处理各种用户反馈过来的数据问题。几次想重构这个网站,方案也想了好几版,但是还是没有着手去做。最初的思路是想写个Flink的任务,流式去处理新的Patch信息,然后更新统计结果。后来仔细想了想,其实不用这么复杂,就目前的数据规模,直接把原始往数据库里一塞,然后正常查询就足够了。同时数据精准度也还有待进一步提高,但是这个主要是人肉工作,有不小的难度。期望2018年能把这个事情落地了。

– 几个IT产品

Amazon Echo Dot:对智能音箱的第一次尝试,总体感受是低于期望值。最重要的原因是它并不面对中国市场,所以很多功能并不适合在中国使用。最明显的就是在音乐播放这个功能上,无法识别中文歌名就是一个硬伤,播放自有音乐也非常困难。在智能家居方面,跟Home Assistant可以有一定程度上的集成,但是在国内依然用处不大。所以目前已几乎闲置。

天猫精灵:公测时第一批买到的,支持中文就是它最大的优点,智能家居的功能目前在国内也比Echo要稍稍接地气一点。从公测到现在有快半年时间了,能够看到它的明显进步的。目前在家里还是经常使用它的音乐、提醒、天气时间、智能家居等功能的。不过在有魔盒、魔盘等产品在先,我个人是不看好这类天猫XX的硬件产品的未来的。

SONY MDR-1000X蓝牙降噪耳机:在上下班的大巴上使用,降噪效果还是不错的,可以把音量保持在比较低的程度。不过这个产品有时会让我的耳朵产生胀痛的不适感。但是我其实一直没想明白,降噪的原理是把噪音声波的相位颠倒一下播放,那是不是就等同于一直有跟噪音音量相同的声音给灌到我耳朵里了?音量虽然开低了,但这个降噪的声音本身会不会损伤耳朵呢?

Brother PT-1230PC标签机:用几次就会吃灰的东西,所以买了个廉价的全新二手机器。接电脑使用是一件很不方便的事情,好处是可以完全自定义打印的内容。每次打印都会浪费很长一段标签纸,所以最好一批多打印几个才环保。然而它没有自动半切的功能,所以打印完以后还要手工把标签一段段的剪开(即使一次只打一个,也得手工剪掉前面浪费的那一段),这才是这个机器最不方便的地方。淘宝上的廉价耗材完全堪用,除了标签薄一点、表面光泽度稍差,在家用环境下应该都没有问题。

佳能CP910照片打印机:也是一个大部分时间吃灰的东西,所以也是买了个廉价的全新二手。现在偶而会有临时打印照片的需求,家附近的照相馆的打印的价格坑爹不说,主要是打印效果惨不忍睹,而线下或在线冲印服务则时效性不够。总体来说,对这个产品是满意的,打印的品质稍逊于冲印的品质,锐度和饱和度稍差。但是可以自己把屏幕调到跟打印出来的效果一致,这样就不用担心PS得好好的照片打出来不合心意了。

Synology DS918+:又换了个NAS,去年买的916+才用了一年多就把它换掉了。原因是新机器比旧机器便宜,买新卖旧,损失不大,而新机器可以支持NVME的SSD Cache,这样就不用浪费宝贵的硬盘槽位来做SSD Cache了。然而现实却并不美好,Synology的SSD Cache只能对一个存储空间生效,并且不会对系统文件分区进行加速,而且只用一条SSD时,只能进行只读Cache,所以除了在使用VMM时有那么一点点小作用以外,其它时候几乎都感受不到SSD带来的加速作用。

玩客云:迅雷出的“NAS”,背后的风起云涌的故事我就不讲了,反正我原价买了两个,卖了一个留了一个,就等于白拿了一个还有得赚。跟群晖比,这个东西真是连NAS都算不上,而且从安全性、可靠性等角度来说,我根本不敢用它。但是我非常喜欢它的思路,这才是普通人可以用的NAS:插上硬盘就能用,不用太担心内网、外网、端口映射的问题(群晖的QuickConnect?只能呵呵它一下了),没有文件、文件夹的概念,放进去的就是照片、视频、文档这样的数据,直接自动归类放好、视频文件自动下载元信息,需要的话可以手工再添加标签来分类。这样的产品用来做手机存储的扩展和备份,非常方便。

博朗耳温枪IRT6520:2016年买了一个,2017年又买了一个,必须专门拿出来黑它一下。山寨做工就不说了,操作繁琐也不说了,重点是太太太容易坏了,而且几乎没有质保。2016年我是亚马逊闪购买的,无质保。2017在京东超市自营买的,坏了依然需要自己跟代理商扯皮。一气之下直接联系了京东客服投诉,京东售后自己给兜底了,换了个新的。现在每次用还是提心吊胆的,不知道什么时候就又会测温不准了。

荣耀V9手机:三年内买的第6个荣耀手机,现在半家人都在用荣耀手机。华为的产品不良心,但还算省心。荣耀虽然硬件各种缩水,但是日常用用还算够。V9的屏幕色彩调得有点夸张,乍一看还挺惊艳的,但是仔细看还是掩盖不了它的低端屏幕的本质。NFC当公交卡很好用,指纹解锁我也一直觉得国产手机全都可以秒杀同时期的iPhone。

戴森V8 absolute吸尘器:跟只有它价格十分之一不到的某型号的小狗吸尘器来比较,它工作时的表现确实是非常不错的。不过它的塑料件的质感和做工,真是对不起它的价格。另外,因为所有的主要部件(电机、电池)的重量都在手上,所以使用起来还是有点费劲的,尤其是使用短小的吸头清理小地方的时候。

– 出行

量子号邮轮,出行前只要多看看网站评价中的差评,就可以把自己的心理预期降低到一个合理的程度,然后就可以玩得很开心。邮轮旅行的陆地行程大都是坑爹的,正确的姿势就是充分享受在船上的休闲时光。

成都,对于不能吃辣又本来就不是吃货的我,成都算不上是一个“来了就不想走”的城市。大熊猫基地比想象的要有意思一些。

南京/江苏大剧院,江苏省终于有了一个说得过去的音乐厅。祖宾‧梅塔和以色列爱乐的演出,虽然比不上维也纳爱乐乐团,但也足够惊艳。期待2018年能有值得让我再专门跑一趟的演出。

千岛湖,一个除了休闲啥也干不了的地方。

展望2018年:

还是说点工作,2017年在工作上实现了从Java回到C++的转型,如果说C++ 14语言和纯异步编程带来的挑战还不是个大问题的话,真正的挑战存在于从简单业务代码开发转型为去做高性能底层系统的设计和实现。尤其是设计阶段需要参考很多现有的系统和论文,去理解它们的设计意图,去理解它们的实现机制,并在这个基础上找到适合自己的方案,在之前没有太多积累的前提下,非常难。

可以说,2017年的工作压力是相当的大,也是我自己第一次在工作中真正开始怀疑自己分析、解决问题的能力。不过在经历了系统的几次迭代后,似乎还是找到了一点点感觉,期待2018能更好的迎接新的挑战。

关注2018维也纳新年音乐会

曾经关注过的那些维也纳新年音乐会:关注维也纳新年音乐会

在2018年的新年音乐会上,我们将迎来一张熟悉的老面孔,他就是意大利指挥家里卡尔多‧穆蒂。穆蒂1993年第一次登上新年音乐会的指挥台,后来又指挥了1997年、2000年和2004年的新年音乐会,2018年他将第5次登上新年音乐会的指挥台。

实话说,刚开始的时候我并不是非常喜欢他,1997年我是第二次看新年音乐会的直播,看到穆蒂时,我不自觉地把他与前一年的指挥洛林‧马泽尔进行了比较,相比马泽尔生动的演出,穆蒂的演出显得要严肃一些,与新年的节日气氛有点格格不入。2000年没有看直播,看录播时就没了新年的气氛,加上开场那平淡如水的《大河圆舞曲》,这一年的音乐会也没有给我留下深刻的印象。倒是2004年的那一次,穆蒂选择的那些让人耳目一新的曲目,让我改变了对他的印象。但是那段时间有传闻说穆蒂已经表态以后不会再上新年音乐会,便只能放弃了对他的期待。所以,当年初时得知穆蒂会指挥2018年新年音乐会时,颇是激动了一番。穆蒂此次登台,也破解了传说中的“天体乐声大魔咒”——在新年音乐会历史上,波斯科夫斯基、卡拉扬、克莱伯这几位大师在演完这个曲子以后就都没有再上过维也纳新年音乐会的指挥台了,而穆蒂恰巧在2004年时选择过这个曲目。

2018维也纳新年音乐会CD封面

2018维也纳新年音乐会CD封面

来看曲目单:

  • 01 Johann Strauss II – Einzugsmarsch aus ‘Der Zigeunerbaron’ – 入城式进行曲,选自《吉普赛男爵》
  • 02 Josef Strauss II – Wiener Fresken; Walzer; op. 249 – 维也纳壁画圆舞曲 *
  • 03 Johann Strauss II – Brautschau-Polka; op. 417 – 相亲波尔卡(选自《吉普赛男爵》) *
  • 04 Johann Strauss II – Leichtes Blut; Polka schnell; op. 319 – 轻如鸿毛快速波尔卡
  • 05 Johann Strauss I – Marien-Walzer; op. 212 – 玛丽安圆舞曲 *
  • 06 Johann Strauss I – Wilhelm-Tell-Galopp; op. 29b – 威廉退尔加洛普 *

 

  • 07 Franz von Suppé – Boccaccio; Ouvertüre – 薄伽丘序曲 *
  • 08 Johann Strauss II – Myrtenblüten; op. 395 – 桃金娘花冠圆舞曲 *
  • 09 Alphons Czibulka – Stephanie-Gavotte; op. 312 – 史蒂芬妮加沃特舞曲 *
  • 10 Johann Strauss II – Freikugeln; Polka schnell; op. 326 – 魔弹快速波尔卡
  • 11 Johann Strauss II – Geschichten aus dem Wienerwald; Walzer; op. 325 – 维也纳森林的故事圆舞曲
  • 12 Johann Strauss II – Fest-Marsch; op. 452 – 庆典进行曲
  • 13 Johann Strauss II – Stadt und Land; Polka Mazur; op. 322 – 城市与乡村玛祖卡波尔卡
  • 14 Johann Strauss II – Maskenball-Quadrille; op. 272 – 假面舞会四对舞
  • 15 Johann Strauss II – Rosen aus dem Süden; Walzer; op. 388 – 南国玫瑰圆舞曲
  • 16 Josef Strauss – Eingesendet; Polka schnell; op. 240 – 读者来信快速波尔卡
  • 17 ?
  • 18 Johann Strauss II – An der schönen blauen Donau, Walzer, op. 314 – 蓝色多瑙河圆舞曲
  • 19 Johann Strauss I – Radetzky-Marsch, op. 228 – 拉德茨基进行曲

这次的新年音乐会选择了19个曲子,应该是一个比较合适的数字,不至于让穆蒂像2004年时那样赶场子。除了目前未知的第一个加演曲目,穆蒂选择了7首从未在新年音乐会上演出过的全新的曲目,其中还包括阿尔冯斯·齐布尔卡(Alphons Czibulka)的一首加沃特舞曲,他是一位奥地利的军人、作曲家、钢琴家、指挥家。

开场的入城式进行曲是新年音乐会的常客,看到这个标题,我的耳边就响起了它的旋律,好像新一年的音乐会就这样开始了,非常期待。

接下来就是两个新的曲子,不过相亲波尔卡是选自大家耳熟能详的轻歌剧《吉普赛男爵》,所以里面会有一些熟悉的旋律出现。

轻如鸿毛快速波尔卡在新年音乐会上演出过4次,最近的一次是2003年哈农库特指挥的,这个曲子我印象非常深刻,因为它的旋律一点也不“轻如鸿毛”,尤其是在被誉为“节拍器”的哈农库特演绎下,更是激烈无比,不知道穆蒂会给我们带来如何的感受。

音乐会上半场以老约翰的两首新曲子收尾,而下半场则以苏佩、约翰和齐布尔卡的三个新曲子开场,新曲子如此集中的出现,一定会成为本场音乐会最为吸引人的部分。

新曲子都演完以后,音乐会就进入了怀旧与经典的篇章。魔弹快速波尔卡,曾经在阿巴多指挥的1991年新年音乐会和巴伦博伊姆指挥的2009年新年音乐会中出现过,是一首适合加入“噱头”的曲子,不过这次把它放在下半场还未到高潮的时段,很可能就不会有什么特别的了。

旋律优美的维也纳森林圆舞曲则是新年音乐会的常客,已故的洛林‧马泽尔就多次选择了这个曲目,并自己拿起小提琴,演奏其中的独奏部分。这个曲子中还选用了一种奥地利的民间乐器——齐特尔琴,音色很特别。

庆典进行曲虽然只在1996年作为开场曲在新年音乐会上亮相过一次,它却是一首我熟悉得不能再熟悉的曲子,因为这是我第一次看新年音乐会时听到的第一个曲子。有着这样的情怀加成,这首曲子成为2018年新年音乐会中我最期待的曲子之一。

乡村和城市以及假面舞会,也都曾经在新年音乐会上出现过,却不是常客。其中假面舞会只在阿巴多指挥的1988年新年音乐会上出现过。阿巴多指挥过两次新年音乐会,选曲风格都很特别,也带来了不少争议,2018年是阿巴多诞辰85周年,不知道是不是这个原因,穆蒂才特别选择了两首阿巴多指挥过曲子。

南国玫瑰和读者来信,这两个曲子我都很熟悉,在新年音乐会上也出现过数次,其中读者来信穆蒂曾经在1997年选择过。穆蒂在16个正式演出曲目中,只炒了自己指挥过的一首冷饭,为他点个大大的赞。

十四年未见,非常期待穆蒂的再次亮相。

2017新年好

2016年,我做了这些事:

– 写了8篇博客

博客空间总访问量61198 PageView(Google Analytics数据),比前一年稍有下降,但是实际的访问量应该还没有这么多,因为发现Google Analytics结果中出现了相当数量的Spam数据,暂时还没研究怎么能去过滤掉。跟去年一样,首页、在Linux下使用“360随身WiFi 2”calibre常见问题为Raspberry Pi 2编译内核模块这几个页面的PV占去了总PV的50%多。饭否发消息85条,包括照片17张。

– 自由软件相关

接手了一个网站:Linux Kernel Patch Statistics。这个网站的内容是按人、公司、国家等维度的指标去统计各Linux内核版本中Patch的数量。我很偶然地看到有人在LKML中吐槽说这个网站的域名过期了。这个网站的作者是我以前的同事,于是我联系他提醒他,没想到他表示说不打算继续维护这个网站了。我觉得就这么放弃一个在社区有一定影响力的网站有点可惜,所以在征得他同意的前提下,把这个网站接了过来,并且还请朋友帮忙把过期的域名给抢注了回来。

网站恢复运行的不到一个月时间中,我已经收到各种数据订正、添加功能和Bug报告的邮件,看来这个网站的的价值比我想象的还大一些。不过这个网站的后台代码确实是经久失修,所以目前数据统计的精准度非常糟糕(因为根据邮件地址把数据按公司、国别来归类,这里面的映射关系绝大部分是需要人肉来维护的,一旦没有及时维护,归类为Unknown的数据就会越来越多,也就失去了统计的意义),而且每天一次全量数据产出过程需要占用大量的CPU、IO和内存资源。所以后面需要优先先维护一下基础数据,保证统计数据质量,然后再考虑下整体的重构问题。

calibre贡献了一点点代码,改写了一下从Amazon获取书籍元信息的插件,使之可以支持中国亚马逊网站。给HBaseFlink的代码/文档各修正了一处Typo,其实只是为了实践一下给这两个项目Contribute的流程,不过后来由于工作内容的变化,没有再深入关注过这两个项目。给C++异步框架Seastar修正了一处Bug。train-graph合并了一些其它人贡献的代码和数据,发布了一个3.0版本。

– 几个IT产品

群晖DS916+ NAS:淘汰了原来用的DS214play,主要是出于盘位和性能的考虑。不过新的机器的性能依然很让人捉鸡。不过出于对DSM系统版权的尊重,我还是没有选择自己买机器组黑群晖的方案。我的群晖系统的评价依然是:轻度使用很不错,重度使用时细节缺失很多、问题也很多。但是市面上已经找不出更好的了。

Macbook Air:公司提供的工作电脑,我的第二台苹果设备(N年前得到过一个iPod Nano)。这样的电脑用来做开发机实在是性能捉鸡,尤其是为了编译Linux程序再启一个Docker的情况下。公认的优点就不说了,缺点就是有些Windows能做的事情它还是不能做,而有些Linux能做的事情它也不能做。对于我这种已经被Linux虐了十年的人来说,不能做Windows能做的事是很容易接受的,但现在不能做的事的又变多了,所以还有点不爽,于是有了下面的Dell 7040m。

Dell 7040m微型台式机:为了更有效的开发Linux C++程序,买了这个微型台式机当工作机。配置成i7 6700T的CPU,16G内存,SM951的SSD,装Arch Linux。实际用下来整体能满意,但是就编译大型C++程序来说,单核性能仍然不是非常出色。另有同事买了相似配置的Intel的Skull Canoyo,也是差不多的体验。我也知道我的应用场景下应该买个标准台式机才能配置更好性能的CPU,但是谁让我这个机器的外型的毒呢?

华硕AC68U路由器:其实去年买的AC66U完全够用了,不过还是因为一次特价剁手了更高端一点的AC68U。整体使用体验与AC66U相仿。不过从外观来说,我反而还更喜欢AC66U一点,AC66U给人的感觉是做工精致、用料实足。AC68U其实也一样,但给我的感觉却是:傻大笨粗。

Raspberry Pi 3:没啥说的,我是树莓派的脑残粉,出一个买一个。相对2来说,主要就是64位、内置蓝牙和Wi-Fi,性能稍有提高,别的就没有了。树莓派是吃灰神器是名不虚传的,这个现在已经吃灰。还买了一个Sense HAT传感器模块,做了一个贪吃蛇游戏后也吃灰了。有了3以后,我用以前吃灰的2和Camera Module做了一个网络摄像头,配合群晖做监控,效果勉强凑合。

Pebble 2:本来是在Kickstarter预定了Pebble Time 2,但因为正在用的Pebble花屏越来越严重,等不及就先收了一个Pebble 2,没想到次日Pebble就宣布被fitbit收购了(我觉得与其说是收购,不如就当是破产了更合适),Time 2也没有机会再问世了。Pebble 2的使用体验与Pebble高度一致,我很满意,只可惜这已经是绝唱了。希望在它坏掉以前,能有更出色的产品出现。

二手Kindle Paperwhite 2:跟以前用的Paperwhite比,差别并不大,只不过因为Paperwhite被老妈重度使用中,所以自己重买一个。没买3是因为性价比,毕竟我也不是重度使用。而且看书这个单一需求来说,我并不觉得Paperwhite 1/2/3/Kindle Voyage有多大的差别。

二手Intel Compute Stick:我需要一台常开的Windows机器来满足把NAS上的照片上传到 Google Photos的需求,这个东西很符合我的要求,功耗不到5W,直接由路由器USB口供电就可以了。性能对于我来说也完全够用,有了它不但解决了Google Photos上传的问题,甚至我的电脑上已经不再需要安装Windows虚拟机了,偶而需要用Windows的时候,直接远程桌面连上去用就可以了。

– 出行

南京*3、合肥、西安。对南京的感情依然不变、合肥真不是一个旅游城市、第二次去陕西省历史博物馆已找不回第一次去时惊艳的感觉。

展望2017年:

谈点工作,在用Java写了4年业务代码后,2016年,我终于又回归了技术开发。在短暂地用了一段时间Scala后,还回归到了C++开发。说是“回归”,其实还是更大的挑战,因为需要用C++ 14来写一些高性能的分布式程序,对于我来说也仍然是一个全新的课题。期待2017年可以在这个方面能有所收获。

关注2017维也纳新年音乐会

曾经关注过的那些维也纳新年音乐会:关注维也纳新年音乐会,2017年将是我第22次收看维也纳新年音乐会的直播。

2017维也纳新年音乐会CD封面

2017维也纳新年音乐会CD封面

  • 01 Franz Lehár – Nechledil Marsch aus der Operette Wiener Frauen – 内西雷迪尔进行曲(选自喜歌剧《维也纳的妇女》)
  • 02 Èmile Waldteufel – Les Patineurs; Walzer; op. 183 – 溜冰者圆舞曲
  • 03 Johann Strauss II – ‘s gibt nur Kaiserstadt, ‘s gibt nur Wien!; Polka; op. 291 – 只有帝国之都,只有维也纳(皇城)波尔卡 – 1997
  • 04 Josef Strauss – Winterlust; Polka schnell; op. 121 – 冬趣快速波尔卡 – 2005
  • 05 Johann Strauss II – Mephistos Hollenrufe; Walzer; op. 101 – 梅菲斯特的地狱圆舞曲 – 1995
  • 06 Johann Strauss II – So angstlich sind wir nicht!, op. 413 – 我们决不畏惧波尔卡 – 2009
  • 07 Franz von Suppé – Ouvertüre zu Pique Dame – 黑桃皇后序曲
  • 08 Carl Michael Ziehrer – Hereinspaziert!; Walzer; op. 518 – 闲庭信步圆舞曲 – 1979
  • 09 Otto Nicolai – Die lustigen Weiber von Windsor, Moon Choir – 月升小合唱(选自轻歌剧《愉快的温沙妇人》)
  • 10 Johann Strauss II – Pepita-Polka; op. 138 – 细花纹方格波尔卡
  • 11 Johann Strauss II – Rotunde-Quadrille; op. 360 – 圆形大厅四对舞
  • 12 Johann Strauss II – Die Extravaganten; Walzer; op. 205 – 奢靡圆舞曲
  • 13 Johann Strauss I – Indianer-Galopp; op. 111 – 印度人加洛普 – 2004
  • 14 Josef Strauss – Die Nasswalderin; Polka mazur; op. 267 – 纳斯瓦尔德的女孩玛祖卡波尔卡 – 1996
  • 15 Johann Strauss II – Auf zum Tanze!; Polka schnell; op. 436 – 跳舞吧快速波尔卡
  • 16 Johann Strauss II – Tausend und eine Nacht; Walzer; op. 346 – 一千零一夜圆舞曲 – 1992, 2005
  • 17 Johann Strauss II – Tik-Tak; Polka schnell; op. 365 – 提塔快速波尔卡 – 1979, 2002, 2012
  • 18 Eduard Strauss ? – ?
  • 19 Johann Strauss II – An der schönen blauen Donau, Walzer, op. 314 – 蓝色多瑙河圆舞
  • 20 Johann Strauss I – Radetzky-Marsch, op. 228 – 拉德茨基进行曲

2017年维也纳新年音乐会即将迎来首次登上该音乐盛事指挥台的指挥家古斯塔沃·杜达梅尔。做为当代最为杰出的指挥家之一,80后的杜达梅尔也将成为有史以来新年音乐会上最年轻的指挥。

年轻的指挥家为这传统古老的音乐会带来了新的气息,这次音乐会正式演出的17个曲目中,有8首是第一次在新年音乐会上与乐迷见面,剩下的9首中也有7首是只在新年乐会上演出过一次的“冷门”曲目。加演的第一个曲目目前还没有公布,如果“路边社”消息属实,加演的是爱德华的一首快速波尔卡,那么这次音乐会的曲目单中就将史无前例地出现九位作曲家的名字,新年音乐会在演绎施特劳斯家族音乐的传统之上,越来越多的融入了更多其他作曲家的作品。

维也纳音乐之友协会合唱团将第一次加入新年音乐会的演出行列,在下半场与爱乐乐团一同演绎“月升小合唱”。

中央电视台从1987年开始转播维也纳新年音乐会,到现在已经有30年。我从1996年开始收看新年音乐会,到现在已经超过了20年。经历了刚开始的陌生和新奇以及中间的狂热,新年音乐会如今已经成为了一种习惯。我用上面的文字列举完了音乐会曲目单的各项“技术参数”以后,惊讶地发现,对于每一个具体的曲目,我竟然写不出任何文字再去深入的点评它们。那些曾经演出过的曲目,在脑海中的印象似乎也变得越来越模糊。不过我也不打算像以前那样把曲目单上的曲子都找出来复习+预习一遍了,我相信在新年到来的时候,乐团的演绎会让我回忆起那些曾经熟悉旋律,那种与老朋友相见的感觉想必是非常美好的。

期待新年音乐会,也期待新的一年。