go 本身没有对外提供 goroutine 本地存储，而现实中，又经常需要在上下文中传递一些数据。使用 context 也是一种方式，但是要求在所有需要的地方都要传递，还是非常麻烦，而且有侵入性。偶然发现 go 已经提供了一个用于 profile 的 pprof label，可以在 goroutine 中携带一些数据。不过这个东西既然是用于 pprof 的，随意往里塞太多东西显然也不适合，还会对 pprof 产生干扰。所以，想办法只用其中一个 label，用一些黑科技把一个 map 放了进去，将影响降到最小。同时，pprof 包中已经有一些基于 context 访问处理 label 的逻辑，所以还要做一些兼容处理，避免被其覆盖。写了个简单的库：https://github.com/xiezhenye/gls ...继续阅读 (14)

go 本身没有对外提供 goroutine 本地存储，而现实中，又经常需要在上下文中传递一些数据。使用 context 也是一种方式，但是要求在所有需要的地方都要传递，还是非常麻烦，而且有侵入性。偶然发现 go 已经提供了一个用于 profile 的 pprof label，可以在 goroutine 中携带一些数据。不过这个东西既然是用于 pprof 的，随意往里塞太多东西显然也不适合，还会对 pprof 产生干扰。所以，想办法只用其中一个 label，用一些黑科技把一个 map 放了进去，将影响降到最小。同时，pprof 包中已经有一些基于 context 访问处理 label 的逻辑，所以还要做一些兼容处理，避免被其覆盖。写了个简单的库：https://github.com/xiezhenye/gls ...继续阅读 (7)

go 本身没有对外提供 goroutine 本地存储，而现实中，又经常需要在上下文中传递一些数据。使用 context 也是一种方式，但是要求在所有需要的地方都要传递，还是非常麻烦，而且有侵入性。 偶然发现 go 已经提供了一个用于 profile 的 pprof label，可以在 goroutine 中携带一些数据。不过这个东西既然是用于 pprof 的，随意往里塞太多东西显然也不适合，还会对 pprof 产生干扰。所以，想办法只用其中一个 label，用一些黑科技把一个 map 放了进去，将影响降到最小。同时，pprof 包中已经有一些基于 context 访问处理 label 的逻辑，所以还要做一些兼容处理，避免被其覆盖。 写了个简单的库：https://github.com/xiezhenye/gls ...继续阅读 (13)

最近负责的一个 Java 服务经常报 CPU 占用高的告警。于是乘着一次 CPU 高的时候，去用 JFR profile 了一下。（使用 JFR 对 Java 应用 profile 可以参考这篇文章：Java 应用在线性能分析和火焰图）。把数据拖回来用 JMC 打开一看，发现热点都在反射上：reflect_jfr图里排在最前面的都是反射相关的函数，而且实际都是同一个地方引入的。那里为了读取一个私有字段，使用了类似下面的代码：public class SomeSingleton {private Field field;public SomeSingleton() {field = someObject.getDeclaredField("fieldName");field.setAccessible(true);}private void someMethod() {Object value = field.get(someObject);}}这里已经 SomeSingleton 是个单例对象，field 只会反射一次，而且 setAccessible(true) 后已经避免了额外的访问权限检查。profile 出来的性能问题集中在 field.get(someObject) 上。于是去看了下这块 Java 反射的源代码，发现一个有意思的地方。Field.get 会创建并缓存一个 ...继续阅读 (15)

最近负责的一个 Java 服务经常报 CPU 占用高的告警。于是乘着一次 CPU 高的时候，去用 JFR profile 了一下。（使用 JFR 对 Java 应用 profile 可以参考这篇文章：Java 应用在线性能分析和火焰图）。把数据拖回来用 JMC 打开一看，发现热点都在反射上：reflect_jfr图里排在最前面的都是反射相关的函数，而且实际都是同一个地方引入的。那里为了读取一个私有字段，使用了类似下面的代码：public class SomeSingleton { private Field field; public SomeSingleton() { field = someObject.getDeclaredField("fieldName"); field.setAccessible(true); } private void someMethod() { Object value = field.get(someObject); } }这里已经 SomeSingleton 是个单例对象，field 只会反射一次，而且 setAccessible(true) 后已经避免了额外的访问权限检查。profile 出来的性能问题集中在 field.get(someObject) ...继续阅读 (6)

