xguox (XguoX)

Ruby 的并发, 进程, 线程, GIL, EventMachine, Celluloid

xguox — Thu, 31 Aug 2017 10:33:11 +0800

RubyInside 最近推了一篇文章关于 Ruby 的并发, 加一点，删一点半翻译理解了一下，讲的都是基础没深入涉及原理，Ruby China 可以搜到过去相关的讨论也很多，更深层的也不少

关于并发与并行，前不久刚好真实发生。同事一行人去 Family Mart 买午餐，拿回来公司只有一个微波炉加热，在 Family Mart 有两个微波炉可以加热。也就是说，我们一行人一起去买午餐这是一个并发的程序，然后在 Family Mart 可以并行加热，但是，如果拿回公司的话，因为只有一个微波炉 (单核), 所以是只能一个接一个顺序执行。

Processes

串行执行

给一个 range, 转成 array 以后获取某个特定数字的 index

range = 0...100_000_000
number = 99_999_999
puts range.to_a.index(number)

➜ time ruby sequential.rb
99999999
ruby sequential.rb  4.04s user 0.56s system 98% cpu 4.667 total

执行这段代码大约耗时 5s, 利用了 99% 的 CPU(单核).

并行执行

通过分割 range 以及 Ruby 标准库中的 fork 方法，我们可以使用多个进程来执行上面的代码。

range1 = 0...50_000_000
range2 = 50_000_000...100_000_000
number = 99_999_999
puts "Parent #{Process.pid}"
fork { puts "Child1 #{Process.pid}: #{range1.to_a.index(number)}" }
fork { puts "Child2 #{Process.pid}: #{range2.to_a.index(number)}" }
Process.wait

➜ time ruby parallel.rb
Parent 5086
Child2 5100: 49999999
Child1 5099:
ruby parallel.rb  3.73s user 0.43s system 192% cpu 2.162 total

在多核 CPU 下，因为是把 range 对半拆开，所以，处理时间也快了。(数字有时候会有一些差距). Process.wait 是等待所有子进程完成的意思。

因为 GIL(global interpreter lock) 的存在，Ruby MRI 要利用 CPU 的核数唯一方法就是多进程。

Unicorn 就是通过 fork Rails 主进程衍生出多个 workers 来处理 HTTP 请求的。

这种多进程的方式最大优点是充分的利用多核 CPU, 且进程间不共享内存，因此 debug 也会容易一些，但是因为不共享内存，也就意味着内存消耗会变大。不过从 Ruby 2.0 开始使用系统的 COW(Copy On Write) 功能可以让 fork 的进程共享内存数据，只有在数据改变时候才复制数据。

Threads

Ruby 从 1.9 开始，线程的实现改为系统的 Native 线程，线程也由操作系统来完成调度。但是由于 GIL 的存在，同一时间一个 Ruby 进程只会有一个线程获取到 GIL 在跑。GIL 的存在意义就是线程安全，防止发生竞争条件，比起在数据结构上实现线程安全，GIL 的实现方式更为容易一些。

然而，其实，GIL 并不能完全阻止竞争条件的发生 = . =

Race Condition

# threads.rb
@executed = false
def ensure_executed
  unless @executed
    puts "executing!"
    @executed = true
  end
end
threads = 10.times.map { Thread.new { ensure_executed } }
threads.each(&:join) # 主线程等待子线程执行完毕再继续往后面跑, 比如在后面 p 'done'.

➜ ruby threads.rb
executing!
executing!
executing!
executing!

因为所有的线程共享一个 @executed 变量，并且读 (unless @executed) 写 (@executed = true) 操作又不是原子级的，也就是说当在某个线程中读这个 @executed 的值的时候，可能在别的线程已经把 @executed 给改写了。

GIL and Blocking I/O

GIL 不能让多个线程同时跑的话那还要多线程来干啥？其实还是有其高端的地方的。当线程遇到阻塞 I/O时就会释放 GIL 给到其他线程，比如 HTTP 请求，数据库查询，磁盘读写，甚至 sleep .

# sleep.rb
threads = 10.times.map do |i|
  Thread.new { sleep 1 }
end
threads.each(&:join)

➜ time ruby sleep.rb
ruby sleep.rb  0.09s user 0.03s system 9% cpu 1.146 total

