操作系统里的buffer和cache

  • A buffer is something that has yet to be “written” to disk. (把即将到磁盘的数据缓存起来)
  • A cache is something that has been “read” from the disk and stored for later use.(从磁盘中取数据,作为缓存)
发表在 IT | 标签为 , , | 留下评论

j1900工控机Ubuntu 16.04.5 LTS卡死问题的解决

1.编辑/etc/default/grub,修改GRUB_CMDLINE_LINUX

GRUB_CMDLINE_LINUX="intel_idle.max_cstate=1"

sudo vi /etc/default/grub

2.sudo update-grub

3.重启

ps:

我的ubuntu内核:

Linux ubuntu-server 4.15.18-041518-generic #201804190330 SMP Thu Apr 19 07:34:21 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

参考:

https://www.cnblogs.com/cobranail/p/6032890.html

http://www.jyguagua.com/?p=3888

 

发表在 其他 | 留下评论

git的三个阶段和文件回撤

git的三个阶段

working tree:就是你所工作在的目录,每当你在代码中进行了修改,working tree的状态就改变了。
index file:是索引文件,它是连接working tree和commit的桥梁,每当我们使用git-add命令来登记后,index file的内容就改变了,此时index file就和working tree同步了。
commit:是最后的阶段,只有commit了,我们的代码才真正进入了git仓库。我们使用git commit就是将index file里的内容提交到commit中。

git diff的使用

git diff:是查看working tree与index file的差别的。
git diff –cached:是查看index file与commit的差别的。
git diff HEAD:是查看working tree和commit的差别的。(你一定没有忘记,HEAD代表的是最近的一次commit的信息)

git add回撤

git reset HEAD:回撤所有文件的add

git reset HEAD 目录文件:回撤某个文件的add:

git commit回撤

git reset –soft commit_id:只回撤git commit,git add依然生效,修改的文件存在

git reset –mixed commit_id:回撤git commit和git add,修改的文件存在

git reset –hard commit_id:回撤git commit和git add,修改的文件也不存在了

修改commit备注

git commit –amend

发表在 IT | 标签为 , , | 留下评论

论详细日志的重要性

最近使用git遇到了问题,让我感觉到详细的日志是多么的重要。

我的pc装的是windows 10操作系统,git的版本是2.19.2,在拉取code的时候总是报500错误。如下图:

这个错误一度让我以为是服务端的错误,花了好多时间在服务寻找问题的根源。但是发现一个现象,在linux server里可以顺利的拉取代码,查看其git的版本是2.7.4。

于是乎,我把pc上的git版本换成2.7.4,再去拉代码,还是不行,但是提示错误就不一样了。如下图:

错误提示里说,连不上localhost的80端口。这让马上我联想到git是不是启用了代理。结果发现,还真的是启用了代理。

可见详细的日志是多么的重要。

 

 

发表在 IT | 标签为 | 留下评论

修改ubuntu18.04主机名

1.修改/etc/hostsname

ubuntu-node1

2.修改/etc/hosts文件

127.0.0.1       ubuntu-node1

3.修改/etc/cloud/cloud.cfg

把preserve_hostname配置设置为true

preserve_hostname: true

 

 

发表在 IT | 标签为 | 留下评论

R7000原厂固件不支持不同网段转发数据

R7000原厂固件不支持不通网段转发数据

The problem is that the R7000 will only NAT its own subnet. 
 It won't NAT traffic from other subnets.

来自:https://community.netgear.com/t5/Nighthawk-WiFi-Routers/R7000-Static-routing-not-able-to-reach-internet/td-p/1122475?cid=PSarlogoogleps10.26BG-PetMonitoring

I heard from another poster that Netgear quietly removed support for NATing traffic from other local subnets. 
I think the reason they gave him was something like it was too complicated for users?!?

来自:https://community.netgear.com/t5/Nighthawk-WiFi-Routers/NAT-for-different-subnet/td-p/1018525

 

 

发表在 IT | 标签为 , | 留下评论

win10激活

“以管理员身份”打开cmd

