这是一个创建于 2871 天前的主题，其中的信息可能已经有所发展或是发生改变。
tail -s 设置 X 秒扫描文本（单位秒），
但是，我的程序 1 秒内，有大量 IO 输出操作，另外加上 IO 延迟。有好多 LOG 输出延迟，影响看 LOG 的逻辑思路。
希望能满足后台启动程序的条件下，有更好实时显示 LOG 的方法
第 1 条附言 2017-12-05 20:27:01 +08:00
// 程序启动各种 Engine int Application::Init() { // Engine，打印各种 LOG // Loop在最后执行 this->Loop() } // 更新各种 Engine 逻辑 void Application::Loop() { while(true) { printf("loop") Engine.Loop(); // .... sleep(1) } } 逻辑上，Application::Init先于Application::Loop执行，那么Application::Init内触发LOG，应早于Application::Loopprint("loop")打印。 tail -f 实际情况系，Application::Init后小部的LOG，在比较固定地打印7次左右的printf("loop")才出现，
第 2 条附言 2017-12-05 20:43:00 +08:00
虽然可以去掉 printf("loop")，先绕过问题。
但是，这个问题难免再次出现，影响开发。
另外，感谢各位的回答
但是，这个问题难免再次出现，影响开发。
另外，感谢各位的回答
第 3 条附言 2017-12-05 21:19:53 +08:00
相同的程序，我对比加或不加nohup启动程序 log打印区别
不加nohup： 所有Application::Init里触发的log，都符合逻辑打印显示 加nohup: Application::Init里逻辑靠后（但在this->Loop前），小部分LOG，在几次printf("loop")后，才出现。此 时，vim log文体内容也是”小部分LOG，在几次printf("loop")后“
为了贴出log的对比，我加回了print("loop")，问题是.....什么就好了呀！！！！！我晕
 | 1 QAPTEAWH 2017-12-05 15:24:00 +08:00 你确定延迟不是在写入端产生的么... |
 | 2 GuiPulp 2017-12-05 15:32:51 +08:00 你居然对一个用了 20 多年的命令产生了怀疑 |
 | 3 YMB 2017-12-05 15:36:57 +08:00 你居然对一个用了 20 多年的命令产生了怀疑 |
 | 4 privil 2017-12-05 15:41:20 +08:00 大量的 IO 输出，你想想人眼能看过来么，我就问……不过 tail -f 的问题我总觉得在于 ssh 传输的延迟上面 |
 | 5 xlrtx 2017-12-05 15:47:26 +08:00 记得 python 有 buffer, 可以加-u |
 | 7 phttc 2017-12-05 15:52:53 +08:00 一个大池子，，，写入端 以 10L 每秒的速度 倒水，，而你读取端 每秒只能消化 5L，，，你说的延迟，，是你终端来不及输出，，并不会阻塞写入端的行为 |
 | 11 b821025551b 2017-12-05 16:02:44 +08:00 大量 IO，那不得刷屏么，我只好奇眼睛能看过来？ |
 | 12 shoaly 2017-12-05 16:04:46 +08:00 我就是楼上提到的 "眼睛看不过来的那种人" , 所以我一般都是直接用 vim 日志, 然后 :e 手动刷新... |
 | 13 Victor215 2017-12-05 16:13:45 +08:00 你可以测试一下你的硬盘 io 性能，是不是 io 有问题 time dd if=/dev/zero of=/test.dbf bs=32k count=1000 |
 | 15 acoder2013 2017-12-05 16:24:09 +08:00 @Victor215 tail -f 的内容才输出到 vim。。。 |
 | 16 lonenol 2017-12-05 16:29:10 +08:00 看啥日志需要这么实时... |
 | 17 vus520 2017-12-05 16:31:19 +08:00 你居然对一个用了 20 多年的命令产生了怀疑 |
 | 19 vincenttone 2017-12-05 17:59:59 +08:00 既然是局域网内 ssh，不考虑网络延迟，tail |
| 20 vincenttone 2017-12-05 18:02:44 +08:00 @vincenttone tail 应该是个死循环拿的，应该是写日志那头的延迟。 一般来讲，写日志不会产生就往里写，不然磁盘的 io 受不了，一般都是弄一个 buffer，buffer 满了且碰到了换行再往文件里 flush，然后继续指导进程退出做最后一次 flush。所以到底多久 flush 一次，取决于你的日志的量，如果是量很大的 log，条数也多，flush 也更频繁一些，不然最后那点日志可能要等进程退出才给 flush。 |
 | 21 chcx 2017-12-05 18:13:09 +08:00 本地磁盘 tailf 延迟 7-8s，你确定？ 文件几十 G ？不是初次 tailf ? |
 | 22 Tony8Finet 2017-12-05 19:41:41 +08:00 印象中有些程式会依 stdout 是否为 tty 模式，而决定是否要缓冲输出。是否是这样才会在 pipe 到 "tail -f" 时有所延迟? 最好是贴出你有问题的完整语句，或是追踪上游程式的输出行为，才好判断。 |
 | 23 WhoMercy 2017-12-05 19:59:48 +08:00 via Android 接上面倒水比出水快的：开多个水龙头 用 grep 过滤部分 log，多个终端显示不同标识的 log。 （都是同类 log 加随机标识或 ts ） |
 | 24 lzjamao OP @chcx 有两段逻辑，Application::Init</br> ``` // 程序启动各种 Engine int Application::Init() { // Engine，打印各种 LOG } ``` ``` // 更新各种 Engine 逻辑 Application::Loop() { while(true) { printf("loop") Engine.Loop(); // .... sleep(1) } } ``` |
 | 26 extreme 2017-12-05 21:01:48 +08:00 via iPhone  1 printf()… 个人感觉很有可能是 stdio 的 I/O buffer 导致的，可以尝试调用 output 函数后调用 fflush()。 |
| 27 extreme 2017-12-05 21:05:01 +08:00 via iPhone 最好能确认下 Engine LOG 的输出方式，用的是哪些函数。 理论上不是 tail 的问题，应该是 OUTPUT Buffer 的问题。 |
 | 28 shiny 2017-12-05 21:05:19 +08:00 1 以前写 Python 的时候也遇到过这个问题，flush 刷下就好了。 |
 | 29 bbsteel 2017-12-05 21:13:33 +08:00 via Android lz 一目百行的能力让人叹服 |
 | 30 phoneli 2017-12-05 21:24:23 +08:00 试试加一个 fflush |
 | 31 jasontse 2017-12-05 21:31:51 +08:00 via iPad 用内核提供的 inotify，再延迟就是你输出的问题。 |
 | 34 jy01264313 2017-12-06 01:59:07 +08:00 1 如果你是用 nohup 启动的命令，本身 stdout 是有缓存在的，可以试试 stdbuf -o0 nohup xxx & |
| 35 lzjamao OP @jy01264313 get it!!! :thumbsup: |
| 36 lzjamao OP |
Select Language