• DHH在Railfconf2018中很自豪的说: “我们不招聘DBA,数据库不分库分表,只用一个主实例和其他slave, 怎么省事怎么来”

    其实就是 Basecamp 量小,业务不够复杂而已。

  • Ruby 的好朋友 -- jemalloc at 2018年11月08日

    这是用动态配置的方式让应用使用jemalloc吧,不想用时可以动态修改环境变量来控制。重新编译就没这个灵活性了。https://github.com/jemalloc/jemalloc/wiki/Getting-Started

  • 小规模数据可以这样:

    • 按照created_at分区(partition)。 例如三个月或一年一个区(看具体情况),这个最简单。数据分布情况对应用透明,最近的查询会自动落到最新的分区上(得带上分区字段的查询条件)。
    • 按照某字段分表。例如,可以是created_at,三个月或一年一个表(看具体情况),分表的情况由应用自己维护。在查询时先按照created_at计算一下是在哪个表,然后就直接从对应表拿数据。
  • Ruby 的好朋友 -- jemalloc at 2018年11月04日

    我看到的解释和你接近。 对于jemalloc持谨慎态度的人一般是两个原因:

    对于glibc malloc,它为了减少多线程环境下,申请内存所产生的锁竞争,将可分配的arena数量放的比较大,这导致了严重的内存碎片,也是因为它本身不是为多线程环境而设计的。 将MALLOC_ARENA_MAX调小,可以减轻这种情况,但是会使得线程间的竞争变得严重,内存碎片是降低了,但是性能会受影响。

  • Ruby 的好朋友 -- jemalloc at 2018年11月01日

    清洗是对于脏页(dirty page)进行的回收、合并等操作,是增加可用内存和减少碎片的操作,并不会有大量的内存移动之类的操作。 具体的过程有点复杂,可以参考下附录中的这篇文章

  • Ruby 的好朋友 -- jemalloc at 2018年11月01日
  • Ruby 的好朋友 -- jemalloc at 2018年10月31日

    已经在facebook上正常运行多年了,获得了广泛的认可。 这儿有个讨论帖 https://ruby-china.org/topics/35515

  • @ThxFly @Rei 感谢,我的说法有点问题。

  • Rails项目中ruby 版本和gemset大多可以自动切换,是不是痛点得据情况而定,一般在项目切换不频繁时,ruby版本不会是痛点。

    Docker的本质是对运行环境进行隔离,主要价值在于可保证各个运行环境的一致性。 对于环境不一致导致的问题,其实也可以考虑打造一个 和生产环境高度一致的测试环境,在测试环境中暴露问题。一般由于环境不一致导致的问题,其实不会太频繁。 如果导致方案整体不可用的情况, 则可能方案的选择上欠考虑或者开发环境和生产环境差别过大。这其实也可以解决环境不一致带来的潜在问题,当然得根据情况而定。

    在开发环境中用docker,除了环境一致性的优点外,其他的差不多可以视为缺点,带来反向价值。特别是对于像我等菜鸟,在开发时,经常拼错单词, 或者变量名取的不好要改,或者其他纰漏。这些小错在代码自动reload时,可以高效的解决。docker嘛,毕竟多了一层,差不多活生生把动态语言开发搞成了静态语言开发,改一下还要构建一下。是否值得选择,也得看自身情况。

    至于用了docker是否区分Rails的三个模式,我实在想不出两者有什么关联。不用docker也不妨碍只用一种模式吧,只要你想。 用了docker,有多个模式也不会有问题。 关联何在?

    以上是我的个人观点。

努力走向优雅、简洁、有逻辑地表达。