这是Redis源码阅读系列第一篇文章。
dict 是 redis 最重要的数据结构,db、hash、以及服务器内部需要用到hashmap的场景都是用dict来实现的。学习 dict 的源码,我们可以学到hashmap的原理及实现。
人类一思考,上帝就发笑。
这是Redis源码阅读系列第一篇文章。
dict 是 redis 最重要的数据结构,db、hash、以及服务器内部需要用到hashmap的场景都是用dict来实现的。学习 dict 的源码,我们可以学到hashmap的原理及实现。
一直在寻找比较好的番茄工作法工具,但是都不那么满意。
物理番茄钟,主要问题是不够灵活,比如调整番茄时长,而且不能和GTD清单同步。
手机app的话,番茄钟结束的提醒声音过于吵闹,特别在公共场合,比如公司或者图书馆;如果静音或者震动的话,又常常感知不到,导致经常关注番茄钟时间,不能集中精力。
也用过安卓智能手表,但目前番茄工作法相关应用还是很少,没有找到合适的,而且手表续航太短,高强度使用基本得每天充电,心智负担大。
之前也用过手机番茄app配合手环,通过手环震动提醒番茄钟结束,方法可行,但是通知经常触达不到,体验不好。
最近小米手环6上市了,经过几天摸索,发现配合滴答清单的专注功能,以及小米穿戴的通知提醒,总体体验挺好,通知也准确,应当是目前最好的番茄工作法方案了。
公司的线上模型服务是基于brpc + xgboost
实现的,而xgboost官方是不支持在多线程环境下使用的(1.2.0版本之前)
这个模型服务已经有两年多了,显然当时用的版本是不支持多线程的,有位同事当时修改了xgboost的源码,解决了多线程的问题,在线上也稳定运行到现在。
那么,问题来了。最近有个新需求,用到了xgboost的pred_leaf
功能,然后就发现并发请求时0.1%
的模型结果不对。
最近偶然又玩起了GBA游戏,瞬间又像是回到了儿时的时光。也碰到了许久以来的老问题,如何作弊,毕竟游戏里刷资源和练级实在是体力劳动,年龄大了毕竟肝不动了。
先说一下,我现在玩GBA的平台是安卓的Pizza Boy GBA
模拟器加游戏手柄,总体游戏体验感觉比GBA真机还好,毕竟现在的设备机能放在这,而且还有倍速播放相关功能。
Windows Subsystem for Linux(WSL)从Version 1 (WSL1)
升级到Version 2 (WSL2)
之后,底层实现方式发生了改变。
由于使用Hyper-V来实现WSL2,使得WSL更像虚拟机,一个能访问本地硬盘的虚拟机。
这带来一些便利,能够把它当做独立服务器来使用,可玩性就增强很多。当然,这也导致WSL上的端口不能从外部访问到,总之有利有弊。
虽然能够配置端口转发,曲线救国突破这个缺陷,但是有些服务的端口是约定俗成的(比如samba),更换端口号(原端口号被windows占用)之后其他设备可能识别不到服务。
经过一番思考后,觉得给WSL2开启桥接模式,直接连接物理网络才是相对最好的方案。
平时例行午睡时间是下午1:20-1:50,今天也一样,只是闹钟响的时候感觉没睡够。
于是想再眯一会儿,然后我睡朦了,做了一个让我哭笑不得的梦。
下面描述下这个梦
在梦中,我被一阵持续的噪音惊醒,声音类似老式空调压缩机的声音,嘈杂而持久,整个房间都有一点震动的感觉。我在房间里仔细搜寻噪音的源头,好让自己再次入眠。
找来找去,发现我的冲牙器在不停震动,声音也很是类似,还以为忘记关开关了。于是准备把开关关了,一阵手忙脚乱开关还是没能关掉(梦中这种细致的操作不好实现?)。于是我把冲牙器的插头拔下了,但是它好像没有停下来的意思,还在不停震动着,而且冲牙器的位置也不是现实中的位置,我好似也坦然接受了这无须电源的震动(这好像不是重点),但是又无法确定噪音的源头就是它。
然后,富有逻辑的操作来了,我找了个桶把冲牙器盖起来,发现噪音并没有减弱,于是我排除了它的嫌疑。
接着就发现应该是空调的压缩机在响,我就认定是它了,然后空调的指示灯变清晰了,原来是我误开了空调,我笃定开得是制热,只有制热需要这么大的功率,空气也燥热起来,一切是那么符合逻辑。
心满意足找到答案之后,我醒了,发现噪音来源是外面修路的水泵。
最近发生了一个服务故障,在一个同事对日志服务做了改动后,服务的耗时就变大了很多,数据大量积压。
通过观察监控报表,我们发现从他的改动上线后,服务器的CPU使用率大幅增加,基本处于满载状态。
粗略审查代码并没有发现问题,我们只能紧急回滚了服务,日志消费也恢复到正常状态了。
但是根本问题还没有找到,所以我请出了line_profiler来分析程序的具体耗时情况。
line_profiler是个代码耗时分析器,可以逐行分析代码的耗时情况。