我正在尝试解决这个问题。场景是这样的：
具有 sqlite 后端的线程 tcp 套接字守护程序将信息存储在每个 IMEI ID 的唯一 sqlite2 文件中，每天存储在一个唯一的子目录中 ( pseudo: 2012/11/01/event_$imei.sqlite)。每天大约有3000个。如您所知，在接收和存储传入数据时，有一个阶段会创建和删除 sqlite 日志文件。
此应用程序仅写入今天或昨天的目录，（小）数据馈送最多可能需要 255 秒。因此，在 UTC 时间 00:00 会有一个阶段结束。在连接期间，可能会发生多次写入，网络链接保持打开状态，并且资产可以在连接打开时发送额外的新数据突发。根本没有显式锁定，sqlite 会自行处理，每个 IMEI 连接都是唯一的，因此永远不会有 2 个线程写入同一个文件。换句话说，控制守护进程不知道 sqlite 做什么，也不关心。
当然，我想将在给定时间点创建的 sqlite 日志文件的数量计算为 2 个总数。本质上它们是相似的，但从来没有真正相同，无论如何，它们只活了很短的时间。监控系统通常会及时计算当前文件的数量作为快照。这不是我正在寻找的指标。
那么如何才能以最小的负载足迹准确地进行这种计数呢？一定有什么窍门，毕竟是*nix。这里的系统是 Ubuntu 服务器，但我稍微喜欢（但不限于）通用解决方案。但请记住，随着时间的推移，将会创建新的目录，我应该能够遵循这一点，并且我希望它是易失性的（因此重新启动可以（必须）重置它）。
预先感谢您在任何方向上引导我。
答案1
inotify将是进行这种计数的一个很好的候选者，但正如怀疑的那样，这种方法并不理想并且容易出现竞争条件，最后我同意事实上我正在尝试用它来计算交易数量，所以它会最好在应用程序本身中执行此操作并进行计数。