十个线程执行 sleep 并不需要执行 10s. 线程执行到 sleep 执行权就会递交出去。相比起使用进程，线程更轻量一些，你甚至可以跑好几千个线程，处理阻塞 I/O 的操作也非常有用。但是，得要小心 race-conditions. 如果用了互斥锁 (Mutex) 来避免的话，又得注意死锁之类的出现。此外，线程之间的切换也是会有消耗的，所以，太多线程的话，会把时间都花在切换线程上了。

Puma 允许在每个进程中使用多线程，每个进程都有各自的线程池。大部分时候不会遇到上面说的竞争问题，因为每个 HTTP 请求都是在不同的线程处理。

EventMachine

EventMachine(EM) 是一个基于 Reactor 设计模式提供事件驱动 (event-driven) I/O 的 gem. 使用 EventMachine 的一个好处就是当处理大量 IO 操作的时候，不需要手工处理多线程，EM 可以在一个线程里边处理多个 HTTP 请求。

# em.rb
require 'eventmachine'

EM.run do
  EM.add_timer(1) do
    puts 'sleeping...'
    EM.system('sleep 1') { puts "woke up!" }
    puts 'continuing...'
  end
  EM.add_timer(3) { EM.stop }
end

➜ ruby em.rb
sleeping...
continuing...
woke up!

EM.system 模拟了 I/O 操作，并传入一个 block 作为回调，在等待回调期间可以继续响应别的操作 (事件). 但是复杂的系统因为要处理成功与失败的回调，而且可能回调内部嵌套着其他事件和回调，因此，很容易就会陷入 Callback Hell

Fiber

用的巨少，语法掌握了又忘，语法掌握了又忘 = . =

Fiber 是 Ruby 1.9 开始新增的轻量级运行单元。类似线程的暂停，恢复执行代码，最大的区别在于，线程是由于操作系统调度执行，而 Fiber 是由程序员自己处理调度。

# fiber.rb
fiber = Fiber.new do
  # 3. Fiber.yield 交出执行权, 并返回 1 (在这里)
  Fiber.yield 1
  # 5. 执行完毕, 返回 2
  2
end
# 1. fiber 创建以后不会执行里边的代码

# 2. 调用 resume 才会执行
puts fiber.resume

# 4. Go on here...
puts fiber.resume

# 5. fiber 已挂, 报错
puts fiber.resume

➜ ruby fiber.rb
1
2
dead fiber called (FiberError)

Fiber 结合 EventMachine 可以避免 Callback Hell

EventMachine.run do
  page = EM::HttpRequest.new('https://google.ca/').get       
  page.errback { puts "Google is down" }
  page.callback {
    url = 'https://google.ca/search?q=universe.com'
    about = EM::HttpRequest.new(url).get
    about.errback  { ... }
    about.callback { ... }     
  }
end

使用 Fiber 重写

EventMachine.run do
  Fiber.new {
    page = http_get('http://www.google.com/')     
    if page.response_header.status == 200
      about = http_get('https://google.ca/search?q=universe.com') 
      # ... 
    else 
      puts "Google is down"
    end  
  }.resume 
end
def http_get(url)
  current_fiber = Fiber.current
  http = EM::HttpRequest.new(url).get    
  http.callback { current_fiber.resume(http) }   
  http.errback  { current_fiber.resume(http) }    
  Fiber.yield
end

如果在 Fiber 中执行 I/O 操作，整个线程将会被这个 fiber 阻塞住，终归还是 GIL 的原因，其实并没有真正的解决并发的问题，而且 Fiber 的语法估计我后天又忘了。

Celluloid

Celluloid 借鉴了 Erlang 给 Ruby 带来了相似的 Actor 模型。每个 include 了 Celluloid 的类都变成了一个拥有自己的执行线程的 Actor.

class Sheen
  include Celluloid

  def initialize(name)
    @name = name
  end

  def set_status(status)
    @status = status
  end

  def report
    "#{@name} is #{@status}"
  end
end

irb(main):009:0> charlie = Sheen.new "Charlie Sheen"
=> #<Celluloid::Proxy::Cell(Sheen:0x3ffd8ac62b50) @name="Charlie Sheen">
irb(main):010:0> charlie.set_status "winning!"
=> "winning!"
irb(main):011:0> charlie.report
=> "Charlie Sheen is winning!"
irb(main):012:0> charlie.async.set_status "asynchronously winning!"
=> #<Celluloid::Proxy::Async(Sheen)>
irb(main):013:0> charlie.report
=> "Charlie Sheen is asynchronously winning!"

