该内存不能为read修复工具（内存不能为read修复工具有用吗

大家好,小宜来为大家讲解下。该内存不能为read修复工具（内存不能为read修复工具有用吗这个很多人还不知道,现在让我们一起来看看吧！

今天，是Linux回炉的第六十四天

FastCGI

在看nginx的调优的时候正好看到FastCGI缓冲区，突然无法理解

于是有一个疑问，关于vue.js的*命周期的问题的。

我们之前遇到过一个项目，客户每次打开网页之后，停顿一段时间，客户再次触发网页该网页就会重新加载页面并且返回主页，无法保留客户所在的当前页面，我当时建议的是在vue的*命周期里考虑一下解决方案，后面还有mysql的limit分页也可以解决这个问题，大脑始终卡在客户端与FastCGI的缓冲区的关联上，我简单的查了一下资料

什么是FastCGI

首先，是个接口，高速接口，看到高速基本可以解释FastCGI的缓冲机制了

然后，是在http和动态语言之间的接口

在linux下fastCGI类似于进程

它是C/S架构

我理解的原理：

现在的web网页是静态和动态交织在一起的，所以客户端访问nginx的页面的时候，其网页动态和静态部分同时向nginx发出请求。

然后，nginx承担静态页面的工作，类似于一些框架内容展示部分。

而动态网页数据库填充部分由后端的，如python django：

def vote_get(request):

return HttpResponse(output)

动态调用则交给了FastCGI了。

所以，我现在认为FastCGI的缓冲区不是给客户的，是给nginx的，因为最终呈现给客户的是nginx服务。

fastcgi_connect_timeout 300; #指定链接到后端FastCGI的超时时间。

fastcgi_send_timeout 300; #向FastCGI传送请求的超时时间，这个值是指已经完成两次握手后向FastCGI传送请求的超时时间。

fastcgi_read_timeout 300; #指定接收FastCGI应答的超时时间，这个值是指已经完成两次握手后接收FastCGI应答的超时时间。

fastcgi_buffer_size 64k; #指定读取FastCGI应答第一部分需要用多大的缓冲区，这个值表示将使用1个64KB的缓冲区读取应答的第一部分（应答头），可以设置为fastcgi_buffers选项指定的缓冲区大小。

fastcgi_buffers 4 64k; #指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答请求，如果一个php脚本所产*的页面大小为256KB，那么会分配4个64KB的缓冲区来缓存，如果页面大小大于256KB，那么大于256KB的部分会缓存到fastcgi_temp指定的路径中，但是这并不是好方法，因为内存中的数据处理速度要快于磁盘。一般这个值应该为站点中php脚本所产*的页面大小的中间值，如果站点大部分脚本所产*的页面大小为256KB，那么可以把这个值设置为“8 16K”、“4 64k”等。

fastcgi_busy_buffers_size 128k; #建议设置为fastcgi_buffer的两倍，繁忙时候的buffer

fastcgi_temp_file_write_size 128k; #在写入fastcgi_temp_path时将用多大的数据库，默认值是fastcgi_buffers的两倍，设置上述数值设置小时若负载上来时可能报502Bad Gateway

fastcgi_cache gnix; #表示开启FastCGI缓存并为其指定一个名称。开启缓存非常有用，可以有效降低CPU的负载，并且防止502的错误发*，但是开启缓存也可能会引起其他问题，要很据具体情况选择

fastcgi_cache_valid 200 302 1h; #用来指定应答代码的缓存时间，实例中的值表示将200和302应答缓存一小时，要和fastcgi_cache配合使用

fastcgi_cache_valid 301 1d; #将301应答缓存一天

fastcgi_cache_valid any 1m; #将其他应答缓存为1分钟

fastcgi_cache_min_uses 1; #请求的数量

fastcgi_cache_path #定义缓存的路径

安装MySQL，需要用到存储，就了解了下K8S中相关的概念：PV 和 PVC

PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，*命周期独立于 Pod。

PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV。

有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。

kubectl get storageclasses --all-namespaces

查看StorageClass name，然后编写pvc，会*成对应的pv

我使用的是minikube，查到的StorageClass name 为 standard，对应的pvc.yaml为

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: mysql-pvc

