nginx: [emerg] could not build server_names_hash, you should increase server_names_hash_bucket_size: 64技术
一口气写了十几篇文章。第一次碰到这种情况，看来我就是太温柔的玩家了，什么东西，只要能干，都得往死里干。
nginx “nginx could not build the server_names_hash” 解决方法
给一个服务器下增加了一些站点别名，差不多有 20 多个。
重启 nginx 时候，提示：
could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32
解决方法：
在配置文件的 http{} 段增加一行配置
server_names_hash_bucket_size 64;
如果 64 还不够，那么就按32的倍数往上加。
下面是在中文 wiki 上摘抄的一段说明：
保存服务器名字的hash表是由指令 server_names_hash_max_size 和 server_names_hash_bucket_size 所控制的。参数 hash bucket size 总是等于 hash 表的大小，并且是一路处理器缓存大小的倍数。在减少了在内存中的存取次数后，使在处理器中加速查找hash表键值成为可能。如果 hash bucket size 等于一路处理器缓存的大小，那么在查找键的时候，最坏的情况下在内存中查找的次数为 2。第一次是确定存储单元的地址，第二次是在存储单元中查找键值。因此，如果Nginx给出需要增大 hash max size 或 hash bucket size 的提示，那么首要的是增大前一个参数的大小.
aliyun cli 操作示例技术
不得不说，阿里云在 api 方面还是努了一点力的，至少把接口做的好用一点了，更加从用户的角度考虑问题了。
$ ./aliyun alidns DescribeDomainRecords --DomainName a.com
{
"DomainRecords": {
"Record": [
{
"DomainName": "",
"Line": "default",
"Locked": false,
"RR": "",
"RecordId": "",
"Status": "ENABLE",
"TTL": 600,
"Type": "A",
"Value": "192.168.1.1",
"Weight": 1
},
{
"DomainName": "",
"Line": "default",
"Locked": false,
"RR": "*",
"RecordId": "",
"Status": "ENABLE",
"TTL": 600,
"Type": "A",
"Value": "",
"Weight": 1
},
{
"DomainName": "",
"Line": "default",
"Locked": false,
"RR": "@",
"RecordId": "",
"Status": "ENABLE",
"TTL": 600,
"Type": "A",
"Value": "",
"Weight": 1
}
]
},
"PageNumber": 1,
"PageSize": 20,
"RequestId": "",
"TotalCount": 3
}
$
$ ./aliyun alidns DescribeDomainRecords --SubDomainName a.com
ERROR: '--SubDomainName' is not a valid parameter or flag. See `aliyun help alidns DescribeDomainRecords`.
$ ./aliyun alidns DescribeDomainRecords --SubDomain
ERROR: '--SubDomain' is not a valid parameter or flag. See `aliyun help alidns DescribeDomainRecords`.
$ ./aliyun alidns DescribeSubDomainRecords --SubDomain
"DomainRecords": {
"Record": [
{
"DomainName": "",
"Line": "default",
"Locked": false,
"RR": "",
"RecordId": "",
"Status": "ENABLE",
"TTL": 600,
"Type": "A",
"Value": "192.168.1.1",
"Weight": 1
}
]
},
"PageNumber": 1,
"PageSize": 20,
"RequestId": "",
"TotalCount": 1
}
$ ./aliyun alidns UpdateDomainRecord --RecordId * --RR * --Type A --Value 168.168.1.1 --Line default
{
"RecordId": "",
"RequestId": ""
}
$ ./aliyun alidns DescribeSubDomainRecords --SubDomain a.com
{
"DomainRecords": {
"Record": [
{
"DomainName": "",
"Line": "default",
"Locked": false,
"RR": "",
"RecordId": "",
"Status": "ENABLE",
"TTL": 600,
"Type": "A",
"Value": "168.168.1.1",
"Weight": 1
}
]
},
"PageNumber": 1,
"PageSize": 20,
"RequestId": "",
"TotalCount": 1
}
树莓派网速特别慢怎么回事技术
兜了一圈，发现可能是路由器的锅，重启路由器搞定，对于长时间联网的设备，路由器速度会降低？有 Bug？
速度只有 500KB/s 左右，写入文件速度测试能达到 10M/s，说明问题不在 SD 卡上。我测试过局域网其他设备之间传输文件，也没有慢，能达到 5M/s 左右，树莓派一直保持 500kb/s 的速度，想了很多招，查阅了很多资料。无果
最后，重启路由器解决！
重启路由器后，连上了 2.4G wifi，不知道是不是 rasp 的 5G wifi 不稳定导致的，可能吧！我懒得折腾了。就使用 2.4 G 吧，让它连 5G 是因为 2.4 真的太拥挤了。
重新设置地区，改成 5G wifi 后，发现速度没有问题，至少现阶段没有问题。现在也搞不清到底是什么问题了，反正重启路由解决了。但是又不能肯定说是路由器的问题，因为用其他设备测试没有什么问题，可能路由器对于长时间连接的设备会有这个问题。这么看来，应该大概率还是路由器的锅。
磁盘分区的坑技术
记录下分区的坑，总之，千万别用Windows自带的功能分，浪费不说，不兼容啊！
弄好了之后如下，umount /Volumes/下面的设备，重新挂载指定 rw，完美搞定。网上的一些消息说是希捷硬盘的问题，一下子颠覆了我的认知，为什么其他硬盘的 ntfs 在 mac 下可以读写，唯独希捷不行。
$ sudo diskutil list
/dev/disk0 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 500.3 GB disk0
1: EFI EFI 314.6 MB disk0s1
2: Apple_APFS Container disk1 500.0 GB disk0s2
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +500.0 GB disk1
Physical Store disk0s2
1: APFS Volume Macintosh HD 98.1 GB disk1s1
2: APFS Volume Preboot 22.8 MB disk1s2
3: APFS Volume Recovery 519.0 MB disk1s3
4: APFS Volume VM 1.1 GB disk1s4
/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk2
1: Microsoft Basic Data seagate 4.0 TB disk2s1
$ df -h
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk1s1 466Gi 91Gi 373Gi 20% 1083846 9223372036853691961 0% /
devfs 194Ki 194Ki 0Bi 100% 673 0 100% /dev
/dev/disk1s4 466Gi 1.0Gi 373Gi 1% 1 9223372036854775806 0% /private/var/vm
map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net
map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home
/dev/disk2s1 3.6Ti 181Mi 3.6Ti 1% 22 3906831475 0% /Users/l/Work/seagate
PHP 内存泄露重现 include 匿名函数技术
这个坑估计全网没有人踩过，这篇应该是公开出来的第一篇，很多人就算是踩了这个坑，也不一定会触发，即使是触发了，也不一定发现的了。
这个是 include 或者是 require 对于匿名函数的内存泄露大坑。
很多市面上的 PHP 教程都说 include require 相当于把代码复制到那个位置，从这个代码示例验证来看，其实不是这样的！
$i=0;
while (true) {
if ($i%1000 == 0) {
echo memory_get_usage()."\n";
sleep(1);
}
$i++;
$b = 'b';
$render_func = function($d) use ($b) {
$u = 1;
//test3.php $x = function(){};
require 'test3.php';
};
$render_func($i);
}
return;