Celluloid::Proxy::Async 对象会截获方法的调用，然后保存到 Actor 并发对象的调用队列中，程序不必等待响应就可以往下执行 (异步). 每个并发对象都有一个自己调用队列，并且按顺序地一个接一个执行里边的方法调用。

Actor 之间通过发送消息来交流，而与 Erlang 的 Actor 模型最大的区别就在于 Erlang 的变量是不可变的, 而 Ruby 没有这个限制，所以，消息 (对象) 在传递的过程就可能会被修改了，除非 freeze?

https://engineering.universe.com/introduction-to-concurrency-models-with-ruby-part-i-550d0dbb970
https://www.jstorimer.com/blogs/workingwithcode/8085491-nobody-understands-the-gil
http://merbist.com/2011/02/22/concurrency-in-ruby-explained/
https://www.slideshare.net/mperham/actors-and-threads
http://practicingruby.com/articles/gentle-intro-to-actor-based-concurrency

题外话有没一起玩 Erlang 的小伙伴，贡献几篇笔记

Erlang weekly note 01
Erlang weekly note 02 - Module 模块
 Erlang weekly note 03 - Function 函数
 Erlang weekly note 04 - Recursion 递归
 Erlang weekly note 05 - Records & Maps 记录与键值对
 Erlang weekly note 06 - Exceptions 异常
 Erlang weekly note 07 - Processes 进程

ElasticSearch 的分数 (_score) 是怎么计算得出 (2.X & 5.X)

xguox — Mon, 19 Dec 2016 15:41:13 +0800

上次写了关于 Elasticsearch 如何分词索引, 接着继续写 Elasticsearch 怎么计算搜索结果的得分 (_score).

Elasticsearch 默认是按照文档与查询的相关度 (匹配度) 的得分倒序返回结果的。得分 (_score) 就越大，表示相关性越高。

所以，相关度是啥？分数又是怎么计算出来的？(全文检索和结构化的 SQL 查询不太一样，虽然看起来结果比较'飘忽', 但也是可以追根问底的)

在 Elasticsearch 中，标准的算法是 Term Frequency/Inverse Document Frequency, 简写为 TF/IDF, (刚刚发布的 5.0 版本，改为了据说更先进的 BM25 算法)

Term Frequency

某单个关键词 (term) 在某文档的某字段中出现的频率次数，显然，出现频率越高意味着该文档与搜索的相关度也越高

具体计算公式是 tf(q in d) = sqrt(termFreq)

另外，索引的时候可以做一些设置，"index_options": "docs" 的情况下，只考虑 term 是否出现 (命中), 不考虑出现的次数。

PUT /my_index
{
  "mappings": {
    "doc": {
      "properties": {
        "text": {
          "type":          "string",
          "index_options": "docs"
        }
      }
    }
  }
}

Inverse document frequency

某个关键词 (term) 在索引 (单个分片) 之中出现的频次。出现频次越高，这个词的相关度越低。相对的，当某个关键词 (term) 在一大票的文档下面都有出现，那么这个词在计算得分时候所占的比重就要比那些只在少部分文档出现的词所占的得分比重要低。说的那么长一句话，用人话来描述就是 "物以稀为贵", 比如，'的', '得', 'the' 这些一般在一些文档中出现的频次都是非常高的，因此，这些词占的得分比重远比特殊一些的词 (如'Solr', 'Docker', '哈苏') 占比要低，

具体计算公式是 idf = 1 + ln(maxDocs/(docFreq + 1))

Field-length Norm

字段长度，这个字段长度越短，那么字段里的每个词的相关度也就越大。某个关键词 (term) 在一个短的句子出现，其得分比重比在一个长句子中出现要来的高。

具体计算公式是 norm = 1/sqrt(numFieldTerms)

默认每个 analyzed 的 string 都有一个 norm 值，用来存储该字段的长度，

用 "norms": { "enabled": false } 关闭以后，评分时，不管文档的该字段长短如何，得分都一样。

PUT /my_index
{
  "mappings": {
    "doc": {
      "properties": {
        "text": {
          "type": "string",
          "norms": { "enabled": false }
        }
      }
    }
  }
}

最后的得分是三者的乘积 tf * idf * norm

