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;