namespace: kube-system

labels:

app: mysql-pvc

spec:

accessModes:

- ReadWriteMany

resources:

requests:

storage: 2Gi

storageClassName: standard

这样，pv 和 pvc就都ok了，可以部署对应的MySQL了

注意：如果是M1的mysql，image为 mysql/mysql-server

@K8S@Docker@开发环境

前端每日干货

如何实现文件拷贝问题？

一，先来看一下小文件拷贝问题

我们使用NodeJS内置的fs模块。

简单实现这个程序如下：

var fs = require('fs');

function copy(src, dst) {

fs.writeFileSync(dst, fs.readFileSync(src));

}

function main(argv) {

copy(argv[0], argv[1]);

}

main(process.argv.slice(2));

这段代码实现上：

fs.readFileSync从源路径读取文件内容，并使用fs.writeFileSync将文件内容写入目标路径。

需要注意的知识是：

process是一个全局变量，可通过process.argv获得命令行参数。由于argv[0]固定等于NodeJS执行程序的绝对路径，argv[1]固定等于主模块的绝对路径，因此第一个命令行参数从argv[2]这个位置开始。

二，再来看一下大文件拷贝问题

上边的程序拷贝一些小文件没啥问题，但这种一次性把所有文件内容都读取到内存中后再一次性写入磁盘的方式不适合拷贝大文件，内存会爆仓。对于大文件，我们只能读一点写一点，直到完成拷贝。因此上边的程序需要改造如下。

代码实现如下：

var fs = require('fs');

function copy(src, dst) {

fs.createReadStream(src).pipe(fs.createWriteStream(dst));

}

function main(argv) {

copy(argv[0], argv[1]);

}

main(process.argv.slice(2));

fs.createReadStream创建了一个源文件的只读数据流，并使用fs.createWriteStream创建了一个目标文件的只写数据流，并且用pipe方法把两个数据流连接了起来。连接起来后发*的事情，说得抽象点的话，水顺着水管从一个桶流到了另一个桶。

32位的VB使用64位DLL，系统本身就支持哦！

1、笔者在前几篇中讨论VB在64位Win中如何充分利用Win的兼容特性时，提到了一款开源32位DLL（wow64ext），可供VB完成诸如Hook注入64位进程、64位进程地址空间的内存分配及读写，使用64位库资源从而实现充分利用新硬件资源等。

2、在网友的提示下，笔者去看了下64位Win下32位地址空间载入的Ntdll.dll，发现有很多跟WOW64兼容层有关的函数。比如ZwWow64CallFunction64，ZwWow64QueryVirtualMemory64，ZwWow64ReadVirtualMemory64，ZwWow64WriteVirtualMemory64，ZwWow64QueryInformationProcess64等。

3、这说明，系统实际上提供了32位访问64位库的API，谁说VB死了呢！就是不知那句『32位与64位互不能加载』是何用意了？只不过，这些函数均未文档化，在官网上查不到相关函数原型。

关注BtOfficer呀，更多精彩仍在继续哦，有严肃的技术，也有轻松的唠嗑，期待你的加入！

【香橙派Orange Pi Zero2开发板26pinGPIO口测试】#GPIO#

香橙派Zero2开发板采用全志H616 四核 64位处理器,拥有512MB/1GB 内存可选，集成千兆以太网、蓝牙5.0+双频WiFi、USB2.0、Micro-HDMI等端口，还可通过板上的13pin接口和26pin扩展功能口，下文要介绍的就是Zero2上26pinGPIO接口的测试。

wiringOP 已适配 Orange Pi Zero 2 开发板，使用 wiringOP 可以测试GPIO的功能：

1. 开始测试前，请确保已经安装好了 wiringOP

1) 下载 wiringOP 的代码（图1）

2) 编译安装 wiringOP （图2）

3) 测试 gpio readall 命令的输出如下

a. 其中 1 到 26 号引脚与开发板上的 26 Pin 引脚是一一对应的

b. 27 号引脚对应开发板上 13pin 的 10 号引脚

c. 29 号引脚对应开发板上 13pin 的 11 号引脚