以上描述的是最原始的针对单个关键字 (term)的搜索。如果是有多个搜索关键词 (terms)的时候，还要用到的 Vector Space Model

如果查询复杂些，或者用到一些修改了分数的查询，或者索引时候修改了字段的权重，比如 function_score 之类的，计算方式也就又更复杂一些。

Explain

看上去 TF/IDF 的算法已经一脸懵逼吓跑人了，不过其实，用 Explain 跑一跑也没啥，虽然各种开方，自然对数的，Google 一个科学计算器就是了。

举个例子

/*先删掉索引, 如果有的话*/
curl -XDELETE 'http://localhost:9200/blog'

curl -XPUT 'http://localhost:9200/blog/' -d '
{
  "mappings": {
     "post": {
        "properties": {
           "title": {
              "type": "string",
              "analyzer": "standard",
              "term_vector": "yes"
           }
        }
     }
  }
}'

存入一些文档 (Water 随手加进去测试的.)

curl -s -XPOST localhost:9200/_bulk -d '
{ "create": { "_index": "blog", "_type": "post", "_id": "1" }}
{ "title": "What is the best water temperature, Mr Water" }
{ "create": { "_index": "blog", "_type": "post", "_id": "2" }}
{ "title": "Water no symptoms" }
{ "create": { "_index": "blog", "_type": "post", "_id": "3" }}
{ "title": "Did Vitamin B6 alone work for you? Water?" }
{ "create": { "_index": "blog", "_type": "post", "_id": "4" }}
{ "title": "The ball drifted on the water." }
{ "create": { "_index": "blog", "_type": "post", "_id": "5" }}
{ "title": "No water no food no air" }
'

bulk insert 以后先用 Kopf 插件输出看一下，5 个文档并不是平均分配在 5 个分片的，其中，编号为 2 的这个分片里边有两个文档，其中编号为 0 的那个分片是没有分配文档在里面的。

接下来，搜索的同时 explain

原本输出的 json 即使加了 pretty 也很难看，换成 yaml 会好不少

curl -XGET "http://127.0.0.1:9200/blog/post/_search?explain&format=yaml" -d '
{
  "query": {
    "term": {
      "title": "water"
    }
  }
}'

输出如图 (json)

可以看到五个文档都命中了这个查询，注意看每个文档的 _shard

整个输出 yml 太长了，丢到最后面，只截取了其中一部分，如图，

返回排名第一的分数是 _score: 0.2972674, _shard(2),

"weight(title:water in 0) [PerFieldSimilarity], result of:" 这里的 0 不是 _id, 只是 Lucene 的一个内部文档 ID, 可以忽略。

排名第一和第二的两个文档刚好是在同一个分片的，所以跟另外三个的返回结果有些许不一样，主要就是多了一个 queryWeight, 里面的 queryNorm 只要在同一分片下，都是一样的，总而言之，这个可以忽略 (至少目前这个例子可以忽略)

只关注 fieldWeight, 排名第一和第二的的 tf 都是 1,

在 idf(docFreq=2, maxDocs=2) 中，docFreq 和 maxDocs 都是针对单个分片而言，2 号分片一共有 2 个文档 (maxDocs), 然后命中的文档也是两个 (docFreq).

所以 idf 的得分，根据公式，1 + ln(maxDocs/(docFreq + 1)) 是 0.59453489189

最后 fieldNorm, 这个 field 有三个词，所以是 1/sqrt(3), 但是按官方给的这个公式怎么算都不对，不管哪个文档。后来查了一下，说是 Lucene 存这个 lengthNorm 数据时候都是用的 1 byte 来存，所以不管怎么着都会丢掉一些精度。呵呵哒了 = . =

最后的最后，总得分 = 1 * 0.5945349 * 0.5 = 0.2972674.

同理其他的几个文档也可以算出这个得分，只是都要被 fieldNorm 的精度问题蛋疼一把。

完整结果太长了，贴个 gist
https://gist.github.com/xguox/077e18afe24f52f6e2b45efb0b4e304f

Elasticsearch 5 (Lucene 6) 的 BM25 算法

Elasticsearch 前不久发布了 5.0 版本, 基于 Lucene 6, 默认使用了 BM25 评分算法。