最近负责的一个 Java 服务经常报 CPU 占用高的告警。于是乘着一次 CPU 高的时候，去用 JFR profile 了一下。（使用 JFR 对 Java 应用 profile 可以参考这篇文章：Java 应用在线性能分析和火焰图 ）。把数据拖回来用 JMC 打开一看，发现热点都在反射上： 图里排在最前面的都是反射相关的函数，而且实际都是同一个地方引入的。那里为了读取一个私有字段，使用了类似下面的代码： public class SomeSingleton { private Field field; public SomeSingleton() { field = someObject.getDeclaredField("fieldName"); field.setAccessible(true); } private void someMethod() { Object value = field.get(someObject); } } 这里已经 SomeSingleton 是个单例对象，field 只会反射一次，而且 setAccessible(true) 后已经避免了额外的访问权限检查。profile 出来的性能问题集中在 field.get(someObject) 上。 […] ...继续阅读 (15)

LVS 是个很流行的高性能负载均衡程序。不过因为工作在 3-4 层，对被代理的后端来说，就只能看到 LVS 的源地址，看不到实际的用户来源 IP 地址了。所以 LVS 提供了一个 toa 内核模块，在后端安装后，可以从 TCP 头的扩展段里获取源 IP 地址。不过这只限于应用层面。系统层面的工具比如 netstat，tcpdump 等仍然只能看到 LVS 的源地址，想通过 tcpdump 抓包过滤或者分析实际来源地址就不行了。不过既然在 TCP 头里有这数据我们就还是可以利用。 tcpdump 输出的内容里，如果有 toa 扩展，会多出一截 Unknown Option。其中后面的 32bit 就是实际的源 IP。如 ... ack 1562404315, win 29, options [Unknown Option 20030390a0a0101], length 0 按 TOA 的结构： struct toa_data { __u8 opcode; __u8 opsize; __u16 […] ...继续阅读 (16)

LVS 是个很流行的高性能负载均衡程序。不过因为工作在 3-4 层，对被代理的后端来说，就只能看到 LVS 的源地址，看不到实际的用户来源 IP 地址了。所以 LVS 提供了一个 toa 内核模块，在后端安装后，可以从 TCP 头的扩展段里获取源 IP 地址。不过这只限于应用层面。系统层面的工具比如 netstat，tcpdump 等仍然只能看到 LVS 的源地址，想通过 tcpdump 抓包过滤或者分析实际来源地址就不行了。不过既然在 TCP 头里有这数据我们就还是可以利用。tcpdump 输出的内容里，如果有 toa 扩展，会多出一截 Unknown Option。其中后面的 32bit 就是实际的源 IP。如... ack 1562404315, win 29, options [Unknown Option 20030390a0a0101], length 0按 TOA 的结构：struct toa_data { __u8 opcode; __u8 opsize; __u16 port; __u32 ip; };这里的0a0a0101就是 10.10.1.1，3039就是源端口 12345。因为 TCP 头里多了扩展字段，所以 TCP 头中的data_offset就会大于 5（words）。用((tcp[12] & 0xf0)>>4) > 5这个条件过滤可以只处理带 ...继续阅读 (16)

LVS 是个很流行的高性能负载均衡程序。不过因为工作在 3-4 层，对被代理的后端来说，就只能看到 LVS 的源地址，看不到实际的用户来源 IP 地址了。所以 LVS 提供了一个 toa 内核模块，在后端安装后，可以从 TCP 头的扩展段里获取源 IP 地址。不过这只限于应用层面。系统层面的工具比如 netstat，tcpdump 等仍然只能看到 LVS 的源地址，想通过 tcpdump 抓包过滤或者分析实际来源地址就不行了。不过既然在 TCP 头里有这数据我们就还是可以利用。tcpdump 输出的内容里，如果有 toa 扩展，会多出一截 Unknown Option。其中后面的 32bit 就是实际的源 IP。如... ack 1562404315, win 29, options [Unknown Option 20030390a0a0101], length 0按 TOA 的结构：struct toa_data { __u8 opcode; __u8 opsize; __u16 port; __u32 ip; };这里的0a0a0101就是 10.10.1.1，3039就是源端口 12345。因为 TCP 头里多了扩展字段，所以 TCP 头中的data_offset就会大于 5（words）。用((tcp[12] & 0xf0)>>4) > 5这个条件过滤可以只处理带 ...继续阅读 (10)

centos 发行版是跟随 redhat 发行版的。在内核版本上比较保守。比如 centos 6.x 分支最高是 2.6.32 内核。虽然也会 backport 一些高版本的功能，但是总会需要的功能没有的情况。 不过 centos 的仓库里其实藏着一个 4.x 的内核。 在 centos 仓库里，有一个 centos-release-xen 的包，是 由 Centos、CitrixXen、Godaddy、Rackspace 共同维护的 Xen4CentOS 项目的一部分。 Xen4CentOS The project, while hosted at centos.org, is a collaboration between the Xen Project, the Citrix Xen open source teams, the CentOS developers, GoDaddy Cloud Operations team, Rackspace Hosting […] ...继续阅读 (14)

centos 发行版是跟随 redhat 发行版的。在内核版本上比较保守。比如 centos 6.x 分支最高是 2.6.32 内核。虽然也会 backport 一些高版本的功能，但是总会需要的功能没有的情况。不过 centos 的仓库里其实藏着一个 4.x 的内核。在 centos 仓库里，有一个centos-release-xen的包，是 由 Centos、CitrixXen、Godaddy、Rackspace 共同维护的 Xen4CentOS 项目的一部分。Xen4CentOS The project, while hosted at centos.org, is a collaboration between the Xen Project, the Citrix Xen open source teams, the CentOS developers, GoDaddy Cloud Operations team, Rackspace Hosting and members of the CentOS QA Team.这个包中其实并没有 xen 的工具，只是一个内核而已。安装这个包就能将 linux 内核升级到高版本。yum install centos-release-xen yum update重启，然后uname -r检查一下就会发现内核版本已经到了比如4.9.58- ...继续阅读 (13)

centos 发行版是跟随 redhat 发行版的。在内核版本上比较保守。比如 centos 6.x 分支最高是 2.6.32 内核。虽然也会 backport 一些高版本的功能，但是总会需要的功能没有的情况。不过 centos 的仓库里其实藏着一个 4.x 的内核。在 centos 仓库里，有一个centos-release-xen的包，是 由 Centos、CitrixXen、Godaddy、Rackspace 共同维护的 Xen4CentOS 项目的一部分。Xen4CentOS The project, while hosted at centos.org, is a collaboration between the Xen Project, the Citrix Xen open source teams, the CentOS developers, GoDaddy Cloud Operations team, Rackspace Hosting and members of the CentOS QA Team.这个包中其实并没有 xen 的工具，只是一个内核而已。安装这个包就能将 linux 内核升级到高版本。yum install centos-release-xen yum update重启，然后uname -r检查一下就会发现内核版本已经到了比如4.9.58- ...继续阅读 (9)

本文曾载于 有赞技术团队博客 https://tech.youzan.com/id_generator/ 为什么需要一个发号器 在使用数据库时，表的主键经常会使用数据库的自增（auto_increment）来产生。这当然很方便也很高效。但是使用自增也会带来一些麻烦。如果从一个数据库以外的地方，也就是发号器来产生全局唯一 ID，这些问题就可以得到解决，生活就可以更美好。 难以适应分片场景 在采用数据库分片时，如果使用数据库自增 ID，不同分片上会产生相同的 ID。单靠 ID 无法唯一标示一个对象，还需要额外加上分片字段才行。如果需要将 ID 用于其他对象的关联时，会麻烦很多。而采用发号器生成的是全局唯一的 ID，单靠 ID 就能实现关联。同时，这也使得采用 ID 作为分片字段成为可能。 主备切换时数据冲突 在 MySQL 集群发生主备切换时，异步复制无法确保主从完全同步。在备库开放写入后，备库上产生的自增 ID 会和尚未同步的主库上的数据冲突。这样一来，即使原来的主库恢复了，也无法重新加入集群。数据修复也变成了一件非常困难的事情。引入发号器以后，备库上插入的 ID 和原来主库上的 ID 是不会重复的。因此，未复制的新增数据和对这些新增数据的修改就不会在备库发生冲突。 网络异常时无法判断插入是否成功 当插入记录时，如果使用数据库自增 ID，在完成插入后，才能得到产生的 ID。如果在执行 ...继续阅读 (13)

本文曾载于 有赞技术团队博客https://tech.youzan.com/id_generator/为什么需要一个发号器在使用数据库时，表的主键经常会使用数据库的自增（auto_increment）来产生。这当然很方便也很高效。但是使用自增也会带来一些麻烦。如果从一个数据库以外的地方，也就是发号器来产生全局唯一 ID，这些问题就可以得到解决，生活就可以更美好。难以适应分片场景在采用数据库分片时，如果使用数据库自增 ID，不同分片上会产生相同的 ID。单靠 ID 无法唯一标示一个对象，还需要额外加上分片字段才行。如果需要将 ID 用于其他对象的关联时，会麻烦很多。而采用发号器生成的是全局唯一的 ID，单靠 ID 就能实现关联。同时，这也使得采用 ID 作为分片字段成为可能。主备切换时数据冲突在 MySQL 集群发生主备切换时，异步复制无法确保主从完全同步。在备库开放写入后，备库上产生的自增 ID 会和尚未同步的主库上的数据冲突。这样一来，即使原来的主库恢复了，也无法重新加入集群。数据修复也变成了一件非常困难的事情。引入发号器以后，备库上插入的 ID 和原来主库上的 ID 是不会重复的。因此，未复制的新增数据和对这些新增数据的修改就不会在备库发生冲突。网络异常时无法判断插入是否成功当插入记录时，如果使用数据库自增 ID，在完成插入后，才能得到产生的 ID。如果在执行语句时发生网络中断 ...继续阅读 (18)

本文曾载于 有赞技术团队博客https://tech.youzan.com/id_generator/为什么需要一个发号器在使用数据库时，表的主键经常会使用数据库的自增（auto_increment）来产生。这当然很方便也很高效。但是使用自增也会带来一些麻烦。如果从一个数据库以外的地方，也就是发号器来产生全局唯一 ID，这些问题就可以得到解决，生活就可以更美好。难以适应分片场景在采用数据库分片时，如果使用数据库自增 ID，不同分片上会产生相同的 ID。单靠 ID 无法唯一标示一个对象，还需要额外加上分片字段才行。如果需要将 ID 用于其他对象的关联时，会麻烦很多。而采用发号器生成的是全局唯一的 ID，单靠 ID 就能实现关联。同时，这也使得采用 ID 作为分片字段成为可能。主备切换时数据冲突在 MySQL 集群发生主备切换时，异步复制无法确保主从完全同步。在备库开放写入后，备库上产生的自增 ID 会和尚未同步的主库上的数据冲突。这样一来，即使原来的主库恢复了，也无法重新加入集群。数据修复也变成了一件非常困难的事情。引入发号器以后，备库上插入的 ID 和原来主库上的 ID 是不会重复的。因此，未复制的新增数据和对这些新增数据的修改就不会在备库发生冲突。网络异常时无法判断插入是否成功当插入记录时，如果使用数据库自增 ID，在完成插入后，才能得到产生的 ID。如果在执行语句时发生网络中断 ...继续阅读 (7)

有一台 etcd，突然出现了响应缓慢的情况。排查中发现，系统 CPU，带宽，IO，内存，rlimit 都还有很大余量。但是 ss 发现，端口的backlog 堆积了大量连接。 $ ss -lnt State Recv-Q Send-Q Local Address:Port Peer Address:Port ... LISTEN 745 65535 10.20.30.40:2379 *:* ... 但是看并没有 SYN_RECV 状态的连接存在。所以不像由于并发连接太多造成的来不及 accept，而是 etcd 本身处理 accept 的过程慢。统计 ESTABLISHED 连接数，发现数量总是大致在 10000 个左右。这个连接数看起来很整，怀疑是不是有什么特殊的限制。 于是去看 etcd 的代码，发现 etcdmain/etcd.go 中，启动 etcd 的代码里有 l = transport.LimitListener(l, int(fdLimit-reservedInternalFDNum)) 这个 LimitListener 限制了最多同时服务的客户端连接数，超过时就会等待已有连接退出。传入的 fdLimit 是获取的 open files rlimit 限制。reservedInternalFDNum 是保留的 […] ...继续阅读 (13)

有一台 etcd，突然出现了响应缓慢的情况。排查中发现，系统 CPU，带宽，IO，内存，rlimit 都还有很大余量。但是 ss 发现，端口的backlog 堆积了大量连接。$ ss -lnt State Recv-Q Send-Q Local Address:Port Peer Address:Port ... LISTEN 745 65535 10.20.30.40:2379 *:* ...但是看并没有 SYN_RECV 状态的连接存在。所以不像由于并发连接太多造成的来不及 accept，而是 etcd 本身处理 accept的过程慢。统计 ESTABLISHED 连接数，发现数量总是大致在 10000 个左右。这个连接数看起来很整，怀疑是不是有什么特殊的限制。于是去看 etcd 的代码，发现etcdmain/etcd.go中，启动 etcd 的代码里有l = transport.LimitListener(l, int(fdLimit-reservedInternalFDNum))这个 LimitListener 限制了最多同时服务的客户端连接数，超过时就会等待已有连接退出。传入的 fdLimit 是获取的 open files ...继续阅读 (14)

有一台 etcd，突然出现了响应缓慢的情况。排查中发现，系统 CPU，带宽，IO，内存，rlimit 都还有很大余量。但是 ss 发现，端口的backlog 堆积了大量连接。$ ss -lnt State Recv-Q Send-Q Local Address:Port Peer Address:Port ... LISTEN 745 65535 10.20.30.40:2379 *:* ...但是看并没有 SYN_RECV 状态的连接存在。所以不像由于并发连接太多造成的来不及 accept，而是 etcd 本身处理 accept的过程慢。统计 ESTABLISHED 连接数，发现数量总是大致在 10000 个左右。这个连接数看起来很整，怀疑是不是有什么特殊的限制。于是去看 etcd 的代码，发现etcdmain/etcd.go中，启动 etcd 的代码里有l = transport.LimitListener(l, int(fdLimit-reservedInternalFDNum))这个 LimitListener 限制了最多同时服务的客户端连接数，超过时就会等待已有连接退出。传入的 fdLimit 是获取的 open files ...继续阅读 (4)

在测试可用性的时候，经常需要模拟断网。这时候用 iptables 是比较方便的。但是如果想更方便一点，不用去敲那么长的命令会更好些。于是就写了个 ban_ip 脚本。 #!/bin/bash if [[ "$EUID" != 0 ]]; then echo "should run as root" exit 1 fi action="DROP" comment="ban_ip" cmd="$1" case "$cmd" in list) iptables -L -n | awk -v "cmt=$comment" '$0~cmt{print $4}' ;; add) ip="$2" if [[ -z "$ip" ]]; then echo "missing arg ip" exit 1 fi iptables -A […] ...继续阅读 (16)

在测试可用性的时候，经常需要模拟断网。这时候用 iptables 是比较方便的。但是如果想更方便一点，不用去敲那么长的命令会更好些。于是就写了个 ban_ip 脚本。#!/bin/bash if [[ "$EUID" != 0 ]]; then echo "should run as root" exit 1 fi action="DROP" comment="ban_ip" cmd="$1" case "$cmd" in list) iptables -L -n | awk -v "cmt=$comment" '$0~cmt{print $4}' ;; add) ip="$2" if [[ -z "$ip" ]]; then echo "missing arg ip" exit 1 fi iptables -A INPUT -s "$ip" -j "$action" -m comment --comment "$comment" ;; del) ip="$2" if [[ -z "$ip" ]]; then echo "missing arg ip" exit 1 fi iptables -D INPUT -s "$ip" -j "$action" -m comment --comment " ...继续阅读 (23)

在测试可用性的时候，经常需要模拟断网。这时候用 iptables 是比较方便的。但是如果想更方便一点，不用去敲那么长的命令会更好些。于是就写了个 ban_ip 脚本。#!/bin/bash if [[ "$EUID" != 0 ]]; then echo "should run as root" exit 1 fi action="DROP" comment="ban_ip" cmd="$1" case "$cmd" in list) iptables -L -n | awk -v "cmt=$comment" '$0~cmt{print $4}' ;; add) ip="$2" if [[ -z "$ip" ]]; then echo "missing arg ip" exit 1 fi iptables -A INPUT -s "$ip" -j "$action" -m comment --comment "$comment" ;; del) ip="$2" if [[ -z "$ip" ]]; then echo "missing arg ip" exit 1 fi iptables -D INPUT -s "$ip" -j "$action" -m comment --comment " ...继续阅读 (11)

在 linux 系统中，很多操作是需要 root 用户权限才能操作的。比如 chown，改变进程 uid，使用 raw socket 等等。要不就得用 sudo 提升权限，如果想让每个用户都能用特权来执行一个程序，配置管理和权限控制就很麻烦了。还有一个办法是使用粘滞位，通过 chmod +s，可以让一个 owner 为 root 的可执行文件再运行时具有 root 权限。在一些发型版中，ping 命令就是这么干的。给 ping 命令加上粘滞位以后，普通用户也可以使用这个命令通过 raw socket 发送 icmp 包了。不过这样一来，这个程序也就无所不能了。万一程序有啥漏洞，就容易造成严重后果。有没有办法只给这个程序开所需要的权限呢？其实是可以的。linux 有一套 capabilities 机制就是用来实现这个。 事实上，linux 本身对权限的检查就是基于 capabilities 的，root 用户有全部的 capabilities，所以啥都能干。如果想给一个可执行文件加上某个 capability，可以用 setcap 命令，如 setcap cap_net_raw=+ep ping 就可以给 ping 命令加上使用 raw socket 的权限。cap_net_raw 是 capability 的名字，后面是 mode，可以有 e：表示是否激活该 capability ...继续阅读 (12)

在 linux 系统中，很多操作是需要 root 用户权限才能操作的。比如 chown，改变进程 uid，使用 raw socket 等等。要不就得用 sudo 提升权限，如果想让每个用户都能用特权来执行一个程序，配置管理和权限控制就很麻烦了。还有一个办法是使用粘滞位，通过chmod +s，可以让一个 owner 为 root 的可执行文件再运行时具有 root 权限。在一些发型版中，ping 命令就是这么干的。给 ping 命令加上粘滞位以后，普通用户也可以使用这个命令通过 raw socket 发送 icmp 包了。不过这样一来，这个程序也就无所不能了。万一程序有啥漏洞，就容易造成严重后果。有没有办法只给这个程序开所需要的权限呢？其实是可以的。linux 有一套 capabilities 机制就是用来实现这个。事实上，linux 本身对权限的检查就是基于 capabilities 的，root 用户有全部的 capabilities，所以啥都能干。如果想给一个可执行文件加上某个 capability，可以用 setcap 命令，如setcap cap_net_raw=+ep ping就可以给 ping 命令加上使用 raw socket 的权限。cap_net_raw 是 capability 的名字，后面是 mode，可以有e：表示是否激活该 capabilityp：是否允许 ...继续阅读 (16)

在 linux 系统中，很多操作是需要 root 用户权限才能操作的。比如 chown，改变进程 uid，使用 raw socket 等等。要不就得用 sudo 提升权限，如果想让每个用户都能用特权来执行一个程序，配置管理和权限控制就很麻烦了。还有一个办法是使用粘滞位，通过chmod +s，可以让一个 owner 为 root 的可执行文件再运行时具有 root 权限。在一些发型版中，ping 命令就是这么干的。给 ping 命令加上粘滞位以后，普通用户也可以使用这个命令通过 raw socket 发送 icmp 包了。不过这样一来，这个程序也就无所不能了。万一程序有啥漏洞，就容易造成严重后果。有没有办法只给这个程序开所需要的权限呢？其实是可以的。linux 有一套 capabilities 机制就是用来实现这个。事实上，linux 本身对权限的检查就是基于 capabilities 的，root 用户有全部的 capabilities，所以啥都能干。如果想给一个可执行文件加上某个 capability，可以用 setcap 命令，如setcap cap_net_raw=+ep ping就可以给 ping 命令加上使用 raw socket 的权限。cap_net_raw 是 capability 的名字，后面是 mode，可以有e：表示是否激活该 capabilityp：是否允许 ...继续阅读 (12)

在有一次手误合错分支以后，就决定为 bash 提示符加上显示当前分支，以及提交状态，这样就可以更清楚地知道当前在哪个分支，以及是不是 commit 了，是不是 push 了。代码如下： function __git_prompt() { local s=$(git status -b --porcelain 2>/dev/null) if [[ -z "$s" ]]; then PS1="\h:\W \u$ " else local l=$(echo "$s"|wc -l) local br=$(echo "$s"|head) if [[ "${br%[ahead*}" != "$br" ]]; then local np=1 fi br="${br#\#\# }" br="${br%...*}" if [[ "$l" -gt 1 ]]; then local g="(git:\[$(tput […] ...继续阅读 (12)

在有一次手误合错分支以后，就决定为 bash 提示符加上显示当前分支，以及提交状态，这样就可以更清楚地知道当前在哪个分支，以及是不是 commit 了，是不是 push 了。代码如下：function __git_prompt() { local s=$(git status -b --porcelain 2>/dev/null) if [[ -z "$s" ]]; then PS1="\h:\W \u$ " else local l=$(echo "$s"|wc -l) local br=$(echo "$s"|head) if [[ "${br%[ahead*}" != "$br" ]]; then local np=1 fi br="${br#\#\# }" br="${br%...*}" if [[ "$l" -gt 1 ]]; then local g="(git:\[$(tput setaf 9)\]$br\[$(tput sgr0)\])" # dirty: red elif [[ -z "$np" ]]; then local g="(git:\[$(tput setaf 10)\]$br\[$(tput sgr0)\])" # clean: gr ...继续阅读 (15)

在有一次手误合错分支以后，就决定为 bash 提示符加上显示当前分支，以及提交状态，这样就可以更清楚地知道当前在哪个分支，以及是不是 commit 了，是不是 push 了。代码如下：function __git_prompt() { local s=$(git status -b --porcelain 2>/dev/null) if [[ -z "$s" ]]; then PS1="\h:\W \u$ " else local l=$(echo "$s"|wc -l) local br=$(echo "$s"|head) if [[ "${br%[ahead*}" != "$br" ]]; then local np=1 fi br="${br#\#\# }" br="${br%...*}" if [[ "$l" -gt 1 ]]; then local g="(git:\[$(tput setaf 9)\]$br\[$(tput sgr0)\])" # dirty: red elif [[ -z "$np" ]]; then local g="(git:\[$(tput setaf 10)\]$br\[$(tput sgr0)\])" # clean: gr ...继续阅读 (10)

最近在升级一个 java 应用时，在刚启动不久的时候发生了长时间的 gc，时间到了数秒，业务访问纷纷超时。 看了下 gc log： 2016-12-06T22:50:44.256+0800: 13.632: [GC pause (G1 Evacuation Pause) (young) Desired survivor size 13631488 bytes, new threshold 1 (max 15) - age 1: 27212320 bytes, 27212320 total 13.632: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 4890, predicted base time: 28.66 ms, remaining time: 71.34 ms, target pause time: 100.00 ms] […] ...继续阅读 (11)

最近在升级一个 java 应用时，在刚启动不久的时候发生了长时间的 gc，时间到了数秒，业务访问纷纷超时。看了下 gc log：2016-12-06T22:50:44.256+0800: 13.632: [GC pause (G1 Evacuation Pause) (young) Desired survivor size 13631488 bytes, new threshold 1 (max 15) - age 1: 27212320 bytes, 27212320 total 13.632: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 4890, predicted base time: 28.66 ms, remaining time: 71.34 ms, target pause time: 100.00 ms] 13.632: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 89 regions, survivors: 13 regions, predicted young region time: 6880.88 ms] 13.632: [G1Ergonomics ( ...继续阅读 (19)

最近在升级一个 java 应用时，在刚启动不久的时候发生了长时间的 gc，时间到了数秒，业务访问纷纷超时。看了下 gc log：2016-12-06T22:50:44.256+0800: 13.632: [GC pause (G1 Evacuation Pause) (young) Desired survivor size 13631488 bytes, new threshold 1 (max 15) - age 1: 27212320 bytes, 27212320 total 13.632: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 4890, predicted base time: 28.66 ms, remaining time: 71.34 ms, target pause time: 100.00 ms] 13.632: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 89 regions, survivors: 13 regions, predicted young region time: 6880.88 ms] 13.632: [G1Ergonomics ( ...继续阅读 (13)