亿贝(eBay) 上海招聘各种岗位 - 2019 年 11 月
内部推荐 联系: eGlhdGlhbkBlYmF5LmNvbQ==
以下是最新(2019/11/18)的职位列表: 具体 JD 见 https://www.ajinga.com/company-detail-new/5790/
you know you know, you know you don't know, and you don't know you don't know.
内部推荐 联系: eGlhdGlhbkBlYmF5LmNvbQ==
以下是最新(2019/11/18)的职位列表: 具体 JD 见 https://www.ajinga.com/company-detail-new/5790/
围绕这个图, 做几点解说:
从操作系统层面来说, 收到 TCP 的 SYN 之后, 放到 TCP SYN backlog 队列;
SYN backlog 长度由 /proc/sys/net/ipv4/tcp_max_syn_backlog 设置, 还有文章说最终值有几个因素共同决定;
如何查看一个监听端口的 SYN backlog 当前的队列长度? -> TODO ->
如果 SYN backlog 已经满了, 那么操作系统层面会自动丢弃接收到的 syn 包, 那么客户端以为对端没收到, 会继续尝试
当操作系统回复 syn+ack 之后, 对端返回 ack, 完成三次包握手, 这时, 这个连接编程 Established 的状态, 进入 listen backlog;
listen backlog 的长度由 listen 系统调用的参数决定, 在 Java 里由 ServerSocket(int port, int backlog)的第一个参数决定. java 默认是 50. Tomcat 7 里面由 Connector 参数 acceptCount 决定, 默认是 100;
如果这个 listen backlog 满了, OS 收到对端为了完成握手的 ack 时, 选择 ignore 这个 ack, 那么客户端会以为丢包, 会继续尝试发送 ack;
如何查看一个监听端口的 listen backlog 队列的当前长度? -> Linux -> ss -ltn 看 Send-Q 列
Tomcat 7 NIO 处理这些 socket 连接有 2 类 background 线程, 分别是 Acceptor 线程和 Poller 线程;
Acceptor 线程 通过 serverSock.accept() 方法接受新连接, 就是 listen backlog 里面已经建立的连接;
Acceptor 接受之后, 就把这个接受的 socket 送给 Poller 线程去处理;
Poller 线程把 socket 封装之后放入 TaskQueue;
Poller 线程还负责 从 socket 的 Channel 搬运数据到对应的 Buffer, 也就是负责 NIO 的 Selector 的处理任务;
Acceptor 线程和 Poller 线程的数量分别由 Tomcat Connector 的 acceptorThreadCount 和 pollerThreadCount 决定;
Tomcat 的 TaskQueue 是一个 LinkedBlockingQueue;
TaskQueue队列里的 Task 由 Executor 里的线程读取并执行;
TaskQueue队列里的 Task 由 Poller 放入;
TaskQueue的长度默认是 Int 的最大值, 不过基本不会放这么多, 如果TaskQueue的任务和在处理的超过 maxConnection 的值, Poller 就会决绝新的任务;
有时候我们浏览网页的时候, 想打印该页面, 可是打开打印预览, 发现和正常模式差别很大, 实际上是差很多. 这时候, 我们想以正常模式打印.
照抄: https://developers.google.com/web/tools/chrome-devtools/css/print-preview
本文是遇到像打印 oreilly 书的页面的时候, 出现的这个问题. https://learning.oreilly.com
let classes = [
"sbo-site-nav",
"sbo-reading-menu sbo-menu-top",
"interface-controls interface-controls-top",
"t-sbo-prev sbo-prev sbo-nav-top",
"t-sbo-next sbo-next sbo-nav-top",
"t-sbo-prev sbo-prev sbo-nav-bottom",
"t-sbo-next sbo-next sbo-nav-bottom",
"pagefoot t-pagefoot"
];
classes.forEach(function(className, i){
var ele = document.getElementsByClassName(className)[0];
if (ele) {
ele.parentNode.removeChild(ele);
}
});
var ctt = document.getElementById("sbo-rt-content");
ctt.setAttribute("style", "max-width:700px");
var ct = document.getElementsByClassName("annotator-wrapper")[0];
if (ct) {
ct.setAttribute("style", "font-size:180%!important");
}
最近一段时间, 经常发现生产环境上有些服务器的 CPU 使用率比其它高很多. 检查下来, 都不是我们自己的应用程序导致的, 细分下来有两种, 一种是 puppet agent 导致的(诊断 puppet agent 导致的 CPU 使用率非常高的问题), 另外一种就是 twagent 导致的.
首先, 通过 top -i -H 可以看到这个进程十分耗 CPU
然后, 通过 ps aux | grep twagent | less -w 可以看到它是怎么被启动的
xiatian 28604 0.0 0.0 10476 2084 pts/7 S+ 03:33 0:00 grep --color=auto twagent
root 31695 31.9 0.0 494272 11340 ? Ssl May22 60485:45 /opt/tripwire/agent/twagent --service.mode=true --service.type=SysV --agent.dir=/opt/tripwire/agent --plugins.dir=/opt/tripwire/agent/plugins --tools.dir="/opt/tripwire/agent/tools" --data.dir="/var/cache/tripwire" --lock.dir="/var/lock/tripwire" --log.dir="/var/log/tripwire" --spool.dir="/var/spool/tripwire"
然后, 执行 sudo strace -C -e trace=all -p 31794 (这里一定是要那个耗CPU 的线程, 不是进程号), 可以看到N多这样的 event:
statfs("/var/spool/tripwire", 0x7fe61a247450) = -1 ENOENT (No such file or directory)
statfs("/var/spool/tripwire", 0x7fe61a247450) = -1 ENOENT (No such file or directory)
然后执行 添加文件夹 (我这里是 root 起的这个进程, 所以用 root 加一个文件夹)
sudo mkdir /var/spool/tripwire
然后呢, 问题消失了
内部推荐 联系: eGlhdGlhbkBlYmF5LmNvbQ==
以下是最新(2019/09/09)的职位列表: 具体 JD 见 https://www.ajinga.com/company-detail-new/5790/