BM25 的 BM 是缩写自 Best Match, 25 貌似是经过 25 次迭代调整之后得出的算法。它也是基于 TF/IDF 进化来的。Wikipedia 那个公式看起来很吓唬人，尤其是那个求和符号，不过分解开来也是比较好理解的。

总体而言，主要还是分三部分，TF - IDF - Document Length

IDF 还是和之前的一样. 公式 IDF(q) = 1 + ln(maxDocs/(docFreq + 1))

f(q, D) 是 tf(term frequency)

|d| 是文档的长度，avgdl 是平均文档长度。

先不看 IDF 和 Document Length 的部分，变成 tf * (k + 1) / (tf + k),

相比传统的 TF/IDF (tf(q in d) = sqrt(termFreq)) 而言， BM25 抑制了 tf 对整体评分的影响程度, 虽然同样都是增函数，但是，BM25 中，tf 越大，带来的影响无限趋近于 (k + 1), 这里 k 值通常取 [1.2, 2], 而传统的 TF/IDF 则会没有临界点的无限增长。

而文档长度的影响, 同样的，可以看到，命中搜索词的情况下，文档越短，相关性越高，具体影响程度又可以由公式中的 b 来调整，当设值为 0 的时候，就跟之前 'TF/IDF' 那篇提到的 "norms": { "enabled": false } 一样，忽略文档长度的影响。

综合起来，

k = 1.2

b = 0.75

idf * (tf * (k + 1)) / (tf + k * (1 - b + b * (|d|/avgdl)))

最后再对所有的 terms 求和。就是 Elasticsearch 5 中一般查询的得分了。

http://opensourceconnections.com/blog/2015/10/16/bm25-the-next-generation-of-lucene-relevation/

What Is Relevance?

From:

Elasticsearch 的分数 (_score) 是怎么计算得出
 Elasticsearch 5.X(Lucene 6) 的 BM25 相关度算法

使用 Ruby 处理大型 CSV 文件

xguox — Wed, 26 Oct 2016 22:24:36 +0800

原文来自：http://dalibornasevic.com/posts/68-processing-large-csv-files-with-ruby
译文链接：http://xguox.me/processing-large-csv-with-ruby.html

早些个月看到的一篇，翻译了以后好久其实也好像没啥机会正式用到，今天刚好要处理一个 100+ MB 的 CSV 文件，想起了这篇。跑的时候顺手打开监视器看看内存使用什么的，个别方法都跑到 6G + 内存了 Σ( ° △ °|||)︴

处理大文件是一项非常耗内存的操作，有时候甚至会跑光服务器上的物理内存和虚拟内存。下面来看看使用 Ruby 来处理大型 CSV 文件的几种方式，同时测试一下这几种方式的内存消耗以及性能。

准备测试用的 CSV 数据文件。

在开始之前，先准备一个拥有一百万行的 CSV 文件 data.csv(大约 75mb) 用于测试。

# generate_csv.rb
require 'csv'
require_relative './helpers'

headers = ['id', 'name', 'email', 'city', 'street', 'country']

name    = "Pink Panther"
email   = "pink.panther@example.com"
city    = "Pink City"
street  = "Pink Road"
country = "Pink Country"

print_memory_usage do
  print_time_spent do
    CSV.open('data.csv', 'w', write_headers: true, headers: headers) do |csv|
      1_000_000.times do |i|
        csv << [i, name, email, city, street, country]
      end
    end
  end
end

内存及时间的消耗

上面这个脚本需要引用到 helpers.rb 脚本，helpers.rb 定义了两个 helper 方法来测量并打印出内存以及时间的消耗情况。

# helpers.rb
require 'benchmark'

def print_memory_usage
  memory_before = `ps -o rss= -p #{Process.pid}`.to_i
  yield
  memory_after = `ps -o rss= -p #{Process.pid}`.to_i

  puts "Memory: #{((memory_after - memory_before) / 1024.0).round(2)} MB"
end

def print_time_spent
  time = Benchmark.realtime do
    yield
  end

  puts "Time: #{time.round(2)}"
end

执行并生成 CSV 文件：

$ ruby generate_csv.rb
Time: 7.14
Memory: 4.79 MB

不同的机器输出结果也不尽相同，不过，幸运的是，得益于 garbage collector (GC) 回收已使用过的内存，这个 Ruby 进程耗掉的内存 (4.79MB) 并不是很夸张。同时生成的数据文件如图为 74MB.

CSV.read

