LMLPHP后院

nginx: [emerg] could not build server_names_hash, you should increase server_names_hash_bucket_size: 64技术

maybe yes 发表于 2022-06-13 11:00

一口气写了十几篇文章。第一次碰到这种情况,看来我就是太温柔的玩家了,什么东西,只要能干,都得往死里干。

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 操作示例技术

maybe yes 发表于 2022-06-05 12:21

不得不说,阿里云在 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
}

树莓派网速特别慢怎么回事技术

maybe yes 发表于 2022-05-27 17:15

兜了一圈,发现可能是路由器的锅,重启路由器搞定,对于长时间联网的设备,路由器速度会降低?有 Bug?

速度只有 500KB/s 左右,写入文件速度测试能达到 10M/s,说明问题不在 SD 卡上。我测试过局域网其他设备之间传输文件,也没有慢,能达到 5M/s 左右,树莓派一直保持 500kb/s 的速度,想了很多招,查阅了很多资料。无果

最后,重启路由器解决!

重启路由器后,连上了 2.4G wifi,不知道是不是 rasp 的 5G wifi 不稳定导致的,可能吧!我懒得折腾了。就使用 2.4 G 吧,让它连 5G 是因为 2.4 真的太拥挤了。

重新设置地区,改成 5G wifi 后,发现速度没有问题,至少现阶段没有问题。现在也搞不清到底是什么问题了,反正重启路由解决了。但是又不能肯定说是路由器的问题,因为用其他设备测试没有什么问题,可能路由器对于长时间连接的设备会有这个问题。这么看来,应该大概率还是路由器的锅。

磁盘分区的坑技术

maybe yes 发表于 2022-05-27 13:52

记录下分区的坑,总之,千万别用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 匿名函数技术

maybe yes 发表于 2022-05-01 10:11

这个坑估计全网没有人踩过,这篇应该是公开出来的第一篇,很多人就算是踩了这个坑,也不一定会触发,即使是触发了,也不一定发现的了。

这个是 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;
2024-11-19 08:31:40 1731976300 0.016703