1. slmgr.vbs /upk

2.slmgr /ipk W269N-WFGWX-YVC9B-4J6C9-T83GX

3.slmgr /skms zh.us.to

4.slmgr /ato

发表在 IT | 标签为 , , | 留下评论

shadowsocks优化

1.操作系统要支持BBR

2./etc/sysctl.conf

# max open files
fs.file-max = 1024000
# max read buffer
net.core.rmem_max = 67108864
# max write buffer
net.core.wmem_max = 67108864
# default read buffer
net.core.rmem_default = 65536
# default write buffer
net.core.wmem_default = 65536
# max processor input queue
net.core.netdev_max_backlog = 4096
# max backlog
net.core.somaxconn = 4096

# resist SYN flood attacks
net.ipv4.tcp_syncookies = 1
# reuse timewait sockets when safe
net.ipv4.tcp_tw_reuse = 1
# turn off fast timewait sockets recycling
net.ipv4.tcp_tw_recycle = 0
# short FIN timeout
net.ipv4.tcp_fin_timeout = 30
# short keepalive time
net.ipv4.tcp_keepalive_time = 1200
# outbound port range
net.ipv4.ip_local_port_range = 10000 65000
# max SYN backlog
net.ipv4.tcp_max_syn_backlog = 4096
# max timewait sockets held by system simultaneously
net.ipv4.tcp_max_tw_buckets = 5000
# TCP receive buffer
net.ipv4.tcp_rmem = 4096 87380 67108864
# TCP write buffer
net.ipv4.tcp_wmem = 4096 65536 67108864
# turn on path MTU discovery
net.ipv4.tcp_mtu_probing = 1

# for high-latency network
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

# forward ipv4
net.ipv4.ip_forward = 1

net.ipv4.tcp_fastopen = 3

3.修改vi /etc/security/limits.conf文件,加入

*               soft    nofile           512000
*               hard    nofile          1024000

4.shadowsocks服务器、客户端开启TCP Fast Open

发表在 IT | 标签为 , , | 留下评论

RxJava2.0的Flow Control(流量控制的方法)

Flow Control(流量控制的方法):背压(Backpressure)、节流(Throttling)、打包处理、调用栈阻塞(Callstack Blocking)

1.Backpressure:也称为ReactivePull,就是下游需要多少(具体是通过下游的request请求指定需要多少),上游就发送多少。这有点类似于TCP里的流量控制,接收方根据自己的接收窗口的情况来控制接收速率,并通过反向的ACK包来控制发送方的发送速率。

2.Throttling:说白了就是丢弃。消费不过来,就处理其中一部分,剩下的丢弃。还是举音视频直播的例子,在下游处理不过来的时候,就需要丢弃数据包。具体策略:sample(也叫throttleLast)、throttleFirst、debounce (也叫throttleWithTimeout)

Sample(throttleLast):sample,采样。类比一下音频采样,8kHz的音频就是每125微秒采一个值。sample可以配置成,比如每100毫秒采样一个值,但100毫秒内上游可能过来很多值,选哪个值呢,就是选最后那个值。所以它也叫throttleLast。

ThrottleFirst:跟sample类似,比如还是每100毫秒采样一个值,但选这100毫秒内的第一个值。在Android开发中有时候可以把throttleFirst用作点击事件的防抖动处理,就是因为它可以在指定的一段时间内处理第一个点击事件(即采样第一个值),但丢弃后面的点击事件。

Debounce:也叫throttleWithTimeout,名字里就包含一个例子。比如,一个网络程序维护一个TCP连接,不停地收发数据,但中间没数据可以收发的时候,就有间歇。这段间歇的时间,可以称为idle time。当idle time超过一个预设值的时候,就算超时了(timeout),这个时候可能就需要把连接断开了。实际上一些做server端的网络程序就是这么工作的。每收发一个数据包之后,启动一个计时器,等待一个idle time。如果计时器到时之前,又有收发数据包的行为,那么计时器重置,等待一个新的idle time;而如果计时器时间到了,就超时了(time out),这个连接就可以关闭了。debounce的行为,跟这个非常类似,可以用它来找到那些连续的收发事件之后的idle time超时事件。换句话说,debounce可以把连续发生的事件之间的较大的间歇找出来。