# parse1.rb
require_relative './helpers'
require 'csv'

print_memory_usage do
  print_time_spent do
    csv = CSV.read('data.csv', headers: true)
    sum = 0

    csv.each do |row|
      sum += row['id'].to_i
    end

    puts "Sum: #{sum}"
  end
end

执行结果：

$ ruby parse1.rb

Sum: 499999500000
Time: 21.3
Memory: 1277.07 MB

惊人的超过 1GB 内存消耗啊。

CSV.read 源码

 # File csv.rb, line 1750
def read
  rows = to_a
  if @use_headers
    Table.new(rows)
  else
    rows
  end
end

CSV.parse

# parse2.rb
require_relative './helpers'
require 'csv'

print_memory_usage do
  print_time_spent do
    content = File.read('data.csv')
    csv = CSV.parse(content, headers: true)
    sum = 0

    csv.each do |row|
      sum += row['id'].to_i
    end

    puts "Sum: #{sum}"
  end
end

执行结果：

$ ruby parse2.rb
Sum: 499999500000
Time: 21.88
Memory: 1362.89 MB

可以看到，内存消耗的比刚刚第一个脚本还略多，差距大概就是刚好 CSV 文件大小。

CSV.parse 源码

# File csv.rb, line 1293
def self.parse(*args, &block)
  csv = new(*args)
  if block.nil?  # slurp contents, if no block is given
    begin
      csv.read
    ensure
      csv.close
    end
  else           # or pass each row to a provided block
    csv.each(&block)
  end
end

CSV.new

# parse3.rb
require_relative './helpers'
require 'csv'

print_memory_usage do
  print_time_spent do
    content = File.read('data.csv')
    csv = CSV.new(content, headers: true)
    sum = 0

    while row = csv.shift
      sum += row['id'].to_i
    end

    puts "Sum: #{sum}"
  end
end

执行结果：

$ ruby parse3.rb
Sum: 499999500000
Time: 16.89
Memory: 76.72 MB

这次结果可以看到，因为只是在内存中加载了整个文件内容，所以内存的消耗大概就是文件的大小 (74MB), 而处理时间也快了不少。当我们只是想逐行逐行的操作而不是读取要一次过读取一整个文件时候，这种方法非常奏效。

通过 IO 对象一行一行解析

虽然有了很大的进步，但是，使用 IO 文件对象还可以做得更好。

# parse4.rb
require_relative './helpers'
require 'csv'

print_memory_usage do
  print_time_spent do
    File.open('data.csv', 'r') do |file|
      csv = CSV.new(file, headers: true)
      sum = 0

      while row = csv.shift
        sum += row['id'].to_i
      end

      puts "Sum: #{sum}"
    end
  end
end

执行结果：

$ ruby parse4.rb
Sum: 499999500000
Time: 13.78
Memory: 2.64 MB

仅仅用了 2.64MB, 速度也稍稍又快了一些。

CSV.foreach

# parse5.rb
require_relative './helpers'
require 'csv'

print_memory_usage do
  print_time_spent do
    sum = 0

    CSV.foreach('data.csv', headers: true) do |row|
      sum += row['id'].to_i
    end

    puts "Sum: #{sum}"
  end
end

执行结果跟上一个差不多：

$ ruby parse5.rb
Sum: 499999500000
Time: 15.54
Memory: 2.62 MB

CSV.foreach 源码

# File csv.rb, line 1118
def self.foreach(path, options = Hash.new, &block)
  return to_enum(__method__, path, options) unless block
  open(path, options) do |csv|
    csv.each(&block)
  end
end

升级 Ubuntu 12.04 后的杯具

xguox — Sat, 28 Apr 2012 19:48:02 +0800

昨晚把 ubuntu 升级到了 12.04，结果全部项目都杯具了，运行时候 passenger 都是报错如下：

Error message:
libmysqlclient_r.so.16: cannot open shared object file: No such file or directory - /home/xguox/.rvm/gems/ruby-1.9.2-p290@rails/gems/mysql2-0.3.11/lib/mysql2/mysql2.so

百度谷歌也没找着办法，也试着自己 down 了 libmysqlclient.so.16 这个文件，依旧无果，有大神帮托下嚜？thx~

搭建 ruby-china，半成功吧.

xguox — Sat, 24 Mar 2012 01:18:54 +0800

