本文为十月川北自驾游记系列之二，乐山。

十月川北自驾游记系列：

1. 十月川北自驾游记——成都
2. 十月川北自驾游记——乐山
3. 十月川北自驾游记——都江堰
4. 十月川北自驾游记——九寨沟
5. 十月川北自驾游记——黄龙

乐山

成都到乐山一日游，采用高铁+打车的方案，高铁单程大约50分钟。考虑到乐山的美食非常出名，希望三餐都在乐山解决。由于还在十一假期，成都去乐山的车次很好买，但晚上7点以后返程的车票就比较紧俏了，好在通过候补车票的方式买到了往返车票。

本文为十月川北自驾游记系列之第一篇，成都。

十月川北自驾游记系列：

1. 十月川北自驾游记——成都
2. 十月川北自驾游记——乐山
3. 十月川北自驾游记——都江堰
4. 十月川北自驾游记——九寨沟
5. 十月川北自驾游记——黄龙

继前年9月 自驾青甘大环线 之后，因为疫情原因，两年没出远门。又是一年秋天，连着十一休了一周年假，去九寨沟看看。

提前做旅游攻略是件很累的事情，尤其在行程时间较长（大于一周）时，不确定性比较大，安排合理的行程就更是困难。反而是在行程的中后期，随着剩余时间的不断减少，安排一两天的行程就很简单了。

考虑到时间和舒适度，实际玩了乐山大佛，成都市，青城山，都江堰，卧龙大熊猫苑，九寨沟和黄龙。

# The Curious Case of Neural Text Degeneration

这篇ICLR 2020年的文章我很喜欢，因为它简洁直观。文章首先提出一个有意思的发现：人说的自然语言常常出人意料，即说出的并不总是语言模型中概率最大的词，而Beam Search会总会选择最符合语言模型的词汇，因此生成的文本没有新意(less surprising)。之后提出了一种top-k sampling的改进方案来解决问题：nucleus sampling (top-p sampling)。

如果一个Pod在错误状态启动不了 (crashloopbackoff)，那么Kubernetes就会自动重启该Pod。这就给调试这个Pod带来了麻烦，无法exec到这个Pod上查看问题，也不容易看到这个Pod的日志，因为此时这个Pod已经被Kubernetes杀掉了：

unable to upgrade connection: container not found ("")

那如何防止有错误的Pod无限重启或反复重启？

训练GPT等语言模型可以参考Huggingface Transformer训练语言模型的tutorial: Transformers Language Model Training

示例提供了三个脚本: run_clm.py, run_mlm.py 和 run_plm.py。GPT是个causal language model，可以使用 run_clm.py 进行训练或微调。但这脚本并不支持行式数据集，即每行一个训练样本的数据集。它默认的数据处理是按行读取样本并把它们连接成一个block_size的连续文本。

而这种数据处理方式在某些情况下并不适用，可能会让语言模型学偏。比如QA任务：

Q1 [SEP] A1 Q2 [SEP] A2 ...

连接后就成了 Q1 [SEP] A1 Q2 [SEP] A2 ... ，可能会让模型认为Q1的答案是A1 Q2。可对run_clm.py支持行式数据集。

The latest training/fine-tuning language model tutorial by huggingface transformers can be found here: Transformers Language Model Training

There are three scripts: run_clm.py, run_mlm.py and run_plm.py. For GPT which is a causal language model, we should use run_clm.py. However, run_clm.py doesn't support line by line dataset. For each batch, the default behavior is to group the training examples into a single block_size line.

However, grouping text doesn't make sense for datasets whose lines are not related such as QA dataset:

Q1 [SEP] A1 Q2 [SEP] A2 ...

Concatenate them to: Q1 [SEP] A1 Q2 [SEP] A2 ... might mislead the language model.

Follow # Dynamically create and use a persistent volume with Azure Files in Azure Kubernetes Service (AKS) to create a new storage class in AKS:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard-grs
provisioner: kubernetes.io/azure-disk
parameters:
  cachingmode: ReadOnly
  kind: Managed
  skuName: Standard_GRS
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

If you create new resource by kubernetes dashboard, an error might occur:

Deploying file has failed
the server could not find the requested resource

在同一机器上对不同repo使用不同的github账号是个常见需求。举个例子，repo1托管在github账号x1下，而repo2托管在账号x2下，如何方便地在同一机器上使用不同账号自动git push到对应的远端？比较直接的做法是在不同repo目录下使用git config配置用户名，但这样有两个问题：

• 每个repo都要配置一遍比较繁琐
• 有些情况下无法配置。比如使用 hexo-deployer-git 部署Hexo网站时，.deploy_git目录是动态生成的，而所用的git账户和远端url修改不便。

于是，我们可以借用SSH config文件来把不同github账号与repo联系起来。在SSH config中定义多个不同的host项即可，然后在访问github时，使用一个虚拟host作为别名代替真正的主机名github.com即可。

How to use different github account for different repository? For instance, we have two github accounts x1 and x2, while x1 for repo1 and x2 for repo2. At the first glance, we can set git config in different repository folder by git config user.name xxx. However, this approach has two drawbacks:

• Need to config user name/email in every repository
• In some case, the git user cannot be configured by git config. For example, hexo-deployer-git. Since the git repo is automatically generated by the deployer, it's hard to manually set the user name.

Fortunately, we can leverage SSH config to associate different github accounts with different repos. Define different host entries does the trick: since we login to github via SSH, we use a virtual host as an alias to represent the real host name.

最近发现MongoDB分片集群的流量不太均衡，研究之后发现根本原因在于数据分布不均衡。虽然数据分布均衡不等于流量均衡，但还是应该尽量使得数据分布在不同shard之间基本均衡。三个shard的数据分布大概这样：

mongo-1这个分片的数据大小显著高于其他分片，而三个分片的chunk数目是基本一致的，所以需要分析不同分片上的chunk大小分布。