3.打包处理:打包就是把上游来的小包裹打成大包裹,分发到下游。这样下游需要处理的包裹的个数就减少了。RxJava中提供了两类这样的机制:buffer和window。buffer和window的功能基本一样,只是输出格式不太一样:buffer打包后的包裹用一个List表示,而window打包后的包裹又是一个Observable。

4.调用栈阻塞(CallstackBlocking):这种方式只适用于整个调用链都在一个线程上同步执行的情况,这要求中间的各个operator都不能启动新的线程。在平常使用中这种应该是比较少见的,因为我们经常使用subscribeOn或observeOn来切换执行线程,而且有些复杂的operator本身也会在内部启动新的线程来处理。

 

在RxJava2.x中,Observable不再支持Backpressure,而是改用Flowable来专门支持Backpressure。上面提到的四种operator的前三种分别对应Flowable的三种Backpressure策略:
BackpressureStrategy.BUFFER,

BackpressureStrategy.DROP,

BackpressureStrategy.LATEST

BackpressureStrategy.BUFFER是不丢弃数据的处理方式。把上游收到的全部缓存下来,等下游来请求再发给下游。相当于一个水库。但上游太快,水库(buffer)就会溢出。

BackpressureStrategy.DROP和BackpressureStrategy.LATEST比较类似,都会丢弃数据。这两种策略相当于一种令牌机制(或者配额机制),下游通过request请求产生令牌(配额)给上游,上游接到多少令牌,就给下游发送多少数据。当令牌数消耗到0的时候,上游开始丢弃数据。但这两种策略在令牌数为0的时候有一点微妙的区别:onBackpressureDrop直接丢弃数据,不缓存任何数据;而onBackpressureLatest则缓存最新的一条数据,这样当上游接到新令牌的时候,它就先把缓存的上一条“最新”数据发送给下游。

发表在 IT | 标签为 , | 留下评论

client_max_body_size和client_body_buffer_size

最近发现给家里的nas上传大文件总是失败。于是看了nginx的日志发现:

2018/09/27 03:35:52 [error] 8#8: *14739 client intended to send too large body: 9247821 bytes, client: 115.214.xxx.xxx, server: 192.168.188.64, request: "POST /cgi-bin/filemanager/utilRequest.cgi?func=upload&type=standard&sid=ke3nzp1z&dest_path=%2Fhome%2FCamera%20Uploads%2FCamera&overwrite=0&progress=-home-Camera%20Uploads-Camera-IMG_20180922_143956.jpg HTTP/1.1", host: "www.xxxxx.com:81"

看到“too large body”就知道是http的请求体太小。然后就在nginx里增加配置,把请求体的最大大小设置为100M:

client_max_body_size 100m;

重启nginx后,在error.log里又看到下面的警告:

2018/09/27 05:33:37 [warn] 8#8: *364 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000000049, client: 115.214.xxx.xxx, server: 192.168.188.64, request: "POST /cgi-bin/filemanager/utilRequest.cgi?func=chunked_upload&sid=d8cqr8yi&upload_id=tmpqEaIWu&settime=1&mtime=1533434732&offset=0&dest_path=%2Fhome%2FCamera%20Uploads%2FCamera&overwrite=0&filesize=6596195&upload_root_dir=%2Fhome HTTP/1.1", host: "www.xxxxxx.com:81"

这个错误的意思是每个请求的请求体缓存太小了,缓存(内存)放不下上传的文件,就写到文件系统里。不调整这个缓存大小也不会影响功能。但是每次上传一张较大的照片,nginx就要写一次文件系统。在批量上传照片的场景,nginx的io太多了。

我把这个缓存设置为20M,对于手机拍的照片,20M足够。大于20M的问题就,就够就写到文件系统里呗。

nginx配置:

client_body_buffer_size 20m;

 

 

发表在 IT | 标签为 , , | 一条评论