全程跟 github 下面的那个帮助文档差不多，也看了下@bindiry 之前的一个帖。同样是

sudo rake assets:precompile

的那个错误，不过我试过重装 MongoDB 就通过了。重装是直接用 ubuntu 的安装包安装的 And then

执行 thin start -O -C config/thin.yml这步报错： /home/xguox/.rvm/rubies/ruby-1.9.3-p125/lib/ruby/1.9.1/psych.rb:229:in `initialize': No such file or directory - config/thin.yml (Errno::ENOENT)

缺少那个 thin.yml？没明白，不过直接跳过接后面的步骤都 OK，然后用 rails s 也能打开，不过端口是在 0.0.0.0:3000，localhost：3000 被我的另外一个 nginx 部署的项目用了。

另外，每次执行命令貌似都会冒出： DEPRECATION WARNING: ActiveSupport::Memoizable is deprecated and will be removed in future releases,simply use Ruby memoization pattern instead. 貌似不影响吧。

routes 莫名的出错

xguox — Tue, 06 Mar 2012 14:01:05 +0800

localhost:3000/login 显示下面的错误提示。

Routing Error
No route matches {:action=>"destroy", :controller=>"sessions"}
Try running rake routes for more information on available routes.

请问这是什么情况？SessionsController 有定义 destroy 这个 action 呀 PS:这是我跟着 Ruby on Rails Tutorial 写的一个小项目。StackOverflow 上貌似也有人提问，不过回答好像没看明白。貌似没正解

rake routes 如下：

   users         GET            /users(.:format)                users#index
                   POST              /users(.:format)          users#create
   new_user GET    /users/new(.:format)      users#new
  edit_user GET    /users/:id/edit(.:format) users#edit
       user GET    /users/:id(.:format)      users#show
            PUT    /users/:id(.:format)      users#update
            DELETE /users/:id(.:format)      users#destroy
   sessions POST   /sessions(.:format)       sessions#create
new_session GET    /sessions/new(.:format)   sessions#new
    session DELETE /sessions/:id(.:format)   sessions#destroy
     signup        /signup(.:format)         users#new
      login        /login(.:format)          sessions#new
     logout DELETE /logout(.:format)         sessions#destroy
       help        /help(.:format)           pages#help
      about        /about(.:format)          pages#about
    contact        /contact(.:format)        pages#contact
       home        /home(.:format)           pages#home
     comics        /comics(.:format)         pages#comics
  animation        /animation(.:format)      pages#animation
       root        /                         pages#home

routes.rb 如下

resources :sessions, only: [:new, :create, :destroy]
match '/signup',  to: 'users#new'
match '/login',  to: 'sessions#new'
match '/logout', to: 'sessions#destroy', via: :delete

Rspec 各种无法运行，求帮托

xguox — Fri, 02 Mar 2012 02:46:10 +0800

如何卸载 Nginx

xguox — Thu, 01 Mar 2012 16:28:29 +0800

Ubuntu 下用 sudo passenger-install-nginx-module 安装的 Nginx 如何卸载掉，因为同时装了 Nginx 和 Apache 会老占用端口，要自己 CUT 掉进程。 PS:为嘛貌似更多人推 Nginx 而不是 Apache？个人感觉 Apache 更友好些。

很诡异的博客

xguox — Fri, 09 Dec 2011 12:33:53 +0800

http://blog.xdite.net ~~deleted~~

xguox (XguoX)

Ruby 的并发, 进程, 线程, GIL, EventMachine, Celluloid

Processes

串行执行

并行执行

Threads

EventMachine

Fiber

Celluloid

ElasticSearch 的分数 (_score) 是怎么计算得出 (2.X & 5.X)

Term Frequency

Inverse document frequency

Field-length Norm

最后的得分是三者的乘积 tf * idf * norm

Explain

Elasticsearch 5 (Lucene 6) 的 BM25 算法

Related:

使用 Ruby 处理大型 CSV 文件

准备测试用的 CSV 数据文件。

内存及时间的消耗

CSV.read

CSV.parse

CSV.new

通过 IO 对象一行一行解析

CSV.foreach

升级 Ubuntu 12.04 后的杯具

搭建 ruby-china，半成功吧.

sudo rake assets:prec﻿om﻿pile

routes 莫名的出错

Rspec 各种无法运行，求帮托

如何卸载 Nginx

很诡异的博客

sudo rake assets:precompile