昨天想用 iPad 上的 GoodReader 看一本书，但是从 iCloud 同步的时候出了些问题，进度始终为零。由于国内糟糕的网络环境，这种同步失败的问题时有发生。虽然可以直接通过 WiFi 把书从电脑上传过来，但是因为偶尔需要在另一个 iPad 上查看，为了同步进度，还是最终决定还是自己搭建一套云存储设施。
ftp 协议有诸多问题，现在用的已经很少了。WebDav 协议基于 HTTP，相比 FTP 有不少有点，可以参见文章1。另外不少开源的网盘客户端也支持 webdav。NextCloud 支持 webdav，后面会讲到
sftp 则和 ftp 是完全独立的两个东西，虽然最终目的是一样的。好比海豚和鲨鱼都是在海里的生物，但是一个是哺乳动物，而一个是鱼类。sftp …
虽然 K8S 本身不建议在 Master 节点中部署 Pod，但是实际上也是可以的。
kubectl taint nodes --all node-role.kubernetes.io/master-
这行命令的意思是移除所有节点的 master taint，这样就可以在 master 节点部署 pod 啦~
Case 1：
CPU 和内存都被打满了，同时发现硬盘 IO 也很高。
ps -eo pid,ppid,cmd,%mem,mem,%cpu --sort=-%mem | head -n 50
发现 kswapd0 偶尔会占用很高的 CPU，而这个进程是在内存满的时候负责在内存和 swap 之间交换。也就是问题的根源是内存满了，而 kswapd0 开始在内存和 swap 之间反复读写文件，导致 CPU 和 IO 也涨了起来，这时候应该找到内存暴涨的根源，进而解决问题。
[1] https://askubuntu.com/questions/259739/kswapd0-is-taking-a-lot-of-cpu
服务治理有两种方式：
两种模式的区别如图：
本来想坐下来写篇 2018 年的总结，仔细想想这一年发生的事情太多了，还是写篇技术文章吧。
前几天调试程序，发现 QPS 总是卡在 20 左右上不去。开始以为是 IO 问题，就多开了些并发，然并卵，这才想到可能是 CPU 的问题。看了看监控，发现程序某一步的延迟在 400ms 左右，而且这一步是 CPU 密集的。当时开了 4 台双核的机器：(1s / 400ms) * 2 * 4 = 20 啊。看来需要优化下这一步的代码了，那么第一步就是找到可以优化的地方。
测量程序的性能之前并没有实际做过，Google 了一番，感觉标准库的 cProfile 似乎值得一试。
要测量的代码逻辑也很简单，使用 lxml 解析 HTML，然后提取一些字段出来，这些基本都是调用的 …
2019-01-02 更新：相对于 Kubernetes 来说，Nomad 还是太简陋了，弃坑
Nomad 是 HashiCorp 出品的一个容器编排服务，相较于重量级的 Kubernetes 来说，Nomad 的特点在于
从官网下载二进制文件，复制到 /usr/local/bin 就好了，不再赘述
$ sudo nomad agent -dev
$ nomad node status
ID …Python Redis 的客户端使用了链接池机制，通过复用链接可以减低服务器的压力并在失败时重试。连接池其实是一种很通用的机制，在实现客户端是是一个经常需要（或许其实不需要）重复发明的轮子。
Redis 客户端一共涉及到了三个类：
Connection 类主要负责建立和 Redis 服务器的一个 Socket 链接，并且沟通相关信息。下面的代码是 Connection 类和 socket 处理相关的代码。
class Connection(object):
def __del__(self):
try:
self.disconnect()
except Exception:
pass
def connect(self):
"""
连接 Redis 服务器
"""
if …parted -s -a optimal /dev/sda mklabel gpt -- mkpart primary ext4 1 -1s
mkfs.ext4 /dev/sda1
parted -l
首先挂载到临时分区
mount /dev/sdb1 /mnt
把之前的数据考进去
# rsync -av /home/* /mnt/
OR
# cp -aR /home/* /mnt/
校验数据
diff -r /home /mnt
删除老数据
rm -rf /home/*
umount /mnt
为什么我们要把监控数据存到 influxdb 呢? 存到 MySQL 或者 MongoDB 甚至 Elasticsearch 不好么?
数据模型上, 监控数据是和时间相关的, 脱离点产生的时间, 那么数据将毫无意义, 传统数据库中并没又强调这一点.
性能上, influxdb 是时间序列数据库, 这类数据库面临的问题是写入非常多, 而读取比较少. 而普通的数据库一般都是读比较多, 而写入较少, 并且要保证写入的正确性.
监控打点显然是一个面向时间序列的过程, 并且写入非常多, 而一般只有在触发告警, 排查问题的时候可能读取才比较多. 所以从性能和功能考虑上来说, 传统数据库都是不适用的.
influxdb 中常见的存储数据格式:
cpu_usage value=49 1502043216
cpu_usage value=50 1502193042
cpu_usage value=5 1502196258
我们以一个 measurement(测量) 作为一个表 …
前几篇写了一写 k8s 部署方面的东西, 后来发现阿里云的 k8s 集群还很好用...何苦自己研究几天部署呢...?
------分隔线------
在 k8s 上部署一个应用还是有些复杂的, 自己的应用当然需要自己一步一步部署, 但是对于一些通用的应用, 比如说 mysql/grafana 这种就没必要自己手工一步一步部署了. 这时候就有了 helm, 通俗的来说他就是 kubernetes 上的 AppStore, 常见的应用都已经在了, 而且你也可以按照他的格式打包自己的应用部署.
在 helm 的 release 页面下载, 然后拷贝到本地的 /usr/local/bin/ 目录就好了. helm 运行的时候会使用 ~/.kube/config 文件, 所以本地 kubectl 可以使用就好了.
helm 分为两部分, helm 是本地命令, tiller 是服务端 …