Mr Sunshine

发表于 |

在 Linux 多线程编程中，我们常常用 pthread_mutex_lock 来做线程间同步。当锁被占用时，当前线程会进入等待队列，直到锁被释放时才被唤醒。那么如果有多个线程同时在等待队列中，唤醒顺序是怎样的呢？文档中关于这点的解释比较简略：

If there are threads blocked on the mutex object referenced by mutex when pthread_mutex_unlock() is called, resulting in the mutex becoming available, the scheduling policy shall determine which thread shall acquire the mutex.

阅读全文 »
Mr Sunshine

发表于 |

最近项目中需要实现一个进程间共享的动态增长队列（单写多读），采用的是文件 mmap 的方案，有这么几点考虑：

  • 进程间可以共享 mmap 文件映射的内存页，省去额外的内核态到用户态的内存拷贝及可能的 IO 开销，且修改能“实时”被看到（页表已经建好时）
  • mmap 使用方便，就跟访问本地内存一样；而普通文件 read/write 处理动态增长的数据很麻烦
  • mmap 的数据能被 kernel 在后台自动同步回文件，解决了持久化的问题
  • 底层文件可以放在 tmpfs 上，这样性能就与正常的共享内存无异了（事实上 Linux 的 POSIX shared memory 就是这么实现的）

看起来不错，便捷、高效。鱼掌可以兼得，就是这么任性——直到上线后发现系统指标异常，一路怀疑到这里可能有性能问题，才知道事实并不尽然。

阅读全文 »
Mr Sunshine

发表于 |

原有系统及问题

我们原有的监控体系出于稳定和可靠性考虑，采用 mysql 存储，再加 python 开发分析与报警逻辑。好处是技术成熟，灵活可控，少坑。随着业务发展，这套方案逐渐难以应付更加复杂、多样化的监控需求。
监控数据往往都带有时间戳，其实就是一种典型时间序列数据，而这方面已经有很多专门的存储系统，如 opentsdb，influxdb。相比 mysql 这样的传统数据库，这类系统在存储、查询上针对时间序列数据都做了特别的优化。当然对于需要复杂查询的报表类数据，mysql 也有它的优势。为了支持丰富的监控指标，我们希望找到更加合理的存储方案。
此外，监控系统存在失效问题，而且在保持监控系统足够简单的前提下，很难同时保证低误报（假阳性）与不漏报（假阴性）告警。结合业务特点，比较稳妥的方式是人工与自动化监控相结合。告警与展示数据同源，所有的告警指标都能在监控页面上反映出来，这样一方面人工能做交叉验证，另外一方面收到告警信息之后也能方便地查看相关数据。

阅读全文 »
Mr Sunshine

发表于 | 分类于 |

忘记是在哪得知世间有这么一个奇人的存在。柳比歇夫，苏联生物学家，昆虫学家，数学家，哲学家⋯⋯柳比歇夫的遗产包括几个部分：有著作，探讨地蚤的分类、科学史、农业、遗传学、植物保护、哲学、昆虫学、动物学、进化论、无神论⋯⋯他的知识面有多广，是很难测度的。谈起英国的君主制度，他能够说出任何一个英国国王临朝秉政的细节；说到宗教，不管是古兰经、犹太传经，还是罗马教廷的源流、马丁·路德的学说、毕达哥拉斯学派的思想他都是如数家珍。他懂复变数理论、农业经济、罗·费歇的社会达尔文主义、古希腊古罗马⋯⋯

阅读全文 »