惊现 awk bug!-凯发app官方网站

凯发app官方网站-凯发k8官网下载客户端中心 | | 凯发app官方网站-凯发k8官网下载客户端中心
  • 博客访问: 1257808
  • 博文数量: 1140
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 11688
  • 用 户 组: 普通用户
  • 注册时间: 2018-03-07 16:26
个人简介

linux学习小标兵,专注linux资讯分享,技术文章分享

文章分类

全部博文(1140)

文章存档

2023年(97)

2022年(285)

2021年(265)

2020年(248)

2019年(213)

2018年(32)

我的朋友
最近访客
相关博文
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·

分类: linux

2023-05-03 22:33:42

导读 在对日志信息进行实时监控分析时,需要对日志中纳秒级的时间进行计算,逻辑比较简单:找出开始时间、结束时间,遇到结束时间后输出时间间隔。

在对日志信息进行实时监控分析时,需要对日志中纳秒级的时间进行计算,逻辑比较简单:找出开始时间、结束时间,遇到结束时间后输出时间间隔。
日志中的部分数据如下:

2016-01-30 19:37:30 1454153850967748663 remove alive file
2016-01-30 19:37:34 1454153854621122459 role change to fault

一开始写出来是这样的:

awk '
/remove alive file/ {
  start=$3
  printf "%6s: %dn","start",start
}
/role change to fault/ {
  end=$3;
  printf "%6s: %dn","end",end
  diff=(end-start)/1000^3
  printf "%6s: %0.9f(s)n","diff",diff
}'

输出结果看似就是我想要的:

 start: 1454153850967748608
   end: 1454153854621122560
  diff: 3.653373952(s)

有的朋友可能看到这个结果后就直接使用了,但是较真的我还是把输出结果和bc的结算结果比较了一下,没问题。

接下来我习惯性的到日志中把每个输出结果进行确认,略一看没什么不对的地方,仔细一对比,发现日志中纳秒级的时间被awk处理后竟然变了。为了进行确认,写了如下代码:

awk 'begin {
  printf " s == %-20sn","0x2fffffffffffff","13510798882111487"
  printf " x    %dn",0x2fffffffffffff,0x2fffffffffffff
  printf " x    %dn",13510798882111487,13510798882111487
  printf "---------------------------------------------n"
  printf " s == %-20sn","0x2ffffffffffffe","13510798882111486"
  printf " x    %dn",0x2ffffffffffffe,0x2ffffffffffffe
  printf " x    %dn",13510798882111486,13510798882111486
}'

输出结果如下:

0x2fffffffffffff == 13510798882111487   
      30000000000000    13510798882111488
      30000000000000    13510798882111488
---------------------------------------------
    0x2ffffffffffffe == 13510798882111486   
      2ffffffffffffe    13510798882111486
      2ffffffffffffe    13510798882111486

对应的二进制数值如下:

0x30000000000000: 11 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x2fffffffffffff: 10 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111
0x2ffffffffffffe: 10 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1110

发现awk的数值处理范围超过0x2ffffffffffffe(13510798882111486)就不不准确了(为了找这个临界值,费了一番功夫),他会把0x2fffffffffffff当成0x30000000000000,如果在awk中对0x2fffffffffffff进行减一计算,值没有任何变化,对0x2ffffffffffffe进行加法运算,加1和加2的结果都是0x30000000000000,但是awk又可以显示/处理更大的数值,从二进制结果中我也没看出有什么规律可循。有兴趣的可以深入源码层面研究下。

接下来,毅然放弃awk自身的计算功能,选择awk与bc的结合。于是,把代码修改成下面的样子:

awk '
/remove alive file/ {
  start=$3
  printf "%6s: %sn","start",start
阅读(439) | 评论(0) | 转发(0) |
0

上一篇:

下一篇:没有了

给主人留下些什么吧!~~
")); function link(t){ var href= $(t).attr('href'); href ="?url=" encodeuricomponent(location.href); $(t).attr('href',href); //setcookie("returnouturl", location.href, 60, "/"); }
网站地图